| 00:11 | <TabAtkins> | Worse for me (rachel doesn't get home until late on fridays) |
| 00:11 | <MikeSmith> | what exactly is https://www.w3.org/Bugs/Public/show_bug.cgi?id=23254 asking for? |
| 00:11 | <TabAtkins> | whoops, wrong window |
| 00:11 | <MikeSmith> | is it asking that any arbitrary element that has a hype in it should be considered valid/conformant? |
| 00:12 | <MikeSmith> | *has a hypen in it |
| 00:12 | <MikeSmith> | only about document conformance? |
| 00:15 | <MikeSmith> | Hixie_: any clue about https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/qcDiw-QP4RE ? |
| 00:16 | <MikeSmith> | I already pointed out to him (off list) that he should be reading the whatwg spec, not the TR link he cited |
| 00:16 | <MikeSmith> | but in this case the TR and whatwg source don't have any difference |
| 00:17 | <Hixie_> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=23254 looks to be rather premature, since until we merge in web components, it's only applicable to web components... |
| 00:18 | <Hixie_> | (presumably only elements that are bound would be conforming) |
| 00:18 | <MikeSmith> | Hixie_: ok |
| 00:18 | <Hixie_> | (dglazkov and i chat about this stuff occasionally to keep in sync re what should be merged into html) |
| 00:19 | <MikeSmith> | yeah, I figured |
| 00:19 | <Hixie_> | as far as that chromium-dev post is concerned -- would have to see the output to comment |
| 00:20 | <MikeSmith> | he seems to be saying the blink requires the length to be specified in the headers, but he can't find any spec that requires that |
| 00:20 | <Hixie_> | HTTP headers? |
| 00:22 | <MikeSmith> | I assume so |
| 00:22 | <MikeSmith> | dunno what else he'd mean |
| 00:22 | <MikeSmith> | hex-encoded |
| 00:24 | <MikeSmith> | seems like he's saying he can't even figure out what chromium expects |
| 00:24 | <MikeSmith> | anyway, I just figured there might be something he was missing as far his reading of the specs |
| 00:24 | <MikeSmith> | but it seems not |
| 00:25 | <Hixie_> | "to each message" is what confuses me |
| 00:25 | <MikeSmith> | yeah that too |
| 00:25 | <Hixie_> | so i dunno |
| 00:25 | <Hixie_> | would have to see the output |
| 00:26 | <dev11> | What is wrong with chrome |
| 00:26 | <dev11> | all have problems or just me |
| 00:26 | <MikeSmith> | but if he's running into problems implementing server support compatible with Chrome's SSE implementation, it makes me wonder how others manage to implement it without running into the same problem |
| 00:27 | <dev11> | someone that works in chrome project here |
| 00:27 | <dev11> | ? |
| 00:28 | <Hixie_> | dev11: what's up? |
| 00:28 | <Hixie_> | MikeSmith: yeah, i dunno |
| 00:28 | <Hixie_> | MikeSmith: i have to admit that i just do websockets now, for pretty much everything |
| 00:29 | <dev11> | something is very bad right now |
| 00:29 | <dev11> | I am not sure if its just me or all thats why I though to ask sorry |
| 00:29 | <dev11> | that I ask here Hixie.. |
| 00:29 | <Hixie_> | MikeSmith: anything that's not just static file serving, i do over web sockets |
| 00:29 | <Hixie_> | MikeSmith: so i never actually used sse :-) |
| 00:29 | <dev11> | youtube videos don't open and pages don't open, I am doing 112412 thingsright now so I am not sure whats goin on |
| 00:29 | <Hixie_> | dev11: are you on a dev build? |
| 00:30 | <dev11> | no |
| 00:30 | <dev11> | normal |
| 00:30 | <Hixie_> | weird |
| 00:30 | <dev11> | wait ill try on other pc lol I forgot that I have 6 pcs :D |
| 00:30 | <MikeSmith> | Hixie_: yeah I kind of wonder why at this point somebody would put work into implementing SSE support in a server rather than just providing websocket support |
| 00:30 | <Hixie_> | dev11: if you can't get any help here, try #chromium |
| 00:30 | <dev11> | yeah |
| 00:30 | <dev11> | it chrome |
| 00:30 | <dev11> | laptop is same |
| 00:31 | <dev11> | hm let me recheck |
| 00:31 | <dev11> | damn its my pc, sorry for annoying |
| 00:55 | <inaimathi> | Hi; I've been asking questions about SSE server implementations. |
| 00:55 | <inaimathi> | Someone wanted to see some output? :D |
| 00:55 | <MikeSmith> | hi inaimathi yeah Hixie_ might be able to provide some insights |
| 00:56 | <MikeSmith> | since he's the one who wrote the spec |
| 00:56 | <MikeSmith> | way back when.. |
| 00:57 | <inaimathi> | Ok. Let me get my notes in order and I'll try to summarize. |
| 01:07 | <inaimathi> | So. |
| 01:07 | <inaimathi> | The server implementation I worked up is here (I don't have a repo up on Github yet): http://langnostic.blogspot.ca/2013/09/deal-journal-interlude-one-treatise-on.html |
| 01:07 | <inaimathi> | As written, the stream it generates for one message looks like this: http://pastebin.com/KPBS7egD |
| 01:07 | <inaimathi> | which doesn't conform to the spec as far as I understand, because it contains two lines that have no colons, but aren't ignored. |
| 01:08 | <inaimathi> | If I change that stream output so that it instead looks like this: http://pastebin.com/A57URpnK |
| 01:08 | <inaimathi> | it stops working with Firefox/Iceweasel/Conkeror/etc and Chromium. |
| 01:08 | <inaimathi> | Firefox+friends eat the first message, correctly process the second, and choke on the third (tripping the `onerror` event). Chromium chokes on the first message, immediately tries to reconnect and continues that cycle for each message you send. |
| 01:09 | <inaimathi> | My question boils down to: why? |
| 01:10 | <inaimathi> | My best theory at this point is that those lines represent length headers which the named browsers use to allocate space for incoming messages (either the full stream, or on a message by-message basis), but I don't understand what the benefit is, and I can't find a specification for how exactly they're supposed to work. |
| 01:17 | <inaimathi> | Any hints in the right direction would be appreciated. |
| 01:22 | <inaimathi> | Huh |
| 01:22 | <inaimathi> | I guess I should have checked if Hixie |
| 01:22 | <inaimathi> | was online before dumping that. |
| 01:23 | <inaimathi> | Will he appear if I type his name three times? |
| 01:23 | <inaimathi> | Hixie_ Hixie_ Hixie_ |
| 01:24 | <Hixie_> | here |
| 01:24 | <Hixie_> | sorry, was having dinner |
| 01:24 | <Hixie_> | so the hex length stuff you're outputting is HTTP's chunked encoding |
| 01:24 | <Hixie_> | has nothing to do with Event Source per e |
| 01:25 | <Hixie_> | per s |
| 01:25 | <Hixie_> | per SE |
| 01:25 | <Hixie_> | i am not familiar with it enough to tell you if it's right |
| 01:25 | <Hixie_> | but |
| 01:25 | <Hixie_> | if you just load the file regularly in a browser, not in EventSource, what does it look like? |
| 01:25 | <Hixie_> | inaimathi: ^ |
| 01:27 | <inaimathi> | 1e |
| 01:27 | <inaimathi> | data: Got a message! G1064 |
| 01:27 | <Hixie_> | you shouldn't be seeing the "1e" if you are doing the chuncked encoding correctly |
| 01:27 | <inaimathi> | That's as written, connecting directly to the event-stream handler and publishing one message |
| 01:27 | <Hixie_> | it should get processed at the HTTP layer |
| 01:27 | <Hixie_> | so my guess is that you're mangling the http chunked transfer encoding stuff |
| 01:28 | <inaimathi> | High probability. |
| 01:28 | <inaimathi> | Ok, I'm off to read up on HTTP chunked transfer encoding |
| 01:28 | <inaimathi> | Thanks for your help, Hixie_ |
| 01:29 | <Hixie_> | good luck... |
| 01:29 | <inaimathi> | Heh. I get the feeling I'll need it. |
| 01:29 | <inaimathi> | Anywhere you think I should start? |
| 01:31 | <Hixie_> | what's your web server? |
| 01:32 | <inaimathi> | I'm writing one (which is more or less the problem). |
| 01:32 | <Hixie_> | oh, in that case, i recommend writing a websocket server instead. |
| 01:32 | <Hixie_> | it's i zillion times easier, and gets you more. |
| 01:32 | <inaimathi> | Huh. |
| 01:33 | <Hixie_> | (and then serve the static resources from that off-the-shelf http server like apache or something) |
| 01:33 | <Hixie_> | s/that/an/ |
| 01:33 | <inaimathi> | I'll give it a shot. My impression was that websocket support wasn't as consistent across browsers as SSEs. |
| 01:34 | <Hixie_> | what browsers do you care about? |
| 01:34 | <Hixie_> | caniuse.com suggest websocket is actually better supported than SSE |
| 01:35 | <Hixie_> | dunno how reliable that is |
| 01:35 | <inaimathi> | FF, Chrome and their Debian counterparts (although my pet browser is Conkeror, so I'd like to support it if I can at all manage). I take your point I guess. |
| 01:35 | <Hixie_> | ff and chrome definitely support websockets |
| 01:35 | <Hixie_> | no idea about conkeror |
| 01:36 | <Hixie_> | if you were using apache then i'd say use sse, because it's trivial to output sse messages from a CGI script |
| 01:36 | <Hixie_> | but if you're about to write your own HTTP server, then that changes the calculus a lot |
| 01:37 | <Hixie_> | web sockets is a couple hundred lines of code on the server in most languages at most |
| 01:37 | <Hixie_> | http takes thousands to do a half-decent implementation |
| 01:41 | <inaimathi> | Ok, I'll look into it. |
| 01:41 | <inaimathi> | You're right, from what I'm reading here, it's not high effort at all. |
| 01:41 | <inaimathi> | Thanks again |
| 02:11 | <zewt> | help, SSE means http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions to me and my parser keeps having to backtrack |
| 02:34 | <TabAtkins> | On the other hand, every time someone mentions SIMD stuff, I get confused and think they're talking about HTML. |
| 07:50 | <matjas> | http://isup.me/whatwg.org http://isup.me/software.hixie.ch |
| 09:08 | <jgraham> | zewt: I have the same issue whenever someone mentions NFC and doesn't mean "Normal Form C" |
| 09:09 | <hsivonen> | jgraham: me, too |
| 09:40 | <zcorpan> | when people talk about HTML i think of High Temperature Materials Laboratory |
| 10:56 | <jgraham> | zcorpan: Are you happy with the whole timeout=normal/long idea, rather than giving more precision? |
| 10:57 | <jgraham> | (for the overall harness, not for individual tests) |
| 10:57 | <zcorpan> | jgraham: what was the idea? |
| 10:58 | <jgraham> | By default you get a short timeout, say 10s. You can opt in to a longer timeout, say 60s. There are no more choices. |
| 10:59 | <jgraham> | (obviously the actual values there would be adjusted in autoimation scenarios so that all non-brokwn tests would actually complete) |
| 11:00 | <jgraham> | The theory seems to be that letting authors specify a number of ms doesn't make much sense because in many cases it totally depends on the nature of the system that the test is running on |
| 11:06 | <jgraham> | (for individual tests, I think a number-of-ms makes more sense because particular tests often do things like setTimeout that will take a known amount of time to complete) |
| 11:51 | <zcorpan> | <http://www.w3.org/mid/5238389B.7010701⊙nc>; ... i wonder why they don't use critic |
| 11:52 | <zcorpan> | jgraham: i'm OK with that |
| 11:52 | <jgraham> | Why use one convenient, integrated system, when you can spread it out over email, wikis, github and notes on bits of paper passed under the door |
| 11:53 | <jgraham> | zcorpan: OK, I will have a got at implementing it then |
| 11:53 | <jgraham> | Well, I already started;) |
| 11:54 | <zcorpan> | would it make sense for the harness to be smart about the timeout if tests declare their timeout? |
| 11:54 | <jgraham> | Define "smart"? |
| 11:54 | <jgraham> | It is a common bug that people set test timeouts that are longer than the harness timeout |
| 11:54 | <zcorpan> | so for instance if a test has 15s timeout, the file's timeout could be e.g. 15+normal |
| 11:55 | <jgraham> | But I don't really know how to deal with that because I don't know the test timeout when the overall timeout is set |
| 11:55 | <zcorpan> | just increase the overall timeout dynamically |
| 11:55 | <jgraham> | And, moreover, for automation I plan to set the overall timeout externally before I even load the test |
| 11:55 | <jgraham> | and diable the in-harness timeout |
| 11:57 | <jgraham> | (of course it is *possible* to pass a message about that back to the automation. But it's not exactly easy) |
| 11:57 | <zcorpan> | ok |
| 16:37 | <JakeA> | Is there any spec reason browser couldn't allow a video as the src for an <img> |
| 16:37 | <JakeA> | Maybe play it without sound |
| 16:39 | <Hixie_> | the spec talks about that, iirc |
| 16:43 | <JakeA> | There's mention of gif/apng |
| 16:43 | <JakeA> | It doesn't explicitly disallow, say, webm |
| 16:43 | <JakeA> | No mention of audio |
| 16:44 | <JakeA> | Basically, animated webp needs to die |
| 16:44 | <JakeA> | such a silly idea |
| 16:44 | <Hixie_> | it just says that you can't have scripted content, right? |
| 16:44 | <Hixie_> | says you can't use HTML |
| 16:44 | <Hixie_> | and doesn't disallow video |
| 16:55 | <jgraham> | If you want video, what's wrong with a video element? |
| 17:01 | <JakeA> | I guess the question is, why do people use gif? |
| 17:03 | <miketaylr> | because it just works™ |
| 17:04 | <jgraham> | I don't know, but I wish they wouldn't :p |
| 17:04 | <JakeA> | Just works, as in autoplays everywhere? |
| 17:05 | <JakeA> | animated webp sounds like the wrong answer for a question no one's asking |
| 17:05 | <miketaylr> | pretty much. and you can host them basically anywhere. |
| 17:06 | <miketaylr> | without needing to know about servers and content type and formats, etc |
| 17:06 | <zewt> | ... there aren't exactly any alternatives, if you want something that works everywhere, supports transparency (even if bad transparency), and is computationally cheap |
| 17:06 | <Hixie_> | apng? |
| 17:06 | <zewt> | does that actually work? |
| 17:07 | <Hixie_> | sure |
| 17:07 | <zewt> | i don't have any software that can output it, so i haven't tried it |
| 17:07 | <miketaylr> | http://caniuse.com/apng |
| 17:07 | <Hixie_> | (in firefox) |
| 17:07 | <zewt> | (in firefox) != actually works :P |
| 17:08 | <Hixie_> | well, same as webp :-) |
| 17:08 | <miketaylr> | there's been a few articles about using animated gifs to get around certain mobile browsers not being able to play inline |
| 17:08 | <zewt> | miketaylr: :| |
| 17:09 | <jgraham> | In unrelated questions, if I have a scatter graph with an axis that looks like ' 4 ' 5 ' 6 ', what is the correct way to vent my frustration? |
| 17:09 | <miketaylr> | similar hack, zewt https://docs.google.com/document/pub?id=1GWTMLjqQsQS45FWwqNG9ztQTdGF48hQYpjQHR_d1WsI |
| 17:10 | <Hixie_> | jgraham: are you complaining about the origin, or the postioning of the grid? |
| 17:10 | <jgraham> | Hixie_: The psoitioning of the grid |
| 17:10 | <Hixie_> | then i recommend venting on twitter. |
| 17:10 | <jgraham> | Haha |
| 17:11 | <jgraham> | (although the fact that the origin isn't 0 makes the positioning of the grid harder to deal) |
| 17:12 | <zewt> | miketaylr: at least there's some justice in them having to use gross hacks to work around limitations of ... their own platform |
| 17:12 | <miketaylr> | :)~ |
| 17:13 | <Hixie_> | jgraham: (if the number represent periods of time, e.g. days, months, years, then i think that alignment makes sense. if they represent specific moments, then yeah, that's dumb and annoying. |
| 17:14 | <Domenic_> | Hixie_: what would you have recommended if he was complaining about the origin? :P |
| 17:15 | <Hixie_> | facebook. |
| 17:16 | <jgraham> | Hixie_: Well, it's times of day. |
| 17:16 | <jgraham> | So looking closely, the tickmarks are totally misleading |
| 17:16 | <Hixie_> | oh no, i didn't close my brackets.) |
| 17:16 | <jgraham> | Assuming that the data is sampled on the hour, they are half-hour tick marks |
| 17:17 | <jgraham> | OTOH, it's possible that the data is sampled on the half hour and I still have mu original problem |
| 17:17 | <jgraham> | Basically this chart is rubbish |
| 17:17 | <jgraham> | I wonder how people who deal with this sort of thing ever day manage to get anything done |
| 17:18 | <jgraham> | *every |
| 17:18 | <zewt> | there's a question everyone, of every walk of life, asks themselves periodically |
| 17:19 | <zewt> | one of those little things we all share, as carlin put it |
| 17:27 | <bradleymeck> | is there any spec working on improving keyboard accessibility, looked in the DOM groups on w3c but didn't see too much activity for keyboard accessibility |
| 17:28 | <Hixie_> | HTML has done some work in that area, e.g. by providing new types in form controls |
| 17:28 | <Hixie_> | what specific problem are you thinking about? |
| 17:30 | <bradleymeck> | Hixie_: dialogs/modals/3rd party widgets need a little bit finer control over focus. IE modals should be where iteration starts/stops when iterating on a document. 3rd party widgets may want to have slightly better control over tab index if you mix tabindex=0 and tabindex=number |
| 17:31 | <bradleymeck> | I've written up the basics of what we did at BV as a spec, but am inclined to port it to existing stuff if it exists |
| 17:33 | <bradleymeck> | the big use cases are modals, and <form>s that are positioned with CSS rather than dom tree due to nesting problems and supporting older browsers |
| 17:37 | <Hixie_> | ah, yes. HTML has addressed that. Look for the inert="" attribute in the spec. http://whatwg.org/html#inert |
| 17:38 | <bradleymeck> | mmm could do a crawl when popping up a modal i guess and that fixes modals, anything about <form>s that are inlined for CSS? |
| 17:39 | <Hixie_> | "modals" are handled in HTML by the new <dialog> element |
| 17:39 | <Hixie_> | http://whatwg.org/html#dialog |
| 17:39 | <Hixie_> | makes it all work basically automatically, including making the other parts of the spec inert |
| 17:39 | <Hixie_> | er |
| 17:39 | <Hixie_> | parts of the doc |
| 17:39 | <Hixie_> | not sure what you mean by "<form>s that are inlined for CSS" |
| 17:41 | <bradleymeck> | we have submission forms that are appended to the bottom of the body (we provide 3rd party widgets), these are inlined for display / keyboard purposes to places higher in the dom tree since our customers may have wrapped the area of the 3rd party widget in a <form>. we cannot use form="x" due to supporting older browsers and not wanting to "infect" client <forms>. |
| 17:42 | <bradleymeck> | dialog might work if we can polyfill it properly as well |
| 17:42 | <Hixie_> | i have no idea what that means, sorry. what is the difference between "appended to the bottom of the body" and "inlined for display / keyboard purposes" ? |
| 17:42 | <bradleymeck> | ill make a jsfiddle |
| 17:43 | <Hixie_> | do you mean "positioned" rather than "inlined"? |
| 17:43 | <Hixie_> | i think the solution is probably form="". |
| 17:44 | <Hixie_> | anything we add to the spec will naturally take some time to be usable, though |
| 17:44 | <Hixie_> | but that's true of anything |
| 17:46 | <bradleymeck> | positioned, yes |
| 17:47 | <bradleymeck> | http://jsfiddle.net/6WchK/ |
| 17:47 | <bradleymeck> | either way if form="" is the way to do it I guess we can't move to that for quite a while |
| 17:47 | <bradleymeck> | thanks for the <dialog> info, will try and see if we can make that work |
| 17:50 | <Hixie_> | web components are probably the even better long-term solution to that |
| 17:50 | <Hixie_> | so i guess, to answer your original question, HTML and Web Components are indeed fixing the accessibility issues you're worried about. :-) |
| 17:51 | <bradleymeck> | yep, just can't use form= ever until it is supported everywhere |
| 17:54 | <Jasper> | Hixie_, how are the two path examples you gave in http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Sep/0186.html different? |
| 17:54 | <Jasper> | erm, wrong link |
| 17:54 | <Jasper> | Hixie_, how are the two examples in http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Sep/0185.html different? |
| 17:55 | <Jasper> | Hixie_, the only thing I can imagine is that you'll double-paint the arc and get some fringes around the edges |
| 17:57 | <Hixie_> | oh, i meant to put beginPath() after hte first fill(), my bad |
| 17:58 | <Jasper> | Hixie_, so I'm not the only one who makes that mistake. |
| 17:58 | <Jasper> | good to know |
| 17:58 | <Hixie_> | i make that mistake all the freaking time |
| 17:59 | <Jasper> | it's the biggest mistake in the canvas API. doing an operation should really clear the working path |
| 17:59 | <Jasper> | and it would be nice if save()/restore() saved and cleared the path as well |
| 17:59 | <Jasper> | but oh well |
| 18:01 | <Hixie_> | well, you sometimes want to both stroke and fill a path |
| 18:01 | <Hixie_> | but yeah, that's one thing hte Path API is supposed to fix |
| 18:01 | <Jasper> | Hixie_, yeah, cairo has fill_preserve(); stroke_preserve(); for this use case |
| 18:32 | <Hixie_> | TabAtkins: (further to my e-mail just now) but really i just wish we had real type checking. |
| 19:20 | <matjas> | annevk: thanks for filing that ES identifier bug and CCing me |
| 19:21 | <annevk> | matjas: figured you'd be interested |
| 19:21 | <annevk> | matjas: everyone basically agreed that since IE throws and ES having magic lists was not desirable, relying on Unicode would be better for this |