| 01:58 | <Domenic_> | If people at W3C members ask me who their AC rep is for TAG elections, where can I find that out? |
| 02:03 | <heycam> | Domenic_, not sure where the canonical place to look is, but https://www.w3.org/2000/09/dbwg/orgs lists organisations, and if you click on an org it will tell you which person is in the AC |
| 02:06 | <Domenic_> | why does my w3c member account password never fucking work... |
| 02:07 | <heycam> | it's a member only page, if that matters |
| 02:11 | <Domenic_> | yeah but i signed up as a member and was able to access the members area before... but every time i have to reset my password several times. |
| 02:13 | <Domenic_> | nope, won't let me log in, no matter how many times i reset my password. |
| 02:16 | <Domenic_> | thanks though heycam. maybe support will email me back and i'll be able to do that then... |
| 02:16 | <heycam> | hopefully the page should work for those people looking to bug their AC reps |
| 04:00 | <TabAtkins> | Woo, finally got Bikeshed's install flow corrected. |
| 04:01 | <TabAtkins> | Nothing like having to completely reset your system for getting your project's installation flow correct. |
| 06:30 | <crocket> | hi |
| 06:30 | <crocket> | I have an internet explorer question. |
| 06:30 | <crocket> | IE has MSSelection objects. |
| 06:30 | <crocket> | Does anyone know where to find a reference to MSSelection object? |
| 06:31 | <crocket> | If I invoke any method in MSSelection, IE10 says "800a025e error" |
| 08:06 | <MikeSmith> | hsivonen: there's an XHTML validation case that others on the W3C team have told me they think the behavior runs against user expectations; which is, http://validator.nu/?doc=http://tantek.com/XHTML/Test/xhtmlwithoutprolog.xml |
| 08:07 | <MikeSmith> | the argument is that since that document has an XHTML1 Strict doctype and not a <!doctype html> doctype, it should by default be validated against the XHTML1 schema |
| 08:08 | <MikeSmith> | instead of against the XHTML5 schema, as the current behavior causes it to be |
| 08:09 | <MikeSmith> | I see the reason for the current behavior is that for all docs served with an XML MIME type, the validator sniffs the root namespace to make a determination about which schema to use for validation -- before it every gets around to looking at the doctype |
| 08:13 | <MikeSmith> | I think I can change the code to maybe have it skip the step of automatically using the XHTML5 if it finds the http://www.w3.org/1999/xhtml namespace, but not sure whether you think that it should or whether the existing behavior is in fact actually better (from a user perspective) |
| 09:03 | <tantek> | oh hello MikeSmith - wow someone found that old test case? |
| 09:04 | <tantek> | I'm not sure it has any relevance these days. |
| 09:04 | <hsivonen> | MikeSmith: the validator behavior is intentional in this case, IIRC |
| 09:05 | <hsivonen> | MikeSmith: HTML5 allows legacy doctypes for entity ref compat |
| 09:05 | <hsivonen> | MikeSmith: I'd like to keep this behavior |
| 09:06 | <MikeSmith> | tantek: it's one of the few xhtml documents on the Web that are actually served as xml |
| 09:06 | <hsivonen> | MikeSmith: in general, we should move even more towards validating according to current specs unless the validator user asks for an old thing |
| 09:06 | <MikeSmith> | hsivonen: ok |
| 09:06 | <MikeSmith> | hsivonen: yeah, that makes sense |
| 09:53 | <jgraham> | annevk-cloud: Do you have time to look at https://critic.hoppipolla.co.uk/5fd7fd9b?review=368 ? |
| 10:28 | <zcorpan> | hsivonen: do you mean we should do that for text/html also? |
| 10:43 | <hsivonen> | zcorpan: I thought that was the plan, but we just haven't gotten around to it |
| 10:43 | <zcorpan> | hsivonen: ok. sounds good to me |
| 10:51 | <zcorpan> | is there a way to invoke http://www.whatwg.org/html#extracting-json without the user starting a drag operation? |
| 10:52 | <zcorpan> | there are no other xrefs, so i guess not :-| |
| 10:56 | <Ms2ger> | OH: "how to use frameset in html5 .. I want to divide the page into parts so that the bottom of my page has a framset for menu and top frame has a marquee goin on .." |
| 11:23 | hsivonen | wonders where Ms2ger overhears conversations like that |
| 11:24 | <Ms2ger> | #html5 |
| 11:24 | <hsivonen> | this template element stuff keeps turning up interesting cases that don't work according to someone's expectations |
| 11:25 | <hsivonen> | I hope this <template> feature actually ends up being useful |
| 11:27 | <jgraham> | Yeah, so the whole web components thing has turned into an enormous gamble |
| 11:27 | <Ms2ger> | I hope you don't mind if I don't put any money on it |
| 11:27 | <jgraham> | It is being built on shaky foundations |
| 11:28 | <jgraham> | And if the whole thing collapses, we will be left building on top of the rubble for evermore |
| 11:28 | <MikeSmith> | zcorpan: yeah we should do it for text/html too. Like hsivonen said, I think that's been the plan. I think actually had I had been pushing for that before but somewhere between then and now I'd forgotten that's what we'd agreed on. |
| 11:28 | <jgraham> | (this is true of most things ofc, but this particular project feels more like trying to build a castle on sand, whereas usually we just build beach huts) |
| 11:31 | <zcorpan> | jgraham: or we make a new castle in 5 years |
| 11:32 | <jgraham> | zcorpan: Yeah, but partially on top of the ruins of a previous castle |
| 11:33 | <jgraham> | On the other hand, I guess that has historical precedent in real castles |
| 11:33 | <jgraham> | So maybe this was an ill-chosen metaphor |
| 11:34 | jgraham | will now try to imagine the whole Web Components project as if it was an episode of Grand Designs |
| 11:34 | <MikeSmith> | "You have deprecated simplicity and ease in favour of complexity and difficulty. You wanted to create something more flexible but ended up causing trouble." |
| 11:34 | <marcosc> | so, I'm going to try playing this hand at the w3c: http://w3c.github.io/manifest/releases/FPWD.html |
| 11:34 | <marcosc> | too much? |
| 11:34 | <marcosc> | it's a FPWD |
| 11:35 | <hsivonen> | ridiculing the <center> post is as easy reaction, but centering in CSS is, indeed, much less obvious |
| 11:35 | <hsivonen> | s/as/an/ |
| 11:36 | <MikeSmith> | I think there's a lot of wisdom in that post. At least a useful facsimile of wisdom. |
| 11:38 | <zcorpan> | marcosc: i think it's missing something, maybe something should be blinking |
| 11:39 | <marcosc> | good idea |
| 11:39 | <jgraham> | "you'll eventually have to create a policing department who's job is to oversee adherence to bureaucracy" - clearly marks him out as a nutter. I mean the policy police have existed for *years*. |
| 11:40 | <MikeSmith> | he's not a nutter for not knowing that the things he predicted already exist |
| 11:40 | <MikeSmith> | that makes him more of a .. prophet |
| 11:40 | <jgraham> | Well |
| 11:41 | <marcosc> | :) |
| 11:41 | <jgraham> | I could certainly get behind carving the bit you quoted in stone |
| 11:42 | <zcorpan> | it would be fun to actually carve the html spec in stone |
| 11:42 | <jgraham> | Maybe erecting as a statue it at the offices of major vendors as a lesson in humility and the folly of designing for the 1% (e.g. for the Gmail team or framework authors only) |
| 11:45 | <MikeSmith> | there's also the fact that the official whatwg theme song is "Whatever Happened To The Teenage Dream?" and that guy titled his message "What happened?" |
| 11:45 | <MikeSmith> | that seems more than coincidental |
| 12:09 | <smaug____> | hayato_: would be nice to get that shadow dom event propagation issue fixed (before implementation lands to Gecko) |
| 12:24 | <smaug____> | hmm, when will I have time to read the stream API proposal |
| 12:25 | <smaug____> | it looks mostly wrong |
| 12:29 | <jgraham> | smaug____: Which one? |
| 12:29 | <smaug____> | https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm |
| 12:29 | <smaug____> | mostly wrong == I don't like it :) |
| 12:32 | <smaug____> | using events for streams tend to make APIs simpler |
| 12:32 | <smaug____> | Promises are better for things which happen once |
| 12:32 | <jgraham> | There is a second propossl |
| 12:33 | <jgraham> | https://github.com/whatwg/streams |
| 12:34 | <marcosc> | smaug____: can you please send that feedback to public-webapps |
| 12:34 | <marcosc> | we are trying to get the two proposals to merge |
| 12:35 | <smaug____> | I need to find time to write something... |
| 12:35 | <smaug____> | some kind of dummy proposal |
| 12:36 | <smaug____> | based on events |
| 12:36 | <smaug____> | promises are hip and all, but that doesn't mean they should be used for everything |
| 12:38 | <marcosc> | BLAAASSPPHEEEMMYYY!!!! next you will be saying that ServiceWorkers are not going to cure cancer! PFFF |
| 12:39 | <smaug____> | :) |
| 12:39 | <smaug____> | ServiceWorkers might be something cool but still haven't seen a spec |
| 12:40 | <marcosc> | you must have faith in ServiceWorkers. You need to find your own inner/personal ServiceWorker. |
| 12:40 | <marcosc> | Only then will you be "offline" |
| 12:40 | marcosc | hummmmmsss.... service service service worker... hummmmmm |
| 12:41 | smaug____ | tries hard. Offline for lunch. |
| 13:11 | <zcorpan> | Hixie: about EventSource/Worker/SharedWorker using utf-8 query encoding, it occurred to me that XHR already uses utf-8. gecko uses utf-8 for EventSource. presto uses utf-8 for all of these |
| 13:12 | <zcorpan> | Hixie: while blink seems to use the document's encoding for all (including XHR) |
| 13:17 | <zcorpan> | marcosc: http://www.youtube.com/watch?v=GP9k1pn9Mo0 |
| 13:21 | <annevk> | Ms2ger: next time please make the change yourself |
| 13:21 | <annevk> | Ms2ger: generating 3 tweets for removing "in" is somewhat annoying |
| 13:27 | <hayato_> | smaug___: I left a comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887. We need a counter example. |
| 14:19 | <annevk> | Hixie: ancestor-or-self -> inclusive ancestor |
| 14:19 | <annevk> | Hixie: DOM uses and defines that |
| 14:20 | annevk | finally gets to a message from jgraham this morning |
| 14:23 | <annevk> | jgraham: reviewed |
| 14:23 | <jgraham> | annevk: Thanks! |
| 15:18 | <annevk> | What the fuck? DOM Parsing just got published over objections? |
| 15:20 | <Ms2ger> | As expected |
| 15:20 | <Ms2ger> | We should probably leave the WG |
| 15:38 | <annevk> | I'm not in the WG |
| 15:38 | <annevk> | I'm only on the TAG |
| 15:38 | <Ms2ger> | Well, Mozilla is |
| 15:39 | <jgraham> | Since webapps is probably the most productive group at W3C, leaving would be a bit controversial, I would think |
| 15:40 | <jgraham> | Even though crazy stuff sometimes happens |
| 16:18 | <tyoshino> | smaug___: something like WebSocket's onmessage? |
| 16:19 | <smaug____> | tyoshino: ? |
| 16:19 | <tyoshino> | re: Streams |
| 16:19 | <smaug____> | ah, right |
| 16:19 | <smaug____> | so yes, something like that |
| 16:20 | <smaug____> | basically that one doesn't need to add the callback all the time to read data |
| 16:20 | <tyoshino> | i'm a co-author of https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm |
| 16:20 | <smaug____> | with events one just adds an event listener |
| 16:20 | <smaug____> | with promises one needs to get a promise |
| 16:20 | <smaug____> | and implementation needs to buffer data |
| 16:20 | <Domenic_> | smaug____: events have proven pretty problematic in Node |
| 16:21 | <Domenic_> | you lose data |
| 16:21 | <smaug____> | eh |
| 16:21 | <Domenic_> | also, of course, the usual problem where anyone can trigger the event |
| 16:22 | <Domenic_> | which will mess up any consumers as they get an inconsistent view from the streams internal state machine vs. the random event being triggered |
| 16:22 | <smaug____> | random? |
| 16:22 | <smaug____> | if you're the only one who has access to the Stream object, no one else can trigger events |
| 16:22 | <smaug____> | and there is always event.isTrusted |
| 16:22 | <Domenic_> | sure, but then it's a pretty useless stream object |
| 16:24 | <smaug____> | promise based is hard for more than one consumer |
| 16:25 | <Domenic_> | promise-based is generally a dead-end |
| 16:25 | <Domenic_> | although i am not sure multi-consumer would be my concern |
| 16:26 | <Domenic_> | but i see what you mean in the sense that it's very convenient for naive cases involving one consumer and one producer, and very bad for realistic cases of pipe chains and graphs. |
| 16:27 | <Domenic_> | i feel like some kind of generator of promises or similar might work well as a reactive observable, not sure... but definitely not for I/O streams. |
| 16:29 | <smaug____> | what is wrong with events? |
| 16:29 | <Domenic_> | the data loss problem is a huge one |
| 16:29 | <smaug____> | developers know events usually quite well, and the fit in to stream handling rather well |
| 16:29 | <smaug____> | what data loss |
| 16:29 | <Domenic_> | https://github.com/whatwg/streams/blob/master/Requirements.md#you-must-not-lose-data |
| 16:30 | <smaug____> | Domenic_: sounds like a bug in the API user |
| 16:31 | <Domenic_> | it was a huge footgun in node |
| 16:31 | <Domenic_> | of the kind that is easily avoided |
| 16:31 | <smaug____> | if the API is event based, it is up to the API user to buffer the data, if needed |
| 16:31 | <Domenic_> | right |
| 16:31 | <Domenic_> | which is really annoying |
| 16:31 | <smaug____> | how so |
| 16:31 | <Domenic_> | almost unusably annoying |
| 16:31 | <smaug____> | in normal cases it isn't needed |
| 16:31 | <Domenic_> | because buffering logic is very hard to get right |
| 16:31 | <Domenic_> | especially if you want to use that buffering to inform backpressure |
| 16:31 | <smaug____> | usually you just get the data and process it immediately |
| 16:31 | <Domenic_> | that is pretty rarely true in the Node ecosystem's experience |
| 16:32 | <Domenic_> | async processing is extremely common |
| 16:32 | <smaug____> | without that you easily force implementations to buffer data |
| 16:32 | <Domenic_> | as is piping to data sources of varying speed |
| 16:32 | <smaug____> | and effectively cause memleaks |
| 16:32 | <Domenic_> | e.g. reading from disk, piping to TCP socket |
| 16:32 | <Domenic_> | it's not a memleak to hold data in memory until the TCP socket tells you it's ready to accept more data |
| 16:33 | <smaug____> | but if you don't accept that data, implementation is forced to keep the mem around |
| 16:33 | <smaug____> | events force application to decide what to do with the API |
| 16:33 | <smaug____> | and there is no data loss |
| 16:33 | <Domenic_> | events force applications to build real streams on top of them |
| 16:33 | smaug____ | doesn't understand this data loss argument at all |
| 16:33 | <Domenic_> | streams which are usually much more leaky than a well-implemented buffering and backpressure-aware stream |
| 16:34 | <Domenic_> | the number of flat-out buggy implementations of BufferedStream in the Node ecosystem pre-0.6 was staggering. |
| 16:34 | <Domenic_> | it was our second-biggest problem implementing a node API two years ago. |
| 16:35 | <Domenic_> | rolling that logic into core was one of the best decisions node made. |
| 16:36 | <Domenic_> | events are convenient for certain use cases |
| 16:36 | <smaug____> | events are good for stream like cases |
| 16:36 | <Domenic_> | i would say streams will be consumed 80% of the time with pipe, 15% of the time with events (e.g. passive data listening), and 5% of the time directly |
| 16:36 | <smaug____> | input events from user form a stream |
| 16:37 | <Domenic_> | https://github.com/whatwg/streams/blob/master/Requirements.md#you-must-have-a-way-of-passively-watching-data-pass-through-a-stream |
| 16:39 | smaug____ | tries to understand https://github.com/whatwg/streams |
| 16:39 | <smaug____> | looks like it might be ok for server side |
| 16:40 | <Domenic_> | smaug____: would love to understand what you see different about server vs. client side |
| 16:40 | <smaug____> | if I read https://github.com/whatwg/streams correctly (looking at the examples), it has some sync processing |
| 16:41 | <smaug____> | while (readable.readableState === "readable") { and such |
| 16:41 | <Domenic_> | right, because data is often available from I/O sources synchronously. (Very often, in fact.) |
| 16:41 | <annevk> | reply from chaals on public-webapps o_O |
| 16:41 | <smaug____> | but for the Web we can't bring such APIs |
| 16:41 | <Domenic_> | https://github.com/whatwg/streams/blob/master/Requirements.md#you-must-not-force-an-asynchronous-reading-api-upon-users |
| 16:41 | <Domenic_> | smaug____: why not? |
| 16:41 | <smaug____> | eh |
| 16:42 | <smaug____> | sync APIs are from hell |
| 16:42 | <Domenic_> | that's not true |
| 16:42 | <tyoshino> | blocking API is bad, but this is not. |
| 16:42 | <Domenic_> | right, blocking vs. sync is the right distinction. |
| 16:42 | <Domenic_> | this is not blocking |
| 16:42 | <smaug____> | aha |
| 16:42 | <smaug____> | well, so it is not sync |
| 16:42 | <tyoshino> | WHATWG Streams returns data only when data is available for reading synchronously |
| 16:42 | <Domenic_> | while loops are scary that way |
| 16:42 | <tyoshino> | doesn't wait |
| 16:42 | <smaug____> | it is just reading the buffered sutff |
| 16:43 | <tyoshino> | it makes some sense |
| 16:43 | <Domenic_> | i agree at first glance while loops make people think "eek i'm gonna lock the browser" |
| 16:43 | <tyoshino> | yes |
| 16:43 | <smaug____> | ok, so it is just like having event.data |
| 16:43 | <Domenic_> | but usually the loop will only happen for two or three iterations |
| 16:43 | <Domenic_> | (numbers pulled out of hat) |
| 16:43 | <smaug____> | but ok, I should skip that loop |
| 16:44 | <Domenic_> | let me open an issue to explain that better |
| 16:44 | <Domenic_> | smaug____: are you on GitHub? |
| 16:45 | <smaug____> | no |
| 16:46 | <smaug____> | for reading data events should still make api usage simpler |
| 16:47 | <tyoshino> | i understand cumbersomeness of callback setting every time. but it's kind of smart way to use a Promise for telling the producer that we (consumer) are ready. |
| 16:47 | <Domenic_> | I agree, although I think that use case is pretty small. Thus ReadableStreamWatcher and WritableStreamWatcher. |
| 16:48 | <Domenic_> | i have used stream events mainly for progress notification. |
| 16:49 | <Domenic_> | other people tell me they use it for logging |
| 16:49 | <smaug____> | tyoshino: but if you forget to set the callback, implementation is forced to buffer all the data |
| 16:49 | <smaug____> | and if you happen to keep the stream object alive, you buffer forever |
| 16:49 | <smaug____> | (web apps are good at accidentally keeping objects alive) |
| 16:49 | <Domenic_> | if nobody reads, backpressure is applied |
| 16:50 | <Domenic_> | (but yes, the already-buffered data is still there.) |
| 16:50 | <tyoshino> | back pressure tells the producer not to work. there are some producers like WebSocket which doesn't understand backpressure |
| 16:51 | <smaug____> | yes |
| 16:51 | <smaug____> | so what happens when data is sent from the server |
| 16:51 | <Domenic_> | yeah, so you will be unable to wrap WebSocket in a stream yourself with backpressure support |
| 16:51 | <smaug____> | stream needs to buffer forever? |
| 16:51 | <Domenic_> | but WebSocketStream itself should support backpressure |
| 16:51 | <smaug____> | with events we don't have similar problem |
| 16:52 | <smaug____> | it is up to the application to decide what to do with the data |
| 16:52 | <Domenic_> | but with events you haven't really solved any problems |
| 16:52 | <tyoshino> | event delivery can also be queued |
| 16:52 | <Domenic_> | you have just forced the API user to solve the problem themselves |
| 16:52 | <tyoshino> | so, the situation is not so different between them |
| 16:52 | <Domenic_> | tyoshino: interesting, how so? |
| 16:53 | <tyoshino> | i mean, that even with event |
| 16:53 | <smaug____> | tyoshino: events will be handled when event loop spins |
| 16:53 | <tyoshino> | data can be queued forever if the loop is busy |
| 16:53 | <annevk> | Domenic_: you could argue that forcing the API user to solve the problem is a lower-level primitive ;) |
| 16:53 | <Domenic_> | annevk: yeah, I did have that thought :) |
| 16:53 | <smaug____> | well, events will be dispatched when event loop spins |
| 16:53 | <Domenic_> | annevk: but I think we already have EventTarget |
| 16:53 | <smaug____> | tyoshino: loop is busy doing what? |
| 16:53 | <smaug____> | that is not a realistic case |
| 16:55 | <tyoshino> | in event case |
| 16:55 | <tyoshino> | data arrival speed vs. event handler processing speed |
| 16:55 | <tyoshino> | Promises: |
| 16:56 | <tyoshino> | data arrival speed vs. read() invocation speed |
| 16:56 | <smaug____> | in event case the data is still in the event waiting for to be processed. promise case just needs to buffer it all and hope that someone will process the data |
| 16:58 | <tyoshino> | you just need to keep read() (and waitForReadable in WHATWG ver) called |
| 16:59 | <smaug____> | but you must read all the time |
| 16:59 | <smaug____> | but if you don't, buffer just increases and increases |
| 16:59 | <tyoshino> | yes. but even for event, if the app is not fast enough compared to data delivery |
| 16:59 | <smaug____> | with events the dispatch is there whether or not you have listeners |
| 17:00 | <tyoshino> | the app needs to drop data or keep the event loop waiting until the handler process the delivered data |
| 17:00 | <tyoshino> | that's what i meant by "busy" |
| 17:01 | <tyoshino> | drop data is done by "noop in handler" or "no handler" |
| 17:01 | <smaug____> | tyoshino: in event case if app can't process data fast enough, it can just cache it if needed |
| 17:01 | <smaug____> | but the data isn't buffered anywhere magically |
| 17:01 | <Domenic_> | there's nothing magic about the data buffering |
| 17:02 | <Domenic_> | the algorithm is very transparent |
| 17:02 | <tyoshino> | you are concerned about implicitness of buffering? |
| 17:02 | <smaug____> | web devs don't read specs |
| 17:02 | <smaug____> | tyoshino: yes |
| 17:02 | <Domenic_> | streams are largely *about* buffering |
| 17:02 | <Domenic_> | otherwise just use event emitters |
| 17:02 | <smaug____> | web apps tend to keep random objects alive longer than needed |
| 17:03 | <tyoshino> | once everything is rebuilt to respect backpressure, it would be fine. but yes, i understand your concern |
| 17:04 | <tyoshino> | but as Domenic said, we're introducing a buffer |
| 17:04 | <tyoshino> | convenient buffer |
| 17:04 | <smaug____> | a buffer sure, but not with unlimited size |
| 17:05 | <smaug____> | buffer would be the size of .data in an event |
| 17:05 | <smaug____> | and sure, there can be several events alive simultaneously |
| 17:06 | <tyoshino> | there should be kinda consumption pressure to reader? |
| 17:07 | <tyoshino> | thinking |
| 17:07 | <Domenic_> | i don't think such limits really make sense for ambitious web applications. |
| 17:08 | <Domenic_> | we can't pretend to be a real platform if we withhold tools from programmers for fear of them hurting themselves |
| 17:08 | <Domenic_> | people will just have to build an unlimited real stream on top of the limited one. |
| 17:10 | <smaug____> | it is not fear, but an issue which has come up often |
| 17:10 | <smaug____> | web apps keeping objects alive longer than needed. Google Reader was the best app to leak everything. |
| 17:11 | <smaug____> | Facebook used to leak tons of stuff until few weeks ago |
| 17:11 | <smaug____> | (well, that was some new feature which introduced such leak. but it was there for months ) |
| 17:12 | <Domenic_> | i guess this seems like a larger issue and i am not really sure of the general sentiment regarding it |
| 17:12 | <Domenic_> | of giving web developers the power to allocate memory |
| 17:12 | <Domenic_> | but i am for such capabilities, msyelf |
| 17:16 | <tyoshino> | filed a bug to think about it more |
| 17:17 | <jgraham> | Well of course web developers can allocate memory already |
| 17:17 | <jgraham> | The situation we want to avoid is one where it is easy to create a leak by accident |
| 17:17 | <jgraham> | Which is distressingly common already |
| 17:18 | <jgraham> | (not that I have a particular opinion on how this relates to stream APIs) |
| 17:19 | <jgraham> | (see the discussion about moving DOM nodes between documents for an example of where the design of the platform makes accidential leaks of large objects easy) |
| 17:27 | <annevk> | "design" |
| 17:36 | <jgraham> | annevk: I didn't say "intelligent design" |
| 17:38 | <annevk> | that's biology, oh wait |
| 17:59 | <Hixie> | jgraham: we tried building a castle on concrete, but people didn't want to buy into the whole thing at once (xbl2). at least people are implementing the piecemeal castle. |
| 18:00 | <Ms2ger> | Or implementing something |
| 18:22 | <annevk> | Hixie: by concrete you mean XML? :P |
| 18:22 | <Hixie> | not just XML, but yes |
| 18:22 | <Hixie> | (remember, xbl2 predates xhtml2) |
| 18:23 | <Hixie> | but i think that is one of the big differences |
| 18:23 | <Hixie> | i mean, basing web comp on html is what led to hsivonen's comments which led to this conversation :-) |
| 18:57 | <Hixie> | TabAtkins: you around? (i might need new selectors) |
| 19:54 | <Hixie> | ok i posted a big proposal for how to do keyboard focus to https://www.w3.org/Bugs/Public/show_bug.cgi?id=23475 |
| 20:13 | <hober> | polyglot rec v. note poll closes today, and is currently 18 rec v. 11 note: https://www.w3.org/2002/09/wbs/40318/polyglot-status-preference-poll/ |
| 20:16 | <Ms2ger> | And 351 abstain |
| 20:17 | <hober> | indeed :) |
| 20:17 | Ms2ger | feels sad he wasted a minute of his life looking at that |
| 20:44 | <Domenic_> | soooo is there a way for people who aren't members of w3c organizations to see who the w3c members' AC reps are? |
| 20:49 | <Ms2ger> | Maybe https://www.w3.org/services/list-audit/query?queryList=w3c-ac-forum |
| 20:52 | <Domenic_> | nope, 401 |
| 20:52 | <Ms2ger> | Oh, I thought that was public |
| 20:56 | <Ms2ger> | Looks like the official list is [MO] https://www.w3.org/Member/ACList |
| 21:00 | <Domenic_> | good times |
| 21:02 | <tantek> | henri, MikeSmith, and similarly for adding new rel values to http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions ? (e.g. rel=syndication was added 2013-04-25 and seems to produce an error in both validator.nu and validator.w3.org) |
| 21:56 | <zcorpan> | i like Hixie's comment on the poll |
| 22:07 | <zewt> | grr cors |
| 22:07 | <zewt> | "Wildcards cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true." |
| 22:08 | <zewt> | and some script is setting credentials to work around some browser bug (even though there are no credentials), so now I have to jump hoops on the server side |
| 22:09 | <Hixie> | zcorpan: unfortunately looks like the wg will be wasting lots more time on this, given the way the vote is going |
| 22:10 | <jgraham> | I wonder if I should change my comment to "I think polls are a stupid way to make technical decisions, as is clearly demonstrated by the organisation-level block voting which will determine the outcome of this poll" |
| 22:10 | <jgraham> | It won't make any difference of course |
| 22:11 | <zcorpan> | is yucca just trolling or am i missing something? |
| 22:14 | <Domenic_> | ^ i too find this confusing |
| 22:40 | <Hixie> | it's the respect that i get from my fellow editors, as shown in https://bugzilla.mozilla.org/show_bug.cgi?id=946370#c8, that really makes me love the w3c |
| 22:43 | <SteveF> | hixie: reap what you sow big fella |
| 22:49 | <Hixie> | lol |
| 22:54 | <Hixie> | i like the dichotomy of the dismissive tone in that bug comment where he implies it wouldn't work, and the accusatory tone in his tweet where he implies its so good it ends anonymity |
| 22:54 | <Hixie> | it's, rather |
| 23:01 | <hober> | it's weird that msft are voting yes in a block on that poll |
| 23:02 | <Hixie> | in a block? i thought you only got one vote per organisation |
| 23:03 | <Hixie> | oh it's by individual, interesting |
| 23:03 | <hober> | well, a bunch of them have voted, and they've all voted yes. i'm only presuming that was coordinated. |
| 23:03 | <Hixie> | i guess microsoft really want a TR spec for polywhatsits! |
| 23:03 | <Hixie> | i'm not sure what that means, but that's apparently not an issue! :-) |
| 23:04 | <Hixie> | (i tried reading those arguments, but i couldn't find anywhere that actually defined what it meant for this to be normative) |
| 23:04 | <Hixie> | we should have more polls, i'd forgotten how fun they are |
| 23:06 | <hober> | more polls? are you a polyglutton for punishment? |
| 23:07 | <hober> | oooof, that was awful. sorry |
| 23:07 | <Hixie> | not w3c polls, those are about boring things |
| 23:07 | <Hixie> | i mean we should have whatwg polls! |
| 23:08 | <Hixie> | like, "should the whatwg html standard be on the whatwg Recommendation track or the whatwg Specification track?" |
| 23:08 | <gsnedders> | WHATWG Note track. |
| 23:09 | <gsnedders> | Because recommendations are meaningless, because web developers don't care. |
| 23:11 | <Hixie> | we could also have votes about what topics to use in examples. |
| 23:11 | <gsnedders> | Hixie: Would you not just use a veto to ensure they were cats? |
| 23:11 | <Hixie> | many of the examples aren't about cats! |
| 23:11 | <Hixie> | and only one of my cats actually has her picture in the spec |
| 23:12 | <Hixie> | (mind you there's 26 mentions of my other cat) |
| 23:17 | <Domenic_> | i <3 the whatwg spec examples |
| 23:36 | <annevk> | Domenic_: get jQuery to get you a Member account |
| 23:36 | <annevk> | Domenic_: I think marcosc might have a list of all AC email addresses too somewhere |
| 23:36 | <annevk> | Domenic_: we spammed some people last TAG election... |
| 23:37 | <gsnedders> | DEATH TO SPAMMERS. |
| 23:37 | <hober> | when does tag voting close? |
| 23:37 | <annevk> | (after we learned another candidate did that and it was apparently pretty normal) |
| 23:37 | <annevk> | hober: end of month I guess? |
| 23:38 | <marcosc> | do we know how many positions are open? |
| 23:38 | <hober> | 2 |
| 23:39 | <hober> | and there are 4 candidates |
| 23:39 | <marcosc> | I like those odds |
| 23:39 | <marcosc> | Domenic_: will get you the list |
| 23:41 | <Hixie> | lordy |
| 23:41 | <Hixie> | have you people still not learnt the futility of the TAG |
| 23:41 | <tantek> | Hixie some of us are even still working on improving things in and from AB ;) |
| 23:42 | Hixie | shakes his head sadly |
| 23:42 | <annevk> | Hixie: well, I guess some haven't tried yet |
| 23:43 | <Domenic_> | heh |
| 23:43 | <Domenic_> | annevk: right, that makes a lot of sense... should have thought of that... |
| 23:43 | <marcosc> | I kinda have to agree with Hixie a bit... Anne and I opted to do conferences instead |
| 23:44 | <marcosc> | But if the people on the TAG actually do stuff that is needed, then it's not harmful |
| 23:44 | <Hixie> | conferences are something that i believe could really help |
| 23:44 | <Hixie> | feel free to cc me into any discussions about those if you care for any input. i probably can't make it to any myself, but i'd be happy to help and would love to hear back. |
| 23:49 | <marcosc> | Hixie: thanks! much appreciated |
| 23:51 | <jgraham> | I don't understand the TAG obsession either. I don't think there is a useful function for a group with their structure, so ee should neuter them rather give them false legitimacy |