| 00:07 | <heycam> | Hixie, can I give you a perl script rather than a diff to remove the "in"s? |
| 00:08 | <heycam> | Hixie, http://pastebin.mozilla.org/1302853 |
| 00:08 | <heycam> | I didn't check the output extensively, but it looks right on a first glance :) |
| 00:12 | Philip` | notes the $a thing could likely be replaced by "..", like "while (<>) { if (/<pre class="idl/ .. /<\/pre>/) { s/whatever/ } }" |
| 00:12 | <Philip`> | which is one of my top 50 favourite Perl features |
| 00:14 | <annevk> | yay for removing 'in' |
| 00:14 | <annevk> | now modules |
| 00:14 | <Hixie> | heycam: i'll try, but it scares me! |
| 00:14 | <heycam> | Philip`, wow I don't know about that feature |
| 00:15 | <heycam> | Philip`, is it an implicit while loop there? |
| 00:15 | <Philip`> | heycam: The "while (<>) {" looks pretty explicit to me :-) |
| 00:15 | <Hixie> | what is ".."? is that new? |
| 00:16 | <heycam> | oh I see, so it's not an implicit loop, just an implicit variable |
| 00:16 | <Hixie> | wow i never knew about the bistable .. operator |
| 00:16 | <Philip`> | Scalar ".." is a flip-flop |
| 00:17 | <Philip`> | It goes true when the first operand is true, and false when the second goes true |
| 00:18 | <Philip`> | It's existed forever, I think |
| 00:18 | <heycam> | that's kind of awesome |
| 00:19 | <Hixie> | that's pretty sweet |
| 00:20 | <Philip`> | (Given http://www.cs.cmu.edu/cgi-bin/perl-man it seems to have existed since before Perl 5) |
| 00:22 | <Hixie> | ok well i found some problems with this scrtip |
| 00:22 | <Hixie> | e.g. it missed "[Clamp] in..." |
| 00:22 | <heycam> | ah! |
| 00:22 | <heycam> | do you want me to fix it or can you handle it? |
| 00:23 | <Hixie> | i found four. fixed them. |
| 00:23 | <heycam> | ah cool. only four extended attributes on arguments? fewer than i thought there'd be. |
| 00:24 | <Hixie> | two [Clamp]s and two [AllowAny]s |
| 00:24 | <Hixie> | one of the [Clamp]s is movign to the arraybuffer spec soon |
| 00:26 | <heycam> | cool |
| 00:26 | <Hixie> | no webidl errors |
| 00:26 | <Hixie> | if we missed any i guess we'll find out when dom updates the checker |
| 00:27 | <Hixie> | is there a bug # for this? |
| 00:29 | <Hixie> | couldn't find it again. nevermind, i'll just commit without a bug #. |
| 00:31 | <annevk> | there's no bug |
| 00:31 | <Hixie> | k |
| 01:12 | <Hixie> | did anyone else get invited to this schema.org thing next month? (foolip?) |
| 01:48 | <mkanat> | "in which the transparent element finds itself" seems redundant in this paragraph: http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#transparent |
| 01:48 | <mkanat> | Should I file a bug? |
| 01:50 | <TabAtkins> | Ah, now I understand the scalar .. operator. It's defining a range implicitly over multiple invocations. |
| 02:26 | <yuhong> | Just found this: http://picturoku.blogspot.com/2011/08/diaries-of-vulnerability.html |
| 05:58 | <zcorpan> | Hixie: &lt in r6493 should be < |
| 05:58 | <Hixie> | can you paste the rest of the line? |
| 05:59 | <zcorpan> | + <strong><option value=""> Select unit type </option></strong> |
| 05:59 | <Hixie> | oh yeah i fixed that already |
| 05:59 | <zcorpan> | ok |
| 06:00 | <Hixie> | thanks though! |
| 06:28 | <zcorpan> | ooh, meta robots, why haven't we thought of that before? |
| 09:08 | <asmodai> | hahaha: http://imgur.com/1nZfG |
| 09:30 | <rimantas> | yup. Saw the post on HN, did not expect it to be _that_ bad |
| 09:35 | <annevk> | Hixie, in the base URL change steps change you used <span> instead of <dfn> |
| 09:38 | <annevk> | zcorpan, did you see my comments in the XHR bugs? |
| 09:39 | <zcorpan> | nope |
| 09:41 | <annevk> | it seems you don't get email for bugs |
| 09:41 | <zcorpan> | indeed. i think i've set that up since i usually get email anyway on public-html-bugzilla etc |
| 09:42 | <zcorpan> | but i'm not subscribed to public-webapps-bugzilla if there's such a thing |
| 09:44 | <zcorpan> | annevk: seems like a bug in eventsource if it can get still get open/error events and be GC |
| 09:44 | <annevk> | yeah, filed that bug |
| 09:45 | <annevk> | but EventSource also uses strong reference rather than the language WebSocket uses |
| 09:45 | <annevk> | heycam, idea I had last night |
| 09:45 | <zcorpan> | *shrug* |
| 09:45 | <annevk> | heycam, Web IDL defines DOMException |
| 09:46 | <annevk> | heycam, other than that we keep exceptions the way they are and if people want new exceptions they define extensions to Web IDL, to be coordinated via the WebApps WG |
| 09:46 | <zcorpan> | maybe websockets should use "strong reference" also |
| 09:46 | <heycam> | annevk, to solve the coordination problem? |
| 09:46 | <annevk> | you can say shrug, but if you don't really know what's going on that's quite confusing |
| 09:47 | <annevk> | heycam, yeah, we just consolidate all exceptions into DOMException and just like DOMString and DOMTimeStamp Web IDL takes care of it |
| 09:47 | <annevk> | heycam, that way you only need a reference to Web IDL to make use of DOMException too |
| 09:47 | <heycam> | annevk, maybe. I'm not too fussed where DOMException itself lives -- I would be fine with it in DOM Core still. |
| 09:48 | <zcorpan> | annevk: agree it should use the same language if it means the same |
| 09:48 | heycam | has to run |
| 09:49 | <annevk> | heycam, the idea is more that there would be nothing apart from DOMException |
| 09:49 | <annevk> | guess I'll add that to some bug somewhere |
| 09:50 | <zcorpan> | annevk: did you file a bug about language difference between websocket/eventsource? |
| 09:52 | <annevk> | I think I put that in the same bug |
| 09:52 | <annevk> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=13812 |
| 09:52 | <annevk> | could use some elaboration maybe |
| 09:53 | <david_carlisle> | hixie: (who isn't here) Henri's parser doesn't like the complete spec: Recoverable error on line 31460 column 13 of complete.html: |
| 09:53 | <david_carlisle> | SXXP0003: Error reported by XML parser: No dt element in scope but a dt end tag seen. |
| 09:53 | <david_carlisle> | would it be possible to remove the /dt from line 31460 which is currently </dt></dt></dt><dd> |
| 09:55 | <jgraham> | david_carlisle: File a big? |
| 09:55 | <jgraham> | *bug |
| 09:55 | <jgraham> | But it could be an error somewhere in the pipeline ofc |
| 09:55 | <jgraham> | In fact I'm not really sure how Hixie could cause that |
| 09:56 | <david_carlisle> | jgraham: yes i suppose I should, the spurious dts are explict in wget http://www.whatwg.org/specs/web-apps/current-work/complete.html, not in a file I had pre-processed |
| 09:56 | <annevk> | also, reported by XML parser? |
| 09:57 | <david_carlisle> | oh that was really Henri's html 5 parser, just that I was using its sax interface so saxon thought itwas xml... |
| 09:58 | <annevk> | crazy ;p |
| 09:59 | <zcorpan> | probably a bug in the html parser that's used in anolis or something |
| 10:00 | <jgraham> | david_carlisle: Right, but Hixie's text goes through a parser -> tree -> serializer pipeline |
| 10:00 | <zcorpan> | where <dt> doesn't close dt |
| 10:00 | <jgraham> | So it seems unlikely that he could do anything that would cause a stray </dt> |
| 10:00 | <david_carlisle> | ah but I got a pdf out of xslt and tex with only using a few bytes of memory which seems to be rather less than the current pdf generation:-) |
| 10:01 | <annevk> | sweet |
| 10:01 | <david_carlisle> | jgraham: you're all using html rather than xml tools, things going wrong iand appearing in stray places is the expected behaviour isn't it:-) |
| 10:02 | <jgraham> | david_carlisle: Well in this case the input is being processed by an xml toolset with a hacked on html parser |
| 10:02 | <jgraham> | (libxml2) |
| 10:02 | <david_carlisle> | just like me then |
| 10:02 | <jgraham> | (specifically lxml) |
| 10:03 | <zcorpan> | isn't there a good perf html5 parser these days we can use instead? |
| 10:04 | <jgraham> | But I don't really see how that could cause the bug; you could have thought that as long as it generates a tree it can only be the serliaizer that causes ill-formed output |
| 10:04 | <zcorpan> | jgraham: if the input is <dl><dt>foo<dt>foo<dt>foo<dd>bar</dl> |
| 10:04 | <zcorpan> | jgraham: and the parser creates a tree where teh <dt>s are nested |
| 10:05 | jgraham | wonders if david_carlisle will use his xslt script to generate fortran bindings for the dom apis, for good measure :p |
| 10:05 | <zcorpan> | then voilà |
| 10:05 | <david_carlisle> | jgraham: want some? |
| 10:05 | <jgraham> | zcorpan: Oh, yes, that would do it I suppose |
| 10:06 | <jgraham> | david_carlisle: I'm good thanks :) |
| 10:06 | <david_carlisle> | jgraham: yes the file has the same number of <dt> and </dt> it's just that the html5 parser has closed some dt by the time it gets to the /dt/dt bit at that line |
| 10:06 | <jgraham> | So, uh, you could file a bug on the spec to use explicit close tags I guess |
| 10:07 | <zcorpan> | or flip a pref in the serializer to omit </dt> |
| 10:08 | <jgraham> | Or you could help hsivonen get the gecko html parser working for non-gecko uses |
| 10:10 | <annevk> | libxml2 guys should get their act together |
| 10:21 | <Dimitri87> | There is a failure on the following wiki page. http://wiki.whatwg.org/wiki/HTML_vs._XHTML#HTML_Elements_with_Optional_Tags There stands twice "dt" should one not mean "dd"? |
| 10:21 | <annevk> | zcorpan, so I think garbage collection rules can be pretty simple |
| 10:22 | <annevk> | if XMLHttpRequest is a) fetching and b) has event listeners for ... don't |
| 10:22 | <annevk> | otherwise, terminate any ongoing fetching algorithm and die happily |
| 10:29 | <foolip> | Hixie, I was invited, but I doubt Opera will be putting me on a plane to California for it |
| 10:36 | <jgraham> | Since Google have all the money they should have more conferences that they have to travel for :) |
| 10:47 | <Dimitri87> | Is that the right location for my report or should i do report this wrong info any where else? |
| 10:48 | <annevk> | you can fix it yourself ;) |
| 10:48 | <annevk> | it's a wiki |
| 10:54 | <zcorpan> | annevk: sounds good |
| 10:55 | <zcorpan> | annevk: except you can GC if there's just a loadstart listener and loadstart has already been fired |
| 11:30 | <Dimitri871> | annevk: ok done! |
| 11:32 | <annevk> | thanks! |
| 11:42 | <annevk> | zcorpan, I guess I will not mention them |
| 11:42 | <annevk> | they will only dispatch if you invoke send() |
| 11:42 | <annevk> | and invoke before send() returns |
| 11:47 | <zcorpan> | ah |
| 11:53 | Ms2ger | likes how Hixie added another Avenue Q reference |
| 11:55 | <zcorpan> | heh |
| 11:58 | <annevk> | is there a wiki page documenting the references? :) |
| 11:59 | <Ms2ger> | No, that should be hosted at IANA |
| 12:00 | <annevk> | damn it Julian |
| 12:01 | <MikeSmith> | annevk: I changed the XHR link to point to -2 and added a link to Adam's URL API doc |
| 12:01 | <MikeSmith> | but still not sure what crypto stuff you meant |
| 12:01 | <MikeSmith> | DOMCrypt or the random-number thing |
| 12:10 | <annevk> | MikeSmith, DOMCrypt I guess, but maybe the other too? |
| 12:10 | <annevk> | whatever is on window.crypto |
| 12:10 | <annevk> | or going to be there |
| 12:10 | <MikeSmith_> | hai |
| 12:17 | <annevk> | zcorpan, http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#garbage-collection |
| 12:17 | <annevk> | oh great |
| 12:18 | <annevk> | that needs some XHR1 markers |
| 12:19 | <smaug____> | annevk: why its state is HEADERS_RECEIVED, or its state is LOADING ? |
| 12:19 | <smaug____> | er, nm |
| 12:20 | <smaug____> | hmm |
| 12:20 | <smaug____> | annevk: yes, why "its state is HEADERS_RECEIVED, or its state is LOADING" |
| 12:21 | <annevk> | because those are states while it is fetching data? |
| 12:21 | <smaug____> | ah, I'm reading that wrong |
| 12:22 | <smaug____> | would it be easier to say something like "send() flag is set and state is not DONE" |
| 12:24 | <annevk> | yeah maybe |
| 12:24 | <smaug____> | but that depends on how the spec defines send() flag |
| 12:24 | <annevk> | currently the spec sort of associates the send() flag with OPENED |
| 12:24 | <smaug____> | I mean in which cases it is cleared |
| 12:24 | <annevk> | but only in prose |
| 12:25 | <annevk> | it would be either UNSENT or DONE btw |
| 12:27 | <zcorpan> | annevk: looks good |
| 12:29 | <MikeSmith> | so I see that Adam implemented window.crypto.getRandomFloat32Array(length) and window.crypto.getUint8Array(length) in WebKit but I can't find an actual spec for those anywhere |
| 12:30 | <zcorpan> | wonder if an open eventsource should set salvegeable to false. i guess it should |
| 12:31 | <annevk> | it didn't need make disappear at least |
| 12:31 | <annevk> | and that file in WebKit you said was about salvageable didn't contain references to XHR |
| 12:32 | <zcorpan> | oh, so browsers bfcache the page even if there's an ongoing XHR? |
| 12:33 | <annevk> | no idea :( |
| 12:33 | <annevk> | I don't really feel like diving into that either |
| 12:34 | <zcorpan> | shouldn't be so hard to test |
| 12:34 | zcorpan | checks |
| 12:35 | <MikeSmith> | ah, found http://wiki.whatwg.org/wiki/Crypto |
| 12:35 | <MikeSmith> | hmm, that's not it either |
| 12:39 | <Ms2ger> | MikeSmith, that's it, but it's out of date |
| 12:39 | <MikeSmith> | ok |
| 12:40 | <MikeSmith> | Ms2ger: so you are all implementing window.crypto.getRandomFloat32Array(length) and window.crypto.getUint8Array(length) ? |
| 12:40 | <Ms2ger> | I don't know who's implementing what |
| 12:41 | <Ms2ger> | Hmm |
| 12:41 | <Ms2ger> | I see a patch for getRandomValues in b.m.o |
| 12:42 | <Ms2ger> | Do you have a link to the webkit implementation? |
| 12:42 | <MikeSmith> | I find https://bugzilla.mozilla.org/show_bug.cgi?id=440046 and https://bugzilla.mozilla.org/show_bug.cgi?id=673432 |
| 12:42 | <MikeSmith> | yeah, lemme get a link to the bug |
| 12:43 | <MikeSmith> | in the mean time, http://trac.webkit.org/browser/trunk/Source/WebCore/page/Crypto.cpp |
| 12:43 | <Ms2ger> | That's fine |
| 12:43 | <MikeSmith> | bug is https://bugs.webkit.org/show_bug.cgi?id=22049 |
| 12:43 | <Ms2ger> | Er |
| 12:44 | <Ms2ger> | "Crypto::getRandomValues" |
| 12:45 | <Ms2ger> | Where did you get getRandomFloat32Array from? |
| 12:50 | <MikeSmith> | hmm, I guess that was an earlier patch |
| 12:50 | <MikeSmith> | https://bug-22049-attachments.webkit.org/attachment.cgi?id=81287 |
| 12:51 | <MikeSmith> | but it's now just Crypto::getRandomValues(ArrayBufferView* array, ExceptionCode& ec) |
| 12:51 | <MikeSmith> | http://trac.webkit.org/browser/trunk/Source/WebCore/page/Crypto.cpp |
| 13:16 | <zcorpan> | annevk: from my testing it seems opera and chrome bfcache even if there's an open XHR |
| 13:16 | <zcorpan> | annevk: firefox seems to think my navigation is a redirect and removes the previous history entry |
| 13:17 | <zcorpan> | http://simon.html5.org/dump/bfcache-test/ |
| 13:19 | <zcorpan> | so... yeah, when navigating back you have a dead XHR object |
| 13:26 | <zcorpan> | oh, actually |
| 13:26 | <zcorpan> | not dead |
| 13:26 | <Ms2ger> | Alive? |
| 13:27 | <zcorpan> | yeah |
| 13:27 | <zcorpan> | but you will miss the readystatechange events if it changes while you're away |
| 13:27 | <zcorpan> | at least in opera |
| 13:28 | zcorpan | tests other browsers |
| 13:29 | <annevk> | zombie XHR |
| 13:31 | <zcorpan> | but it seems chrome kills the XHR (i see it fills the log when navigating away) and does not bfcache anymore |
| 13:31 | <zcorpan> | maybe because i have an onreadystatechange listener now |
| 13:31 | <smaug____> | zcorpan: does chrome have bfcache? |
| 13:31 | <smaug____> | that is news to me |
| 13:32 | <zcorpan> | same with firefox |
| 13:32 | <zcorpan> | smaug____: it doesn't? http://simon.html5.org/dump/bfcache-test/baseline.html suggests it does |
| 13:34 | <smaug____> | I guess it just works quite differently |
| 13:34 | <annevk> | that also suggests Opera doesn't |
| 13:34 | <smaug____> | in some cases |
| 13:34 | <annevk> | at least in my build |
| 13:35 | <smaug____> | is there a reason to use sessionStorage in the test? |
| 13:35 | <zcorpan> | annevk: my opera says it was cached |
| 13:35 | <zcorpan> | annevk: 11.50 mac |
| 13:36 | <zcorpan> | smaug____: need a way to check if the script runs for the first time or second time |
| 13:37 | <annevk> | same, build 1074 here |
| 13:37 | <smaug____> | zcorpan: just set some variable |
| 13:37 | <zcorpan> | smaug____: i don't see how that would work |
| 13:39 | <smaug____> | if ("somevar" in window) alert("bfcached") |
| 13:40 | <zcorpan> | smaug____: if it is cached, the script doesn't run again when navigating back |
| 13:40 | <smaug____> | you could add some button which does " if ("somevar" in window) alert("bfcached")" |
| 13:40 | <smaug____> | in onclick |
| 13:40 | <smaug____> | or use pageshow |
| 13:40 | <smaug____> | (I don't know which browsers support pageshow event) |
| 13:40 | <zcorpan> | opera doesn't |
| 13:41 | <zcorpan> | does sessionStorage invalidate the test? |
| 13:41 | <smaug____> | don't know |
| 13:41 | <smaug____> | I was just curious why you use that |
| 13:42 | <zcorpan> | i don't see how the var would work -- if the page was not bfcached, then the script would run again, and the script would again set the variable |
| 13:42 | <zcorpan> | so the button would always say the variable is set |
| 13:42 | <jgraham> | Two buttons? |
| 13:43 | <jgraham> | One to set the variable, one to check it |
| 13:43 | <zcorpan> | ah, yeah |
| 13:44 | <zcorpan> | i just try to automate things without thinking about it :) |
| 13:52 | <smaug____> | zcorpan: also, IIRC, if load event listener causes a new page load, session history is handled specially |
| 13:53 | <smaug____> | so better to load a new page using a timer or something |
| 13:53 | <zcorpan> | smaug____: interesting |
| 13:54 | <zcorpan> | i noticed a difference in chrome if script navigates there and back |
| 13:54 | <zcorpan> | then it would cache |
| 13:54 | <zcorpan> | but if i navigate by clicking links, it doesn't cache |
| 13:54 | zcorpan | checks with a timeout |
| 13:55 | <annevk> | I suspect navigation is full of bugs |
| 13:57 | <smaug____> | zcorpan: session history implementations are full of bugs |
| 13:57 | <smaug____> | and the whole thing is underspeficied |
| 13:57 | <smaug____> | zcorpan: AFAIK, IE's session history is least buggy |
| 13:57 | <zcorpan> | chrome doesn't want to navigate from a timeout |
| 13:57 | <zcorpan> | smaug____: i'm here to get it better specified :) |
| 13:57 | <smaug____> | zcorpan: even if you do location = "url" ? |
| 13:58 | <smaug____> | zcorpan: awesome! |
| 13:58 | <smaug____> | (link.click() is just strange way to navigate to another page) |
| 13:59 | <zcorpan> | location = "url" worked |
| 13:59 | <zcorpan> | i used location first but firefox would just think that it was a redirect and remove the previous history entry |
| 13:59 | <smaug____> | you did that in load event listener |
| 13:59 | <zcorpan> | yeah |
| 14:00 | <zcorpan> | i guess it's better UX for pages that do scripted redirects |
| 14:01 | <zcorpan> | maybe we should spec this also |
| 14:04 | <annevk> | having to wait for load is not better UX though |
| 14:05 | <annevk> | I have pages that redirect using location because of fragment identifiers (that do not go to the server), but they execute directly |
| 14:07 | smaug____ | tries to find when the "handle session history differently during load" was added |
| 14:07 | <smaug____> | my guess is about 10 years ago |
| 14:07 | <annevk> | you actually need something like location.redirect() if you want to handle this properly |
| 14:07 | <annevk> | and then maybe grandfather Firefox' use of onload |
| 14:08 | <zcorpan> | there's already location.replace() |
| 14:08 | <annevk> | or maybe if location was set before any load event handlers return |
| 14:09 | <zcorpan> | anyway, i'm not getting any further with XHR and bfcache. seems it's sometimes cached and sometimes not |
| 14:09 | <annevk> | (and not involving user action...) |
| 14:09 | <zcorpan> | what behavior do we *want* for XHR? |
| 14:10 | <smaug____> | 2003 |
| 14:11 | <smaug____> | hmm, nothing too interesting in https://bugzilla.mozilla.org/show_bug.cgi?id=166736 |
| 14:12 | <smaug____> | zcorpan: have you already started to test the fun parts of session history handling: how to handle "dynamically" added iframes |
| 14:13 | <zcorpan> | smaug____: nope. i only intended to test XHR today |
| 14:14 | <zcorpan> | though i know iframes and navigation is not without problems |
| 14:15 | <smaug____> | yeah |
| 14:15 | <smaug____> | it is easy to get active back button which doesn't do anything |
| 14:15 | <smaug____> | or needs too many click |
| 14:15 | <smaug____> | s |
| 14:16 | <smaug____> | or in some cases it is even possible to get wrong document to be load to some iframe |
| 14:17 | <smaug____> | that used to be a bad problem in Gecko, but hopefully not anymore. IE and Webkit do, IIRC still suffer from that in some cases. Opera, again IIRC, doesn't have that problem |
| 14:18 | <zcorpan> | i recall we've had a number of bugs where teh back button just navigates an ad iframe instead of the whole page. and likely we've had the opposite problem as well. |
| 14:19 | <zcorpan> | dunno if it's good now |
| 14:19 | <zcorpan> | but i doubt it |
| 15:40 | <jgraham> | http://coding.smashingmagazine.com/2011/08/16/html5-and-the-document-outlining-algorithm/ is pretty nice |
| 16:30 | <jgraham> | Yay for things appearing in meeting notes that didn't actually get discussed at the meeting |
| 16:31 | <Ms2ger> | Where? |
| 16:34 | <jgraham> | public-html-testsuite |
| 16:34 | <jgraham> | "Microsoft submitted HTML5 Forms Tests (http://w3c-test.org/html/tests/submission/Microsoft/forms/)"; |
| 16:35 | <jgraham> | I don't remember that coming up and it isn't in the logs… |
| 16:35 | <Ms2ger> | Me neither |
| 16:35 | <jgraham> | In other news one of me|Microsoft has forgotten how missing value defaults are supposed to work |
| 16:35 | <Ms2ger> | Or both :) |
| 16:36 | <jgraham> | OK, at least one :) |
| 16:37 | <jgraham> | The spec is not entirely clear so I am starting to think that I am wrong |
| 16:38 | <jgraham> | If an enumerated attribute foo is in the missing value default state and you do x.foo will you get the default value back, or the empty string? |
| 16:39 | <AryehGregor> | http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflecting-content-attributes-in-idl-attributes |
| 16:39 | <AryehGregor> | If a reflecting IDL attribute is a DOMString attribute whose content attribute is an enumerated attribute, and the IDL attribute is limited to only known values, then, on getting, the IDL attribute must return the conforming value associated with the state the attribute is in (in its canonical case), or the empty string if the attribute is in a state that has no associated keyword value |
| 16:39 | <AryehGregor> | So it depends on whether there's a state associated with the missing value default state. |
| 16:39 | <AryehGregor> | The enum stuff is confusing. |
| 16:41 | <jgraham> | OK, so in this case it looks like it should return the missing value default |
| 16:41 | <jgraham> | So I am wrong |
| 16:41 | <jgraham> | But in some other cases I might be right :) |
| 16:41 | <jgraham> | Gotta love the web |
| 16:42 | <Hixie> | Ms2ger: i had to add it, i dropped the earlier one! |
| 16:43 | <Ms2ger> | You did? :( |
| 16:43 | <Hixie> | it was in the rdf stuff iirc |
| 16:43 | <dglazkov> | good morning. Whatwg! |
| 16:43 | <Philip`> | Also gotta love algorithms (like reflection) that are heavily dependent on complex details of the context in which that algorithm is called (like whether the attribute is an enum with known values etc etc), instead of having specialised versions and linking to the right one |
| 16:44 | <Hixie> | yeah reflection is a bit of a mess |
| 16:44 | <AryehGregor> | It would be a lot nicer if there were separate xrefs for the different types of reflection, yeah. |
| 16:44 | <AryehGregor> | Some of them were actually quite confusing when I first wrote my tests. |
| 16:45 | <AryehGregor> | IIRC, it was unclear in some cases whether some attributes were defined to take a URL or not. |
| 16:45 | <jgraham> | I wonder if I can write an irssi plugin that filters lines that are close matches for "good morning. Whatwg!" |
| 16:45 | <annevk> | morning dglazkov, and hi grumpy jgraham :p |
| 16:46 | <Philip`> | jgraham: "/ignore dglazkov"? :-) |
| 16:46 | <Philip`> | Might be kind of rude though :-( |
| 16:46 | <Hixie> | if anyone wants to send me a patch that changes reflection to N algorithms and updates all the xrefs to point to the right ones, i'd apply it |
| 16:46 | <Hixie> | not gonna spend the time to do it myself though |
| 16:46 | <Hixie> | too many bigger fish to fry |
| 16:47 | <jgraham> | Philip`: Well yeah but at other times he is not being gratingly cheery :) |
| 16:47 | <Hixie> | bbiab |
| 16:47 | <jgraham> | I can only imagine it will be even worse in a few months when it has already been dark for 3 hours here |
| 16:47 | <Philip`> | Maybe you just need a filter that does s/morning/evening/ ? |
| 16:48 | <Philip`> | Then you can be contentedly miserable while everyone else is jollied up by dglazkov's enthusiasm |
| 16:49 | dglazkov | helpfully suggests everyone moving to the Bay Area. |
| 16:49 | <dglazkov> | it's a freakishly gorgeous morning here. You just _can't_ not be cheerful. |
| 16:51 | <hober> | fsvo "bay area" |
| 16:51 | <hober> | it was pretty gross in sf this morning |
| 16:51 | <dglazkov> | ok, everyone move to Mountain View :) |
| 16:52 | <annevk> | all you have is Castro man |
| 16:52 | <Philip`> | Google should just hire the whole of #whatwg |
| 16:52 | <annevk> | though that street is kind of amusing, that's it |
| 16:53 | <dglazkov> | you should view the bay area as <input type="range"> |
| 16:53 | <hober> | annevk: indeed. nothing like the hustle and bustle of downtown cupertino |
| 16:53 | <hober> | oh, wait |
| 16:53 | <hober> | :) |
| 16:53 | <dglazkov> | at the top, in SF, it's awesome nightlife and gross mornings |
| 16:53 | <dglazkov> | at the bottom, in Saratoga, it's always sunny and really, really quiet |
| 16:53 | <annevk> | best of Cupertino is the city council when together with Steve Jobs |
| 16:53 | <hober> | annevk: indeed :) |
| 16:56 | <othermaciej> | SF has great mornings, if you like fog |
| 16:58 | <dglazkov> | fog no |
| 17:03 | <annevk> | http://lists.w3.org/Archives/Public/www-style/2011Aug/0503.html interesting perspective at the end on reading the HTML spec |
| 17:03 | <annevk> | if a bit ranty |
| 17:04 | <zewt> | "read it correctly"? what does that mean? heh |
| 17:04 | <zewt> | it's not like one normally reads a spec like that front-to-back |
| 17:06 | <Hixie> | have you seen the "how to read" section? :-) |
| 17:06 | <Philip`> | I think I once read about the first 2.5 sections from front to back, before getting bored and giving up |
| 17:07 | <Hixie> | annevk: it's a valid concern |
| 17:07 | <zewt> | i don't read things that tell me how to read, i learned that a long time ago :) |
| 17:07 | <Hixie> | annevk: i've been wondering what to do about it for a while |
| 17:09 | <Ms2ger> | I managed to get to the alt attribute section, at least |
| 17:09 | <Ms2ger> | I distinctly remember that my feedback was "tl;dr" |
| 17:11 | <Hixie> | hey it's better than html4's equivalent section |
| 17:11 | <annevk> | Hixie, the stability indicators should prolly be more prominent |
| 17:11 | <Hixie> | that one was "ts;ntr" ("too short, nothing to read") |
| 17:11 | <Hixie> | annevk: yeah |
| 17:11 | <Hixie> | annevk: i made them more obviously editable recently |
| 17:11 | <jgraham> | It's a valid concern, but the situation with CSS is at least as bad |
| 17:11 | <AryehGregor> | Maybe the stability indicators should affect the color scheme of the whole section? |
| 17:11 | <Philip`> | If it's too long for anyone to read then it's no more useful than writing nothing |
| 17:12 | <AryehGregor> | The way ED vs. WD does at the W3C? Well, that doesn't affect the color scheme of the whole section, but it's extremely visible. |
| 17:12 | <jgraham> | I mean at least HTML doesn't have cases where the leven N spec is right but the level N+1 spec is buggy |
| 17:12 | <AryehGregor> | Or N+0.9, as the case may be? |
| 17:12 | <Hixie> | Philip`: i'm sort of assuming some pedantic authors will read it all and then in discussions they'll point authors to the right subsections |
| 17:12 | <jgraham> | I don't think stability indicators are the right solution per-se |
| 17:12 | <Philip`> | The stability indicators seem to give way too little information to be any value to authors |
| 17:13 | <MikeSmith> | http://www.w3.org/community/editing/ |
| 17:13 | <MikeSmith> | oops |
| 17:13 | <Ms2ger> | Hi MikeSmith |
| 17:13 | <jgraham> | I think per-section implementation reports backed by testsuite results are the ideal solution |
| 17:13 | <Hixie> | AryehGregor: we could do something where a section that is marked as implemented by 3 or more UAs gets a thick border or something |
| 17:13 | <annevk> | oh nice, an edit link |
| 17:13 | <Ms2ger> | jgraham, testsuite? Where? ;) |
| 17:13 | <AryehGregor> | Philip`, they're more useful for implementers, I think. |
| 17:13 | <jgraham> | Ms2ger: Well yeah |
| 17:13 | <jgraham> | Think of the testsuite as icing |
| 17:14 | <MikeSmith> | Ms2ger: こんばんは |
| 17:14 | <jgraham> | But we should just integrate caniuse.com into the spec |
| 17:14 | <Hixie> | that would be interesting |
| 17:14 | <Hixie> | not sure how it should work |
| 17:14 | <annevk> | Hixie, for sections that do not yet have a status box you should have a create link |
| 17:14 | <Hixie> | annevk: are there any? i try to create them for every section |
| 17:14 | <Philip`> | It's not useful knowing that features are implemented in trunk versions - I expect authors want to know what caniuse shows (previous/current/next versions of browsers etc) though probably in much more detail, probably with some prose explaining which parts of features are broken or buggy |
| 17:14 | <jgraham> | Although it would provide a big incentive for people to release half-baked implementations of things to look good |
| 17:15 | <annevk> | Hixie, text/html-sandboxed does not have one |
| 17:15 | <Hixie> | if anyone wants to experiment with some scripts btw i'm happy to add them to the spec |
| 17:15 | <annevk> | Hixie, no idea how to fix |
| 17:15 | <jgraham> | So yeah, maybe the icing is important |
| 17:15 | <Hixie> | annevk: alt+double-click |
| 17:15 | <Hixie> | annevk: on the section |
| 17:15 | <MikeSmith> | heh -- Syd Lawrence has a great bio on his twitter page |
| 17:15 | <MikeSmith> | "I am a social web guru using HTML6, CSS4, AJAZ, using twitbook and facedIn. Expert with paint, frontpage and VBScript" |
| 17:16 | <MikeSmith> | http://twitter.com/#!/sydlawrence |
| 17:16 | <annevk> | Hixie, thx |
| 17:17 | <annevk> | Hixie, still not sure whether a little box on the side is helping |
| 17:17 | <Hixie> | yeah |
| 17:17 | <Hixie> | we could do some sort of background colour thing |
| 17:17 | <Hixie> | really no idea what to do |
| 17:17 | <jgraham> | But it still isn't the actual information that people want to know |
| 17:18 | <Ms2ger> | Which people? |
| 17:18 | <Hixie> | authors |
| 17:18 | <jgraham> | If, by some miracle, there is a section that is known to be stable and has 0 implementations, no one cares |
| 17:18 | <Hixie> | i agree that caniuse information is more helpful |
| 17:18 | <Ms2ger> | jgraham, you mean style scoped? |
| 17:18 | <jgraham> | Well I'm not sure if that is stable |
| 17:19 | <jgraham> | Or, I guess the HTML part is |
| 17:19 | <Hixie> | there's pending feedback on style scoped |
| 17:19 | <Hixie> | to do with selectors |
| 17:19 | <annevk> | authors want implemented and widely deployed |
| 17:19 | <Hixie> | don't we all |
| 17:19 | <annevk> | :p |
| 17:19 | <Ms2ger> | No |
| 17:19 | <Hixie> | there's a section status for "implemented and widely deployed" |
| 17:19 | <Hixie> | i don't think any part of the spec is marked that way yet |
| 17:20 | <jgraham> | Right, which is why we should actually give that information rather than providing some abstract proxy |
| 17:20 | <jgraham> | Which doesn't really macth |
| 17:20 | <Hixie> | oh, some bits are marked that way actually |
| 17:20 | <annevk> | yeah |
| 17:20 | <Hixie> | they all seem to also have all browsers marked as buggy! |
| 17:20 | <annevk> | acknowledgments is :) |
| 17:21 | <Hixie> | actually there's a bunch of sections marked this way |
| 17:21 | <Ms2ger> | To send or not to send D3E feedback... |
| 17:22 | <Philip`> | Boolean bugginess doesn't seem useful, since all browsers will always be buggy, at least in trivial details that nobody cares about - what matters is whether the bugs are easy to avoid or to work around (and also the bugs need to be documented so people know what to avoid) |
| 17:22 | <zewt> | documenting all of the bugs--now that sounds like a fun project |
| 17:23 | <Philip`> | All the bugs that authors will regularly hit, at least |
| 17:23 | <Ms2ger> | Might as well fix them |
| 17:23 | <jgraham> | Well they are already documented |
| 17:23 | <annevk> | Hixie, "no support whatsoever" should probably be renamed to "unknown" |
| 17:23 | <jgraham> | Just typically not cross-referenced with the spec |
| 17:23 | <AryehGregor> | The info that authors want is what other authors say browser support is like in practice. |
| 17:24 | <AryehGregor> | If there's a good test suite and a browser passes it, that should be sufficient to say it has good support, but it's far from necessary. |
| 17:24 | <jgraham> | AryehGregor: So we should allow authors to vote on whether a browser supports a particular thing in a good enough way? |
| 17:25 | <AryehGregor> | jgraham, no, just get one or a few good authors to put in the work. Like that QuirksMode guy does for some things. |
| 17:25 | <AryehGregor> | Or, realistically, just give up and let people figure out by word of mouth. |
| 17:25 | <Ms2ger> | jgraham, no, we should have them write tests |
| 17:25 | <AryehGregor> | Also, yeah, let's try actually writing tests. :) |
| 17:26 | <jgraham> | Ms2ger: What, as a fee for being allowed to look at the spec? |
| 17:26 | <Ms2ger> | wfm |
| 17:26 | <jgraham> | Put ads on it and encourage people to become "pro" spec readers by donating tests? |
| 17:26 | <Ms2ger> | Ship it! |
| 17:27 | <Philip`> | The HTML5 t-shirt money could be shared among those people |
| 17:27 | <jgraham> | I look forward to my 25p |
| 17:27 | <Ms2ger> | Do you get paid for all of Opera's tests? :) |
| 17:28 | <jgraham> | Point. I should revise that estimate down a bit |
| 17:32 | <annevk> | so is http://tantek.com/2011/220/b1/web-actions-a-new-building-block the next rel=tag or something we need to standardize? |
| 17:32 | <annevk> | I saw some <intent> element come by at some point |
| 17:33 | Ms2ger | wants <semantics> |
| 17:33 | <zewt> | wow that page is subtly really hard to read |
| 17:33 | <zewt> | and i'm not entirely sure why |
| 17:33 | <zewt> | even ignoring the silly inline diffs |
| 17:34 | <annevk> | still lobbying for background:unicorn |
| 17:34 | <annevk> | or background:unicorn |
| 17:34 | <annevk> | euh |
| 17:34 | <annevk> | double-rainbow |
| 18:05 | <annevk> | http://daringfireball.net/misc/2011/08/white-android-prototype.jpg hahaha |
| 18:10 | <Ms2ger> | Anybody who wants to place a bet on when I'll get a reply to my D3E comments? |
| 18:10 | <zewt> | after they've made an off-list decision |
| 18:11 | <Ms2ger> | Well, that's a given |
| 18:13 | <AryehGregor> | How easy would it be to write a tool that converts more or less arbitrary HTML5 into polyglot HTML5/XHTML5? |
| 18:14 | <Philip`> | Depending on how strictly you interpret "polyglot", probably impossible |
| 18:14 | <Philip`> | since you can't use inline scripts |
| 18:14 | <Philip`> | and can't use <pre> if the content starts with a blank line |
| 18:14 | <Philip`> | etc |
| 18:37 | <AryehGregor> | Philip`, polyglot to the extent of "it more or less looks the same when served as HTML vs. XHTML". |
| 18:38 | <AryehGregor> | Basically, I'm talking with Ian Jacobs, and he said that the W3C would be okay with allowing specs to be polyglot HTML5, but aren't so sure about regular HTML5. |
| 18:39 | <AryehGregor> | So if someone could just throw together a tool that would take the a text/html spec and output a polyglot one that behaves more or less the same, that would be helpful for progress. |
| 18:39 | <annevk> | the fuck? |
| 18:39 | <AryehGregor> | s/the// |
| 18:39 | <AryehGregor> | ? |
| 18:39 | <AryehGregor> | Well, what he said maybe wasn't official. |
| 18:39 | <AryehGregor> | So perhaps I shouldn't be repeating it in public. |
| 18:39 | <annevk> | polyglot is such nonsense |
| 18:39 | <AryehGregor> | He made it seem like that would be helpful, though. |
| 18:40 | <annevk> | and has been a failure for many years even when experienced web authors tried it |
| 18:40 | <AryehGregor> | It's reasonably harmless nonsense, though, and sure beats XHTML 1.0 or whatever the W3C's HTML5 is in. |
| 18:40 | <Ms2ger> | HTML4 |
| 18:40 | <Philip`> | Just set the HTML serialiser to not omit optional tags and to quote attributes, and stick an xmlns on it, and surely that'll be good enough |
| 18:41 | <Philip`> | It presumably doesn't need to actually work when parsed as XML (in terms of executing scripts correctly etc), it just needs to look well-formed enough |
| 18:41 | <AryehGregor> | Sounds plausible. |
| 18:41 | <annevk> | which is why it's wrong |
| 18:42 | <annevk> | either go your XML way and require XHTML5 or some such or just don't sit in the way |
| 18:42 | <AryehGregor> | However, doing things that are wrong but harmless is better than doing things that are wrong and also harmful, like having it be HTML 4. |
| 18:42 | <AryehGregor> | So in the interests of progress, it sounds better than the status quo by a large margin. |
| 18:42 | <AryehGregor> | Philip`, you'd have to set the serializer to use only numeric entities, too. |
| 18:42 | <Ms2ger> | anolis --quote-attr-values --no-minimize-boolean-attributes --use-trailing-solidus --space-before-trailing-solidus will probably get you a long way |
| 18:43 | <annevk> | AryehGregor, HTML4 does not bother me that much at the moment |
| 18:43 | <AryehGregor> | It bothers me vis-a-vis my spec, should I get around to publishing it as an ED. |
| 18:44 | <AryehGregor> | Ian was explaining to me that the CG's patent policy should really be just as good as the regular one, so maybe that won't be necessary. |
| 18:49 | <annevk> | I wonder why the W3C Team gets to decide on this and not the membership |
| 18:49 | <annevk> | karlcow always tells me the membership is in charge |
| 18:49 | <AryehGregor> | I don't think it's useful to worry about process issues here. |
| 18:50 | <AryehGregor> | Make sure the practicalities are in place, including our ability to leave if they decide to change their mind and do something stupid. |
| 18:50 | <AryehGregor> | What it says on paper doesn't matter. |
| 19:07 | <gsnedders> | annevk: probably for the same reason editors make a number of decisions and not WGs |
| 19:08 | <gsnedders> | Most of the time nobody really cares. |
| 19:11 | <annevk> | good point, editors should have a say in the format |
| 19:11 | <annevk> | this should be discussed on spec-prod |
| 19:12 | <annevk> | and the Team should justify their opinions there |
| 19:12 | <annevk> | spec-prod is http://lists.w3.org/Archives/Public/spec-prod/ fwiw |
| 19:13 | <Ms2ger> | Where are the canonical parsing tests? |
| 19:14 | <annevk> | http://code.google.com/p/html5lib/ I thought |
| 19:21 | <annevk> | gsnedders, thanks, asked why it's not discussed on spec-prod |
| 19:23 | <gsnedders> | annevk: That's really not what I meant. |
| 19:24 | <gsnedders> | annevk: The reason why the Team makes decisions and not Members is the same reason as why editors make decisions and not WGs. |
| 19:28 | <manu-db> | Does anybody know the history behind why "application/json" was picked over "text/json" - besides Douglas Crockford's rather cryptic response - "JSON is not really JavaScript and not really text"? Trying to figure out if JSON-LD should have an IANA registration for text/json-ld or application/json-ld or application/json+ld (JSON-LD is 100% compatible w/ JSON) |
| 19:30 | <AryehGregor> | I'd guess people here mostly aren't interested or knowledgeable about details of MIME type registration. |
| 19:30 | <AryehGregor> | (not that there's anything wrong with asking, I just wouldn't expect such a good answer here) |
| 19:30 | <manu-db> | alright - just attempting to be thorough in how we pick the name. |
| 19:30 | <manu-db> | s/name/mime type/ |
| 19:31 | <manu-db> | related browser question: Does any browser actually pay attention to the "+" part of a mime type? For example - "text/xml+xhtml" - do browsers go "oh, that's text/xml" and then go "oh, and it's also xhtml" - or do they just do a regular string comparison for "text/xml+xhtml"? |
| 19:32 | <annevk> | it's application/xhtml+xml |
| 19:32 | <manu-db> | sorry... that's what I meant. |
| 19:32 | <annevk> | and Opera pays special attention to +xml |
| 19:32 | <annevk> | not everyone does I believe |
| 19:32 | <Ms2ger> | There's an old Gecko bug to do that |
| 19:32 | <Ms2ger> | Don't think it's fixed yet |
| 19:32 | <annevk> | text/* in general is a flawed media type according to the IETF and therefore they encourage everyone to just use the application/* one |
| 19:32 | <manu-db> | just wondering what best practice might be from a browser perspective - application/json-ld or application/json+ld ? |
| 19:33 | <annevk> | which of course makes the distinction kind of pointless |
| 19:33 | <annevk> | we have been registering various new text/* types following what we think makes sense... |
| 19:33 | <annevk> | manu-db, doesn't matter |
| 19:33 | manu-db | nods - there doesn't seem to be a clear logical thread through picking MIMEType names... |
| 19:34 | <annevk> | though application/ld+json would make more sense |
| 19:34 | <annevk> | or is it not actually JSON? |
| 19:34 | <manu-db> | it is 100% compatible w/ json. |
| 19:34 | <manu-db> | it's just JSON in a particular structure. |
| 19:34 | <annevk> | then I guess it ought to be +json |
| 19:35 | <annevk> | the goal btw is for browsers to treat all XML media types the same way |
| 19:35 | <annevk> | as in you can label your XHTML file text/xml and it's fine |
| 19:35 | <annevk> | because in practice XML works based on namespaces, not media types |
| 19:36 | <manu-db> | one of the reasons I'm shying away from application/ld+json is because there is no such "application/ld" media type... and because I hate plus signs in MIME Types (although, that can't be a basis for any sort of technical decision). |
| 19:36 | <annevk> | manu-db, I guess you want application/ld+json so it's consistent with the original JSON (which should have been text/json but isn't) and the +xml precedent |
| 19:37 | <annevk> | there's no application/xhtml either so that first reason is groundless |
| 19:37 | <manu-db> | I want to be consistent - but it doesn't seem like any of this is actually consistent... |
| 19:37 | <manu-db> | hmm... true. |
| 19:37 | <kennyluck> | what about application/json+ld ? |
| 19:37 | <annevk> | kennyluck, the format is JSON, not LD |
| 19:37 | <manu-db> | kennyluck, that's under consideration as well... (bikeshedding) |
| 19:40 | Philip` | vaguely remembers reading that +s should be avoided in MIME types unless the suffix is defined by some specification |
| 19:41 | <Philip`> | (and probably nobody has defined a +json suffix yet) |
| 19:41 | <Philip`> | so using that character would be unnecessary hassle |
| 19:42 | <manu-db> | So, I just checked w/ the XHTML folks and they said: the convention for media types based upon XML is applicaiton/foo+xml - it is a convention handed down by the XML working group back in the day...I always thought it was backwards. |
| 19:42 | <manu-db> | Seems like Tim Bray created the +xml meme... |
| 19:42 | <manu-db> | http://www.ietf.org/rfc/rfc3023.txt |
| 19:43 | <manu-db> | This document also standardizes a convention (using the suffix '+xml') |
| 19:43 | <annevk> | doesn't matter who did it and whether or not it's backwards |
| 19:43 | <annevk> | if you are going to do it the other way around for JSON, people will not be kind |
| 19:44 | <manu-db> | which people? (just curious to know who would defend the +xml pattern) |
| 19:45 | <annevk> | everyone who wants some consistency in media types, like me I guess |
| 19:45 | <annevk> | (though I'd really like them to die, it seems we have to keep a few of them around) |
| 19:49 | <Hixie> | the w3c is so confusing |
| 19:49 | <Hixie> | half the decisions are not up to them but up to the membership |
| 19:49 | <Hixie> | while the other half are up to them |
| 19:49 | <Hixie> | and yet they do none of the work |
| 19:56 | <manu-db> | hmm... ok - application/ld+json it is |
| 19:57 | <manu-db> | Philip` any idea where you read the "don't use +s in MIME Type registrations" bit? |
| 19:57 | <Ms2ger> | Trying to figure out which docs one should reference informatively sure is hard work |
| 19:57 | <Philip`> | manu-db: No - I might just be imagining it |
| 19:58 | manu-db | wanders off to look, just in case. |
| 20:00 | <manu-db> | hmm... +json pattern has been used before: vnd.collection+json, vnd.hal+json, and vnd.oftn.l10n+json |
| 20:02 | <jgraham> | Yes, the canonical parsing tests are on google code |
| 20:03 | jgraham | has forgotten who was asking already |
| 20:03 | <jgraham> | Ms2ger: ^ seems you were asking |
| 20:03 | <jgraham> | Yell if you need access |
| 20:04 | <Ms2ger> | Ta |
| 20:30 | <annevk> | Ms2ger, apis-in-html-documents needs to move to DOM I suppose |
| 20:30 | <Ms2ger> | Probably |
| 20:31 | <Ms2ger> | Or I might have left them there because they test SVG parsing as well |
| 20:32 | <annevk> | parsing > html5lib |
| 20:37 | <karlcow> | annevk: spec-prod and chairs mailing-list. There might be a question of the toolchain used already for dealing with these documents maybe. |
| 20:37 | <karlcow> | no harm pushing for it. |
| 20:38 | <karlcow> | You might have some pushback from other members who are used to other tools. Community process, dialogs, etc. |
| 20:39 | <AryehGregor> | Hixie, did you see above where I said that Ian Jacobs told me that he thought the W3C would be okay with allowing specs to be published as HTML5 as long as it's polyglot? |
| 20:40 | <Hixie> | yes |
| 20:40 | <karlcow> | AryehGregor: I would be careful on that statement. From Ian Jacobs to W3C generalization. |
| 20:40 | <shepazu> | I think that's the general W3C staff sentiment |
| 20:41 | <AryehGregor> | karlcow, I made it clear that it was what he told me, not an official statement. |
| 20:41 | <AryehGregor> | If that's the sentiment, it should be trivial to set up. |
| 20:41 | <shepazu> | personally, I don't see the need for them to even be polyglot |
| 20:41 | <AryehGregor> | Nor do we, obviously. :) |
| 20:41 | <AryehGregor> | That's what HTML5 parsers are for. |
| 20:41 | <shepazu> | I think Mike feels similarly |
| 20:41 | <AryehGregor> | But it's a small concession. |
| 20:41 | <AryehGregor> | . . . also, why is non-polyglot HTML5 inferior to HTML4 in any way? HTML4 is allowed. |
| 20:42 | <AryehGregor> | And that's what the spec is now. |
| 20:42 | <shepazu> | yup, agreed |
| 20:42 | <karlcow> | I can imagine that for the Webmasters it might need to refactor a big part of the XML Toolchain but I'm not even sure. I wonder if XSLT is still used for the pub rules checker |
| 20:42 | <shepazu> | dunno |
| 20:42 | <shepazu> | I could test it |
| 20:43 | <AryehGregor> | karlcow, how could it be, if HTML4 is allowed? |
| 20:43 | <shepazu> | yeah |
| 20:43 | <karlcow> | shepazu: creating a dummy HTML5 spec and testing it with the webmaster to see how/if it fails would be good. |
| 20:43 | <AryehGregor> | Is there some place where people other than W3C staff can discuss this with the powers that be, rather than having to be told people's reasoning by intermediaries? |
| 20:43 | <shepazu> | nothing to prevent you from putting in an HTML5 plugin into XSLT, anyway |
| 20:43 | <karlcow> | AryehGregor: I imagine tidy is involved |
| 20:44 | <Hixie> | the only difference between the spec being html5 and being html4 is the doctype, a couple of examples that are stripped out of the w3c copy, the <meta charset> being stripped, and some attributes being added. |
| 20:44 | <shepazu> | AryehGregor: I suggest starting the conversation on spec-prod and seeing if we can get others to chime in |
| 20:45 | <Hixie> | i literally have a four-line perl script to make the spec html4-compliant |
| 20:45 | <shepazu> | Hixie: I don't think that should be necessary, but we can consider that as a fallback |
| 20:46 | <Hixie> | it's only necessary because ij says i have to use html4 and not versionless-html |
| 20:46 | shepazu | doesn't know what that means, but if you mean "HTML5", then I think we can sell that |
| 20:46 | <shepazu> | :) |
| 20:47 | <Hixie> | because somehow even though html3.2, html4, html4.01, xhtml1, and xhtml1.1 were all allowed to be self-hosting, the new html spec, despite being more closely aligned to reality, is apparently a Compatibility Risk that the w3c isn't willing to take on |
| 20:47 | <zewt> | that's called a Vote of Confidence |
| 20:47 | <shepazu> | Hixie: I'm not sure we're in the same conversation here |
| 20:47 | <karlcow> | Maybe there is a fear about what HTML5 means in terms of markup. (No idea really, just trying to imagine). Pandora box. |
| 20:48 | <Philip`> | The spec splitter uses <div> instead of <nav> with the --w3c flag, for HTML4 compatibility |
| 20:48 | <Philip`> | or at least my version of the splitter, which isn't used for the W3C copy |
| 20:49 | <Philip`> | so I suppose there might be more differences in MikeSmith(?)'s version |
| 20:50 | Ms2ger | wants an id on the </sarcasm> dt |
| 20:51 | <gsnedders> | Ms2ger: Where is that in the spec? :P |
| 20:52 | <MikeSmith> | my version is optimized for the sole purpose of creating as little as possible work/bs for me |
| 20:52 | <Ms2ger> | whatwg.org/html/#sa... Ah, dammit |
| 20:53 | <Hixie> | the in-jokes intentionally don't have ids :-) |
| 20:53 | <Ms2ger> | :( |
| 20:54 | <Ms2ger> | Go fix some bugs ;) |
| 20:58 | <AryehGregor> | karlcow, shepazu: http://lists.w3.org/Archives/Public/spec-prod/2011JulSep/0010.html |
| 21:00 | <karlcow> | cool. I would not have turned the mail this way. But at least it starts the discussion :) |
| 21:01 | <karlcow> | shepazu: what about sending a pointer to this discussion to chairs⊙wo too |
| 21:01 | <karlcow> | I'm not on chairs mailing list |
| 21:18 | <jgraham> | FWIW I think requiring polyglotness is worse than not allowing HTML(5) |
| 21:19 | <jgraham> | One is an obviosuly stupid policy. The other is also a stupid policy but looks slightly like a non-stupid one |
| 21:19 | <jgraham> | So people might mistake it for a sensible one |
| 21:29 | <shepazu> | way to hardline it, jgraham…let's hope nobody compromises, so we don't have any progress :) |
| 21:29 | shepazu | nominates jgraham for US Congress :) |
| 21:31 | <karlcow> | heh |
| 21:45 | <jgraham> | shepazu: True polyglotness is a cure worse than the disease. Approximate polyglotness is sort-of acceptable but I don't really see how it helps anyone |
| 21:46 | <jgraham> | I mean if the pubrules want to say "thou must close all thy tags" that's silly, but whatever |
| 21:46 | <jgraham> | Anything that can't be trivially achieved by setting a few serializer options isn't sensible |
| 21:57 | <Hixie> | jgraham: i entirely agree |
| 21:58 | <Hixie> | i don't really see what there is to compromise here. What's the "other" position that we're compromising with to get to polyglot? |
| 21:58 | <TabAtkins_> | XML forever, everywhere? |
| 21:59 | <karlcow> | getting already all heat up :) funny guys. Looks like a boys club before a soccer game. cute |
| 21:59 | <Hixie> | we could move to xhtml5 sent as xml, sure |
| 22:00 | <AryehGregor> | karlcow, this does not appear to be a constructive approach to take when W3C editors complain that a requirement imposed upon them doesn't seem to make sense. |
| 22:00 | <Hixie> | but if that's what the w3c wants, why hasn't anyone even tried suggesting it? |
| 22:00 | <AryehGregor> | Rather than giving us substantive answers, you're brushing us off and suggesting we're being unreasonable (without explaining why). |
| 22:00 | <karlcow> | AryehGregor: who is the "you" :) |
| 22:01 | <karlcow> | who is the "us" |
| 22:01 | <AryehGregor> | you = the person currently using the nick karlcow in this channel |
| 22:01 | <AryehGregor> | us = me, Hixie, jgraham, inter alia |
| 22:01 | <karlcow> | what did I brush off? |
| 22:02 | <karlcow> | beautiful rain outside of my window, right now. And wonderful humid smell. The tree leaves are fragrant. |
| 22:03 | Philip` | doesn't think speaking in haiku will help much |
| 22:04 | <zcorpan> | annevk: i think we dropped +xml knowledge because it broke sites |
| 22:05 | <karlcow> | Philip`: that was not a haiku, that was the description of what I see from the window. |
| 22:06 | <karlcow> | I sincerely do not know what AryehGregor is talking about cf brushing us off. |
| 22:06 | <AryehGregor> | Oh, one of the lines was shepazu rather than you. |
| 22:06 | <AryehGregor> | Well, whatever. |
| 22:07 | <AryehGregor> | We were complaining that requiring polyglot made no sense, and shepazu implied that he considered that uncompromising, and you made an amused remark about how we were getting excited, but no one has yet addressed the substantive concern. |
| 22:07 | <AryehGregor> | (at least, not here, haven't checked the mailing list yet) |
| 22:09 | <karlcow> | yes the discussion is funny, because indeed it looks like yet another little big debate. It's why I find it amusing. Not brushing off, more amused by our childish tendencies to make small issues international issues ;) |
| 22:09 | <shepazu> | AryehGregor: my position is that we should simply be able to use HTML5, not only polyglot HTML5, but I'm not the decision maker |
| 22:10 | <AryehGregor> | shepazu, who is the decision maker? |
| 22:10 | <karlcow> | heh |
| 22:10 | <shepazu> | if some people say they are more comfortable with polyglot, and that's all we can get, well, that's suboptimal, but it's a beachhead |
| 22:10 | <Philip`> | Who decides who is the decision maker? |
| 22:10 | <Philip`> | and who decides who that is? |
| 22:11 | <karlcow> | ah finally Philip` is reasonable ;) |
| 22:11 | <Philip`> | Surely that gets closer to who is the real decision maker |
| 22:11 | <shepazu> | AryehGregor: I'm guessing it would be some combination of Ian Jacobs and TimBL |
| 22:11 | <Philip`> | It must be a finite sequence since there's less than seven billion people in the world |
| 22:12 | <shepazu> | Philip`: don't forget the alien lizard overlords |
| 22:13 | <shepazu> | and it might be time-limited, so by the time you get to the answer, it may have changed |
| 22:13 | <AryehGregor> | If that guess could be clarified a bit so we could speak to the actual people responsible instead of being told by people who agree with us that we should compromise with the people who we've never spoken to, whose reasons have not been explained, and who have not even been clearly identified, that would be a step forward. |
| 22:13 | <Hixie> | also helpful would be an idea of what we're compromising between |
| 22:14 | <shepazu> | AryehGregor: I think that if we are able to get TimBL (who I think is on vacation just now) and IanJ on the conversation, that would be critical mass |
| 22:14 | <AryehGregor> | I already spoke with IanJ, and it sounded like he didn't have any problem with publication as straight HTML5. |
| 22:14 | <AryehGregor> | But let's see, I CC'd him. |
| 22:15 | <shepazu> | Hixie: I think that would be part of the conversation… though maybe there aren't any deal breakers, just clarification needed |
| 22:15 | <shepazu> | I can't really say, since I don't see a problem with just using HTML5 |
| 22:15 | <zcorpan> | which HTML5? |
| 22:16 | <Hixie> | doesn't matter, there's no way to distinguish them in practice for the specs we're talking about :-) |
| 22:17 | <Hixie> | shepazu: i tried to convince w3c to let us publish as contemporary HTML a few years ago, and got told no quite firmly. I figured it wasn't worth my time to argue and that the W3C would catch up with the world eventually. And indeed that seems to be happening, in part through Aryeh poking the hornet's nest again. :-) |
| 22:17 | <zcorpan> | depends on what happens with the HTML5s going forward |
| 22:17 | <Hixie> | other than the doctype, i can't really see anything that could change that would affect us |
| 22:18 | <shepazu> | Hixie: actually, I'd credit MikeSmith with starting this up again, internally |
| 22:18 | <Hixie> | and if the w3c decides to change the doctype, they're going to have bigger problems than the format the spec is in |
| 22:18 | <Hixie> | shepazu: ah, k |
| 22:18 | <shepazu> | not to dismiss what Anne, SamRuby, or AryehGregor have done |
| 22:19 | <zcorpan> | Hixie: well there's an example that uses <p>s in <caption>, i dunno, maybe the html wg decides that teh content model of <caption> shall be changed, or similar |
| 22:19 | <jgraham> | I'm pretty suprised that W3C aren't embarassed not to be publishing their own stuff in their own flagship standard language |
| 22:19 | <Hixie> | zcorpan: well if they change the content model, the example would have to change too |
| 22:19 | <shepazu> | Hixie: you might not have asked in a way that was palatable to whoever you talked to |
| 22:20 | <zcorpan> | Hixie: touche |
| 22:20 | <karlcow> | jgraham: why should they? :) |
| 22:20 | <Hixie> | shepazu: i believe the conversation was something along the lines of pubteam: "Hey, you can't use HTML5 to publish HTML5. You must use HTML4." me: "say what?" |
| 22:20 | <jgraham> | karlcow: It sugests a certain lack of belief in their own propoganda |
| 22:21 | <karlcow> | jgraham: nope. just a different set of priorities. It doesn't really matter. :) the document being readable. |
| 22:21 | <karlcow> | You know if it doesn't break, don't fix it. :) |
| 22:21 | <zcorpan> | Hixie: but now when html5 is at LAST CALL, the situation is clearly quite different |
| 22:22 | <jgraham> | karlcow: By analogy I would also be surprised to find that the IE team all use IE6 |
| 22:22 | <shepazu> | Hixie: I wasn't part of the conversation, so I can't comment on the verity of your characterization… but in any case, I think it's a reasonable think to do |
| 22:22 | <Hixie> | zcorpan: as karlcow would put it, it's very cute |
| 22:22 | <karlcow> | jgraham: I'm not using Opera Next ;) just for testing purpose |
| 22:23 | <jgraham> | karlcow: Or, if you prefer, the document would be readable as flash or pdf. But I don't think we should publish using those |
| 22:23 | shepazu | authors almost exclusively in HTML5 for all his non-TR documents on W3C (group sites, etc) |
| 22:23 | <shepazu> | and have for over a year |
| 22:23 | <karlcow> | and I'm not necessary jumping on new version of OSes or software when they come out. I really don't care about the newness of things :) as long as I can publish and communicate words |
| 22:23 | <jgraham> | HTML 5 actually adds features that are useful for writing specs e.g. the new semantic elements |
| 22:24 | <Hixie> | yeah <aside> is the main thing i wish i could use |
| 22:24 | <Philip`> | jgraham: By "useful" you mean "equivalent to <div class=foo> in practice"? |
| 22:25 | <jgraham> | Philip`: Useul to the person writing the document. Especially for e.g. automatic ToC generation using anolis |
| 22:26 | <jgraham> | *Useful |
| 22:26 | <karlcow> | Hixie: what aside provides as a direct ROI? (being curious. apart of a cleaner semantics) |
| 22:26 | <Hixie> | karlcow: nothing |
| 22:26 | <Hixie> | jgraham: true, <section>/<h1> would be useful too. it could even be used incrementally, though i'm sure the inconsistency would drive me batty. |
| 22:26 | <karlcow> | heh |
| 22:29 | karlcow | time for being off the screen. paper and pen! |
| 22:29 | <jgraham> | More haiku? |
| 22:31 | <shepazu> | would using something like HTMLShiv.js to ensure it works in older browsers be acceptable? |
| 22:31 | <zcorpan> | the spec already doesn't work in older browsers |
| 22:36 | <shepazu> | heh |
| 22:37 | <shepazu> | maybe the HTML5 spec doesn't, but other specs that use HTML5 might |
| 22:41 | <AryehGregor> | You can write HTML4 that doesn't work in old browsers too, if you like. That seems orthogonal. |
| 22:42 | <AryehGregor> | For instance, HTML4 that relies on, I dunno, IndexedDB. |
| 22:42 | <AryehGregor> | If we want compat with old browsers, that should be a separate requirement. |
| 22:43 | <zcorpan> | i thought pubrules didn't allow scripts at all |
| 22:44 | <zcorpan> | not that i can find anything about "script" in pubrules |
| 22:51 | <AryehGregor> | Surely some specs use scripts? |
| 22:51 | <AryehGregor> | W3C HTML5 doesn't use them? |
| 22:52 | <zcorpan> | hmm yeah i think the comment form uses script |
| 22:54 | <shepazu> | scripts are allowed… brb |
| 23:00 | TabAtkins_ | wouldn't want to use <section>/<h1> for CSS specs. Being able to write straight-line code is useful. |
| 23:07 | <AryehGregor> | I always find this report depressing: http://www.redhat.com/f/pdf/security/RHEL4_RiskReport_6yr_wp_5732067_0311_ma_web.pdf |
| 23:07 | <AryehGregor> | Critical flaws in Mozilla products: 194. Critical flaws in all other programs combined: 58. |
| 23:07 | <AryehGregor> | Granted, web browsers are extremely complicated, change rapidly, and are network-exposed, but still . . . |
| 23:10 | <AryehGregor> | Hmm, are there any useful points here? http://www.infoworld.com/print/169665 |
| 23:11 | <AryehGregor> | Point 11 is surprisingly clueful. |
| 23:12 | <Philip`> | Maybe nobody bothers testing other applications much? |
| 23:13 | Philip` | has always wondered how vulnerable multiplayer games are to malicious network packets, since game developers aren't particularly known for focusing on security and clean coding practices |
| 23:14 | <AryehGregor> | You don't have nearly as many targets for multiplayer games, though. |
| 23:14 | <jamesr> | AryehGregor: that's basically punishing mozilla for disclosing accurately |
| 23:15 | <AryehGregor> | jamesr, this is RHEL, everything here is open-source. I don't think many of the major projects are hiding too many of their security fices. |
| 23:15 | <jamesr> | no? |
| 23:15 | <AryehGregor> | Well, not everything, but almost everything. |
| 23:15 | <AryehGregor> | Maybe to some extent, yeah. Like the kernel doesn't give details on vulnerabilities, it's true. |
| 23:15 | <jamesr> | you don't think they fold multiple bugs into a single report, or downgrade some vulns? |
| 23:15 | <jamesr> | i agree that in OSS the problem is not nearly as bad as with closed source |
| 23:16 | <AryehGregor> | AFAIU, the severity and so on are determined by RHEL here, not the vendor. |
| 23:16 | <jamesr> | but mozilla has a pretty responsible security disclosure policy so they look bad here relative to projects that don't spend as much time+effort |
| 23:17 | <AryehGregor> | Also, come to think of it, its userbase is mostly Windows desktop, which gives it about two orders of magnitude usage over almost anything else in the default RHEL install. |
| 23:17 | <AryehGregor> | So you'd expect commensurably more testing. |
| 23:17 | <AryehGregor> | Okay, that's all fair. But I wonder how much of these critical vulnerabilities could be effectively mitigated by Chrome-style sandboxing. |
| 23:18 | <jamesr> | yeah, a lot would become high severity |
| 23:18 | <jamesr> | or at least it would using our terminology, not sure what RHEL's vocabulary is |
| 23:18 | <AryehGregor> | I mean, it's fair to say that there's more effort on finding browser bugs, but hopefully there's also more effort in fixing them. :) |
| 23:19 | <AryehGregor> | So one would hope it could cancel out. |
| 23:19 | <AryehGregor> | Oh well. |
| 23:19 | <yuhong> | http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBwQFjAA&url=http%3A%2F%2Flcamtuf.blogspot.com%2F2010%2F05%2Fvulnerability-databases-and-pie-charts.html&ei=lpBNTo6fO8rTiAKJ7dGCAQ&usg=AFQjCNHwG2qJiz9ugZwdxihAWJu-UV-iUg&sig2=WmNI4ObFu-E7I-bp0Pei8A |
| 23:19 | <yuhong> | http://lcamtuf.blogspot.com/2010/05/vulnerability-databases-and-pie-charts.html |
| 23:19 | <jamesr> | definitely worthwhile to spend a lot of effort on a binary that people feed a lot of untrusted content from the web into on a daily basis |
| 23:19 | <jamesr> | and that tends to manage credentials for their email, banking, etc |
| 23:19 | <AryehGregor> | Yep. |
