| 00:12 | <heycam> | does anyone implement cssElementMap yet? |
| 00:12 | <Hixie> | dunno, tabatkins would know |
| 00:13 | <heycam> | that was for the element() thing, yeah? |
| 00:17 | <heycam> | hi TabAtkins |
| 00:17 | <Hixie> | wow that was good timing |
| 00:17 | <heycam> | I assume you telepathically paged him or something |
| 00:17 | <heycam> | (with your google brain implants) |
| 00:18 | <Hixie> | no, i went to the loo. |
| 00:18 | <Hixie> | so... |
| 00:54 | <heycam> | Hixie, fwiw there are two instances of "initialised" in the document |
| 00:54 | <Hixie> | where? |
| 00:54 | <Hixie> | oh wait |
| 00:54 | <Hixie> | i was narrowed on the websockets section |
| 00:54 | <Hixie> | fixed |
| 01:05 | <heycam> | Hixie, createPattern is defined to throw a TYPE_MISMATCH_ERR if you give it an element that's not img/canvas/video. Web IDL already makes it so that a TypeError will be thrown, though. |
| 01:05 | <heycam> | so if it's necessary that TYPE_MISMATCH_ERR is thrown, you may have to widen the argument type (and remove the overloading) |
| 01:06 | <Hixie> | heycam: TYPE_MISMATCH_ERR only fires for null |
| 01:06 | <Hixie> | heycam: i don't mind if you change that so webidl fires TypeError |
| 01:07 | <heycam> | Hixie, great, will do |
| 01:07 | <heycam> | there are only a couple of instances where I'm making these changes to throw TypeError instead of throwing some DOMException |
| 01:07 | <heycam> | you can let me know if any of them can't be done for compat reasons |
| 01:07 | <heycam> | (but I would be surprised if particular exception types were relied on) |
| 01:08 | <Hixie> | mention them here and i'll let you know if any are problematic |
| 01:08 | <heycam> | ok |
| 01:08 | <Hixie> | but i'm gonna guess they're all fine |
| 07:32 | <zcorpan> | ah so now websocket.onerror is not for bogus frames but for "fail the websocket connection" |
| 07:35 | <zcorpan> | Hixie: for us following along at home, what's the rationale for the new onerror? |
| 07:58 | <Hixie> | zcorpan: ian asked me to expose the case where the connection closed because the client closed the connection due to an error. |
| 08:00 | <zcorpan> | ok |
| 08:00 | <hsivonen> | zcorpan: V.nu doesn't implement the microdata check you asked about |
| 08:01 | <zcorpan> | hsivonen: ok. any plans? |
| 08:14 | <hsivonen> | zcorpan: only vague plans. nothing concretely scheduled |
| 10:53 | <kost-bebix> | Hi everyone! I just wanted to ask about sanitization sules http://wiki.whatwg.org/wiki/Sanitization_rules . I mean, for example -- the "style" attribute. |
| 10:53 | <kost-bebix> | That's not safe from XSS, isn't it? |
| 10:53 | <kost-bebix> | So what's the purpose of that sanitization rules? |
| 10:55 | <kost-bebix> | Or should that "style" be removed? |
| 11:13 | <jgraham> | In some versions of IE you can include script in style rules |
| 11:34 | <hsivonen> | jgraham: also in Gecko |
| 11:34 | <hsivonen> | via XBL |
| 11:35 | <jgraham> | hsivonen: Oh, nice |
| 11:35 | <hsivonen> | which is why we need to sanitize styles in pastes to contenteditable |
| 11:37 | <kost-bebix> | jgraham: oh, got it |
| 11:37 | <kost-bebix> | we're in safe |
| 11:37 | <kost-bebix> | html5lib also parses "style" attribute |
| 11:37 | <kost-bebix> | so your css-expressions and other stuff will be sanitized |
| 11:48 | <jgraham> | Yes |
| 12:14 | <hsivonen> | turns out that there are now very, very few rel keywords in the old registry that aren't already in the new registry and meet the registration requirements |
| 12:14 | <hsivonen> | I'm going to register those few rel keywords |
| 12:29 | <hsivonen> | what's the deal with W3C specs that define rel keywords making those sections informative rather than normative? |
| 12:29 | <hsivonen> | FAIL |
| 12:32 | <jgraham> | Some W3C groups are surprisingly poor at writing specs |
| 12:32 | <jgraham> | Which is surprising given that is the whole point of them existing |
| 12:36 | <hsivonen> | also, a bunch of the old registrations linked to a spec that defined the format of the resoure the link was supposed to point to but didn't spec the rel keyword at all |
| 12:37 | <hsivonen> | I didn't reregister those. |
| 12:37 | <hsivonen> | since they failed the requirements |
| 12:37 | <hsivonen> | since the claimed spec didn't actually say anything about the rel keyword |
| 12:37 | <hsivonen> | not even informatively |
| 12:41 | <kost-bebix> | I need to modify sanitizer a little to allow youtube video's embed. Hope I'll find out how to do that safety)) |
| 12:41 | <kost-bebix> | s/safety/safely/ |
| 12:45 | <hsivonen> | zcorpan: thanks for fixing the wikis regarding registry usability |
| 12:55 | <karlcow> | hsivonen: @forstall said that "“we took Apple's Safari engine and open-sourced it”" at a specific recorded place? |
| 12:55 | <karlcow> | cf http://twitter.com/hsivonen/status/78065920316153856 |
| 12:55 | <hsivonen> | karlcow: in the official keynote recording. I didn't make note of the timecode |
| 12:55 | <karlcow> | wiiiiiz |
| 12:56 | <karlcow> | thanks |
| 12:56 | <hsivonen> | karlcow: but I rewinded to make sure I heard it right |
| 12:56 | <karlcow> | khtml community must be happy |
| 12:57 | <Workshiva> | karlcow: Imagine if Apple hadn't opensourced it, then khtml would be stealing Apple's code! |
| 12:57 | <karlcow> | heh |
| 18:15 | <jgraham> | Hmm, the latest Device Orientation spec specifies that a compassneedscalibartion event is only fired if there are event listeners registered for the deviceorientation event |
| 18:15 | <jgraham> | This seems bad, but I'm not really sure what to suggest |
| 18:16 | <jgraham> | http://dev.w3.org/cvsweb/~checkout~/geo/api/spec-source-orientation.html?rev=1.22;content-type=text%2Fhtml |
| 18:16 | <Ms2ger> | I'd suggest "Don't do that" |
| 18:16 | <zewt> | that sounds similar to the webgl stuff that was fixed recently, the sort of thing people who don't understand dom events spec |
| 18:17 | <zewt> | awkward-looking spec... |
| 18:17 | <zewt> | yeah this is just backwards and needs the same fix webgl did |
| 18:17 | <jgraham> | The spec improved at lot in the last revision :) |
| 18:17 | <jgraham> | What fix did WebGL do? |
| 18:17 | <zewt> | well, maybe not, hmm |
| 18:18 | <zewt> | webgl had something like "if anything is listening for this event, lost contexts are automatically restored", which is the same thing--a side-effect of event registration (bad) |
| 18:20 | <zewt> | the fix was to make it "if you want to restore the event, cancel the event", which is a little odd but a lot saner |
| 18:20 | <zewt> | similar here would be "if you want to display the calibration UI, cancel the event" |
| 18:20 | <zewt> | it's odd for cancellation to *cause* something rather than to stop the default handler, but registration itself having side-effects is broken |
| 19:17 | <AryehGregor> | When I run this in Opera 11.11, hitting backspace will sometimes decide to navigate backwards in history: http://aryeh.name/spec/editcommands/backspacetest.html |
| 19:17 | <AryehGregor> | Doesn't seem to happen in other browsers. |
| 19:38 | <jgraham> | AryehGregor: Hmm, well it didn't for me, but I assume it is a race condition |
| 19:38 | <AryehGregor> | What sort of race condition might it be? |
| 19:38 | <jgraham> | If you hit it fast enough it might navigate before the editable content is focused, or something |
| 19:38 | jgraham | hasn't looked at the source |
| 19:39 | <AryehGregor> | I'm hitting it quite slowly. |
| 19:39 | AryehGregor | tries clearing the cache and doing it again |
| 19:39 | gsnedders | couldn't reproduce it |
| 19:39 | <jgraham> | (what's the "store new result" stuff?) |
| 19:40 | <AryehGregor> | Oh, now it works. |
| 19:40 | <AryehGregor> | Maybe I changed the code at some point. |
| 19:40 | <AryehGregor> | jgraham, the second column is the results my spec say should happen. I use it for regression-testing the spec. If you store the new result, it will put it in localStorage, and on subsequent runs will alert you if the new result differs from the old. |
| 19:41 | <AryehGregor> | It will also alert for random other things, like if the DOM doesn't round-trip through text/html serialization. |
| 19:42 | <jgraham> | Oh, it is local-only |
| 19:43 | <AryehGregor> | Yeah. |
| 19:43 | <AryehGregor> | I've somewhat thought of making it centralized, because that way I don't have to reconfirm new results separately on every browser I use. |
| 19:43 | <AryehGregor> | But it seems like too much hassle for the benefit. |
| 20:30 | <jgraham> | Huh. The W3C is planning to release the author-only view of the HTML5 draft as a seperate normative document? |
| 20:30 | <jgraham> | That seems... confusing |
| 20:31 | <Philip`> | What could possibly go wrong with two separate documents normatively specifying the same subject? |
| 20:31 | <Ms2ger> | They need a replacement for HTML4, I guess |
| 20:37 | <jgraham> | 1 |
| 21:43 | jwalden | wonders where rel="archives" went, or if it was ever present |
| 21:49 | <Philip`> | jwalden: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11486 |
| 21:50 | <jwalden> | hm, why is that complaining it's hidden? and why am I not getting prompted for a member login or somesuch, which I could provide? |
| 21:51 | <Philip`> | jwalden: Doesn't look hidden to me |
| 21:51 | <jwalden> | strange; I get the " Sorry, Insufficient Access Privileges" page |
| 21:52 | jwalden | tunnels somewhere to retry |
| 21:53 | <jwalden> | bizarre |
| 21:53 | <jwalden> | it works from an MIT IP address, but not from the Mozilla network |
| 21:54 | jwalden | tries asking IT about it |
| 22:01 | <jgraham> | It's an evil conspiracy to block Mozilla from W3C! |
| 22:37 | <jamesr> | doesn't work for me either |
| 22:48 | <jwalden> | heh, that almost makes me wonder if it only works from MIT (W3C being there) |
| 22:49 | <jwalden> | nope, works from a dreamhost server |
| 22:52 | <Hixie> | w3c regularly automatically block google |
| 22:52 | <Hixie> | maybe they did the same to mozilla this time for some reason |
| 22:53 | <Hixie> | (it's part of their rather over-zealous DOS protections) |
| 22:55 | <jamesr> | how do i firewalled NAT? |
| 23:10 | <AryehGregor> | jwalden, I think what happens is that people use XML-processing programs that automatically request DTDs when processing XML files. They don't notice the four billion network requests to W3C's servers that happen every time they run through their database of XHTML files or whatever. So the W3C detects this and blocks such sites at the firewall automatically. |
| 23:11 | <jwalden> | "hoisted by their own petard", as it were |
| 23:31 | <Hixie> | if you go to a page that serves a 500 but declares a manifest, we cache it |
| 23:31 | <Hixie> | the next time you go there, you see the cached copy, and we try to update it |
| 23:32 | <Hixie> | but we find it's 500, so we don't update its entry in the cache (we update the rest of the cache) |
| 23:32 | <Hixie> | this continues forever, with you seeing the first 500 rather than any later updates, until it either becomes 200, 404, or 410, or the manifest becomes 410 |
| 23:32 | <Hixie> | now the question is: |
| 23:33 | <Hixie> | if it's a 200 page with no-store, instead of a 500 page: |
| 23:33 | <Hixie> | should we do the same thing? |
| 23:38 | <Hixie> | i guess i'll treat it like a 410/404 |
| 23:39 | <Hixie> | which is kinda weird already |
| 23:47 | <AryehGregor> | Hixie, wait, so there's a whole section that normatively explains authoring conformance requirements for the HTML syntax, but conformance checker requirements are totally different? What happens if there are contradictions? Conformance checkers are required to report things that aren't authoring conformance errors, or are required not to report things that are? |
| 23:47 | <AryehGregor> | (Are there known contradictions?) |
| 23:48 | <Hixie> | there had better not be contradictions |
| 23:48 | <Hixie> | technically i suppose i could have the spec not require that validators use the parser spec |
| 23:48 | <Hixie> | at the time i wrote that they should use it, i hadn't written the other section, and we already had validators |
| 23:54 | <AlexNRoss> | Speaking of validators.... I wish that W3C Jigsaw (CSS) Validator would recognise browser-specific entities such as -moz-* and -webkit-* and -ms-* and -khtml-* |
| 23:54 | <AryehGregor> | "Recognize" in what fashion? |
| 23:54 | <AryehGregor> | Claim that vendor-specific, nonstandard extensions are valid? |
| 23:54 | <AryehGregor> | Or give a more informative error message, or what? |
| 23:54 | <AlexNRoss> | In the sense that it won't give an error. |
| 23:54 | <paul_irish_> | AlexNRoss: there is an option to allow them, now |
| 23:54 | <AryehGregor> | That wouldn't make much sense, since CSS says they're invalid. |
| 23:54 | <AlexNRoss> | paul: Oh? Where's that? |
| 23:55 | <paul_irish_> | Vendor Extensions: Warnings |
| 23:55 | <paul_irish_> | http://paulirish.com/i/5e71.png |
| 23:56 | <AlexNRoss> | paul: That still doesn't help. |
| 23:56 | <paul_irish_> | why not |
| 23:56 | <AlexNRoss> | http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2F76.11.58.232%2Fcss%2Fscreen.css&profile=css3&usermedium=all&warning=1&vextwarning=true&lang=en |
| 23:57 | <paul_irish_> | looks right to me. it doesnt recognize vendor prefixed gradient syntax |
| 23:57 | <paul_irish_> | and the others are marked as warnings |
| 23:58 | <AlexNRoss> | It's still irritable. |
