| 01:10 | <AryehGregor> | "The following extract shows how a messaging client's text entry could be arbitrarily restricted to a fixed number of characters, thus forcing any conversation through this medium to be terse and discouraging intelligent discourse. |
| 01:10 | <AryehGregor> | What are you doing? <input name=status maxlength=140>" |
| 01:10 | <AryehGregor> | I love these little things. |
| 01:10 | <AryehGregor> | Hope the W3C crowd that spotted the jab at Flash doesn't demand this be removed too. :) |
| 01:47 | <Dashiva> | AryehGregor: They will now |
| 01:47 | <Dashiva> | Thanks a lot! |
| 01:47 | <AryehGregor> | :) |
| 01:47 | <Dashiva> | :P |
| 02:31 | <AryehGregor> | "We’re excited that other browsers are starting to optimize for the Windows platform. Taking advantage of the PC’s hardware through the Windows APIs makes browsing on Windows better than browsing on other systems." |
| 02:31 | <AryehGregor> | I totally called that one. |
| 02:32 | <AryehGregor> | I said months ago that when other browsers supported acceleration, the IE team would say "Yeah, but it's way better when they run on Windows." |
| 02:32 | <AryehGregor> | (which it is) |
| 02:32 | <AryehGregor> | (my Linux machine doesn't even support hardware acceleration on my hardware yet unless I install unstable proprietary drivers) |
| 04:00 | <MikeSmith> | AryehGregor: about that potentially objectionable part of the spec, I think in this particular case, anybody who wants to have it removed must be required to provide a careful, thorough argument via a single tweet. |
| 04:00 | <MikeSmith> | hober: cool to hear about initial work on the html parser in elisp |
| 04:01 | <kevo_tool> | What part? |
| 04:02 | <MikeSmith> | kevo_tool: eh? |
| 04:02 | <kevo_tool> | Objectional part of the spec |
| 04:03 | <MikeSmith> | kevo_tool: see the logs |
| 04:04 | <MikeSmith> | would give Chinese speakers a huge advantage |
| 04:05 | <MikeSmith> | or I guess anybody could write their argument in their own language, use Google translate or whatever to translate it to Chinese |
| 04:06 | <MikeSmith> | we should all do that for all our tweets, actually |
| 04:06 | <MikeSmith> | and have twitter auto-translate them back to whatever native language you want |
| 04:14 | <MikeSmith> | http://twitter.com/sideshowbarker/status/24349057841 |
| 04:14 | <MikeSmith> | 如果我用中文写我的Twitter的消息，那么我可以说更多的，具有更少的字符。因此，从现在起，我会用中文写我的Twitter的所有邮件。 |
| 04:16 | <MikeSmith> | to express that in English takes me 180 characters |
| 04:16 | <MikeSmith> | to express it in Chinese takes 67 |
| 04:17 | <jcranmer> | but each Chinese character is several bytes in most charsets |
| 04:17 | <MikeSmith> | that sucks for those charsets |
| 04:17 | <jcranmer> | English is 1 byte/character in any sane charset |
| 04:18 | <jcranmer> | and no, UTF-16/UCS-2 and UTF-32 are not sane |
| 04:18 | <MikeSmith> | my message to those charsets is: Suck it up and find something else to complain about. |
| 04:18 | <jcranmer> | and UTF-9 is out of the question |
| 04:20 | <MikeSmith> | that's why this whole twit-tarded 140-character-limit thing is so senseless |
| 04:20 | <MikeSmith> | hence the editiorial comment in the spec, which is speaking gospel truth |
| 04:20 | <jcranmer> | does it count characters or bytes? |
| 04:21 | <MikeSmith> | twitter counts characters, not bytes |
| 04:21 | <MikeSmith> | to in the world of twitter, Chinese is king |
| 04:22 | <jcranmer> | characters as in Unicode codepoints? |
| 04:22 | <MikeSmith> | yeah, I reckon so |
| 04:23 | <MikeSmith> | with perhaps the usual exceptions |
| 04:23 | <MikeSmith> | surrogate pairs or whatever |
| 04:23 | <jcranmer> | so a + ` would be two characters |
| 05:32 | <MikeSmith> | d'oh |
| 05:32 | MikeSmith | remembers that the number box tells me how many characters I have left before I reach the limit |
| 07:32 | <hsivonen> | hober: cool (re: emacs) |
| 07:33 | <annevk> | jgraham, what is wrong about it? |
| 07:34 | <annevk> | jgraham, and why does it make Chrome not fail? |
| 07:41 | <annevk> | jcranmer, MikeSmith, twitter counts 16-bit code units |
| 07:41 | <annevk> | i.e. str.length |
| 07:43 | <MikeSmith> | annevk: 喔 |
| 07:43 | <MikeSmith> | 谢谢 |
| 07:51 | <webben> | AryehGregor: Don't mind the jab myself, but it would be better if the example used a <label>. |
| 07:55 | <paul_irish> | what's the word on using dot notation to access web storage? |
| 07:56 | <annevk> | it's fine |
| 07:57 | <paul_irish> | good. the spec doesnt really mention it at all, so lots of folks think it's a dirty hack to be avoided. |
| 07:58 | <annevk> | it's part of the IDL |
| 07:58 | <annevk> | I grant you that specs are hard to read :) |
| 08:07 | <jgraham> | annevk: It tries to check the .name property of the exception, which makes sense for ECMAScript exceptions but not for DOMExceptions |
| 08:07 | <jgraham> | Chrome simply doesn't throw an error in that case |
| 08:08 | <jgraham> | So it fails for an entirely different reason (or at least the version of Chrome I have does) |
| 08:10 | <annevk> | DOMExceptions have .name as well |
| 08:10 | <annevk> | or maybe they don't? |
| 08:11 | <jgraham> | annevk: I couldn't see it in the spec |
| 08:11 | <jgraham> | I think they have .name === "Error" from the prototype chain |
| 08:11 | <annevk> | the new spec has it, I assume Simon added it for a reason |
| 08:11 | <jgraham> | but I didn't dig deep enough into spec land to find out |
| 08:12 | <annevk> | oh yeah, it's simply error |
| 08:12 | <annevk> | maybe I should just remove .message and .name from the spec for now |
| 08:12 | <annevk> | DOM3Core only has .code |
| 08:13 | <annevk> | i guess .message and .name are general to exceptions? maybe something for either ECMAScript or Web IDL |
| 08:14 | <jgraham> | .name comes from ECMAScript assuming DOMException inherits from Error |
| 08:14 | <jgraham> | Not sure how I tell that from DOM Core 3 |
| 08:15 | <jgraham> | But the name won't be the name of the exception |
| 08:15 | <MikeSmith> | annevk: 15.11.4.3 Error.prototype.message |
| 08:15 | <MikeSmith> | in the ES5 spec |
| 08:15 | <annevk> | ta |
| 08:15 | <jgraham> | Maybe simon trying to make the spec more useful? |
| 08:15 | <MikeSmith> | and 15.11.4.2 Error.prototype.name |
| 08:15 | <annevk> | could be |
| 08:15 | <jgraham> | Anyway, remove that check and it all works as expected |
| 08:16 | <annevk> | but I'm not sure why it would be useful |
| 08:16 | <annevk> | oh wait, that is what WebKit does |
| 08:17 | <annevk> | Mozilla gives back "NS_ERROR_DOM_NAMESPACE_ERR" |
| 08:17 | <annevk> | and Opera just Error |
| 08:17 | <annevk> | (for a NAMESPACE_ERR) |
| 08:20 | <annevk> | but it seems this should be addressed at the binding level somehow |
| 08:20 | <annevk> | since these are ECMAScript exception members |
| 08:21 | <othermaciej> | Web IDL should let you have an exception interface that inherits from whatever the normal language-native exception interface is |
| 08:21 | <annevk> | right |
| 08:22 | <annevk> | and for ECMAScript some way to set the name attribute |
| 08:22 | <annevk> | or have it map automatically or something |
| 08:25 | <jgraham> | annevk: In any case I suggest we remove that from testharness.js and check it as part of the WebIDL testsuite |
| 08:26 | <annevk> | ja |
| 09:02 | <hsivonen> | I'd like to get a sanity check on http://www.w3.org/Bugs/Public/show_bug.cgi?id=10589 from a Web designer |
| 09:03 | <hsivonen> | (that is, am I arguing for a change that'd make things better for designers) |
| 09:03 | <hsivonen> | (I think I am) |
| 09:04 | <othermaciej> | <figure> in <p> for floating figure makes sense to me |
| 09:04 | <othermaciej> | making <figure> close <p> is less compatible with legacy browsers than not doing so |
| 09:05 | <MikeSmith> | hsivonen: I'm not a designer but I agree with you |
| 09:05 | <othermaciej> | I don't think the rest of us need to be bound by Chrome's release schedule |
| 09:05 | <othermaciej> | if they ship every 4 months, then they'll just ship again before whatever they ship in 7 gets locked in |
| 09:06 | <othermaciej> | and frankly the new HTML5 parser has a number of what I'd consider critical regressions that are not yet fixed |
| 09:06 | <hsivonen> | othermaciej: what kind of critical regressions? |
| 09:06 | <MikeSmith> | I'm sympathetic to abarth point about impact on implementations, but my response about that would be, it's cheaper to change it now than it will be later, so let's make absolutely sure we have it right |
| 09:06 | <annevk> | it's scarily conservative imo |
| 09:07 | <hsivonen> | annevk: what's conservative? |
| 09:07 | <annevk> | not doing any more changes |
| 09:07 | <abarth> | othermaciej: what regressions? |
| 09:07 | <othermaciej> | of course, I am not sure what Adam would consider the same issues critical |
| 09:08 | <abarth> | my concern is that there are lots of dials to twiddle |
| 09:08 | <othermaciej> | we have 7 live regressions in our internal bug tracker that we consider P1; some are originally reported on Apple-internal sites so they have no bugzilla except maybe a scrubbed one |
| 09:08 | <hsivonen> | fwiw, I'm very close to going to the annotation-xml bug and say that it won't make it in by the time for Firefox 4 feature freeze and it's feature-ish |
| 09:09 | <othermaciej> | sure, you *could* fiddle endlessly, but hsivonen in particular has been giving feedback for a long time and the rate of changes he asks for seems to be declining, not increasing |
| 09:10 | <othermaciej> | abarth: here's two in bugzilla that we consider P1: <https://bugs.webkit.org/show_bug.cgi?id=44637>; <https://bugs.webkit.org/show_bug.cgi?id=43328>; |
| 09:10 | <abarth> | https://bugs.webkit.org/show_bug.cgi?id=44637 is a UA detect |
| 09:10 | <abarth> | it's not clear what we can do to fix it |
| 09:10 | <othermaciej> | we also have 4 bugs in Mail, the AIM client, and Pages |
| 09:11 | <othermaciej> | why would the UA detect start causing failure after the HTML5 parser is enabled? |
| 09:11 | <MikeSmith> | hsivonen: as a courtesy at last, please talk with David Carlisle before making a final decision on implementing it or not for the release |
| 09:11 | <othermaciej> | was that just a misdiagnosis? |
| 09:11 | <MikeSmith> | *at least |
| 09:11 | <abarth> | we started behaving more like other browsers |
| 09:11 | <othermaciej> | we also have two bugs on apple.com which can probably be fixed through evangelism |
| 09:11 | <abarth> | basically, they do a UA detect |
| 09:11 | <abarth> | and based on that |
| 09:12 | <abarth> | they decide which dom element to set to display:none |
| 09:12 | <othermaciej> | er, on internal apple sites rather, not the public apple.com |
| 09:12 | <abarth> | assuming that different UAs will produce different DOMs |
| 09:12 | <abarth> | for https://bugs.webkit.org/show_bug.cgi?id=43328, we have a two-line reduction |
| 09:12 | <abarth> | we just need to get eric's attention to finish the fix |
| 09:13 | <othermaciej> | does that one need a spec change? |
| 09:13 | <abarth> | i can't really help with apple-internal bugs unless someone tells me what the problem is |
| 09:14 | <othermaciej> | for the native apps we may have to add quirks |
| 09:14 | <othermaciej> | we are prepared to handle those ourselves as necessary |
| 09:14 | <abarth> | i imagine https://bugs.webkit.org/show_bug.cgi?id=40961 is something we'll need to add a pref for |
| 09:14 | <othermaciej> | for apple-internal sites, I sure hope evangelism works, cause I'd rather not ship a site-specific hack for an Apple intranet site |
| 09:15 | <othermaciej> | we have some cases of "<style</style>" in Mail messages |
| 09:16 | <abarth> | I don't think bug 43328 will need a spec change. the issue is two async events that are racing |
| 09:16 | <hsivonen> | happily, evangelism has worked for Mozilla's intranet :-) |
| 09:16 | <othermaciej> | probably no way to handle that but an app-specific quirk, since even if we stop sending such content, those emails already exist |
| 09:16 | <abarth> | something subtle changed in the timing that reversed the outcome of the race |
| 09:16 | <othermaciej> | we have one report of unclosed <tilte> eating the page on a real site |
| 09:16 | <othermaciej> | that one should go into bugzilla |
| 09:16 | <hsivonen> | I thought window.location setting and .reload() were supposed to kill the parser synchronously |
| 09:17 | <hsivonen> | at least in Gecko, we have an API for terminating the parser synchronously |
| 09:17 | <abarth> | yes |
| 09:17 | <hsivonen> | at one time, it seemed like and endless pit of trouble |
| 09:17 | <abarth> | that's what we need |
| 09:17 | <hsivonen> | but I think I have it working now |
| 09:17 | <abarth> | AFAIK webkit doesn't/didn't have that |
| 09:17 | <hsivonen> | s/and/an/ |
| 09:17 | <abarth> | but the observable results where the same |
| 09:18 | <hsivonen> | MikeSmith: OK. |
| 09:18 | <abarth> | othermaciej: the goal of this project (from my point of view) is that we pay these debts now and then never have to worry about this stuff again |
| 09:18 | <othermaciej> | anyway we'll add whatever quirks we need to handle compat with Mac OS X (and maybe iOS) native apps correctly |
| 09:18 | <annevk> | does HTML5 define that? |
| 09:18 | <annevk> | terminating the parser synchronously? |
| 09:18 | <abarth> | othermaciej: ideally, we'd have done this when we had 0% market share |
| 09:18 | <othermaciej> | abarth: I definitely think it's a worthwhile exercise |
| 09:19 | <othermaciej> | all I'm saying is that it's not done-and-practically-ready-to-ship from Apple's POV at least |
| 09:19 | <hsivonen> | annevk: I'm not sure if it does now, but at least it did when I was dealing with it |
| 09:19 | <othermaciej> | we are not even necessarily expecting anyone else to fix the bugs we consider showstoppers in it |
| 09:20 | <hsivonen> | annevk: IIRC, at least at the time, Hixie considered forced stopping a stop button thing (i.e. a browser-specific UI issue) |
| 09:20 | <abarth> | i'm happy to do whatever needs to be done, but communication is important |
| 09:20 | <hsivonen> | but window.location makes it a script-exposed issue :-( |
| 09:20 | <othermaciej> | anything that's on public sites, I'm sure we'll put in bugzilla well ahead of time |
| 09:21 | <othermaciej> | I think even for the native app cases, we've communicated the quirks we've hit, though the details of making it an app-specific hack are up to us |
| 09:21 | <othermaciej> | it looks like <foo</foo> is by far the most common source of problems |
| 09:21 | <abarth> | i'll add a setting for that now |
| 09:22 | <othermaciej> | it's too bad that HTML5 chose to go the Opera/IE way on that one |
| 09:22 | <othermaciej> | but perhaps IE team would be eating this same kind of pain otherwise |
| 09:22 | <abarth> | according to ian, stuff breaks either way |
| 09:22 | <othermaciej> | (though it's harder to imagine content depending on the IE/Opera way) |
| 09:23 | <othermaciej> | I haven't seen the data but I'm ok with just taking it on faith and biting this particular bullet |
| 09:23 | <hsivonen> | othermaciej: IIRC, someone from Opera on this channel has said content does depend on it |
| 09:23 | <hsivonen> | othermaciej: I'm taking the Opera guys' word for this, too |
| 09:24 | <othermaciej> | I have heard that and am mostly willing to believe it though I have not actually seen pointers to actual such content |
| 09:24 | <abarth> | w.r.t. conservatism, i think its easy to lose site of the fact that a stable platform is essential for building complex sites |
| 09:24 | <abarth> | in some sense, having IE6 around for so long was very good for the web |
| 09:24 | <othermaciej> | the parsing algorithm is definitely settling down I think |
| 09:25 | <othermaciej> | even though its simulated annealing process has not yet quite hit thermal equilibrium with the environment |
| 09:25 | <hsivonen> | abarth: in this particular <p><figure> case, I think it's essential not to make certain useful trees impossible by sprinkling implicit <p> closing around too much |
| 09:25 | <othermaciej> | I do believe HTML5 parsing has fixed more bugs than it has created, even though the latter end up more salient |
| 09:26 | <othermaciej> | abarth: btw, you don't *have* to add the setting - it would be useful for more people to learn the code by actually adding something to it |
| 09:26 | <hsivonen> | abarth: especially when experience with <p><table> suggests that not letting authors put stuff inside <p> isn't exactly helping authors |
| 09:26 | <othermaciej> | abarth: advice may add more value here than code |
| 09:26 | <annevk> | abarth, the problem with completely stable is that the most stupid bugs become platform features - some amount of change is needed to prevent that, I think |
| 09:26 | <othermaciej> | <p><ul> is also clearly fail in retrospect |
| 09:26 | <hsivonen> | othermaciej: yes |
| 09:27 | <abarth> | othermaciej: ok, i'm happy to review adding the setting. it's actually very easy. basically, you make '<' move out of the tag name state and get reconsumed in the data state |
| 09:27 | <hsivonen> | I nowaways think implicit <p> closing is a general fail |
| 09:27 | <hsivonen> | I'm willing to accept it for legacy stuff, but adding it for new stuff is a (small) tragedy if it makes things harder for authors |
| 09:28 | <annevk> | for <section> it makes sense |
| 09:28 | <annevk> | for <figure> not so much |
| 09:29 | <abarth> | each tweak is made with good intentions |
| 09:29 | <othermaciej> | I think implicit close tags in general might be fail |
| 09:29 | <hsivonen> | annevk: yeah, section makes sense, though I've had disapproving private feedback once about that, too |
| 09:29 | <abarth> | i'm not going to fight about it |
| 09:30 | <othermaciej> | over the next couple of months, changes to the w3c spec at least are going to become process-wise more difficult |
| 09:30 | <abarth> | but i'll be happy when we're done changing the spec :) |
| 09:30 | <MikeSmith> | amen to that |
| 09:30 | <othermaciej> | so it's kind of the last chance to make tweaks before things freeze up |
| 09:30 | <othermaciej> | I wish we could be done already but I feel that hsivonen has the merits of the case on that bug |
| 09:31 | <othermaciej> | because it's an HTML5 behavior that moves away from the behavior of any legacy browser, and is bad on the merits |
| 09:48 | <hsivonen> | given https://bugs.webkit.org/show_bug.cgi?id=44637 , maybe Safari should put "Chrome" in its UA string, too |
| 09:48 | <hsivonen> | "Safari (like Chrome)" and "Chrome (like Safari)" |
| 09:49 | <abarth> | the UA string is the definitely the thing i dislike the most about the web |
| 09:49 | <abarth> | one can only imagine what UA strings will look like 10 years from now |
| 09:50 | <abarth> | hsivonen: you should see the bug where the gtk version of WebKit gets locked out of advanced features because sites (including google) don't realize that it's webkit |
| 09:51 | <hsivonen> | the root of the problem is that you can't have your UA string cake and eat it too: if you put something in there for marketing statistics, someone *will* sniff it to exclude functionality |
| 09:51 | <abarth> | https://bugs.webkit.org/show_bug.cgi?id=39617 |
| 09:51 | <hsivonen> | btw, SeaMonkey is putting "Firefox" in its UA string and providing an advanced pref for the hard-liners to take it out of the UA string |
| 09:52 | <hsivonen> | Open Source prefs... |
| 09:54 | <hsivonen> | abarth: why didn't WebKit GTK just always say "Safari" instead of making it a site-specific hack? |
| 09:54 | <hsivonen> | once you've put "Firefox", "Safari" or "Chrome" in the UA string, making sites sniff for a less obvious name like "Gecko" or "WebKit" is an exercise in futility |
| 09:54 | <othermaciej> | Chrome alrady has Safari in the UA string IIRC |
| 09:54 | <abarth> | it was hard to discuss the issue with the stakeholders |
| 09:55 | <hsivonen> | othermaciej: indeed |
| 09:55 | <abarth> | because they were somewhat emotional about it |
| 09:55 | <hsivonen> | abarth: I see. |
| 09:55 | <annevk> | yeah, User-Agent is a pain and bloat |
| 09:56 | <annevk> | kudos to Microsoft for promoting good detection practices on their blog |
| 09:56 | <abarth> | the part that gets me about it is how it makes it harder for browsers to fix their bugs |
| 09:56 | <annevk> | if only Google would take note... |
| 09:56 | <abarth> | :) |
| 09:57 | <hsivonen> | which reminds me that one of the things I have on my todo list today is working around GWT's on-by-default UA sniffing in V.nu live dom |
| 09:58 | <hsivonen> | http://groups.google.com/group/mozilla.dev.apps.seamonkey/msg/47f95dafd399495f?pli=1 |
| 09:59 | <jgraham> | FWIW I agree with hsivonen about the <p><figure> thing |
| 09:59 | <abarth> | oh that FoxFire |
| 09:59 | <abarth> | always causing trouble |
| 10:00 | <othermaciej> | google sites have in the past had some of the worst UA checks I have ever seen |
| 10:01 | <hsivonen> | fwiw, if Mozilla executes on the currently announced Firefox 5.0 UA string plan, GWT apps would think Firefox 5.0 has Gecko < 1.8 |
| 10:01 | <hsivonen> | s/would/will/ |
| 10:05 | <jgraham> | GWT is evil |
| 10:05 | <jgraham> | evil |
| 10:05 | <hsivonen> | <svg><foreignObject><div><![CDATA[foo]]> |
| 10:06 | <hsivonen> | why should the CDATA thing parse as a bogus comment per spec? |
| 10:06 | <hsivonen> | (I understand we want it to parse as a bogus comment) |
| 10:06 | <hsivonen> | but I can't derive it from the spec |
| 10:06 | <jgraham> | hsivonen: The parent element is in the HTML namespace |
| 10:07 | hsivonen | re-checks the tokenizer spec |
| 10:07 | <abarth> | am i confused about http://www.w3.org/Bugs/Public/show_bug.cgi?id=10621 ? |
| 10:07 | <abarth> | i checked in Minefield, but Minefield doesn't seem to pass the tests I wrote about that part of the spec |
| 10:08 | <hsivonen> | abarth: I have unreviewed patches sitting in my queue |
| 10:09 | <hsivonen> | jgraham: the spec doesn't check the namespace of the current node. it checks if the tree builder is in the "in foreign content" mode |
| 10:09 | <jgraham> | hsivonen: Did you find it? In the markup declaration open state it says """Otherwise, if the insertion mode is "in foreign content" and the current node is not an element in the HTML namespace and the next seven characters are an case-sensitive match for the string "[CDATA[" (the five uppercase letters "CDATA" with a U+005B LEFT SQUARE BRACKET character before and after), then consume those characters and switch to the CDATA section state.""" |
| 10:09 | <jgraham> | note "and the current node is not an element in the HTML namespace" |
| 10:10 | <hsivonen> | jgraham: ooh. when did the "and" part get added there? |
| 10:10 | <hsivonen> | jgraham: so why do we have "in foreign content" as a mode again? instead of always checking the namespace of the current node instead |
| 10:11 | <david_carlisle> | hsivonen: annotation-xml bug... Obviously Firefox has to have its production schedule and if that means it needs to go out implementing the currently broken parser specification, so be it, but Firefox having gone out can't then be used as a reason for not fixing this bug in the spec which is pretty critical to MathML usage. |
| 10:11 | <abarth> | yeah, that's one of the annoying leaks of state from tree builder to tokenizer |
| 10:11 | <jgraham> | hsivonen: Ask Hixie :) |
| 10:11 | <abarth> | each one of those is tears |
| 10:11 | <jgraham> | abarth: Didn't hsivonen already file a bug on that? |
| 10:11 | <abarth> | it means things like the preload scanner don't get the right tokenization |
| 10:12 | <abarth> | oh, maybe, not sure |
| 10:12 | <hsivonen> | abarth: in Gecko it does! |
| 10:12 | <hsivonen> | off-the-main-thread parsing FTW! |
| 10:12 | <abarth> | how? |
| 10:12 | <abarth> | you run the whole treebuilder? |
| 10:12 | <hsivonen> | abarth: yes |
| 10:12 | <hsivonen> | abarth: there's no separate prescan |
| 10:12 | <abarth> | any then throw away the work if document.write ? |
| 10:12 | <hsivonen> | abarth: the speculative parse is the prescan |
| 10:12 | <hsivonen> | abarth: only if it's a bad kind of document.write |
| 10:13 | <hsivonen> | abarth: most document.writes are ok |
| 10:13 | <abarth> | do you tokenize for view-source? |
| 10:14 | <hsivonen> | david_carlisle: I have a hard time understanding the criticality, but I'll try again |
| 10:14 | <hsivonen> | abarth: the HTML5 parser isn't used for view source, yet, but the plan is to run the tree builder for view source |
| 10:14 | <abarth> | webkit just tokenizes and uses a different tree builder |
| 10:14 | <abarth> | that builds a colorization of the tokens as a DOM |
| 10:15 | <david_carlisle> | most mathml tools annotate the expressions they write so having annotations break in this frankly bizarre fashion means that it's not possible to use most mathml in html without first hand editing it, that's bad, |
| 10:16 | <hsivonen> | abarth: that's how Gecko does it and will continue to do it |
| 10:16 | <hsivonen> | abarth: but the HTML5 tree building algorithm will have to run to get foreign land coloring right |
| 10:16 | <abarth> | that's true |
| 10:17 | <abarth> | i think we don't colorize that correctly today |
| 10:17 | <hsivonen> | HTML5 view source probably won't make it to Firefox 4 |
| 10:17 | <hsivonen> | (unless maybe if the product drivers don't consider it a new feature) |
| 10:17 | <hsivonen> | it's definitely not making it for the feature freeze |
| 10:18 | <abarth> | the firefox release process is very strange |
| 10:18 | <abarth> | betas before feature freezes |
| 10:18 | <abarth> | i guess every browser has a strange release process |
| 10:20 | <abarth> | whoops. we never removed the special case for the sarcasm tag |
| 10:20 | <hsivonen> | david_carlisle: and the tools today say encoding="application/xhtml+xml"? |
| 10:21 | <hsivonen> | abarth: how does WebKit take a deep breath? spin the event loop? |
| 10:21 | <abarth> | there's a comment and then a notImplement() |
| 10:21 | <abarth> | which means the end tag is ignored... :( |
| 10:23 | <annevk> | you have a bug in implementing </sarcasm> |
| 10:23 | <annevk> | now that's funny |
| 10:23 | <abarth> | yep |
| 10:23 | <abarth> | and it's going to ship in a stable release :P |
| 10:24 | <abarth> | so silly |
| 10:24 | <annevk> | Chrome 7 -- the one that didn't get </sarcasm> right ;p |
| 10:25 | <abarth> | https://bugs.webkit.org/show_bug.cgi?id=45645 |
| 10:27 | <david_carlisle> | hsivonen: No of course not, but.. needing to put on an attribute is very much a second choice, but the best we could get out of the bug reporting system it seemed, but tools and people can be instructed to add the attribute and most likely the existing uses of the annotation are unaffected. however if annotation is unusable then tools can't be fixed, the spec is just broken. The current... |
| 10:27 | <david_carlisle> | ...behaviour is just so weird I had a hard time persuading the WG that it was actually specified that way (rather than just a software bug). I can understand product release cycles and code freezes but I can not understand how anyone could possibly try to justify the parse tree that the current parse specification says should be produced. it is simply wrong. |
| 10:29 | <hsivonen> | david_carlisle: I don't see the point of putting HTML in an annotation |
| 10:30 | <hsivonen> | david_carlisle: I expect Hixie didn't, either |
| 10:30 | <hsivonen> | david_carlisle: if it's better expressed as MathML, why have HTML at all there? and if it's better expressed in HTML, why have MathML there? |
| 10:34 | <david_carlisle> | hsivonen: "I don't see the point" perhaps, but we can't see the point of taking a perfectly well nested set of start and end tags and arbitrarily producing a tree for a completely different structure (that doesn't render at all) , So the "add an attribute" was the uneasy compromise that probably no one really liked that much. The bug needs to be fixed somehow or we are in the nonsense of... |
| 10:34 | <david_carlisle> | ...blocking objections and bureaucratic unpleasantness, which i really hoped we'd avoided. |
| 10:35 | <hsivonen> | david_carlisle: I might be able to suggest something better than "add an attribute" if I understood the existing usage patterns and their motivations |
| 10:37 | <david_carlisle> | hsivonen: maybe the html annotation is a proof step hint that just pops up on user interaction, maybe it's a list of references who knows? annotation are like data- attributes, but allowing structured annotation. the whole point is that you, me, anyone is not supposed to second guess how they are to be used, they are a container for arbitrary user defined data. |
| 10:38 | <hsivonen> | david_carlisle: I see |
| 10:38 | <hsivonen> | and when MathML appears as an annotation, there's no new <math> root in the common case? |
| 10:39 | <david_carlisle> | hsivonen: true |
| 10:39 | <hsivonen> | david_carlisle: ok. "add an attribute" is the best I can suggest |
| 10:39 | <david_carlisle> | hsivonen: :-) |
| 10:39 | <hsivonen> | well, I suppose I should go ahead and implement it soonish |
| 10:40 | <david_carlisle> | hsivonen: stop chatting here and get to work (actually that applies to me too) |
| 10:45 | <hsivonen> | david_carlisle: well, figuring out what makes sense to implement is work, too |
| 10:46 | <annevk> | abarth, "callTheAdoptionAgency" lol |
| 10:46 | <abarth> | eric wanted a wittier name |
| 10:47 | <abarth> | but that's all we could think of |
| 10:47 | <othermaciej> | what does that function do? |
| 10:47 | <david_carlisle> | hsivonen: OK you're forgiven than but probably I won't be, I need to go... |
| 10:48 | <abarth> | othermaciej: it goes and reparents a bunch of nodes |
| 10:48 | <annevk> | othermaciej, implements the adoption agency algorithm |
| 10:48 | <abarth> | othermaciej: to correct for mis-nested tags |
| 10:48 | <othermaciej> | abarth: I was thinking either giveUpForAdoption() or adopt() would be good names |
| 10:48 | <abarth> | its somewhat famous in HTML parsing circles |
| 10:48 | <othermaciej> | but it sounds like it does both, depending on your perspective |
| 10:48 | <abarth> | patches welcome :) |
| 10:49 | <abarth> | the spec sayeth |
| 10:49 | <othermaciej> | I know what the AAA is, I just wasn't sure what the parameters and behavior of this particular function were |
| 10:49 | <abarth> | 'Because of the way this algorithm causes elements to change parents, it has been dubbed the "adoption agency algorithm" (in contrast with other possible algorithms for dealing with misnested content, which included the "incest algorithm", the "secret affair algorithm", and the "Heisenberg algorithm").' |
| 10:49 | <abarth> | it just takes the current token |
| 10:49 | <annevk> | hehe |
| 10:49 | <abarth> | like all the tree builder functions |
| 10:49 | <othermaciej> | I guess it is hard to make it a transitive verb then |
| 10:50 | <abarth> | but that's just how the tree builder works |
| 10:50 | <annevk> | I wonder when I'll forgot how each browser (used to) map to those names |
| 10:50 | <othermaciej> | I can figure out which is which from the names |
| 10:51 | <othermaciej> | maybe someday it won't be a memorable fact |
| 10:51 | <othermaciej> | (WebKit, Trident, Presto, Gecko in order of reference) |
| 10:52 | <othermaciej> | and I even vaguely remember why the other three have those names but even talking about what legacy IE does makes me shudder |
| 10:53 | <virtuelv> | othermaciej: are you implying the IE engine is a weapon? |
| 10:53 | <hsivonen> | btw, I was about to suggest a change to the AAA yesterday. maybe I'll get around to it today |
| 10:54 | <jgraham> | hsivonen: Should I be scared? |
| 10:54 | <hsivonen> | jgraham: no, I'd expect you to be happy about it |
| 10:55 | <hsivonen> | oops. actually my change is for putting stuff in the list of active formatting elements in the first place--not to the AAA |
| 10:55 | <othermaciej> | I wonder how the spec version of AAA avoids O(N^2) behavior in the cases where in the old WebKit parser we had to add hardcoded limits |
| 10:55 | <jgraham> | othermaciej: It doesn't |
| 10:55 | <othermaciej> | or rather I wonder how the WebKit implementation of the spec version does so |
| 10:55 | <hsivonen> | jgraham: I was thinking we should search the list for font elements with the same attributes as the current token |
| 10:55 | <hsivonen> | jgraham: then zap the first one on the list if there's a match |
| 10:55 | <hsivonen> | but only if the list is longer than n |
| 10:56 | <hsivonen> | for a carefully chosen n |
| 10:56 | <abarth> | othermaciej: we have limits |
| 10:56 | <hsivonen> | abarth: what do you limit? |
| 10:56 | <othermaciej> | I guess those tests are passing so there must be something |
| 10:56 | <jgraham> | hsivonen: Just to reduce the number of elements on the list? |
| 10:56 | <abarth> | the two loops |
| 10:56 | <hsivonen> | Gecko has a limit on the depth of the tree |
| 10:57 | <abarth> | yeah, we don't have that yet, but i expect someone to complain |
| 10:57 | <hsivonen> | jgraham: to stop insane growth when pages open <font> without ever closing |
| 10:57 | <hsivonen> | and opening <font> a zillion times |
| 10:58 | <othermaciej> | I should probably see if I can get O(N^2) with variants of some of the cases I added as layout tests |
| 10:58 | <hsivonen> | so that reconstructing the active formatting elements reconstruct more and more every time |
| 10:58 | <jgraham> | The current gecko behaviour doesn't stop badness for well-chosen input |
| 10:58 | <hsivonen> | jgraham: I know |
| 10:58 | <jgraham> | I haven't tested webkit yet |
| 10:58 | <jgraham> | hsivonen: I know you know :) |
| 10:58 | <abarth> | the limits are different than the old parser |
| 10:58 | <hsivonen> | abarth: the depth limit is needed in Gecko, because Gecko's layout module has algorithms that are recursive along tree depth |
| 10:59 | <abarth> | webkit used to limit to 4k depth |
| 10:59 | <hsivonen> | and Windows has relatively small permitted call stack depth |
| 11:00 | <othermaciej> | WebKit has recursive algorithms too |
| 11:00 | <hsivonen> | othermaciej: interesting. how do you avoid crashing on Windows? |
| 11:00 | <othermaciej> | I kind of wish all recursive algorithms could be rewritten as iterative but it would be quite awkward in the case of layout |
| 11:00 | <othermaciej> | I think in practice other limits would kick in before the depth limit on bad input |
| 11:01 | <othermaciej> | there might also be a separate render tree limit but I don't recall |
| 11:01 | <othermaciej> | my design preference would be to not limit the dom around the render tree's limitations as probably nearly all dom algorithms could be made iterative without much hassle; and then depth limiting can be in the render tree if it exists at all |
| 11:02 | <othermaciej> | but that implies all sorts of nontrivial changes |
| 11:08 | <hsivonen> | abarth: did you check that the early exit from the AAA loops due to the limit doesn't leave the list of active formatting elements in a bad state? |
| 11:08 | hsivonen | has not gotten around to thinking through the implications |
| 11:09 | <abarth> | what bad states are there? |
| 11:09 | <hsivonen> | abarth: markers getting out of sync, I guess |
| 11:10 | <hsivonen> | but I think the AAA never removes a marker, does it? |
| 11:10 | <Rik`> | Why WebKit browsers add datalist { display: none; } ? |
| 11:10 | <abarth> | dunno. eric wrote the AAA |
| 11:11 | <hsivonen> | maybe we should hard-code 10 as a limit in the spec if 10 is good enough |
| 11:12 | <Rik`> | it makes <datalist> useless for the time being :( |
| 11:12 | <abarth> | 10 lets you build a really big tree |
| 11:12 | <hsivonen> | abarth: have you run this on Google data sets to see how often the limit is hit? |
| 11:13 | <abarth> | http://trac.webkit.org/browser/trunk/LayoutTests/fast/parser/residual-style-dom.html |
| 11:13 | <abarth> | nope |
| 11:13 | <annevk> | Rik`, shouldn't it be display:none? |
| 11:13 | <Rik`> | annevk: not if you don't support @list |
| 11:13 | <abarth> | http://trac.webkit.org/export/67375/trunk/LayoutTests/fast/parser/residual-style-dom-expected.txt |
| 11:13 | <annevk> | Rik`, oh... stupid |
| 11:14 | <Rik`> | annevk: btw, it's also broken in Opera but I can't even set display: block |
| 11:14 | <hsivonen> | abarth: isn't that testing "reconstruct active formatting element" as opposed to testing the AAA? |
| 11:15 | <annevk> | Rik`, data:text/html,<input list=x><datalist id=x><option value=test><option value=grr></datalist> wfm |
| 11:15 | <Rik`> | I'm using <option>test<option>grrr |
| 11:15 | <annevk> | interesting |
| 11:15 | <abarth> | hsivonen: there's no limit on reconstructing the active formatting elements |
| 11:16 | <annevk> | maybe we never supported that |
| 11:16 | <abarth> | hsivonen: i could be wrong about this stuff. AAA is eric's area |
| 11:16 | <abarth> | (i make him do the hard stuff) |
| 11:16 | <Rik`> | annevk: is it supported in HTML5 now ? |
| 11:17 | <annevk> | dunno |
| 11:18 | <annevk> | Rik`, per HTML5 we have a bug yes |
| 11:18 | <Rik`> | annevk: but yeah, at least it's working with value= |
| 11:18 | <annevk> | value of option is either its value attribute or its textContent attribute |
| 11:19 | <Rik`> | I'm really angry at the webforms support in WebKit browsers :( |
| 11:19 | <hsivonen> | https://wiki.mozilla.org/User:Mounir.lamouri/HTML5_Forms#Shipping_Criteria FTW! |
| 11:21 | <Rik`> | this page is a bit out of date |
| 11:21 | <annevk> | yeah, Mozilla is doing it the right way |
| 11:22 | <Rik`> | I really enjoy working with Mounir although he's not in the Paris at the moment |
| 11:22 | <annevk> | Rik`, you work for Mozilla? |
| 11:22 | <Rik`> | currently |
| 11:22 | <abarth> | i might be misremembering, but i think some of the forms work in webkit was done by new contributors |
| 11:23 | <annevk> | ah |
| 11:23 | <Rik`> | my contract ends at the end of this week |
| 11:23 | <annevk> | abarth, someone from Google had the wrong idea too about some stuff iirc |
| 11:23 | <Rik`> | abarth: whoever worked on it, it should have never shipped in this state |
| 11:23 | <annevk> | i.e. that the UI-facing stuff could just be ignored |
| 11:24 | <hsivonen> | http://saintjohnchurchmiddletown.com/default.aspx has markup that exercises "reconstruct the active formatting elements" a lot |
| 11:24 | <hsivonen> | and they actually close </font> eventually! |
| 11:25 | <annevk> | heh |
| 11:25 | <abarth> | hsivonen: hum... that one definitely needs off-the-main-thread parsing |
| 11:25 | <annevk> | they expect logic and get HTML instead ;p |
| 11:26 | <abarth> | ok, bed time for me |
| 11:27 | <abarth> | night all |
| 11:58 | <annevk> | I'm starting to think that lots of stuff was kept on Node to make the Java case of casting the exception rather than the rule... |
| 11:59 | <annevk> | e.g. there's no reason for attributes to be on Node, and yet it is |
| 11:59 | <annevk> | or namespaceURI, or localName |
| 12:05 | <jgraham> | Oh, that makes more sense than my previous theory that the WG meeting happened in the same convention centre as a hippy gathering and the DOM WG got served the wrong brownies |
| 12:10 | <zcorpan_> | annevk: i thought fileapi didn't use domexception? |
| 12:11 | <annevk> | ms2ger wants to keep HTML5 and DOM Core consistent |
| 12:16 | <annevk> | jgraham, :) |
| 12:16 | <annevk> | hopefully we can undue some of the Java damage |
| 12:17 | <annevk> | I suppose the web will disagree, but I'm hoping nobody relies on namespaceURI returning null for e.g. Document and that undefined will be fine too |
| 12:25 | <zcorpan_> | if (!('namespaceURI' in document)) { breakPage(); } |
| 12:41 | <annevk> | yeah, those people |
| 14:56 | <boblet> | any microdata ppl around? random q for ya: why does itemtype not imply itemscope? |
| 14:56 | <hsivonen> | btoa(unescape(encodeURIComponent("\u0000"))) |
| 14:57 | <hsivonen> | for the record, that's how to take a JS string and base64-encode the UTF-8 bytes |
| 14:57 | <zcorpan_> | boblet: iirc it did before (it was just called item="" or item="type"), but from the usability study it turned out to be confusing and having two attributes was better understood |
| 14:58 | <boblet> | zcorpan_: aah thanks. yeah I guessed ease of learning/parsing, nice to know I’m not too far off :) |
| 15:00 | <annevk> | did my bug just get hijacked: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10619 ? |
| 15:00 | <annevk> | it clearly says "other" in "component"... |
| 15:00 | <annevk> | oh well |
| 15:01 | <hsivonen> | MikeSmith: ^ |
| 15:12 | MikeSmith | takes a lookg |
| 15:12 | <karlushi> | annevk, Bugzilla is confusing in terms of UI and indeed people read too quick sometimes. the Comment #1 seems to be out of scope indeed. |
| 15:12 | <MikeSmith> | btw, I will be turning off all Cc'ing of bug mail to the public-html list |
| 15:12 | <MikeSmith> | PhilippJ is right |
| 15:13 | <MikeSmith> | we need to find better ways to help WG members stay informed about bugs |
| 15:13 | <annevk> | ideally we'd use public-html for technical discussion |
| 15:13 | <annevk> | but that might be too high a bar |
| 15:13 | <hsivonen> | looks like Gecko doesn't support DONE property on xhr |
| 15:13 | <hsivonen> | need to use 4 |
| 15:14 | <hsivonen> | so the examples in the spec don't work |
| 15:14 | <annevk> | I just changed those to use DONE |
| 15:14 | <annevk> | Opera doesn't support it either |
| 15:14 | <hsivonen> | annevk: I've sent a couple of technical emails. let's see how that goes |
| 15:14 | <karlushi> | MikeSmith, something that could be helpful but would take a lot more time and resources is a weekly summary of the bugs |
| 15:14 | <annevk> | I'd appreciate if people start fixing their bugs in http://tc.labs.opera.com/apis/XMLHttpRequest |
| 15:15 | <MikeSmith> | annevk: I don't know what you mean by hijacked -- history of changes to the bug doen't show anything changing in component - http://www.w3.org/Bugs/Public/show_activity.cgi?id=10619 |
| 15:15 | <hsivonen> | annevk: anyway, on a more positive note, \0 and CR aren't tampered with |
| 15:15 | <hsivonen> | annevk: http://hsivonen.iki.fi/test/moz/xhr-text.html |
| 15:16 | <annevk> | MikeSmith, oh, nothing like that happened |
| 15:16 | <MikeSmith> | karlushi: probably for some people, but a lot of other people would still not read it |
| 15:16 | <annevk> | hsivonen, cool, I should add that to the testsuite |
| 15:16 | <annevk> | the only interesting bugs are those that affect the big picture |
| 15:16 | <annevk> | and those are no longer filed, afaict |
| 15:17 | <hsivonen> | my priorities probably differ from the priorities of Web developers |
| 15:17 | <hsivonen> | I care more about \0 and CR |
| 15:17 | <MikeSmith> | annevk, hsivonen - just wondering what if anything requires my attention here -- thought Henri was pinging me about that bug |
| 15:18 | <annevk> | MikeSmith, I was complaining about the comment being added |
| 15:18 | <annevk> | MikeSmith, you can go back to sleep :) |
| 15:18 | <hsivonen> | MikeSmith: is it permitted to use that bugzilla component for developing specs that aren't yet at the W3C? |
| 15:18 | <karlushi> | annevk, MikeSmith : In the current design of Bugzilla, what are the labels which are useless? I see things like WhiteBoard |
| 15:19 | <karlushi> | MikeSmith, indeed some people would not read it. :/ |
| 15:19 | <annevk> | karlushi, for the HTML WG? |
| 15:19 | <karlushi> | annevk, yes only for the htmlwg bugzilla |
| 15:19 | <annevk> | karlcow, version, platform, target milestone, QA contact |
| 15:20 | <annevk> | importance prolly only needs the text label, not the p1-5 |
| 15:20 | <MikeSmith> | hsivonen: yes, it absolutely is.. we set up that bugzilla product for people who want to comment on any online version of the spec |
| 15:21 | <hsivonen> | MikeSmith: thanks. I guess shelley isn't aware |
| 15:21 | <MikeSmith> | yeah, well |
| 15:23 | <MikeSmith> | I leave it to Hixie or anybody else who wants to respond there to clarify that if they want |
| 15:26 | <MikeSmith> | (not that I'm saying that it actually needs any explicit clarification) |
| 15:31 | <karlushi> | http://www.symphonious.net/2010/09/12/content-types-matter/ |
| 15:33 | <zcorpan_> | Tivoli Access Manager should have used the same sniffing algorithm as browsers (although it might not have helped in that case since <script src> is a specific context that Tivoli Access Manager might not know about) |
| 15:35 | <hsivonen> | zcorpan_: indeed |
| 15:35 | <hsivonen> | I like this bit: "Tivoli Access Manager is an interesting and powerful beast that never seems to be configured right." |
| 15:35 | <hsivonen> | back in 2003 when I was exposed to Tivoli Access Manager, it had a severe pipelining bug |
| 15:36 | <hsivonen> | if you made pipelined requests, it would return the right set of responses, but the responses would be to the wrong requests |
| 15:36 | <hsivonen> | so requesting a bunch of images made the images switch places on the page |
| 15:38 | <zcorpan_> | heh |
| 15:38 | <karlushi> | http randomizer? :) |
| 15:39 | <zcorpan_> | wonder if we have that in our regression testing system (sometimes it seems like it) |
| 15:58 | <annevk> | hmm, should DOM Core have contains()? |
| 16:02 | <hsivonen> | fwiw, I think COM / C++ is also to blame for "everything on Node" design. not just Java. |
| 16:05 | <MikeSmith> | is Node perceived as a negative reaction against Java? |
| 16:06 | <annevk> | well, my theory was that lots of stuff was put on Node to reduce the need for casting in Java |
| 16:06 | <annevk> | e.g. namespaceURI, localName, the works |
| 16:06 | <Philip`> | MikeSmith: Are you talking about the DOM Node interface, or Node.js? |
| 16:07 | <hsivonen> | also for reduced need to call QueryInterface in COM |
| 16:07 | <MikeSmith> | oh |
| 16:07 | <MikeSmith> | Philip`: sorry, I misunderstoo |
| 16:07 | <MikeSmith> | d |
| 16:07 | <MikeSmith> | ignore me |
| 16:22 | <zcorpan_> | hsivonen: iirc i have suggested not reconstructing on spaces before (and old gecko ignored linebreaks) although Hixie said the spec is the way it is for compat but didn't have a list of urls |
| 16:23 | <zcorpan_> | hsivonen: i've also seen author confusion at sitepoint forums about reconstructing for whitespace |
| 16:25 | <hsivonen> | zcorpan_: having to have it that way for compat seems odd |
| 16:26 | <hsivonen> | zcorpan_: what are people confused about on sitepoint? I thought the sitepoint folks would have clean enough code not to see it. ;-) |
| 16:27 | <zcorpan_> | someone had typoed </a> as <a/> and went WTF about the resulting DOM in webkit and new gecko |
| 16:27 | <hsivonen> | I see |
| 16:49 | <hober> | TabAtkins: made several changes to http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-41 over the weekend--added a use case (thanks hsivonen), rejiggered various other bits. |
| 17:31 | <zcorpan_> | if we're going to change the handshake in incompatible ways again, i hope we make it more straightforward to implement so that articles like these don't need to be written http://deusty.blogspot.com/2010/09/websocket-draft-76-algorithm-example.html |
| 17:51 | <TabAtkins> | hsivonen: Commented on the <p><figure> bug with support. |
| 17:52 | <hsivonen> | TabAtkins: thanks |
| 17:52 | <hsivonen> | TabAtkins: fwiw, the private feedback I've gotten (1 person) was about the same |
| 18:19 | <hober> | I've always emulated <figure> with <div>, not <span> |
| 18:19 | <hober> | so it seems weird to me to want <figure> as a child of <p> |
| 18:19 | <TabAtkins> | I know that I've written plain-text where I have figures inside of paragraphs. |
| 18:20 | <TabAtkins> | In fact, I do it regularly in technical emails, where I'll have a sample of code in the middle of a sentence. |
| 18:25 | <zcorpan_> | TabAtkins: maybe you sometimes also have a list or a table in the middle of a sentence? |
| 18:26 | <TabAtkins> | zcorpan_: Yes, but less commonly. Presumably those have legacy constraints, though. |
| 18:27 | <annevk> | it gets icky when you do <p><figure><ol> though |
| 18:27 | <annevk> | or <p><figure><table> |
| 18:27 | <TabAtkins> | Icky in precisely which way? From a spec-writing standpoint, an implemention standpoint, or an authoring standpoint? |
| 18:27 | <annevk> | hsivonen, so would those have to be disallowed? or do you want to make <figure> scoping which seems kind of hackish... |
| 18:27 | <annevk> | all |
| 18:28 | <annevk> | apart from the first, prolly |
| 18:28 | <annevk> | and the second does not matter much either |
| 18:28 | <TabAtkins> | I don't know about authoring. I mean, the fact that <p><ol> wouldn't work but <p><figure><ol> might is *dumb*, but not a *problem*, per se. It's just a stupid platform quirk. |
| 18:30 | <annevk> | it's not dumb, it's confusing as hell |
| 18:32 | <hober> | the way <p> auto-closes is weird, but it's not going away. given that, it seems like new elements should behave like their closest-analog old elements. so <section> auto-closes <p> because <div> does, etc. |
| 18:33 | <TabAtkins> | I prefer, when legacy behavior is retarded, to instead fix the behavior going forward rather than trying to remain consistent with the retarded behavior. Foolish consistency, hobgoblin, little minds, etc. |
| 18:34 | <hober> | we at least want the language to cohere. given that <div> and the other old "block" elements auto-close <p>, as an author I expect <article> to, and would be (even more) weirded out if it didn't. |
| 18:35 | <hober> | I mean, I can at least sort-of make sense of the legacy auto-closing. If <article> didn't auto-close <p>, suddenly the weird-but-kinda-makes-sense auto-closing rules are even less predictable |
| 18:39 | <annevk> | I would not say it is "retarded" |
| 18:40 | <annevk> | and I also do not think that having half the features work one way and half the features work another way is a win |
| 18:42 | <TabAtkins> | On the other hand, neither is having all of the features work the wrong way. |
| 18:45 | <paul_irish> | annevk: is window.media.matchMedium gone from the spec? |
| 18:46 | <paul_irish> | gone forever? :'( |
| 18:49 | <annevk> | euh no? |
| 18:49 | <annevk> | we just redesigned the feature |
| 18:55 | <paul_irish> | annevk: good good. where can i find the latest ? |
| 19:02 | <annevk> | same draft? |
| 19:02 | <annevk> | it's called matchMedia and lives on window now |
| 19:02 | <paul_irish> | thx |
| 19:02 | <annevk> | http://dev.w3.org/csswg/cssom-view/#dom-window-matchmedia |
| 19:19 | <zcorpan_> | does someone have an example at hand of a utf-8 byte sequence of a 3 or 4-byte overlong form? |
| 19:19 | <TabAtkins> | What's an "overlong form"? Anything that's 3 or 4 bytes in utf-8? |
| 19:19 | <zcorpan_> | "a sequence that decodes to a value that should use a shorter sequence" |
| 19:20 | <TabAtkins> | Oh, gotcha. So called because there are boundary conditions where a value could be validly written with or without the extra byte. Ok. |
| 19:20 | <annevk> | zcorpan_, they're easy to construct from http://en.wikipedia.org/wiki/UTF-8 |
| 19:21 | <TabAtkins> | Just look at the end of the ranges for any given byte-length. Anything sufficiently close to the end should be capable of being rewritten as an overlong form, though I'd have to do some work to actually determine what "sufficiently close" is. |
| 19:21 | <TabAtkins> | Probably just the last one or two of each range. |
| 19:22 | <annevk> | e.g. E0 80 80 80 |
| 19:22 | <TabAtkins> | Or, no, you can construct an overlong from from any character, right? |
| 19:22 | <annevk> | that latest 80 is out of range |
| 19:23 | <annevk> | there's also start of 5 and 6 byte sequences but in theory they ought to be treated as a single invalid byte now, I think |
| 19:23 | <zcorpan_> | annevk: E0 is a 3-byte sequence. you gave a 4-byte sequence... |
| 19:24 | <annevk> | oh sorry |
| 19:25 | <annevk> | so there are 3/4 byte overlong forms? |
| 19:26 | <zcorpan_> | i'm not sure |
| 19:26 | <TabAtkins> | Would, say, F0 80 80 60 work? (A space, expanded out to 4 bytes.) |
| 19:26 | <zcorpan_> | TabAtkins: 60 isn't a continuation byte |
| 19:27 | <TabAtkins> | Urgh, right. Sorry. I meant A0 |
| 19:28 | <zcorpan_> | thanks |
| 19:28 | <zcorpan_> | seems webkit and gecko turn that into a u+fffd but opera doesn't |
| 19:29 | <annevk> | 0xC0 0x8A |
| 19:29 | <annevk> | 0xE0 0x80 0x8A |
| 19:29 | <annevk> | 0xF0 0x80 0x80 0x8A |
| 19:29 | <annevk> | 0xF8 0x80 0x80 0x80 0x8A |
| 19:29 | <annevk> | 0xFC 0x80 0x80 0x80 0x80 0x8A |
| 19:29 | <annevk> | via http://www.cl.cam.ac.uk/~mgk25/unicode.html |
| 19:32 | <hsivonen> | annevk: I'd prefer to make <figure> scoping, yes. |
| 19:38 | <annevk> | zcorpan_, I think what you wrote there should be part of the "web UTF-8" spec (or just the UTF-8 spec if everyone can agree on decoding worldwide) |
| 19:38 | <annevk> | doesn't really make sense to me to handle UTF-8 decoding specifics as part of HTML5 |
| 19:38 | <zcorpan_> | annevk: sure |
| 19:39 | <Hixie> | that would make my life so much easier |
| 19:40 | <Hixie> | btw i'm officially on vacation for the next two weeks -- i'll be online some of the time but not always |
| 19:40 | <annevk> | it's also a problem for instance for responseText |
| 19:41 | <annevk> | ooh, have fun |
| 19:41 | <zcorpan_> | starting today? |
| 19:46 | <MikeSmith> | so... Philip Jägenstedt has said in the past that he finds the volume of automated bug notifications on the public-html list and the a11y-tf list to be excessive |
| 19:47 | <hsivonen> | Hixie: have a good vacation |
| 19:47 | <MikeSmith> | Hixie: yeah, enjoy your break |
| 19:47 | <zcorpan_> | +1 |
| 19:48 | <hsivonen> | I guess this means I'll have to file my pending mailing list questions as bugs in order to have them on file by the cutoff |
| 19:49 | <annevk> | MikeSmith, maybe email should go to public-html once a bug is resolved/reopened? |
| 19:49 | <annevk> | MikeSmith, though then I guess spam that gets closed as INVALID will be emailed too... |
| 19:49 | <annevk> | hmm |
| 19:50 | <zcorpan_> | some bugs are resolved and reopened lots of times |
| 19:51 | <MikeSmith> | annevk: I'm redirecting it to the issue-tracking list |
| 19:51 | <MikeSmith> | which is where we should have had it going to begin with |
| 19:52 | <MikeSmith> | having bug notifications going to a technical discussion list is an anti-pattern |
| 19:52 | <annevk> | ah, I'm not on that list |
| 19:52 | zcorpan_ | would prefer to have no bugmail on public-html |
| 19:52 | <annevk> | I think it's great that bugmail goes to public-webapps |
| 19:53 | <annevk> | but it's a very different kind of bugmail |
| 19:53 | <annevk> | much like it's a very different kind of email that goes to public-webapps |
| 19:53 | <annevk> | you know, technical debate :) |
| 19:58 | <annevk> | Ms2ger, zcorpan_, gsnedders, for DOM Core you may not get listed as editor unless you somehow join the WG |
| 19:58 | <annevk> | I thought of adding something like this to the acknowledgments instead |
| 19:59 | <Ms2ger> | Fine with me |
| 19:59 | <zcorpan_> | me too |
| 19:59 | <annevk> | "Many thanks to ms2ger, Simon Pieters, and Geoffrey Sneddon for editing the initial 80% of this specification." |
| 20:00 | <annevk> | s/ms2ger/Ms2ger/ I guess |
| 20:00 | <Ms2ger> | Please :) |
| 20:16 | <zcorpan_> | wonder how i missed http://www.w3.org/Bugs/Public/show_bug.cgi?id=10343 in opera's impl |
| 20:29 | <zcorpan_> | wonder how many people will file a bug about "outlinee" |
| 20:31 | <Ms2ger> | Half a dozen so far? |
| 20:32 | <zcorpan_> | there were probably half a dozen before bugzilla also |
| 20:34 | <MikeSmith> | about http://hg.diveintohtml5.org/hgweb.cgi/rev/6067cc62b7016825817aa047cef52bc8ee8d7d5f |
| 20:34 | <MikeSmith> | I thought that some versions of IE would go into quirks mode if you had anything before the doctype |
| 20:34 | <MikeSmith> | is that not that case? |
| 20:35 | <hsivonen> | comments, including bogus one like XML decl, are bad in IE6 |
| 20:36 | <Rik`> | I just discovered http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#script-processing-for |
| 20:36 | <zcorpan_> | comments, including bogus one except the XML decl (if it's on one line, iirc), are bad in IE7-8 (dunno about 9) |
| 20:36 | <Rik`> | that's kind of weird to only allow one value for this |
| 20:37 | <zcorpan_> | Rik`: allow? <script for> is invalid |
| 20:37 | <Ms2ger> | It's the only value that matters for compat |
| 20:37 | <Rik`> | zcorpan_: I mean you can only use it for window.onload |
| 20:38 | <zcorpan_> | except it's not equivalent to window.onload at all |
| 20:39 | <Rik`> | it's just a "check" to abort if those attributes use a different value ? |
| 20:39 | <zcorpan_> | yeah |
| 20:40 | <Rik`> | what's the point ? |
| 20:40 | <zcorpan_> | compat |
| 20:40 | <Rik`> | which browsers does that ? |
| 20:41 | <zcorpan_> | gecko and webkit match the spec, i think, and ie ... i don't know what ie does exactly |
| 20:41 | <zcorpan_> | opera ignores these currently |
| 20:41 | <Rik`> | Webkit just added it (http://peter.sh/2010/09/last-week-asynchronous-script-execution-and-gpu-acceleration-by-default/) |
| 20:41 | <zcorpan_> | the attributes that is |
| 20:42 | <zcorpan_> | yeah, webkit found they needed it for compat a few months ago |
| 20:42 | <zcorpan_> | which is why it's in the spec now |
| 20:42 | <Rik`> | who did invented this ? |
| 20:43 | <Rik`> | that's completely weird |
| 20:43 | <Peter-> | apparently comedycentral.com was depending on it |
| 20:43 | <zcorpan_> | i think ie invented it (but with real events), mozilla implemented a hack for compat with something that was ie-only |
| 20:43 | <zcorpan_> | and now webkit copied mozilla and that's what's in hte spec |
| 20:44 | <Peter-> | https://bugs.webkit.org/show_bug.cgi?id=45310#c8 |
| 20:44 | <Rik`> | that's a great exemple of how web content is fucked up |
| 20:45 | <zcorpan_> | you'll get used to it :) |
| 20:45 | <Rik`> | well, I think that's the weirdest one I've seen |
| 20:46 | <annevk> | you don't think <table>test -> test<table> is weird? |
| 20:46 | <annevk> | or <image> -> <img> |
| 20:46 | <Rik`> | not that much |
| 20:48 | <zcorpan_> | should we replace 'This section is non-normative' with 'This section has no conformance requirements'? |
| 20:57 | <annevk> | yeah maybe |
| 20:57 | <annevk> | conformance requirements is somewhat clearer than non-normative |
| 20:58 | <zcorpan_> | i remember at first when i read specs, i didn't understand what normative/informative/non-normative meant |
| 20:59 | <annevk> | same, i recall being somewhat proud when I got it :) |
| 21:19 | <zcorpan_> | i remember thinking it was stupid terminology :P |
| 21:20 | <annevk> | heh |
| 21:21 | <annevk> | I guess DOM Core does not need to say much about baseURI |
| 21:21 | <annevk> | hmm, it's on Node again o_O |
| 21:21 | <annevk> | oh, and it's even readonly... |
| 21:28 | <zcorpan_> | iirc baseURI needs to be on Node, or at least Element |
| 21:29 | <annevk> | Element/Document would make sense to me |
| 21:31 | <annevk> | I guess they should be set at the markup language level |
| 21:31 | <annevk> | so DOM Core just needs to provide some hooks somehow |
| 21:36 | <annevk> | DOM3Core doesn't even define baseURI in detail for the various node types... I guess it could just inherit, but what about DocumentFragment? |
| 21:36 | <zcorpan_> | annevk: i didn't realize DOMException inherited from Error when i added name and message to the spec |
| 21:37 | <annevk> | k |
| 21:38 | <annevk> | I filed the relevant bugs on Web IDL to redo the way we do exceptions |
| 21:53 | <AryehGregor> | Hmm, as of last update http://aryeh.name/tests/reflection.html gives a sad tab in Chrome dev. :( |
| 23:18 | gsnedders | rejoices from his initial fears about his flatmates all being crazy, finding one other that's totally sane, and another who's mostly |
| 23:26 | <AryehGregor> | Yay, my reflection tests cause WebKit nightlies to crash. |
| 23:54 | <mikekelly> | is it valid html to stick a link element in the body ? |