| 01:16 | GPHemsley | wonders why the IETF refers to us as WHAT-WG |
| 01:18 | <GPHemsley> | [22:38:11] <cyrusdaboo> MIME-Sniffing: no objections from the room to drop the draft in favor of WHAT-WG doing the work. |
| 01:18 | <GPHemsley> | [22:40:02] <cyrusdaboo> MIME-Sniffing: W3C had a reference to it, but now points to WHAT-WG so no issue with WG dropping it. |
| 01:18 | <GPHemsley> | (yay?) |
| 01:19 | <GPHemsley> | In other news, I hate M3U files. |
| 01:19 | jwalden | guesses they're wondering, what working group? |
| 01:19 | <jwalden> | ;-) |
| 01:20 | <annevk> | WhatWG is also sometimes used |
| 01:20 | <annevk> | as the old old proverb goes, spelling is hard, lets go shopping |
| 01:22 | <annevk> | GPHemsley: not sure if yay or nay that IETF decides this is not important |
| 01:23 | <GPHemsley> | annevk: Well, I don't know if they think it isn't important... I asked them to drop it: http://trac.tools.ietf.org/agenda/85/slides/slides-85-websec-3.pdf |
| 01:24 | <GPHemsley> | (page 4, FTW) |
| 01:25 | <annevk> | "from WHAT-WG" nice |
| 01:26 | <GPHemsley> | Indeed. |
| 01:27 | <GPHemsley> | Sadly, the audio for the meeting doesn't work. |
| 01:28 | <annevk> | did you try to open it in VLC? |
| 01:29 | <GPHemsley> | yup |
| 01:29 | <GPHemsley> | apparently the stream 404s |
| 01:29 | <GPHemsley> | It may have only been a livestream, rather than a recording |
| 01:30 | <annevk> | oh yeah it is |
| 01:31 | <annevk> | you can find recordings here: http://www.ietf.org/audio/ietf85/ |
| 01:36 | <GPHemsley> | oh my |
| 01:36 | <GPHemsley> | ok |
| 01:39 | <GPHemsley> | I think this is supposed to be it, but it's very quiet: http://www.ietf.org/audio/ietf85/ietf85-grandballroomc-20121108-1730-pm3.mp3 |
| 01:40 | <GPHemsley> | And it doesn't sound like anybody is discussing any agenda items |
| 01:40 | <GPHemsley> | it's also very short |
| 01:40 | GPHemsley | shrugs |
| 01:41 | <GPHemsley> | I guess they got on alright without me |
| 03:31 | <MikeSmith> | http://lists.w3.org/Archives/Public/public-iri/2012Nov/0016.html |
| 05:41 | <MikeSmith> | cool to see ap unilaterally declaring "consensus" based on feedback from just three people https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html |
| 05:42 | <MikeSmith> | https://bugs.webkit.org/show_bug.cgi?id=101660#c1 |
| 07:28 | hsivonen | learns about HTTP response code 420 Enhance Your Calm |
| 08:24 | <hsivonen> | patch review in the morning: r+ to flipping the default endianness for "UTF-16" in FileReader from Workers. |
| 08:41 | <hsivonen> | annevk: see https://bugzilla.mozilla.org/show_bug.cgi?id=809934#c1 |
| 08:45 | <zcorpan> | annevk: "Remove any leading and trailing ASCII whitespace from input." why does this only happen if /url/ is not given? |
| 09:01 | <hsivonen> | https://twitter.com/ronsman/status/266692044460802048 |
| 09:02 | <annevk> | zcorpan: state override is given if url is given |
| 09:02 | <annevk> | zcorpan: e.g. when you set query or pathname you don't want to strip spaces, afaict |
| 09:03 | <zcorpan> | annevk: ok |
| 09:05 | <annevk> | I guess I should change http://url.spec.whatwg.org/#dom-url-href to not pass *url* and instead set *url* to the return value |
| 09:07 | <annevk> | and it should return url when neutering |
| 09:10 | <MikeSmith> | wait you're really using the term neuter in the spec? |
| 09:11 | <MikeSmith> | hmm so I see there's so precedent for that |
| 09:11 | <annevk> | "Who will defend UTF-8 from ASCII suppremacists?" :-) |
| 09:11 | <annevk> | MikeSmith: I would not have come up with that term on my own |
| 09:12 | <MikeSmith> | heh |
| 09:12 | <hsivonen> | who did? |
| 09:12 | <MikeSmith> | postMsg |
| 09:12 | <MikeSmith> | I think |
| 09:13 | <hsivonen> | In other news, someone found a tokenizer bug in the V.nu/Firefox HTML parser |
| 09:13 | <MikeSmith> | oh |
| 09:13 | <MikeSmith> | bug number? |
| 09:13 | <hsivonen> | MikeSmith: https://bugzilla.mozilla.org/show_bug.cgi?id=809956 |
| 09:14 | <MikeSmith> | "lighting source"? |
| 09:14 | <MikeSmith> | ah |
| 09:14 | <MikeSmith> | he means syntax highlighting? |
| 09:14 | <hsivonen> | the summary had me go "WTF?", too, for a while |
| 09:15 | <annevk> | more pruf that spelling is hard |
| 09:15 | <MikeSmith> | I still wondering what "Pruf" means |
| 09:15 | <MikeSmith> | heh |
| 09:15 | <annevk> | and we should just go shopping |
| 09:16 | <MikeSmith> | ah proof |
| 09:16 | <MikeSmith> | ok |
| 09:23 | <hsivonen> | the tokenizer bug is rather shocking |
| 09:23 | <zcorpan> | hsivonen: were there more bugs in the css tests? |
| 09:24 | <hsivonen> | zcorpan: no, AFAICT. thanks for fixing them |
| 09:24 | <zcorpan> | do you pass all tests except the utf-16 endianness one? |
| 09:24 | <hsivonen> | zcorpan: yes (unless I forgot to reload some test) |
| 09:25 | <zcorpan> | nice |
| 09:25 | <hsivonen> | I’m waiting for advice from Ms2ger and fantasai on how to import the tests |
| 09:26 | <hsivonen> | it seems unprecedented to import testharness.js tests from the CSS test suite |
| 09:27 | <zcorpan> | i wonder if the tests should be "approved" |
| 09:30 | <hsivonen> | this kind of tokenizer bug arises when Hixie is lazy and writes the spec like this: http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#cdata-section-state |
| 09:34 | <annevk> | confirmed |
| 09:34 | <annevk> | Opera violated IDNA2008 first |
| 09:36 | <annevk> | zcorpan: Kajtan did not mention supporting more domain label separators but Opera does |
| 09:37 | <annevk> | zcorpan: http://mathias.html5.org/tests/url/idna2003-separators/ |
| 09:37 | <zcorpan> | annevk: feel free to reply to the email. he's cc-ed |
| 09:39 | <annevk> | hsivonen: btw, re that utf-16 bug, I'm not sure how we're gonna find out except by testing |
| 09:40 | <annevk> | hsivonen: I guess the another thing that could work is not flip the default on Unicode, but mandate sniffing |
| 09:46 | <annevk> | hmm no feedback yet on http://html5.org/temp/mo-queue.html |
| 09:50 | <zcorpan> | hsivonen: would it be better to have separate states for "]" "]" and ">"? |
| 09:50 | <zcorpan> | (well i guess the ">" doesn't need a state of its own since you'd switch to the data state at that point) |
| 09:51 | <annevk> | hsivonen: why is that lazy? it's perfectly clear, no? |
| 09:52 | <hsivonen> | annevk: well, IE compat involves willfully violating Unicode/IANA for the UTF-16 default endianness |
| 09:52 | <hsivonen> | annevk: the question is, should we have three independent labels that have defaults but all sniff the BOM |
| 09:52 | <annevk> | hsivonen: yeah, I said the other thing we could do is not flip the default on Unicode |
| 09:53 | <annevk> | hsivonen: aaahh, that would be another option |
| 09:53 | <hsivonen> | annevk: but chances are that UTF-16 is so rare anyway that we can just go ahead with implementing the Encoding Standard |
| 09:53 | <hsivonen> | who checks document.characterSet anyway? |
| 09:54 | <annevk> | dunno; all three solutions above seem equally fine to me, though I guess the one in the Encoding Standard is the cleanest |
| 09:54 | <annevk> | (well, except maybe if we are going to mandate utf-16 sniffing anyway, then we could probably align with Unicode) |
| 09:55 | <hsivonen> | yay. Google Analytics |
| 09:55 | <hsivonen> | dunno if we’ll break them, but they can take care of themselves and aren’t critical for the functionality experienced by the site user |
| 09:56 | <annevk> | they check document.characterSet? whoa |
| 09:56 | <annevk> | I wonder what the use case for that is |
| 09:57 | <hsivonen> | https://code.google.com/codesearch#search/&q=.characterSet%20lang:^javascript$%20-file:urchin.js%20-file:ga.js&type=cs |
| 09:59 | <annevk> | some weird code there |
| 09:59 | <annevk> | setting script.charset to document.charset, seems kinda redundant |
| 10:00 | <annevk> | but then it also sets script.type to text/javascript |
| 10:00 | <annevk> | people don't really know what they're doing |
| 10:02 | <hsivonen> | If I add UTF-16 to the search, I find Gecko sources |
| 10:02 | <hsivonen> | so probably the Web doesn’t care |
| 10:02 | <hsivonen> | carry on |
| 10:07 | hsivonen | sees https://twitter.com/JibberJim/status/266828515830272000 |
| 10:10 | <annevk> | yeah, beautiful |
| 10:18 | <zcorpan> | annevk: "Path could be reused here to keep parsed URL simple." seems confusing and unnecessary |
| 10:41 | <annevk> | mkay |
| 10:54 | <annevk> | thanks for reviewing btw |
| 10:56 | <Stevef_> | FYI - I have taken up the position of co-faciltator of the html accessibility taskforce http://lists.w3.org/Archives/Public/public-html-a11y/2012Nov/0002.html and would like to encourage everybody and anybody to participate or at least be open to providing technical feedback, feel free to ping me at anytime if you don't/won't/can't particiapate directly, I will endeavour to work constructively wit |
| 10:56 | <Stevef_> | h anyone within the constraints of the role (noting that I don't necessarily agree with all/some/any of the work being carried out at any particlaur time). And will be continuing my other web standards work as per usual |
| 10:58 | <annevk> | good luck to you and prolly good news for MikeSmith too |
| 10:58 | <Stevef_> | annevk: thanks i will need it... |
| 11:04 | <zcorpan> | annevk: can http://resources.whatwg.org/ be made to show a directory index? |
| 11:04 | <annevk> | zcorpan: for the :active and :hover quirk, the way it is defined might lead to divergent results once there's a new selector type in town |
| 11:05 | <zcorpan> | annevk: it's a living standard, i can update it when that happens :-P |
| 11:06 | <annevk> | zcorpan: it just seems like implementations would have implemented this as a standalone :hover / :active |
| 11:06 | <annevk> | zcorpan: so now it's a bunch of work to check whether that's the case in the spec too |
| 11:07 | <zcorpan> | annevk: how do you suggest it should be specced? |
| 11:07 | annevk | ducks |
| 11:07 | <annevk> | zcorpan: if you commit a .htaccess to whatwg/resources.whatwg.org it should work |
| 11:15 | <annevk> | we should prolly think a bit about what we want to do there |
| 11:15 | <annevk> | maybe put the style sheet there too? logos |
| 12:01 | <annevk> | zcorpan: hmm, I'll kill some of those DreamHost generated files |
| 12:01 | <zcorpan> | annevk: thanks |
| 12:02 | <annevk> | fixed |
| 12:03 | <zcorpan> | excellent |
| 12:18 | <annevk> | teehee, mutation observer queue approved |
| 12:18 | <annevk> | now I need to commit it and then Opera and Microsoft better ship it fast |
| 12:26 | <zcorpan> | MikeSmith: http://dvcs.w3.org/hg/quirks-mode/raw-file/tip/Overview.html doesn't redirect though .htaccess has a directive to redirect it. (i'd like to redirect file-bug.js as well) |
| 12:33 | <hsivonen> | hmm. Sam is trolling me to reply https://twitter.com/samruby/status/266875865609146370 |
| 12:34 | <zcorpan> | annevk: i don't see my changes reflected on http://resources.whatwg.org/ |
| 12:36 | <annevk> | something is wrong with the script |
| 12:36 | <annevk> | 755 is the correct chmod right? |
| 12:38 | <zcorpan> | "755 means read and execute access for everyone and also write access for the owner of the file." says my first google result |
| 12:39 | <jgraham> | So Sam's position is that the tools won't save us, except for hsi tool that will? |
| 12:39 | <annevk> | zcorpan: ooh |
| 12:39 | <annevk> | zcorpan: when you added the .htaccess Options, ExecCGI got turned off I think |
| 12:40 | <hsivonen> | maintaining a polyglot site without tools is quite a party trick |
| 12:40 | <annevk> | zcorpan: so I will commit a change to set that to on |
| 12:40 | <annevk> | then run the script manually, then it should work |
| 12:41 | <zcorpan> | what i find interesting with Sam's post is his use of "SHOULD NOT" which links to http://www.ietf.org/rfc/rfc2119.txt |
| 12:43 | <annevk> | long live error logs |
| 12:43 | <annevk> | zcorpan: should all work now |
| 12:43 | <zcorpan> | thanks |
| 12:43 | <annevk> | maybe I should become sysadmin |
| 12:44 | <zcorpan> | now we need to update all specs that point to the old file-bug.js. :-/ |
| 12:45 | <annevk> | mine are slowly getting updated |
| 12:45 | <annevk> | I guess we should not move other files there unless there's an actual need |
| 12:46 | <annevk> | although I might put logos there so I need to change cgi scripts around to copy entire directories rather than just Overview.html |
| 12:46 | <annevk> | so I don't need* |
| 12:47 | <annevk> | " There is no way to represent a constant sequence value in IDL." :/ wanted to set it to empty by default |
| 12:47 | <hsivonen> | Should I file a spec bug about the Polyglot doc inspiring the SitePoint article? http://intertwingly.net/blog/2012/11/09/In-defence-of-Polyglot#c1352464695 |
| 12:49 | <jgraham> | I think he has failed to demonstrate an actual problem that needs solving. He says that he wants to produce polyglot markup because he wants to avoid contructs that non-conformant HTML parsers can't deal with. But it is still entirely unclear why a specification is needed; he is totally free to invent whatever restrictions he likes on the output of his tool beyond that logically required by the existing specs. Since it is an assumption that the cons |
| 12:49 | <jgraham> | ... is no possibility of consumers and producers converging on common behaviour. It sounds like what he wants is a document describing how to avoid bugs in existing consumers. Which doesn't sound much like a Rec. track spec. |
| 12:51 | <smaug____> | what is polyglot |
| 12:52 | smaug____ | must have missed something amusing |
| 12:52 | <hsivonen> | smaug____: good for you |
| 12:52 | <jgraham> | It's a way for markup geeks to rathole the HTMLWG |
| 12:54 | <hsivonen> | smaug____: (It’s making a document both HTML and XHTML at the same time so that you can swap the content-type header and keep the same DOM) |
| 12:54 | <jgraham> | (modulo some constructs that just don't work) |
| 12:55 | <smaug____> | sounds like something silly |
| 12:55 | <smaug____> | so, amusing |
| 12:57 | <hsivonen> | “It is helpful and pragmatic advice” http://intertwingly.net/blog/2012/11/09/In-defence-of-Polyglot#c1352465225 |
| 13:10 | <zcorpan> | smaug____: the old name for it is "appendix c" |
| 13:14 | <zcorpan> | "Similarly, it would be great if browser vendors didn’t have to agree on error recovery as this makes the creation of streaming parsers more difficult." um, it's not the agreeing on error recovery that makes streaming difficult |
| 13:14 | <zcorpan> | it's streaming-incompatible error recovery being required for web compat that makes streaming "difficult" |
| 13:19 | <jgraham> | In fairness there is a reading of that that isn't insane; "it would be nice if browsers didn't need to do error recoveray at all" |
| 13:19 | <jgraham> | *recovery |
| 13:20 | <jgraham> | Although since two sentences up he said that he wouldn't recommend a format with no error recovery, it's hard to work out what the consistent position is |
| 13:21 | <jgraham> | (for large values of two) |
| 13:30 | <zcorpan> | annevk: is there a twitter account for quirks changes? |
| 13:32 | <annevk> | zcorpan: I haven't created one |
| 13:33 | <annevk> | jgraham: zcorpan: I recommend leaving a comment, Sam is fairly responsive usually |
| 13:47 | <zcorpan> | annevk: is http://enable-cors.org/#how right about the space-separated value? |
| 13:57 | <hsivonen> | zcorpan: I thought you could only have * or one host |
| 13:57 | <zcorpan> | right |
| 14:03 | <zcorpan> | "In practice the origin-list-or-null production is more constrained. Rather than allowing a space-separated list of origins, it is either a single origin or the string "null"." http://fetch.spec.whatwg.org/#http-access-control-allow-origin |
| 14:05 | <zcorpan> | annevk: why is the authoring conformance criteria wrong? |
| 14:08 | <hsivonen> | Sam was successful in getting me into the 386 mode. :-( |
| 14:11 | <annevk> | zcorpan: the author conformance criteria are under resources |
| 14:13 | <zcorpan> | annevk: i'm looking at http://fetch.spec.whatwg.org/#access-control-allow-origin-response-header |
| 14:13 | <annevk> | yeah, we need HTTP to update I guess |
| 14:14 | <annevk> | and then we can fix that section |
| 14:17 | <zcorpan> | it doesn't reference http. why does http need to update? |
| 14:18 | <annevk> | so that it's more clear how to define a header value |
| 14:18 | <annevk> | and yeah, for this I guess Origin needs to be fixed too |
| 14:19 | <annevk> | but I'm not sure if we need this syntax section at all |
| 14:19 | <zcorpan> | can't you do s#origin-list-or-null#%x6E %x75 %x6C %x6C / serialized-origin# |
| 14:20 | <annevk> | / "*" ? |
| 14:20 | <annevk> | euh | |
| 14:21 | <annevk> | oh, it's / these days |
| 14:21 | <annevk> | oh but not in HTTP |
| 14:21 | <annevk> | man this shit is confusing |
| 14:22 | <annevk> | zcorpan: feel free to file a bug but please consider if we should say something in the Origin header section too |
| 14:22 | <annevk> | zcorpan: I'm gonna look at garbage collection for mutation observers first |
| 14:23 | <zcorpan> | ok |
| 14:24 | <zcorpan> | i don't recall how origin: works. does it use multiple values for redirects or something? |
| 14:24 | <annevk> | no, it's the same |
| 14:24 | <annevk> | but they rejected my errata for the Origin RFC |
| 14:25 | <hsivonen> | gotta love how Sam calls my wording condecending after starting a post with “I see that Henri Sivonen is once again being snarky without backing his position.” |
| 14:26 | <zcorpan> | annevk: i guess we either need to put in a willful violation or take over editing of the origin spec :-( |
| 14:26 | <annevk> | Origin allows subsetting it |
| 14:27 | <annevk> | and only HTML fetch and CORS are involved with setting Origin |
| 14:27 | <annevk> | so it's kinda okay |
| 14:27 | <zcorpan> | ok |
| 14:27 | <annevk> | but I think in the end we should just fold it into "Fetch" therefore |
| 14:32 | <zcorpan> | ok filed a bug |
| 14:32 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=19920 |
| 14:34 | <hsivonen> | hmm. krijn is here but logs stopped growing. |
| 14:36 | <annevk> | krijn: ^^ |
| 14:47 | <karlcow> | log overflow |
| 14:49 | <jgraham> | An unfortunate consequence of blocked tubes |
| 14:50 | <hsivonen> | Sam is very good at writing something that’s annoying in the 386 sense to bait a reply |
| 14:53 | <zcorpan> | hsivonen: now go back to killing utf-16 :-) |
| 15:02 | <karlcow> | http://www.twilio.com/engineering/2012/11/08/adventures-in-unicode-sms |
| 15:03 | <hsivonen> | hmm. has optgroup been in the "special" group at some point during the lifetime of the spec? |
| 15:59 | <annevk> | jgraham: what is confusing about empty text node? |
| 16:00 | <annevk> | I guess I'll just add a definition |
| 16:17 | <annevk> | GPHemsley: why would we want sniffing to be configurable? do we expect anyone to actually do that? |
| 16:18 | <GPHemsley> | annevk: Well, the spirit of the old document pointed in that direction. And Gecko currently does very little sniffing. |
| 16:19 | <GPHemsley> | (At least, compared to e.g. Chrome.) |
| 16:24 | GPHemsley | wonders what 386 is. |
| 16:28 | SimonSapin | too (about 386) |
| 16:30 | <GPHemsley> | "Perhaps this is the most literal "corner case" in the history of software." |
| 16:36 | <annevk> | it's a reference to a URL |
| 16:36 | <annevk> | http://xkcd.com/386/ |
| 16:41 | <GPHemsley> | Oh, wow. XKCDs are just referred to as numbers now? |
| 16:42 | <annevk> | 386 is |
| 16:42 | <GPHemsley> | That's cool. |
| 16:43 | <GPHemsley> | annevk: BTW, looks like Larry's coming around on more fronts than just URL. This is good news. :) |
| 16:43 | <annevk> | may or may not have started with http://annevankesteren.nl/2010/09/h264-still-not-free |
| 16:44 | <annevk> | GPHemsley: pointer? |
| 16:44 | <GPHemsley> | annevk: Private e-mail, sorry. |
| 16:44 | <annevk> | GPHemsley: btw, I think http://www.ietf.org/audio/ietf85/ietf85-grandballroomc-20121108-1730-pm3.mp3 has contents |
| 16:44 | <annevk> | GPHemsley: you just need to wait a couple of minutes |
| 16:45 | <GPHemsley> | When I checked it last night, it seemed to be really quiet "Sorry about my computer problems" |
| 16:45 | <annevk> | GPHemsley: it's background noise at least until 1:40 or so, but at some point it should start |
| 16:45 | <annevk> | GPHemsley: it's a big file |
| 16:45 | <GPHemsley> | Interesting... it seems to not be loading correctly, then. |
| 16:46 | <GPHemsley> | because it only lasts a few seconds when I play it in-browser |
| 16:46 | GPHemsley | tries downloading it. |
| 16:46 | <GPHemsley> | Hmm |
| 16:47 | <GPHemsley> | I wonder whether Firefox or the QuickTime plugin is at fault here. |
| 16:47 | <annevk> | GPHemsley: works in Chrome here |
| 16:47 | GPHemsley | shrugs |
| 16:47 | <annevk> | yeah not sure if useful |
| 16:51 | <GPHemsley> | Ah, the actual meeting starts at the 4-minute mark |
| 16:54 | <GPHemsley> | "Let them have it!" |
| 16:57 | <GPHemsley> | There is some anonymous W3C document that used to reference the IETF draft that now references the WHATWG version. |
| 16:57 | <annevk> | I think that's the HTML spec |
| 16:57 | <GPHemsley> | Trying to get clarification on what that document was. (I'm assuming HTML(5) at this point.( |
| 16:57 | <GPHemsley> | ) |
| 16:57 | <GPHemsley> | ) |
| 16:57 | <annevk> | oh, and maybe Widgets? |
| 16:58 | <GPHemsley> | No idea. |
| 16:59 | <GPHemsley> | The relevant portion of the audio is between the 5-minute to 10-minute points, if you're interested. |
| 16:59 | <GPHemsley> | (If you haven't already listened to it.) |
| 17:01 | <GPHemsley> | 7:20 to 10:20, specifically |
| 17:04 | <GPHemsley> | The first reference to 386 in the logs appears to be 2008-04-08. |
| 17:05 | <GPHemsley> | The first use of '386' by itself appears to be on 2010-09-14, by hsivonen. |
| 17:06 | <GPHemsley> | But annevk expresses knowledge of its use at that time, implying that it had been used as such elsewhere. |
| 17:06 | <GPHemsley> | s/\./ previously\./ |
| 17:07 | <GPHemsley> | ahf: annevk see last two blog posts I made |
| 17:07 | <GPHemsley> | -f |
| 17:07 | <GPHemsley> | annevk: So it seems you may be right about your H264 blog post. |
| 17:08 | <GPHemsley> | (I didn't notice the first time that you used "386" in the post title.) |
| 17:09 | <GPHemsley> | zcorpan used "386" as a verb on 2011-02-03 |
| 17:09 | <GPHemsley> | Which may its first use outside of "386 time" |
| 17:10 | <GPHemsley> | So, it seems that '386' can be used as a noun, verb, and adjective. |
| 17:10 | <GPHemsley> | "Everything you wanted to know about '386' but were afraid to ask." |
| 17:28 | <annevk> | man, why can't we kill childElementCount? |
| 17:29 | <annevk> | prolly cause https://code.google.com/codesearch#search/&q=childelementcount%20lang:js |
| 17:29 | <annevk> | ffffffffuuuuuuuuuuu |
| 18:14 | <Hixie> | hsivonen: i'm amused that what would, by most standards groups, be considered overly-verbose text, is what you consider to be my being lazy in spec writing :-P |
| 19:27 | <Hixie> | ah, rats |
| 19:27 | <Hixie> | the origin of ImageBitmap objects is going to be a mess |
| 19:27 | <Hixie> | if you create an ImageBitmap from a CORS-same-origin <img> |
| 19:27 | <Hixie> | then you post that ImageBitmap to a worker |
| 19:27 | <Hixie> | and then you change hte origin of the document using document.domain |
| 19:28 | <Hixie> | should the origin of the ImageBitmap change? |
| 19:28 | <Hixie> | what if you post it to a worker again afterwards, are the two resulting ImageBitmaps in the worker same-origin? |
| 19:28 | <Hixie> | i'm thinking the answer is that we always _copy_ the origin, don't alias it, since we can't alias across workers and we don't want the behaviour to change based on who you posted the image to |
| 19:29 | <Hixie> | which means it would become cross-origin afte you change document.domain |
| 19:48 | <annevk> | why would you consider document.domain? |
| 19:48 | <annevk> | CORS does not have to be affected by document.domain |
| 19:48 | <annevk> | it can just the actual origin, not the effective origin |
| 19:50 | <Hixie> | hmm |
| 19:50 | <Hixie> | so wait |
| 19:50 | <Hixie> | why do we have aliases then |
| 19:50 | <annevk> | gotta run actually |
| 19:50 | <Hixie> | oh, i remember |
| 19:50 | <Hixie> | nevermind |
| 19:57 | <Hixie> | hm |
| 19:57 | <Hixie> | if you take a canvas |
| 19:57 | <Hixie> | get a proxy |
| 19:57 | <Hixie> | send it to another origin |
| 19:57 | <Hixie> | and they draw on it |
| 19:57 | <Hixie> | should you be able to read it? |
| 19:58 | <Hixie> | i guess not |
| 20:01 | <Hixie> | if, in a worker, you draw green to a canvas, commit, then draw red to the canvas, don't commit, and then spin an infinite loop; and then outside the worker you try to get the bitmap data, you'll get green. |
| 20:01 | <Hixie> | but what if in a worker, you draw green to a canvas, commit, then draw red to the canvas, don't commit, and then try to get the bitmap data? |
| 20:02 | <Hixie> | getImageData() will return red, that's clear |
| 20:02 | <Hixie> | drawImage() presumably will too |
| 20:02 | <Hixie> | but what about createImageBitmap()? |
| 20:03 | <Hixie> | i guess getting stuff from the Proxy should return the red bitmap, but getting stuff from the canvas should return the green one... |
| 20:04 | <Hixie> | that makes sense, basically have the proxy itself be the decided in terms of where the pixels get to |
| 20:04 | <Hixie> | ok |
| 20:16 | <GPHemsley> | In Which Hixie Explains to Himself How Things Work |
| 20:20 | <Hixie> | i dump my thought process to #whatwg in the interests of transparency :-P |
| 20:24 | <Hixie> | sicking: any idea what origin a Blob should be treated as having? |
| 20:24 | <Hixie> | entry script's origin, i guess? |
| 20:25 | <sicking> | Hixie: I believe that in firefox we use the origin of the window from which you got the URL object |
| 20:26 | <sicking> | Hixie: i.e. windowB.URL.createObjectURL(blob) => windowB.location.origin is used as origin |
| 20:26 | <sicking> | Hixie: but you'd have to check |
| 20:26 | <Hixie> | that disagrees with the spec, fwiw. But I actually meant for a case like createImageData(Blob) followed by drawImage(imageData) |
| 20:26 | <Hixie> | (file api spec says origin of blob: URL is the origin of the script that called the method) |
| 20:27 | <Hixie> | (not that it matters since all these origins are forcibly the same) |
| 20:27 | <Hixie> | (unless you have document.domain, i guess) |
| 20:28 | <sicking> | Hixie: I'm not sure I understand. Does imageData have an origin? I.e. can it ever taint the canvas? That doesn't seem needed if you can't get imageData from a "foregin" canvas |
| 20:28 | <sicking> | Hixie: With blobs we assume that if you have access to the Blob object you have access to its data. Just like with a string |
| 20:28 | <sicking> | Hixie: can imageData do the same thing? |
| 20:29 | <Hixie> | you can get a cross-origin ImageData by constructing it from a cross-origin <img> |
| 20:29 | <sicking> | ugh |
| 20:29 | <Hixie> | and you can pass them to cross-origin workers |
| 20:29 | <Hixie> | so even if they only start off same-origin, they can end up in other origins |
| 20:30 | <sicking> | when did we get cross-origin workers? |
| 20:30 | <Hixie> | never not had them |
| 20:30 | <sicking> | explain |
| 20:30 | <Hixie> | you can create a port in a worker in one origin, post it to your document, have that document post it to another origin's document via an iframe, and have it post it to its own worker |
| 20:30 | <sicking> | ah |
| 20:30 | <Hixie> | now the workers can directly communicate |
| 20:30 | <Hixie> | but are cross-origin |
| 20:31 | <sicking> | i still think that having access to a imageData should be equivalent to having access to the data it holds |
| 20:31 | <sicking> | that matches what string, arraybuffers, blobs and js-objets do |
| 20:31 | <Hixie> | if you post a blob to another origin, you give them access to the data? i guess that is true, huh |
| 20:31 | <Hixie> | interesting |
| 20:32 | <Hixie> | so maybe you just can't create an ImageData from a cross-origin <img>, but once you've created an ImageData, it's just always same-origin? |
| 20:32 | <Hixie> | that certainly would make my life easier |
| 20:32 | <sicking> | yeah |
| 20:32 | <sicking> | that's a much simpler mental model I'd say |
| 20:32 | <Hixie> | that's for damn sure |
| 20:32 | <Hixie> | wonder what the implications are for security |
| 20:32 | <Hixie> | i guess it's no worse than now |
| 20:32 | <Hixie> | since you can always serialise to data: and pass that around |
| 20:33 | <sicking> | exactly |
| 20:33 | <Hixie> | sir, you have made my life significantly easier |
| 20:33 | <sicking> | or to a string |
| 20:33 | <Hixie> | so five points to you |
| 20:33 | <sicking> | you're welcome :) |
| 20:33 | Hixie | starts deleting text :-P |
| 20:40 | <Hixie> | aw man, yeah, that's way cleaner |
| 20:53 | <Hixie> | wow |
| 20:53 | <Hixie> | one omitted </dfn> tag in the spec made the validator Very Angry |
| 21:33 | <JonathanNeal> | What do you folks think of these html markup options for a poll? https://gist.github.com/4041906 |
| 21:47 | <divya> | a lot of you here came to our test the web forward paris event http://blogs.adobe.com/webplatform/2012/11/09/test-the-web-forward-paris/ |
| 22:11 | <Hixie> | JonathanNeal: i'd replace the aria-label="poll" with <fieldset> <legend> Poll </legend> so that everyone could benefit, but otherwise they seem about equivalent |
| 22:12 | <JonathanNeal> | Hixie: I would love to use a field set and a legend, but legends are impossible to style with sanity. |
| 22:13 | <Hixie> | <section><h1>...</h1> then |
| 22:15 | <JonathanNeal> | form > fieldset > legend + section > h1? Or form > section > h1? |
| 22:15 | <Hixie> | section > form > h1 is probably how i'd do it, but doesn't matter one way or the other :-) |
| 22:15 | <Hixie> | not fieldset and section though |
| 22:16 | <JonathanNeal> | oh good. |
| 22:16 | <JonathanNeal> | Because a poll may have multiple parts, would form > section be all right? |
| 22:17 | <Hixie> | form is like <div> as far as this kind of thing goes |
| 22:17 | <Hixie> | doesn't matter where you put it, semantically |
| 22:17 | <Hixie> | hard to give more concrete advice without seeing the full thing in context though |
| 22:23 | <Hixie> | roc: so with a worker drawing to a canvas, the plan is to not actually update the screen until either the worker spins its event loop, or until the worker calls commit() on the CanvasProxy object |
| 22:23 | <roc> | sounds good |
| 22:23 | <Hixie> | roc: question, though: should it also commit if you try to drawImage() using the CanvasProxy, or try to use getImageData()? |
| 22:24 | <Hixie> | or should those grab the data from an off-screen buffer somehow? |
| 22:24 | <roc> | I think not |
| 22:24 | <roc> | I think the way this has to work is that there's a local copy of the canvas that gets updated by drawing commands in the worker |
| 22:24 | <roc> | and logically, commit() makes a copy of that for rendering to the screen |
| 22:24 | <roc> | getImageData etc simply access the local copy |
| 22:24 | <Hixie> | ok, that's what i was hoping you'd say |
| 22:25 | <Hixie> | does it make sense then to just let you create a CanvasProxy without it actually being connected to a real <canvas>? i.e. one on which there is no commit()? |
| 22:25 | <Hixie> | (obviously we'd have to find a new name) |
| 22:25 | <roc> | apart from being logical in terms of the mental model, it would be insane to have getImageData or drawImage cause screen updates with partially rendered content |
| 22:26 | <roc> | yes, that would be very useful |
| 22:26 | <roc> | although you could just have commit() be a noop |
| 22:26 | <Hixie> | sure, that's a detail |
| 22:28 | <Hixie> | maybe i should just make the 2d contexts have constructors and be bindable the way the gl people are doing |
| 22:42 | <JonathanNeal> | I hope this clarifies things better, Hixie. https://gist.github.com/4041906 |
| 22:42 | <JonathanNeal> | I'm personally in favor of the third and fourth options. |
| 22:43 | <Hixie> | for bRevity i'd prefer the first one with <p> in front of each <label> |
| 22:43 | <Hixie> | but that, or any of hte first three, are exactly equivalent |
| 22:44 | <Hixie> | the fourth (with links) is semantically weird since a GET request shouldn't have side effects like picking an option in a poll |
| 22:44 | <Hixie> | if you want that kind of UI (one-activation instead of pick a radio button then click a button), which i agree is better, then i'd use <input type=submit> or <button type=submit>. |
| 22:45 | <Hixie> | roc: do you know anything about what the purpose of binding WebGLRenderingContext objects to two canvases is? |
| 22:47 | <JonathanNeal> | Hixie, good advice. Okay. |
| 22:48 | <JonathanNeal> | If I used a <p> there would be unaccounted groupings. |
| 22:49 | <JonathanNeal> | unless I put a div around all the options' <p> . |
| 22:51 | <Hixie> | unaccounted groupings? |
| 23:38 | Hixie | ponders whether to have these transferable objects go from the context to the canvas or the canvas to the context |
| 23:39 | <Hixie> | (as in, do you get a canvasproxy to which you can bind a context in a worker, or a contextproxy that you can bind to a canvas on the main thread) |
| 23:39 | <Hixie> | canvasproxy probably makes the most sense |
| 23:42 | <JonathanNeal> | Hixie, yea, in the first example there was no element wrapping just the four options. Those wrappers make it useful for styling. |
| 23:58 | <Hixie> | JonathanNeal: ah well if you want to wrap things feel free to just stick <div>s wherever you want |
| 23:59 | <dglazkov> | Hixie: in custom DOM elements, I need to run lifecycle callbacks for all newly created elements right after the HTML parser finishes. What's the appropriate HTML idiom for this? |