| 00:00 | <AryehGregor> | And there are lots of such sites, I guess? |
| 00:00 | <AryehGregor> | And they use it in more complicated ways, so that you can't just alias it to textContent? |
| 00:00 | <AryehGregor> | Or at least spec it to not be so complicated? |
| 00:00 | <gsnedders> | Certainly Opera's impl isn't much different to textContent |
| 00:00 | <gsnedders> | Though we do have open site compat bugs because of this |
| 00:00 | <AryehGregor> | Interesting. |
| 00:00 | <AryehGregor> | What do those sites do in Gecko? |
| 00:01 | <Philip`> | AryehGregor: I don't know if there are lots |
| 00:01 | <Philip`> | There's ones with other kinds of fallback like |
| 00:01 | <Philip`> | if (wnd.document.body.innerText != undefined) sel_text=wnd.document.body.innerText; else sel_text=wnd.document.body.innerHTML; |
| 00:02 | <Philip`> | if(a[0].innerText!=undefined)a[0].innerText=d;else a[0].textContent=d; |
| 00:03 | <AryehGregor> | Both of those seem like they should work if you just don't have innerText, or substitute textContent. |
| 00:04 | <gsnedders> | AryehGregor: MooTools uses: script[(Browser.Engine.webkit && Browser.Engine.version < 420) ? 'innerText' : 'text'] = text; |
| 00:06 | <Philip`> | return(elem.textContent||elem.innerText||Sizzle.getText([elem])||"").indexOf(match[3])>=0 |
| 00:07 | <AryehGregor> | All these except the first (explicit browser-sniffing) seem like you could just drop innerText. |
| 00:08 | <gsnedders> | Yeah, there's a fair amount of stuff that just uses it with alternations |
| 00:08 | <Philip`> | These are just the ones that have some fallback, though - I see quite a few that don't appear to |
| 00:08 | <gsnedders> | A lot of the site-compat bugs we have the site doesn't seem to use innerText any more |
| 00:08 | <AryehGregor> | Then they break in Firefox? |
| 00:08 | <Philip`> | In one case it's in a <script language="jscript"> so the script doesn't even run in Firefox |
| 00:09 | <AryehGregor> | othermaciej, do you know why WebKit implements innerText, and if it could just drop support? |
| 00:10 | <othermaciej> | What reason would we have to drop support? |
| 00:11 | <othermaciej> | I believe the reason we have it is that we inherited it from KHTML over 10 years ago - since then we made it match what other browsers do much better. |
| 00:11 | <othermaciej> | At this point, it's likely that WebKit-specific content depends on it |
| 00:11 | <AryehGregor> | Hmm, okay. |
| 00:11 | <AryehGregor> | For WebKit-specific content, it doesn't really need a spec, though. |
| 00:12 | <othermaciej> | also, more generally, it is a more useful "convert to plaintext" operation than textContent |
| 00:12 | <AryehGregor> | Yeah, that's true. |
| 00:12 | <AryehGregor> | Might be worth speccing just because of that. |
| 00:12 | <Philip`> | http://realestateview.com.au/cgi-bin/inspecttimes.pl?GID=2&GID=5&tp=2lease&Con=L says " properties open for inspection this week." with no number in Firefox |
| 00:12 | <AryehGregor> | I had an author remark to me that it was annoying that Selection's stringifier didn't insert newlines into things like <p>a<p>b, for instance. |
| 00:13 | <AryehGregor> | Do we know if Gecko wants to implement it? |
| 00:13 | <AryehGregor> | https://bugzilla.mozilla.org/show_bug.cgi?id=innertext |
| 00:14 | <Philip`> | Seems like zillions of pages use innerText, though mostly in trivial ways where it doesn't really matter if it's not supported, or they use textContent as an equivalent |
| 00:14 | <Philip`> | but that probably means there's a large absolute number that depend on it with no fallback |
| 00:16 | <othermaciej> | I think Mozilla folks have explicitly said they don't want to implement innerText |
| 00:16 | <othermaciej> | I did not find their reasoning very persuasive |
| 00:17 | <AryehGregor> | Hixie, does Gecko want to implement innerText? If not, is it still worth writing a spec? |
| 00:17 | <gsnedders> | We implemented it, FWIW, at IE's peak, where web-compat was very much a game of match-IE-as-much-as-possible |
| 00:19 | <gsnedders> | We have no strong opinion about whether it stays or not — if it isn't going to get specced, we will drop it. |
| 00:19 | <AryehGregor> | https://bugzilla.mozilla.org/show_bug.cgi?id=264412#c10 |
| 00:20 | <gsnedders> | Basically we either want interop, be it through a spec or not supporting it. |
| 00:23 | <erlehmann> | hey, i used to use innerText. |
| 00:31 | <benschwarz> | Philip`: you nailed it on the omit tags option. |
| 00:32 | <benschwarz> | Hixie: When you're around… https://github.com/benschwarz/developers.whatwg.org/issues/#issue/22 |
| 00:47 | <othermaciej> | gsnedders: KHTML developers were much more prone to blindly copy IEisms than WebKit devs are, but I do think the usefulness of innerText exceeds its semi-redundancy |
| 00:51 | <AryehGregor> | Yeah, it does seem more useful than textContent, although harder to spec. |
| 01:29 | <AryehGregor> | Opera is the only browser to display aryeh.name's favicon, hurrah. |
| 01:29 | <AryehGregor> | Now off to bed with me. |
| 01:47 | <Hixie> | AryehGregor: aim for the behaviour of the plurality of browsers. If only one browser doesn't do something, then we should spec it and let the browser vendors argue amongst themselves about whether the others should remove support instead. |
| 01:47 | <Hixie> | AryehGregor: it's always easier to make decisions like that from a position with data (e.g. having a spec), anyway |
| 06:38 | <benschwarz> | Hey folks |
| 06:48 | <asmodai> | http://petewarden.typepad.com/searchbrowser/2011/01/a-fundamental-bug-in-html5s-canvas.html <-- anyone saw that? |
| 06:51 | <hsivonen> | asmodai: that problem is unsolvable without trading away performance or geometric accuracy |
| 06:52 | <hsivonen> | asmodai: the suggestion about stroking the paths is the easiest content-side solution |
| 06:53 | <asmodai> | Figures people would have thought about it. ;) |
| 07:05 | <othermaciej> | hsivonen: I wonder how Flash avoids the problem |
| 07:05 | <othermaciej> | if you have alpha, then stroking the path is not enough |
| 07:05 | <othermaciej> | to get guaranteed seamless joins I suspect you need to turn off antialiasing |
| 07:23 | <hsivonen> | othermaciej: or you can trade away perf by painting the whole thing at a higher resolution without AA and then doing a bicubic downsample |
| 07:23 | <othermaciej> | I assume that isn't what Flash does |
| 07:23 | <othermaciej> | I am curious what they do |
| 07:23 | <hsivonen> | me, too |
| 07:24 | <othermaciej> | in canvas there's no way to turn off AA, so those things aren't options |
| 07:24 | <hsivonen> | Maybe Adobe knows something we don't |
| 07:24 | <hsivonen> | to turn off canvas AA, there's the option of running Chrome |
| 07:24 | <hsivonen> | or does Chrome have AA now? |
| 07:35 | <othermaciej> | I wasn't aware that their canvas ever lacked AA |
| 08:12 | <Hixie> | can't you avoid that problem (in principle, not in current canvas) by providing the renderer with all the geometry of the object and having it all painted at once? |
| 08:13 | <Hixie> | i can't see any way to avoid it if you're painting geometry piecemeal |
| 08:14 | <Hixie> | but anyway, in principle this should be solvable once we introduce Path primitives |
| 08:15 | <estellevw> | Question about the multiple attribute on email input type: according to spec, the emails should be separated with a comma (not a comma+space). FF4 and Opera support the comma and comma+space. Webkit does not. Is the spec changing? is this an issue people are debating? |
| 08:16 | <Hixie> | what do you mean by "support"? in the attribute, or in submission? |
| 08:16 | <estellevw> | :valid versus :invalid |
| 08:16 | <estellevw> | only opera seems to be validating on submission |
| 08:16 | <estellevw> | sorry, opera and FF4 |
| 08:17 | <estellevw> | and both are accepting the space |
| 08:17 | <estellevw> | on submission |
| 08:18 | <Hixie> | well there's no way to set it to have a space, so I don't see how it could matter for :valid or :invalid |
| 08:18 | <Hixie> | are you sure you don't mean the user interface? |
| 08:19 | <estellevw> | Yes, i am looking at the user interface, not testing it via js/DOM |
| 08:19 | <Hixie> | the user interface isn't defined in the spec, it doesn't have to use commas at all |
| 08:19 | <Hixie> | it could ask you to enter the e-mail addresses by thought control or by speech or etched on a piece of wood :-) |
| 08:19 | <Hixie> | the browser is responsible for splitting the user input into separate e-mail addresses and concatenating them with commas automatically |
| 08:21 | <estellevw> | "When the multiple attribute is specified on the element. The element's values are the result of splitting on commas the element's value." |
| 08:21 | <benschwarz> | Hixie: still around? |
| 08:22 | <annevk> | estellevw, both are referring to the underlying values |
| 08:22 | <Hixie> | benschwarz: yo |
| 08:22 | <annevk> | estellevw, not the "UI value" |
| 08:22 | <hsivonen> | Hixie: I suppose it theory you could avoid the AA problem if the rendered had all the geometry available to it. |
| 08:22 | <benschwarz> | Hixie: heyo. Kept missing you today |
| 08:22 | <hsivonen> | *in theory |
| 08:22 | <benschwarz> | Hixie: did you see my messages? |
| 08:22 | <Hixie> | benschwarz: yeah sorry kept going out and stuff |
| 08:22 | <estellevw> | thanks |
| 08:23 | <Hixie> | benschwarz: for blog posts, feel free to post whatever whenever, it's an open blog :-) |
| 08:23 | <Hixie> | benschwarz: for the credits, it's entirely up to you |
| 08:23 | <benschwarz> | Hixie: just wasn't sure how to word it. |
| 08:23 | <benschwarz> | if you're happy with it as is, I'll leave until I come up with something better |
| 08:24 | <benschwarz> | Hixie: whats an open blog? |
| 08:24 | <Hixie> | benschwarz: anyone can post |
| 08:24 | <benschwarz> | oh right |
| 08:25 | <hsivonen> | Hixie: well, admin approval is required |
| 08:25 | <Hixie> | benschwarz: you mean the third paragraph of the About bit? |
| 08:25 | <benschwarz> | Hixie: yeah |
| 08:25 | <hsivonen> | Hixie: now ahead of time, because we had a serious problem with Polish furniture spam |
| 08:25 | <Hixie> | hsivonen: i meant open policy, but yeah |
| 08:25 | <benschwarz> | Hixie: and regarding the chrome frame code—you were right :) |
| 08:26 | <benschwarz> | it will cause invalidation and provide little to no benefit given this audience |
| 08:26 | <benschwarz> | I'd prefer the spec to validate, because people will be looking |
| 08:26 | <hsivonen> | benschwarz: have you registered for the blog already? |
| 08:26 | <benschwarz> | :) |
| 08:26 | <benschwarz> | I haven't hsivonen |
| 08:26 | <Hixie> | benschwarz: looks ok to me. might be useful for new readers who don't know what the html spec is at all to let them know it's a variant of the actual HTML spec done at the WHATWG, and to clarify that the credits are about the styling and presentation and not the content, but that would be my only comment. (maybe link to the acks for more or something?) |
| 08:27 | <benschwarz> | link to acks is a good idea |
| 08:27 | <hsivonen> | benschwarz: if new user registration is now blocked (as it should be), if you /msg me a desired username, your email address and your blog URL, I can try creating an account for you |
| 08:28 | <benschwarz> | hsivonen: sure, I'll wait to bother you when I have something to write :) |
| 08:28 | <hsivonen> | benschwarz: ok |
| 08:28 | <benschwarz> | thanks :) |
| 08:29 | <hsivonen> | kudos to whoever cleaned up the blog user database, BTW |
| 08:29 | <hsivonen> | was the process automated somehow? |
| 08:30 | <benschwarz> | Hixie: so what do you say about removing the chrome frame tag? |
| 08:30 | <hsivonen> | whoa! only markp has posted more posts on the whatwg blog than I have |
| 08:31 | <Hixie> | benschwarz: you mean the microsoft splinter-the-web pragma that chrome adopted as a trigger for their plugin? you can guess my suggestion from the way i've not made it valid :-) |
| 08:31 | <benschwarz> | Hixie: burn it :) |
| 08:31 | <benschwarz> | you were right when we first disagreed :D |
| 08:32 | <benschwarz> | Gotta play a little by the rules for the spec, right? |
| 08:32 | <Hixie> | benschwarz: the rules are intended for all documents, not just the spec |
| 08:32 | <Hixie> | benschwarz: it's no more important to follow them for the spec than anything else |
| 08:33 | <Hixie> | their purpose is just to help catch mistakes and steer people away from bad practices |
| 08:51 | <benschwarz> | Hixie: showing best practice in a spec important too |
| 08:52 | <benschwarz> | Hixie: where are you based, anyway? |
| 08:53 | <annevk> | hsivonen, no, but it didn't take that long |
| 08:53 | <annevk> | note that someone else needs to make an account for you these days |
| 08:53 | <annevk> | free registration did not really work well |
| 09:55 | <annevk> | http://blog.whatwg.org/weekly-sniffing-p2p |
| 09:56 | <annevk> | I will make any major changes requested within the next hour -- otherwise I can add them to the pile for next week |
| 09:56 | <annevk> | Grammar fixes are most welcome anytime |
| 10:07 | <annevk> | Hmm, every morning starts with one spam entry on the Wiki |
| 10:07 | <matjas> | I want t-shirt saying “I read the WHATWG Weekly. Weekly.” |
| 10:07 | <annevk> | I wonder when it will go out of control |
| 10:07 | <annevk> | matjas, haha |
| 10:20 | <annevk> | HTML IS HIGH http://www.flickr.com/photos/8624599@N07/5370520043/ |
| 10:20 | <annevk> | want |
| 10:28 | <hsivonen> | I was rather suprised to find that Firefox as already carrying the footprint burden for Content MathML element names as pre-interned strings without actually doing anything with those names |
| 10:31 | <heycam> | ahaha http://www.flickr.com/photos/8624599@N07/5370515439/in/photostream/ that is too awesome, why haven't I seen that before |
| 10:32 | <hsivonen> | heycam: also SVG bitterness: http://www.flickr.com/photos/8624599@N07/5371122488/in/photostream/ |
| 10:32 | <heycam> | heheh |
| 10:46 | <annevk> | Hixie, blog.whatwg.org apparently gets quite a bit of traffic from whatwg.org so it is being seen |
| 11:18 | <asmodai> | Hixie / hsivonen : looks like truncating the coordinates solves a lot of the issues |
| 11:18 | <asmodai> | http://www.reddit.com/r/programming/comments/fc5f4/a_fundamental_bug_in_html5s_canvas/ |
| 11:24 | <pkondzior> | hello, where i can find html5 tests for hml5 event handling ? |
| 11:34 | <jgraham> | pkondzior: I'm not sure there are any tests for event handling in general |
| 11:35 | <pkondzior> | jgraham: well i didn't found any either |
| 11:37 | <pkondzior> | jgraham: is there are any plan for that at least ? |
| 11:37 | <jgraham> | It is planned to test everything |
| 11:38 | <jgraham> | But contributions are needed |
| 11:38 | <pkondzior> | jgraham: is there any project tracking for that ? |
| 11:39 | <pkondzior> | jgraham: todo ? plan description ? |
| 11:39 | <jgraham> | pkondzior: Well, there is a mailing list |
| 11:39 | <jgraham> | public-html-testsuite |
| 11:43 | <jgraham> | pkondzior: Beyond that, we are rather bad at measuring coverage at the moment |
| 11:44 | <pkondzior> | i see that http://test.w3.org/html/tests/ doesn't look very optimistic with compare to whole spec ;) |
| 11:45 | <jgraham> | Yeah, there is some way to go |
| 11:45 | <pkondzior> | i thnik google, opera, microsoft and mozilla have enough resources to resolve this issue |
| 11:45 | <jgraham> | pkondzior: Well, in principle, yes |
| 11:46 | <jgraham> | But making spec tests is not always the main priority |
| 11:46 | <jgraham> | Compared to making tests for browser-specific issues |
| 11:47 | <pkondzior> | hmm but here shouldn't it be main priority ? i mean 1 set of conformance test for HTML5 would give base for all vendors to see how big part of whole specification they really implement |
| 11:48 | <pkondzior> | right now i feel that any news about HTML5 support in XYZ browser without this test is only FUD |
| 11:49 | <jgraham> | Right, it is something that we (Opera) do whenever possible. But assuming that browser makers will fill out the entire testsuite is optimistic |
| 11:50 | <jgraham> | Especially for old stuff that is already implemented |
| 11:50 | <gsnedders> | Also note that there is a cost for releasing tests, especially older ones |
| 11:50 | <pkondzior> | gsnedders: i understand that timing is important here |
| 11:50 | <jgraham> | We are much more likely to be working on new stuff and hence make releasable tests for that stuff |
| 11:51 | <AryehGregor> | Tests should theoretically be a priority, but apparently no one feels it's enough of a priority to really start releasing really large numbers of them. |
| 11:51 | <Philip`> | asmodai: Only for horizontal/vertical lines, where that makes the lines line up with pixel boundaries so there's no antialiasing |
| 11:51 | <gsnedders> | AryehGregor: There's also the fact that most of our existing tests don't use the harness the TF has decided upon, the fact that ten years ago no browser wrote testsuites on the scale they do today |
| 11:52 | <Philip`> | asmodai: (The problem is that antialiasing implementations aren't designed so that the left half of a pixel plus the right half of a pixel is equivalent to drawing the whole pixel) |
| 11:52 | <AryehGregor> | For WebKit and Mozilla, AFAICT none of their tests use the TF's harness. They have to manually port them if they want to use them. |
| 11:53 | <Philip`> | asmodai: (Instead it's like drawing a whole pixel at 50% opacity, and then again at 50%, so the result is 75% opacity (under normal compositing modes) instead of the desired 100%) |
| 11:53 | <AryehGregor> | Also, at least my tests are way too exhaustive to run on every trybot build or whatever. |
| 11:53 | <AryehGregor> | I should probably try to pare them down by a couple orders of magnitude. |
| 11:53 | <Ms2ger> | I'm not sure we should force all tests to use the same harness, tbh |
| 11:53 | <AryehGregor> | (Like my extend() tests take 30 seconds to run on Firefox 4. Just for extend().) |
| 11:54 | <Ms2ger> | As long as we define a callback for the test runner |
| 11:54 | <AryehGregor> | (But the tests are extremely repetitive and could be pared down a lot if performance were needed.) |
| 11:54 | <gsnedders> | AryehGregor: We run testsuites that complete on every build, FWIW |
| 11:54 | <AryehGregor> | Yes, Mozilla and WebKit do something similar. |
| 11:54 | <AryehGregor> | Whereas I'm writing tests more to be comprehensive than to finish quickly. |
| 11:54 | <AryehGregor> | Actually, one of my two Mozilla patches had to be fixed because the test was taking three seconds or something to run for some trivial feature. |
| 11:55 | <AryehGregor> | (it was inputting 65537 bytes into a textarea by synthesized keypresses or something) |
| 11:55 | <Ms2ger> | Which, arguably, isn't really essential to test |
| 11:56 | <AryehGregor> | Certainly not on every build. |
| 11:56 | <AryehGregor> | But AFAIK, there were some browsers that wouldn't correctly handle more than 64k of text in a textarea. |
| 11:57 | <AryehGregor> | So it's reasonable for conformance tests, but not regression tests. |
| 11:57 | <AryehGregor> | The requirements are somewhat different. |
| 11:58 | <AryehGregor> | (but my tests are still gratuitously repetitive, mainly because they're easier to write that way) |
| 12:02 | <jgraham> | AryehGregor: tbh we would probably try to run those tests as regression tests without paring them down. |
| 12:03 | <AryehGregor> | You're saying you'd run tests that take 20 seconds in Opera 11, just to test Selection.extend()? |
| 12:03 | <jgraham> | (although if it happened that we had 30s of tests for every DOM method, that could be a problem) |
| 12:04 | <AryehGregor> | Yeah, you've got to extrapolate it. |
| 12:04 | <jgraham> | (it depends if our test system get faster faster than the tests grow though) |
| 12:04 | <AryehGregor> | (it's more like 20 s in Opera -- Firefox 4 tends to be the slowest at running all the JS tests I write) |
| 12:05 | <jgraham> | Pretty sure we already have tests that take way longer than 20s e.g. some of the javascript library testsuites |
| 12:05 | <gsnedders> | jgraham: Yes, we would. 20s is nothing compared with some of the testsuites we run today. |
| 12:05 | <gsnedders> | AryehGregor, not jgraham. |
| 12:06 | <AryehGregor> | Yeah, I think your test harness is a large part of the problem. My reflection tests run a lot more tests and only take a few seconds. Although it could also partly be that Selection is slower than pure DOM operations for whatever reason. |
| 12:06 | <AryehGregor> | gsnedders, yes, but for one lousy method? There have to be thousands of comparably large features that you'd want to test to a similar extent. |
| 12:06 | <jgraham> | AryehGregor: We don't have thousands of tests on offer for those other methods though |
| 12:07 | <AryehGregor> | Yet. |
| 12:07 | <gsnedders> | We run a large number of jQuery, Dojo, YUI, Prototype, and other testsuites, for multiple versions of the libraries. That takes a lot of time to run. |
| 12:07 | <gsnedders> | AryehGregor: Selection is something where web-compat requires some quite odd things, and there isn't too much of a difference between 10s and 20s. |
| 12:07 | <jgraham> | It seems insane to refuse tests for one method because hypothetically, in the future, we might have a performance problem if we had a similar number of tests for other methods |
| 12:08 | <jgraham> | AryehGregor: If you can pinpoint performance problems in the test harness, that would be useful |
| 12:08 | <AryehGregor> | I could probably get those tests down to ~1s without greatly reducing how much they test. |
| 12:08 | <AryehGregor> | I auto-generated them from three arrays in an O(K*M*N) way. |
| 12:09 | <AryehGregor> | Which is convenient for writing, but a total waste of resources. |
| 12:09 | <gsnedders> | AryehGregor: Equally, FWIW, we have more than doubled the number of tests we run in the past couple of years. |
| 12:09 | <Philip`> | Maybe the test harness should be designed to run in parallel |
| 12:10 | <Philip`> | so you can run one copy per core per machine |
| 12:10 | <Philip`> | and then throw more machines at it when it's too slow |
| 12:10 | <Philip`> | and it would share out the tests to balance the load |
| 12:10 | Philip` | wonders if anybody does that kind of thing already |
| 12:10 | <gsnedders> | Philip`: the regression testing harness? Ours is. |
| 12:10 | <jgraham> | Philip`: parallelising across a single page seems silly |
| 12:11 | <jgraham> | Philip`: you can easilly parallelise at a per-page level |
| 12:11 | <gsnedders> | Philip`: I have the impression MS's is too. |
| 12:11 | <jgraham> | with no changes to the ahrness |
| 12:11 | <jgraham> | *harness |
| 12:11 | Philip` | has only seen Mozilla's, which looks like it runs all the test cases serially |
| 12:11 | <AryehGregor> | Mozilla's parallelizing across builds, though, right? |
| 12:12 | <Philip`> | (though I could be mistaken) |
| 12:12 | <jgraham> | Oh. That seems quite bad |
| 12:12 | <Philip`> | AryehGregor: Yes, but that doesn't help when the tests take too long per build |
| 12:12 | <wilhelm> | We have about 200 machines testing in parallel. They get a small batch of tests each. |
| 12:12 | <AryehGregor> | True. |
| 12:12 | <AryehGregor> | "We" being who, Mozilla? |
| 12:12 | <jgraham> | Parallelising across builds doesn't seem nearly so useful because there will be << builds than tests |
| 12:12 | <AryehGregor> | Or someone else? |
| 12:12 | <wilhelm> | AryehGregor: Opera. |
| 12:12 | <jgraham> | AryehGregor: Opera |
| 12:12 | <AryehGregor> | Ah. |
| 12:13 | <AryehGregor> | That seems like the smart way to do it. |
| 12:13 | <wilhelm> | That, too, has its share of problems. (c: |
| 12:13 | <jgraham> | (I think Mozilla divide up into different test types, but each test type might have to run in serial) |
| 12:14 | <gsnedders> | jgraham: That's what both Moz and WebKit do, IIRC |
| 12:16 | <Ms2ger> | We've got ten groups of test, each running on one machine or vm |
| 12:16 | <Philip`> | http://atlee.ca/blog/2009/11/02/what-happens-when-you-push/ - hmm, looks like mochitests are split into 5 sections that can run in parallel |
| 12:19 | <gsnedders> | http://my.opera.com/core/blog/2009/10/13/automated-testing-of-the-browser-core is the most detailed in-one-place overview of our system |
| 12:19 | <wilhelm> | A bit old, though. |
| 12:19 | <jgraham> | Yeah, the numbers are very wrong |
| 12:20 | <Ms2ger> | http://webkit.org/blog/ had some posts about WebKit's ust now |
| 12:22 | <gsnedders> | (Feel free to ask more, I'm sure someone (i.e., wilhelm, sometimes jgraham) can answer most questions. *vanishes*) |
| 12:37 | <zcorpan> | typedef sequence<File> FileList; - does webidl say that window.FileList should be defined (in ecmascript binding) ? |
| 12:37 | <zcorpan> | heycam: ^ |
| 12:40 | <zcorpan> | i can't find anything about typedefs in the ecmascript binding |
| 12:42 | <zcorpan> | heycam: also, typedef DOMTimeStamp unsigned long long; in section 6.1 seems to have the syntax wrong (should be identifier last) |
| 12:46 | <zcorpan> | webkit and gecko both expose window.FileList, but webkit says it's a function while gecko says it's an object (with typeof) |
| 12:51 | <Ms2ger> | FWIW, we don't support sequence, FileList is just a NodeList-style interface |
| 12:53 | <zcorpan> | i see |
| 13:23 | zcorpan | marks hgroup as 'being considered for removal' |
| 13:32 | <hsivonen> | aargh. Is SVG 1.1 2nd ed. not available as a single-file version? |
| 13:33 | hsivonen | reads the 1st ed. PDF instead |
| 13:34 | <zcorpan> | Ms2ger: seems nobody implements FileList as a sequence<File> |
| 13:35 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/814 should say 'false' if i'm reading webidl correctly (sequence is exposed as an array in ecmascript and [] instanceof FileList is false) |
| 13:35 | <hsivonen> | wow. SVG naming sure is confusing. there's a CSS property, an attribute, an element and and @-rule named color-profile |
| 13:36 | <hsivonen> | but on the case of clip-path, the attribute is called that but the element is clipPath |
| 13:36 | <zcorpan> | "use the color-profile tag!" |
| 13:37 | <hsivonen> | every time I try to read the SVG spec, it's even worse than I expected :-( |
| 13:38 | <Ms2ger> | Sounds like CSS |
| 13:39 | <zcorpan> | is FileList a <sequence> for xhr file upload? |
| 13:39 | <zcorpan> | so you can do send([file1, file2]) and have it work? |
| 13:41 | zcorpan | doesn't see that xhr2 supports that |
| 13:46 | <zcorpan> | hsivonen: btw i heard the fancy tinyarro.ws urls are invalid with idna2008 |
| 13:49 | <karlcow> | http://syntensity.com/static/python.html |
| 13:51 | <hsivonen> | zcorpan: why? |
| 14:29 | <gsnedders> | zcorpan: Does window.FileList implement [[Call]]? |
| 14:32 | <gsnedders> | zcorpan: (per ES5, host objects that implement [[Call]] must return "function"; host objects that don't implement call can return anything except "undefined", "boolean", "number", or "string") |
| 15:22 | <zcorpan> | gsnedders: FileList.prototype.call is undefined |
| 15:22 | <zcorpan> | gsnedders: or should i check it in some other way? |
| 15:23 | <jgraham> | zcorpan: That won't work |
| 15:23 | <jgraham> | [[Call]] is an internal method |
| 15:23 | <jgraham> | I guess one can try calling the object and see what happens |
| 15:24 | <zcorpan> | throws an exception: gecko says error: FileList is not a function on line 2, webkit says Uncaught TypeError: Illegal constructor on line 1 |
| 15:25 | <jgraham> | zcorpan: that is somewhat consistent with the fact that gecko don't consider it a function and webkit do |
| 15:26 | <jgraham> | (did you just call it, or also use "new"?) |
| 15:26 | <zcorpan> | i called it |
| 15:35 | <MikeSmith> | zcorpan: thanks for catching the unclosed-elements-in-list thing |
| 15:36 | <zcorpan> | MikeSmith: np, i'm sure there are more lurking :) |
| 15:36 | <MikeSmith> | yeah |
| 15:37 | <MikeSmith> | the p-element-in-head reporting is a little harder to refine |
| 15:39 | <zcorpan> | shouldn't be very hard though, right? |
| 15:47 | <MikeSmith> | zcorpan: it's all relative :) |
| 15:47 | <MikeSmith> | easy for somebody who actually knows what he's doing, harder for me |
| 15:49 | <zcorpan> | MikeSmith: :) i don't know how to put it down into code, but conceptually my thinking was to keep some state (a token with its location) when body is implied, and adding a check when seeing a <body> tag |
| 15:49 | <MikeSmith> | yeah, definitely doable |
| 15:50 | <MikeSmith> | in this case, the state information needed may actually be available on the existing stack, without needing to save it separately |
| 15:50 | <MikeSmith> | hmm, or maybe not |
| 15:51 | <MikeSmith> | anyway, I will try messing around with it a bit today or tomorrow |
| 15:51 | <zcorpan> | cool |
| 16:32 | <bfrohs> | Is there a specific reason why the capitalization varies for tags/attributes in the spec's html examples? |
| 16:33 | <Ms2ger> | To avoid blessing one capitalization as the preferred one |
| 16:34 | <bfrohs> | Ah, thank ya |
| 16:36 | <MikeSmith> | bfrohs: because, as Redd Foxx once said, A foolish consistency is the hobgoblin of little minds. |
| 16:36 | <MikeSmith> | or maybe it was David Lee Roth that said it |
| 16:36 | <MikeSmith> | anyway, one of those guys |
| 17:28 | <karlcow> | http://infrequently.org/2011/01/cutting-the-interrogation-short/ |
| 17:34 | <jgraham> | karlcow: I have serious difficulty beleiving that a one-time detect of some features is a significant performance problem |
| 17:35 | <jgraham> | I guess some might be hard to detect |
| 17:35 | <TabAtkins> | It is when you're trying to get page-load times < 100ms |
| 17:35 | <TabAtkins> | Which is a serious goal here at Google. We'd like to find ways the entire web can be that fast. ^_^ |
| 17:35 | <jgraham> | Oh, this is one of those "everyone should do this because Google want it" thing |
| 17:36 | <jgraham> | s |
| 17:36 | <TabAtkins> | I detect a note of hostility, which I find confusing. |
| 17:36 | <jgraham> | Ignoring the fact that Google engineers are unusually capable |
| 17:36 | <karlcow> | jgraham: my issue being that most of the problems I have on a daily basis is bad UA sniffing. So I don't see this improving just by magic because we have a two steps scenarios with more opportunities to fail. But maybe it should be tested at least |
| 17:36 | <jgraham> | karlcow: Right, that's something I see a lot too |
| 17:37 | <jgraham> | I mean we see the same things, so it's not surprising :) |
| 17:37 | <TabAtkins> | jgraham: The point is that good advice that can make everyone faster is a good thing. |
| 17:37 | <TabAtkins> | This is, unfortunately, more complex than "just UA sniff" or "just feature-test". But it's faster and more reliable than both. |
| 17:37 | <jgraham> | TabAtkins: I don't see how it can be more reliable |
| 17:38 | <TabAtkins> | It's exactly as reliable as feature-testing. |
| 17:38 | <jgraham> | It is roughly as reliable as the least reliable method |
| 17:38 | <jgraham> | No, it must be less reliable |
| 17:38 | <TabAtkins> | You skip testing for UAs that you know the capabilities of, but test everyone else. |
| 17:38 | <jgraham> | How do you know which UA the user is using? |
| 17:39 | <TabAtkins> | By accurate sniffing of the UA string (which is, admittedly, the weak point). |
| 17:39 | <jgraham> | UA-string sniffing has a long history of failure |
| 17:39 | <jgraham> | even ignoring edge cases like people who fake UA strings |
| 17:39 | <TabAtkins> | Note, though, that browser vendors have been advertising "Here's how you should be sniffing our new version" lately. |
| 17:40 | <jgraham> | Pointers? |
| 17:40 | <TabAtkins> | Sure, let me dig them up. I know Chrome and Opera have said something in that area. |
| 17:41 | <jgraham> | Also, I can imagine this failing if someone doesn't correctly sniff the difference between the mobile and desktop versions of a browser which could have quite different features |
| 17:41 | <jgraham> | even with the same version numbers and so on |
| 17:41 | <TabAtkins> | Argh, it's hard to find these articles on the web. I'll keep looking. |
| 17:41 | <miketaylr> | (which happens all the time in the wild) |
| 17:42 | <TabAtkins> | jgraham: That's theoretically fixable, at least. I've come to support putting a hash in the UA string. |
| 17:43 | <jgraham> | TabAtkins: My general feeling is that it is something that Google might get right (but might get wrong) but that on average people would probably get wrong |
| 17:43 | <Philip`> | TabAtkins: If only someone had written a web site to help you find things on the web |
| 17:43 | <TabAtkins> | Philip`: THE GOOGLES, THEY DO NOTHING |
| 17:55 | <karlcow> | http://www.brucelawson.co.uk/2011/living-standard/ |
| 17:59 | <jgraham> | karlcow: You should prefix links like that with "Warning: Cliff" |
| 18:04 | <Ms2ger> | annevk, your link about Lars's hgroup experiment points to Lachy's comment in whatwg weekly |
| 18:08 | <annevk> | wow fail |
| 18:11 | <annevk> | more fail that you are the first to notice |
| 18:12 | <annevk> | oh, I thought it was a worse fail |
| 18:12 | <annevk> | a comment of Lachy in a blog post rather than in the same bug report |
| 18:13 | <Ms2ger> | Oh, no, just off by one |
| 18:13 | <Ms2ger> | (I guess nobody cares about hgroup) |
| 18:13 | <annevk> | the Japanese do |
| 18:13 | <annevk> | per twitter anyway |
| 18:15 | <annevk> | haha, bruce is great |
| 18:40 | <AryehGregor> | Can anyone explain to me why this outputs the empty string to the log in Firefox? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/815 |
| 18:40 | <AryehGregor> | Oh, wait, this one does in WebKit too. |
| 18:41 | <AryehGregor> | Oh, it has a bug. |
| 18:41 | <AryehGregor> | I meant this: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/816 |
| 18:42 | <AryehGregor> | Hmm, Firefox isn't selecting anything here either . . . |
| 18:43 | <AryehGregor> | (visually) |
| 18:45 | <AryehGregor> | But if I go to the rendered view as a data URL, it does look visually selected, but still the selection stringifies to nothing . . . ? |
| 18:45 | AryehGregor | decides to work on innerText first |
| 18:50 | Ms2ger | was hoping that would just die |
| 18:52 | <TabAtkins> | D'oh, /wc doesn't work on browser windows. |
| 18:53 | <AryehGregor> | Ms2ger, WebKit doesn't want it to, so Ian says I should spec it. It's more useful than textContent, certainly, it's just too bad it's so crazily complicated. |
| 18:54 | <Ms2ger> | Still, I want it to die |
| 18:59 | <AryehGregor> | Too bad. :P |
| 18:59 | <Ms2ger> | :( |
| 19:00 | <annevk> | fixed the error in the post btw |
| 19:00 | <Ms2ger> | Thanks |
| 19:00 | <annevk> | also pretty great that steve is doing all the additions in the comments |
| 19:01 | <annevk> | unless I'd put significantly more time in it it's really quite hard to cover so much |
| 19:01 | <Dashiva> | karlcow: Re: the infrequently.org thing, was that guy asleep when Opera 10 was released? |
| 19:02 | <TabAtkins> | Dashiva: The proposal is gated on people doing version detection properly. |
| 19:02 | <Ms2ger> | Ha. Ha. Ha. |
| 19:02 | <Dashiva> | TabAtkins: It's also gated on the assumption that version detection algorithms never change |
| 19:03 | <annevk> | AryehGregor, innerText and Selection.toString() probably share some underlying algorithm |
| 19:03 | <AryehGregor> | annevk, I'd hope so. |
| 19:03 | <AryehGregor> | If not, maybe we could make it do that. |
| 19:03 | <annevk> | I wonder how much of copy & paste should be defined in terms of Selection |
| 19:04 | <annevk> | I guess that would only cover copying from browsing contexts when there are no plugins involved, but that is still significant |
| 19:13 | <AryehGregor> | Hixie, could you please serve X-XSS-Protection: 0 from the Live DOM Viewer? Otherwise it's unusable in recent IE. |
| 19:13 | <AryehGregor> | (Ref: http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-header.aspx) |
| 19:14 | <AryehGregor> | Oh, wow, Opera's innerText is useless. |
| 19:14 | <AryehGregor> | So I'm just looking at WebKit and IE, then. |
| 19:20 | <AryehGregor> | Okay, IE9 works totally differently from IE8 and WebKit . . . |
| 19:24 | <AryehGregor> | In IE9, it seems to work mostly like textContent except with different whitespace handling -- in particular, it shows display: none stuff. |
| 19:25 | <AryehGregor> | IE8 also handles whitespace totally differently from WebKit. |
| 19:26 | <AryehGregor> | Hixie, do you want me to just make something up or what? There's almost no common ground here. |
| 19:27 | <AryehGregor> | WebKit is insane too. <p> adds two extra newlines, except if the margin is 7px it doesn't but if it's 8px it does, and <div> doesn't add two extra newlines no matter what its margins are . . . |
| 19:28 | <AryehGregor> | Although it's a pretty good plaintext approximation to what it looks like. |
| 19:29 | <AryehGregor> | WebKit seems to use the same algorithm for Selection's stringifier. |
| 19:29 | <Ms2ger> | Fun, isn't it? :) |
| 19:30 | <AryehGregor> | Ms2ger, do you know why this logs nothing? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/816 |
| 19:30 | <AryehGregor> | It makes it hard to test Selection stringification in Firefox. |
| 19:30 | <Hixie> | AryehGregor: in the absence of interop, yeah, just spec the sanest behaviour |
| 19:33 | <Ms2ger> | What I know is that it works if you put w(selection.focusNode) right after selection.collapse(el, 0); |
| 19:33 | <Ms2ger> | Yay Heisenberg |
| 19:34 | <AryehGregor> | . . . |
| 19:34 | <AryehGregor> | Okay, well, that works for now, anyway. |
| 19:35 | <AryehGregor> | Thanks for the tip. |
| 19:35 | <AryehGregor> | Okay, here's some commonality: selection stringification in Gecko and WebKit seem to at least vaguely resemble each other. |
| 19:37 | <AryehGregor> | But Firefox appears to ignore most CSS, while most of WebKit's behavior seems determined by CSS. |
| 19:37 | <AryehGregor> | (for Selection stringification) |
| 19:52 | <heycam> | hsivonen, there is a single page version of SVG 1.1 2ed: http://dev.w3.org/SVG/profiles/1.1F2/publish/single-page.html |
| 19:53 | <heycam> | hsivonen, it's linked to just below the list of editors on the front page |
| 19:54 | <heycam> | hsivonen, also please do read the second edition spec, it's somewhat better than the first... |
| 19:56 | <Ms2ger> | One would hope so |
| 20:38 | <jgraham> | AryehGregor: DOM methods that depend on CSS are evil |
| 20:38 | <Ms2ger> | Unless Anne defines them |
| 20:41 | <jgraham> | Well ones that are specifically for CSS are basically OK |
| 20:41 | <jgraham> | but adding unnecessary dependencies between DOM and layout seems bad |
| 20:42 | <AryehGregor> | jgraham, it depends on CSS either way, the question is only the extent. |
| 20:42 | <AryehGregor> | E.g., innerText of a display:none element is "" in everyone, I'm pretty sure. |
| 20:42 | <Ms2ger> | Well, innerText is evil |
| 20:43 | <AryehGregor> | That too. |
| 20:44 | jgraham | doesn't think that innerText works like that in Opera |
| 20:44 | <jgraham> | and Gecko don't implement it |
| 20:44 | <jgraham> | so it is only WebKit and IE |
| 20:44 | <AryehGregor> | Actually, not quite. |
| 20:45 | <AryehGregor> | Opera's implementation is different, yeah. |
| 20:45 | <AryehGregor> | But it's not very interesting either. You may as well use textContent then. |
| 20:47 | <jgraham> | well yeah |
| 20:47 | <jgraham> | Ideally innerText would die |
| 20:48 | <bfrohs> | Well, when something isn't dying of natural causes, there is always another option ;) |
| 20:49 | <Ms2ger> | Apple insists on keeping it in its vegetative state, I'm afraid |
| 21:08 | <TabAtkins> | annevk: You around? Got a question about using CORS to unblock a resource when you can't tell that the resource is SOR-protected before making the request. |
| 21:08 | <TabAtkins> | I guess the question is: how? |
| 21:43 | <AryehGregor> | Beginning of a spec: http://aryeh.name/spec/innertext/innertext.html |
| 21:44 | <AryehGregor> | Proof-of-concept (note that in WebKit the two boxes display almost the same): http://aryeh.name/spec/innertext/test/innerText.html |
| 21:44 | <TabAtkins> | Oh man, smallcaps looks horrible on camelcase. |
| 21:44 | <AryehGregor> | Yes, it does. |
| 21:44 | AryehGregor | will adapt the test to fall back to Selection stringification in Firefox, since that logically does roughly the same thing |
| 21:49 | <TabAtkins> | Hixie: Where are the templates for the specs again? I apparently didn't bookmark them last time, and I'm being requested to generate new versions of some specs. |
| 22:08 | <Hixie> | TabAtkins: templates? |
| 22:08 | <Hixie> | TabAtkins: oh, the header boilerplate? |
| 22:08 | <TabAtkins> | Hixie: Yeah. |
| 22:08 | <Hixie> | TabAtkins: http://dev.w3.org/html5/boilerplate/ then tell me to regen |
| 22:08 | <TabAtkins> | kk |
| 22:50 | <matjas> | Should implicit form submission work in this case? <form><input><input><input></form> |
| 22:50 | <TabAtkins> | Why wouldn't it? |
| 22:50 | <matjas> | Reading the spec, I’d say yes, but it doesn’t work in Opera or WebKit |
| 22:50 | <matjas> | And WebKit even has a layout test for this exact situation |
| 22:51 | <matjas> | I guess the layout test is flawed then? |
| 22:51 | <TabAtkins> | Not sure, as I haven't read that section of the spec in a long time. |
| 22:51 | <TabAtkins> | But if the spec says otherwise, then yeah. |
| 22:51 | <matjas> | http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#implicit-submission |
| 22:52 | <TabAtkins> | Yeah, I don't see anything that would restrict it. |
| 22:52 | <TabAtkins> | Though, wait... |
| 22:53 | <matjas> | Doesn’t work in Firefox either |
| 22:53 | <matjas> | Presumably not in IE either since the WebKit layout tests would mention it otherwise |
| 22:53 | <matjas> | Am I missing something? |
| 22:54 | <TabAtkins> | I'm wondering if the fact that it contains no data is stopping it. |
| 22:54 | <matjas> | That shouldn't matter; also it doesn't seem to influence the other relevant layout tests |
| 22:54 | <matjas> | ping Hixie ^ |
| 22:54 | <Hixie> | hey |
| 22:54 | <Hixie> | sup |
| 22:55 | <matjas> | Should implicit form submission work in this case? <form><input><input><input></form> |
| 22:55 | <matjas> | I don’t see anything in the spec that would restrict it |
| 22:55 | Hixie | looks at the spec |
| 22:55 | <matjas> | But browsers seem to restrict it anyways for some reason |
| 22:55 | webr3 | waves good bye to ipv4 http://inetcore.com/project/ipv4ec/index_en.html |
| 22:55 | <matjas> | (Only if there are multiple inputs) |
| 22:55 | <Hixie> | sure, why would it not? |
| 22:55 | <Hixie> | spec seems unambiguous here |
| 22:56 | <Hixie> | what's unclear? |
| 22:56 | <jamesr__> | WebKit layout tests are sometimes more to document behavior so we can know if we accidentally change it. they don't always reflect the behavior we wish WebKit had |
| 22:56 | <matjas> | jamesr__ I believe in this case it's just to mimic IE and Fx’s behavior |
| 22:58 | <jamesr__> | ok. now prove that following the spec will not break websites and we can all change behavior to match it :) |
| 22:59 | <jamesr__> | (that suggestion is half tongue in cheek, i know it's not generally possible to determine if a change will break the web) |
| 23:00 | <dglazkov> | matjas: as the author of the test, I'll tell you that this is simulating IE behavior |
| 23:00 | <dglazkov> | matjas: and most of the browsers' behavior |
| 23:00 | <dglazkov> | matjas: and that I bugged Hixie about adding this to spec, but he said meh. |
| 23:01 | <matjas> | dglazkov: so what exactly is making the difference here? The fact that there are multiple inputs? |
| 23:01 | <dglazkov> | matjas: yup |
| 23:01 | <matjas> | dglazkov: Multiple *text* inputs? |
| 23:02 | <dglazkov> | matjas: yup |
| 23:02 | <matjas> | Browsers are weird. |
| 23:02 | <matjas> | Thanks for clarifying dglazkov! |
| 23:02 | <dglazkov> | matjas: browsers suck |
| 23:03 | <dglazkov> | matjas: http://google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/html/HTMLFormElement.cpp&l=193 |
| 23:03 | <dglazkov> | matjas: this is the line that regulates the behavior. If you only have _1_ text input. |
| 23:03 | <paul_irish> | TabAtkins: https://github.com/LearnBoost/stylus/blob/master/docs/compare.md |
| 23:04 | <dglazkov> | matjas: but the fact that browsers suck is not a secret |
| 23:04 | <matjas> | dglazkov: Yeah, that’s the code I’ve been looking at the past few days :) Was just wondering *why* it was like that, as it’s not documented as far as I can see. |
| 23:05 | <dglazkov> | the secret is that interwebs suck. They write code for buggy old browsers and then all new browsers have to adjust their behavior to support their stupid buggy code. |
| 23:05 | <dglazkov> | matjas: use svn blame :) |
| 23:05 | <dglazkov> | matjas: or git blame |
| 23:05 | <dglazkov> | stupid interwebs. |
| 23:06 | <TabAtkins> | paul_irish: Already out of date, unfortunately, since they apparently based it off of my slide deck. |
| 23:06 | <matjas> | interwebs-- |
| 23:06 | <dglazkov> | that's why you always have to bet on a smaller, more refined, closed platform that has simpler and more elegant APIs and rabid fan base. |
| 23:07 | <dglazkov> | like Amiga. |
| 23:22 | <bga_> | why label:checked doesnt possible? it will be very usefull |
| 23:22 | <AryehGregor> | What? |
| 23:22 | <Hixie> | labels don't get checked? |
| 23:22 | <bga_> | label will share state of input |
| 23:23 | <Hixie> | better to just add :matches() support |
| 23:23 | <TabAtkins> | And/or support for following idrefs. |
| 23:23 | <Hixie> | label:matches(#>:checked) |
| 23:23 | <Hixie> | label /for/ :checked |
| 23:23 | <Hixie> | ah, man, i suggested all these things about 10 years ago now |
| 23:23 | <TabAtkins> | Yup. |
| 23:23 | <bga_> | yeah. it will be good |
| 23:27 | <annevk> | agreed that what RobS added is spam? http://wiki.whatwg.org/wiki/Special:RecentChanges |
| 23:28 | <Hixie> | not entirely spam |
| 23:28 | <Hixie> | i had a look |
| 23:28 | <Hixie> | the site is a bit, um, reminiscent of my style sense |
| 23:28 | <Hixie> | might make sense to separate the list into those really good ones and "others"... |
| 23:29 | <Hixie> | the content seems on par with w3schools.com |
| 23:30 | <TabAtkins> | Which means "spam". |
| 23:30 | <annevk> | I guess you are right |
| 23:30 | <annevk> | there does not seem to be advertising |
| 23:30 | <annevk> | just feels a bit dodgy |
| 23:31 | <annevk> | and the about and contact pages are 404 |
| 23:33 | Hixie | is thinking maybe the right solution to the rel registry problem is just to have a living standard for rel values |
| 23:34 | webr3 | wonders why, if the html spec is already a living standard, and the rels are described in it, it already is a living standard |
| 23:34 | <Hixie> | most of the rels are in the wiki at the moment |
| 23:35 | <annevk> | not all rels are described by it at the moment |
| 23:35 | <annevk> | my idea is the same for legacy encodings |
| 23:35 | <annevk> | except that I want it to die |
| 23:35 | <webr3> | .. so add them to the standard and describe them..? they're either valid for use or not |
| 23:35 | <annevk> | that is, remain stable indefinitely |
| 23:38 | <annevk> | Hixie, "an value" |
| 23:38 | <Hixie> | crap |
| 23:38 | <Hixie> | thanks |
| 23:42 | <hober> | hmm. a couple recent edits on the wiki link to (identically-horrible looking) websites like "namespaces.com" and "html-5.com" that look spammy |
| 23:43 | <annevk> | see above |
| 23:45 | <hober> | farther above than in my irc client backlog, I guess. /me goes to the logs |
| 23:46 | <annevk> | see the bit starting seventeen minutes ago |
| 23:46 | <TabAtkins> | It should be *just* above what you said, hober. |
| 23:48 | <hober> | ahh, thanks. yes, there you go. |
| 23:52 | <hober> | I think it's dodgier than w3schools |
| 23:53 | <hober> | w3schools at least has the decency to stick to one domain name, instead of serving up crappy content on N of them |
| 23:54 | <annevk> | the content does seem unique |
| 23:57 | <annevk> | and http://www.accilent.com/ says Mr Simpson which matches RobS |
| 23:57 | <annevk> | and matches the style more or less |
| 23:57 | <TabAtkins> | The overflowing heading matches, definitely. |