| 00:00 | <smaug___> | annevk: it isn't relevant |
| 00:00 | <smaug___> | if I use xhtml that all just works |
| 00:00 | <smaug___> | in that example using <hX> was simpler |
| 00:00 | <annevk> | well sure |
| 00:00 | <annevk> | but XHTML does not work in IE |
| 00:01 | <annevk> | so that would be a problem |
| 00:01 | <annevk> | if we want to test IE |
| 00:01 | <smaug___> | using divs would have required id attributes or something |
| 00:01 | <smaug___> | that wasn't a testcase |
| 00:01 | <smaug___> | but just an example |
| 00:01 | <smaug___> | even trivial one |
| 00:01 | <annevk> | anyways, it seems like someone needs to define hit testing |
| 00:01 | <smaug___> | maybe |
| 00:02 | <smaug___> | though, if IE really behaves like that with mouseenter/leave |
| 00:02 | <smaug___> | I think those should be just dropped |
| 00:02 | <smaug___> | those aren't that useful |
| 00:02 | <annevk> | are you sure? |
| 00:02 | <smaug___> | well, you can emulate them using scripts |
| 00:02 | <annevk> | lots of developers want those events |
| 00:02 | <smaug___> | and mouseover/out |
| 00:03 | <Dashiva> | I would wager that a majority of all uses of mouseover/out really wants mouseenter/leave |
| 00:04 | <annevk> | e.g. a simple search gives http://blog.stchur.com/2007/03/15/mouseenter-and-mouseleave-events-for-firefox-and-other-non-ie-browsers/ |
| 00:24 | <annevk> | http://foolip.org/microdatajs/live/ neat |
| 00:24 | annevk | -> past bedtime |
| 00:24 | <annevk> | nn |
| 01:16 | <Hixie> | foolip, your microdata tool is awesome |
| 01:16 | <Hixie> | i've added it to my list of consoles on http://damowmow.com/portal/ (top right) |
| 01:16 | <Lachy> | Hixie, new version of Requiem is out. It aparently fixes the 4GiB file size limit. |
| 01:16 | <Hixie> | nice |
| 01:16 | <Hixie> | (there was a 4GB file size limit?) |
| 01:17 | <Lachy> | it's taking me a while to download it from Tor - it's a really slow connection today - and I couldn't find it on any torrent sites yet. |
| 01:18 | <Hixie> | ah |
| 01:19 | <Lachy> | there was a limit, but since only a few of the HD movies available from iTunes are over 4GB, it probably hasn't affected you |
| 01:20 | <Lachy> | it hasn't affected me either, since being outside the US, there is no HD content available |
| 01:21 | <Hixie> | heh |
| 01:22 | <Hixie> | how weird |
| 01:22 | <Lachy> | and the Australian iTunes store (which my account is for) is unlikely to bother with HD content while our internet continues to be over priced and capped with extremely low usage caps |
| 01:22 | <Hixie> | don't they have an itunes datacenter? |
| 01:24 | <Lachy> | yes, they do. But our ISPs count your data usage, and downloading 2GB HD TV shows frequently will send most users over their 10GB to 20GB monthly limit quite quickly. (Plans with more than that are way over priced) |
| 01:25 | <Lachy> | and so unless Apple does some deals with Australian ISPs to make iTunes content be unmetered, the market for HD content will be very small |
| 01:26 | <Hixie> | so basically unless you lose your net neutrality, you're screwed? |
| 01:26 | <Hixie> | what is it with english-speaking countries and being stupid |
| 01:28 | <Lachy> | yeah, basically. Although, to some extent, some Aussie ISPs have gone against net neutrality, and have in the past, included some major download sites (like tucows and cnet downloads) as part of the unmetered freezone. |
| 01:29 | <Lachy> | Telstra includes its own BigPond network in their free zone too |
| 01:30 | <AryehGregor> | Hixie, maybe non-English-speaking countries are also stupid, but you don't notice it as much because it's in a foreign language? |
| 01:30 | <Lachy> | I've heard claims that the reason for the over priced, capped internet is because the cost of sending data across the Pacific ocean is expensive. |
| 01:30 | <AryehGregor> | Bandwidth caps make more sense than "unlimited" plans where you get threatening calls from your ISP if you use too much bandwidth . . . |
| 01:30 | <Hixie> | i speak french and lived in swizterland, and also lived in norway, and i haven't seen the same kinds of stupidity as in the UK, US, and Australia. |
| 01:31 | <Hixie> | but i'm sure each country has its own stupidity, certainly :-) |
| 01:31 | <Lachy> | Hixie, there are plenty of non-English speaking countries that are stupid. LIke China, Iran (I think), and some other middle eastern countries. |
| 01:31 | <AryehGregor> | Unlimited plans don't make much market sense, they encourage tragedies of the commons like BitTorrent. |
| 01:32 | <Lachy> | AryehGregor, what do you mean by tragedies of the commons? |
| 01:32 | <AryehGregor> | Lachy, I mean that if it's unlimited, you won't care how much you use, so you'll be much more likely to use an unreasonably large amount, which in aggregate degrades service for everyone. |
| 01:32 | <AryehGregor> | But every individual bears too little of the cost to care. |
| 01:32 | <AryehGregor> | http://en.wikipedia.org/wiki/Tragedy_of_the_commons |
| 01:34 | <Lachy> | I strongly disagree. Bandwidth caps place an unfair burdon on end users, and place wholly artificial limits on what people can and can't do. |
| 01:35 | <AryehGregor> | How is it wholly artificial or unfair to pay for the resources you use? Most resources you use are metered, like electricity. |
| 01:35 | <AryehGregor> | But yeah, it's a pain, so people don't like it and ISPs try to avoid it. |
| 01:36 | <AryehGregor> | Which creates tragedies of the commons, but oh well. |
| 01:38 | <GarethAdams|Home> | AryehGregor: different argument. Your electricity is metered, but it's probably unlimited |
| 01:38 | <AryehGregor> | Ah, someone upgraded the wiki to 1.15.1. |
| 01:39 | <GarethAdams|Home> | (unlimited within capacity provision) |
| 01:39 | <AryehGregor> | GarethAdams|Home, well, yes. Caps are just a coarser form of metering, though, where you have to pay in advance to upgrade to the next plan. |
| 01:39 | <AryehGregor> | Lachy, should I upgrade the wiki to the latest alphas from SVN so that it's outputting HTML5 instead of XHTML1 Transitional? :) |
| 01:40 | <GarethAdams|Home> | Personally I think pre-pay vs credit is quite a fundamental difference |
| 01:40 | <Lachy> | AryehGregor, bandwidth is not a limited resource in the same sense as physical resources, and bandwidth caps attempt to solve the issue the wrong way. |
| 01:40 | <AryehGregor> | Lachy, it's limited every bit as much as things like electricity or water. How would you solve it? |
| 01:41 | <AryehGregor> | Well, it's too late for me to get into an argument, but I could set up MediaWiki 1.16alpha tonight, or not. |
| 01:41 | <AryehGregor> | You gave me shell access, but I don't want to do it without at least one other person thinking it's a reasonable idea. :) |
| 01:41 | <Lachy> | Bandwidth is, for the sake of simplicity, effectively a measure of how much data can be transmitted at the same time. So offering plans based on the bandwidth, or rather speed, provided to the user makes sense. |
| 01:42 | <AryehGregor> | Whee, still using MySQL 4.1. At least one user is benefiting for our support for ancient MySQL versions! |
| 01:44 | <Lachy> | But imposing monthly usage limits tries to treat data as a finite resource, and implies that it will somehow run out if too much is used in a month. |
| 01:45 | <AryehGregor> | Well, what they really care about is how much you're using at peak. If there's excess capacity, it makes no difference to them, no. So it's a crude metric, that's true. |
| 01:45 | <AryehGregor> | That's not quite true, actually. |
| 01:45 | <AryehGregor> | They do pay for every bit that goes over a backbone, AFAIK. |
| 01:45 | <Lachy> | but that's not the case at all. If a backbone can support 1Gbps, and 50 users are connected to that, each going flat out on their ADSL2+, 20Mbps connection, they could do that all indefinitely. |
| 01:45 | <AryehGregor> | But anyway, are you going to answer me about upgrading the WHATWG wiki? |
| 01:46 | <AryehGregor> | Yes, but they oversell, because people don't use all their bandwidth at once. |
| 01:46 | <Lachy> | Although, with bandwidth caps, they would hit their artificial limit within a day |
| 01:46 | <Lachy> | right. But bandwidth caps do nothing to address that problem of over selling |
| 01:47 | <AryehGregor> | Overselling isn't a problem, it's the only thing that makes sense. It would be crazy to let massive bandwidth capacity lie idle because you have to reserve a fixed amount for each customer. |
| 01:48 | AryehGregor | wonders why Lachy keeps on ignoring the questions about the wiki. |
| 01:48 | <Lachy> | oh, I missed the wiki question. |
| 01:48 | <AryehGregor> | I only asked it about eight times. |
| 01:50 | <Lachy> | sure, do whatever you like with the wiki (as long as you don't break it). |
| 01:50 | <Lachy> | or if you do break it, fix it |
| 01:50 | <AryehGregor> | There are no hacks, are there? |
| 01:50 | <AryehGregor> | So I can overwrite the files and there will be no problems? |
| 01:50 | <Lachy> | no |
| 01:50 | <AryehGregor> | k. |
| 01:50 | <Lachy> | there are plugins, I believe |
| 01:51 | <Lachy> | can't remember which ones we have installed though |
| 01:51 | <AryehGregor> | ConfirmEdit, no problem. |
| 01:57 | <Lachy> | AryehGregor, have you ever lived with an internet connection that was capped? |
| 01:58 | <AryehGregor> | No. Is that relevant? |
| 01:59 | <Lachy> | I was just wondering, since if you had, you might actually understand the detrimental effects that caps can have on many things, including work. I can tell you for a fact that it's no fun trying to do web development when your connection has been shaped to 64kbps for going over your monthly bandwidth limit |
| 02:00 | <AryehGregor> | Did I ever say caps were fun? I'm pretty sure I explicitly said customers don't like them. |
| 02:00 | <AryehGregor> | (although, I was talking more about metering than caps) |
| 02:00 | <Lachy> | metering implies caps |
| 02:01 | <AryehGregor> | No it doesn't. My server's connection is metered but uncapped. |
| 02:01 | <Lachy> | unless you're talking about plans that charge per MB, and can get quite expensive really quickly |
| 02:01 | <jcranmer> | I've legitimately done about 1GiB/day |
| 02:01 | <jcranmer> | granted, scp'ing 100MiB files to a server is going to do that rather quickly |
| 02:02 | <AryehGregor> | Sure, and it would be fair if you were charged more than someone who just checks their e-mail. |
| 02:03 | <Lachy> | if someone just wants to check their e-mail, give them a low bandwidth, but uncapped, plan. I don't mind paying extra for the extra bandwidth. But I expect to be able to make use of it, which caps don't let me do |
| 02:04 | <AryehGregor> | Updating wiki, will be down for a few minutes. |
| 02:04 | <AryehGregor> | Back up. |
| 02:05 | <AryehGregor> | Try viewing source. :) |
| 02:06 | <AryehGregor> | Anyone who finds a problem should report it to me and I'll fix it. Meanwhile, I'm going to sleep. |
| 02:06 | <Lachy> | <!doctype html> |
| 02:06 | <Lachy> | <html lang="en" dir="ltr" version="HTML+RDFa 1.0" > |
| 02:06 | <Lachy> | wtf? |
| 02:06 | <AryehGregor> | Oh, right. |
| 02:06 | <Lachy> | lose the version crap |
| 02:06 | <AryehGregor> | Let me disable the RDFa. :P |
| 02:06 | <Lachy> | how did RDFa shit get into mediawiki? |
| 02:06 | <AryehGregor> | Try now. |
| 02:07 | <AryehGregor> | Someone committed it. |
| 02:07 | <AryehGregor> | Then I said we should also allow microdata, and then I said we should allow only microdata, and a lengthy debate ensued on the mailing list. |
| 02:07 | <AryehGregor> | (wikitech-l, I mean) |
| 02:07 | <AryehGregor> | I think the likely outcome is that both get disabled by default. |
| 02:07 | <Lachy> | you should get the RDFa removed. It's non-conforming HTML5 |
| 02:08 | <AryehGregor> | It's conforming HTML5+RDFa! |
| 02:08 | <AryehGregor> | Anyway, conformance matters less than usefulness. |
| 02:08 | <AryehGregor> | The HTML5 mode means a whole truckload of non-conforming content, since we don't blacklist things like cellpadding and what have you. |
| 02:08 | <Lachy> | that's true. But HTML+RDFa is a completely useless spec |
| 02:09 | <AryehGregor> | But it also means more features, so to heck with validators. |
| 02:09 | <AryehGregor> | Well, you don't have to convince me of that. |
| 02:09 | AryehGregor | points out type=search in the search bar, some type=number in preferences, autofocus in lots of places, . . . |
| 02:10 | <AryehGregor> | All of which I wrote. :P |
| 02:11 | <AryehGregor> | And of course, speaking of bandwidth, look at all those saved bytes! |
| 02:11 | <AryehGregor> | Okay, now's about time to go to bed. |
| 02:34 | Philip` | wonders if Lachy would be happier with an unmetered uncapped 256Kbps connection that he could use all day every day, or with a 20Mbps one that's capped at 100GB/month for the same cost |
| 02:39 | Hixie | looks at Jingle and SIP to see if either would be usable with <device> and comes out disturbed at how complicated people make their protocols |
| 06:25 | <NickYoung> | ping: Hixie |
| 06:27 | <Hixie> | hey |
| 06:32 | <NickYoung> | hey Hixie - do you know, or know someone who knows, or know somewhere I can find out information about youtube.com/html5 ? |
| 06:33 | <Hixie> | what information? |
| 06:33 | <NickYoung> | HTTP requisites |
| 06:33 | <Hixie> | not sure what you mean |
| 06:33 | <NickYoung> | I'm getting 403 on my experimental build of webkit |
| 06:33 | <Hixie> | odd |
| 06:33 | <NickYoung> | so presumably there are requisite headers |
| 06:33 | <Hixie> | 403 for the video file? |
| 06:33 | <NickYoung> | yes |
| 06:34 | <Hixie> | and it works for regular webkit? |
| 06:34 | <Hixie> | how weird |
| 06:34 | <Hixie> | have you dumped the two network traffic sessions and compared them? |
| 06:34 | <Hixie> | i don't see why there'd be anything like that |
| 06:34 | <NickYoung> | this is a different multimedia backend |
| 06:35 | <Hixie> | i'd recommend cracking out tcpdump and comparing them |
| 06:35 | <NickYoung> | hmm, ok |
| 06:36 | <NickYoung> | my thought is it's probably either a cookie it wants, or a missing refferer header |
| 06:36 | <NickYoung> | my backend passes on neither at the moment |
| 06:37 | <NickYoung> | anyway, I just thought you might have seen some documents floating around I could consult :) |
| 06:38 | <Hixie> | oh you almost certainly need the opt-in cookie |
| 06:42 | <NickYoung> | yeah, unfortunately the webkit interface for media is somewhat broken in this respect. The backend is only passed a URL to the media file. |
| 06:44 | <Hixie> | seriously, i'd recommend using tcpdump to see what the working UA is sending |
| 06:44 | <Hixie> | it could be something obvious |
| 06:44 | <othermaciej> | NickYoung: we do want to eventually fix the networking to go through WebKit's http stick - just tricky to beat both WebKit and relevant media engines into shape |
| 06:44 | <othermaciej> | NickYoung: I think Referer or Cookie is a likely candidate |
| 06:45 | <othermaciej> | NickYoung: if you find the differences, one easy way to see which is making the difference could be to use curl or wget with custom headers |
| 06:47 | <NickYoung> | unfortunately I'm on linux atm, and HTML5 media support is in chrome (but not chromium) afaik |
| 06:47 | <NickYoung> | which leaves me with nothing to compare against |
| 06:48 | <NickYoung> | but a massive wget hack could work :P |
| 06:59 | <othermaciej> | there's no official Chrome for Linux yet? |
| 06:59 | <othermaciej> | wait, WebKit/Gtk has video support - does that not work? |
| 06:59 | <othermaciej> | (or is that what you are working on now?) |
| 07:00 | <NickYoung> | I'm working on WebKit/Qt |
| 07:00 | <othermaciej> | you could check if WebKit/Gtk can handle YouTube, that might be the easiest point of reference (though of course you'd need a GStreamer module that does H.264...) |
| 07:01 | <NickYoung> | yeah.. I have that |
| 07:01 | <NickYoung> | I'll investigate :) |
| 07:03 | <NickYoung> | also, it looks like there is an official chrome for linux now |
| 07:20 | <NickYoung> | dear lord, the GTK version explicitly spoofs its user agent for movies.apple.com |
| 08:09 | <othermaciej> | NickYoung: if you find that UA spoofing is indeed required for movies.apple.com, could you please send me the info so I can file a bug on them? mjs⊙ac |
| 08:47 | <hsivonen> | othermaciej: does aria-hidden actually work in Firefox for the use case you mentioned on the list? |
| 08:47 | <othermaciej> | hsivonen: does aria-hidden in Firefox cause content to be hidden from visual rendering? |
| 08:48 | <hsivonen> | othermaciej: no, AFAIK |
| 08:48 | <othermaciej> | hsivonen: I assume not, because that would violate the ARIA spec |
| 08:48 | <othermaciej> | so I assume it does work in Firefox |
| 08:48 | <hsivonen> | othermaciej: but at least at some point, it didn't really prune anything from the accessible tree, either |
| 08:48 | <othermaciej> | hsivonen: that would presumably be a bug in their ARIA support... |
| 08:48 | <hsivonen> | othermaciej: it depended on the author specifying *[aria-hidden="true"] { display: none; } |
| 08:49 | <othermaciej> | hsivonen: I'm certainly not telling authors to include that, since it subverts the intent of the ARIA spec (as far as I can tell) |
| 08:49 | <hsivonen> | othermaciej: I guess "the intent of the ARIA spec" is tricky thing |
| 08:50 | <othermaciej> | my reading is that role="presentation" is supposed to skip an element (but still include its children) in the accessibility tree, and aria-hidden is supposed to hide the element *and* its children in the accessibility tree |
| 08:50 | <hsivonen> | what I've heard from the folks behind ARIA, *[aria-hidden="true"] { display: none; } in an author style sheet is very much something that is expected |
| 08:50 | <hsivonen> | othermaciej: that's my understanding of the spec, too. |
| 08:51 | <othermaciej> | having that in a UA stylesheet would definitely violate the ARIA spec |
| 08:51 | <othermaciej> | having it in an author stylesheet does not seem like a problem per se if you definitely want to visually hide all content that's also hidden from accessibility |
| 08:51 | <hsivonen> | othermaciej: I said "author style sheet" intentionally. Putting it in the UA style sheet would be clearly wrong. |
| 08:51 | <othermaciej> | however, the author should not *have* to specify that, to hide content in the accessibility tree |
| 08:52 | <othermaciej> | if the UA doesn't prune it from the accessibility tree unless the author includes "*[aria-hidden="true"] { display: none; }", that too would violate the ARIA spec (as I read it) |
| 08:52 | <othermaciej> | or at least, if the UA+AT combination still present the content in that case, then there is clearly a bug in at least one of them |
| 08:52 | <hsivonen> | I agree. Dunno what Firefox does now and what's considered a bug and what's a feature here. |
| 08:53 | <othermaciej> | but like I said, I've been advising people to use it like a recursive version of role="presentation" |
| 08:55 | <othermaciej> | (the case this has particularly come up, the content does not actually need to work in other browsers, but that doesn't seem relevant to the actual issue of use cases) |
| 08:55 | <hsivonen> | othermaciej: has this been for iTunes-embedded WebKit? |
| 08:56 | <othermaciej> | can't really talk about the specific details, but feel free to speculate |
| 08:56 | <hsivonen> | I see |
| 08:56 | <othermaciej> | and I am sure we will need something similar in the future in content that works cross-browser |
| 08:57 | <othermaciej> | at which point I guess we will have to test in all the target browsers we care about and possibly report bugs |
| 09:06 | <zcorpan> | othermaciej: aaronlev said back in 2007 that aria-hidden did nothing in firefox but display:none hid from accessibility tree |
| 09:06 | <zcorpan> | othermaciej: dunno if it has changed |
| 09:07 | <othermaciej> | zcorpan: in Safari on Mac with VoiceOver, it definitely hides the whole subtree from the accessibility tree |
| 09:07 | <othermaciej> | I could test in Firefox on Mac |
| 09:07 | <othermaciej> | I have n easy way to test accessibility behavior on Windows though :-/ |
| 09:08 | <zcorpan> | there's an aapi debug tool for windows |
| 09:09 | <zcorpan> | inspect32.exe at http://www.microsoft.com/downloads/details.aspx?familyid=3755582a-a707-460a-bf21-1373316e13f0 |
| 09:15 | <othermaciej> | my favorite thing about voiceover is that it shows what it's speaking, so you can even test with it muted... |
| 09:16 | <othermaciej> | hmm my copy of Firefox does not seem to support VoiceOver on Mac |
| 09:16 | <othermaciej> | I'm running 3.5.2 |
| 09:16 | <othermaciej> | same thing with a minefiled alpha |
| 09:17 | <hsivonen> | othermaciej: IIRC, Mac accessibility of Firefox got frozen, because the developers didn't get enough information out of Apple a couple of years ago |
| 09:17 | <othermaciej> | hsivonen: do you know if Firefox supports accessibility at all on Mac? |
| 09:17 | <othermaciej> | I can't get VoiceOver to read anything but the title controls |
| 09:17 | <hsivonen> | othermaciej: there at least used to be code but IIRC it has never been turned on by default |
| 09:17 | <othermaciej> | guess I can't test this after all |
| 09:20 | <othermaciej> | and in Chrome only the toolbar supports VoiceOver, not the content area |
| 09:21 | <othermaciej> | if anyone feels like testing on Windows, here is my test case: |
| 09:21 | <othermaciej> | <div>First paragraph.</div> |
| 09:21 | <othermaciej> | <div aria-hidden="true">Hidden from accessibility.</div> |
| 09:21 | <othermaciej> | <div>Third paragraph.</div> |
| 09:21 | <othermaciej> | (or on Linux) |
| 09:21 | <othermaciej> | Safari definitely reads the first and third paragraph, but not the second, and shows all three |
| 09:27 | <zcorpan> | othermaciej: from what i can tell with inspect32.exe, firefox does not hide the paragraph from msaa |
| 09:31 | <othermaciej> | zcorpan: how about IE? |
| 09:32 | <hsivonen> | surkov: is it intentional that Firefox doesn't hide stuff from the accessible tree if aria-hidden=true? |
| 09:32 | <surkov> | smaug__, David Bolter tried to contact with Apple developers to get some help but no real success iirc |
| 09:32 | <surkov> | hsivonen: I think so, iirc this ARIA requirement |
| 09:32 | <Hixie> | jeez. i only got this laptop last week and i'm already nearly killing it again. |
| 09:32 | <surkov> | we set proper state on the accessible |
| 09:32 | Hixie | moves his laptop further away from the tea cup |
| 09:32 | <zcorpan> | othermaciej: same as firefox |
| 09:33 | <othermaciej> | maybe on Windows it's the screen reader's job to hide aria-hidden stuff |
| 09:34 | <othermaciej> | (I don't actually know which of Safari or VoiceOver hides it on Mac, I tested end-to-end) |
| 09:34 | <hsivonen> | surkov: where is the requirement in ARIA? |
| 09:35 | <surkov> | hsivonen: it sounds the things were changed, now ARIA impl guide sais "# has one of the WAI-ARIA global states and properties but does not have the aria-hidden property set to "true". Hidden elements are not exposed to assistive technology." |
| 09:35 | <surkov> | http://www.w3.org/WAI/PF/aria-implementation/ |
| 09:36 | <zcorpan> | "This is not used in mapping to platform accessibility APIs. Instead, use information from the layout system to determine if the element is hidden or not. Advisory: it is incorrect use of ARIA if an element with aria-hidden="true" is visible. The aria-hidden property is exposed only so that DOM-based assistive technologies can be informed of visibility changes. However, the layout will be able to provide the most complete set of all truly hidden |
| 09:36 | <zcorpan> | nodes." |
| 09:36 | <zcorpan> | (same url) |
| 09:36 | <zcorpan> | uh i mean https://developer.mozilla.org/En/ARIA_to_API_mapping |
| 09:36 | <othermaciej> | hmm, that seems to contradict what WAI-ARIA itself says |
| 09:37 | <zcorpan> | (but the other url seems to say the same thing) |
| 09:37 | <hsivonen> | zcorpan: English translation: aria-hidden is only for IE7+JAWS |
| 09:37 | <othermaciej> | "This allows http://www.w3.org/TR/wai-aria/terms#def_at or http://www.w3.org/TR/wai-aria/terms#def_useragent to properly skip http://www.w3.org/TR/wai-aria/terms#def_hidden elements in the document." |
| 09:37 | <hsivonen> | yay for UA-specific features |
| 09:37 | <othermaciej> | (boy that copied oddly) |
| 09:38 | <othermaciej> | so I wonder what is the correct way to do the deep equivalent of role="presentation" |
| 09:38 | <othermaciej> | should you just put role="presentation" on every element in the subtree? (But that still won't affect the text nodes) |
| 09:39 | <surkov> | hsivonen: actually it sounds aria-hidden doesn't make sense at all in the current aria impl guide edition |
| 09:39 | <hsivonen> | othermaciej: maybe send feedback to public-pfwg-comments⊙wo today? today is the DL for ARIA comments. |
| 09:39 | <othermaciej> | I wonder also why the implementor's guide apprently contradicts the spec on this |
| 09:39 | <othermaciej> | hsivonen: will attempt to |
| 09:40 | <surkov> | hsivonen: I'll ping David Bolter about this issue since he is a member of ARIA group |
| 09:40 | <hsivonen> | surkov: thanks |
| 09:41 | <Hixie> | othermaciej: the correct way is "don't have presentational elements" |
| 09:41 | <othermaciej> | I'm posting to public-pfwg-comments but I don't necessarily expect to have a prompt reply |
| 09:42 | <othermaciej> | Hixie: we have some markup that would give bad results in a screen reader if you didn't hide part of it, but where the extra bits can't be tacked on via CSS |
| 09:42 | <Hixie> | othermaciej: sounds like a bug for css |
| 09:42 | <othermaciej> | Hixie: so maybe your answer is "redesign the UI", but that does not seem like helpful advice |
| 09:43 | <othermaciej> | is it a goal for CSS to allow generated content with arbitrarily complex internal structure and styling? |
| 09:43 | <othermaciej> | I mean, you can use XBL to do that |
| 09:43 | <othermaciej> | but in that case you'd still need ARIA to control how your XBL binding is presented to a screen reader |
| 09:43 | <Hixie> | maybe the answer is xbl |
| 09:43 | <Hixie> | it's hard to know without examining the actual use case |
| 09:43 | <othermaciej> | which regrettably I am not at liberty to paste here |
| 09:44 | <Hixie> | i think we'll probably need to add something to xbl to indicate whether the accessibility apis are expected to crawl it or not |
| 09:44 | <Hixie> | really this should be solved by not using the same media type for screens as screen readers |
| 09:44 | <Hixie> | but that's another story |
| 09:45 | <othermaciej> | I think you may need more control than binary "yes" or "no" over the accessibility behavior |
| 09:45 | <othermaciej> | though I suppose reading either the surface markup or the contents of the XBL binding which may internally use ARIA would cut it |
| 09:45 | <othermaciej> | but you'd still need a proper mechanism to hide parts of the XBL shadow tree from screen readers |
| 09:46 | <othermaciej> | using a different media type would be cleaner CSS wise, but would require generating two render trees to have both visual and audio presentation at the same time |
| 09:46 | <othermaciej> | (which is the only mode VoiceOver has, so you can work with or help a blind person by looking over their shoulder) |
| 09:55 | <surkov> | I agree XBL markup should have a stuffs to control its accessible tree, in firefox we some basic stuffs to do this. For example, accessible for bound XBL element can provide accessible name or XBL can allow or deny accessible children in its subtree |
| 09:56 | <surkov> | ideally I think XBL should special markup to control all this stuffs |
| 10:12 | <othermaciej> | hsivonen, zcorpan, surkov: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JanMar/0038.html |
| 10:12 | <hsivonen> | http://www.floodgap.com/software/classilla/ wow |
| 10:12 | <othermaciej> | surkov: I think the markup to control accessible presentation of XBL should be (a possibly extended version of) ARIA, and it should also be usable outside XBL, so that it's viable to use DIV soup as fallback to XBL during the transition |
| 10:13 | <othermaciej> | I would not want to see a whole second form of accessibility markup |
| 10:13 | <othermaciej> | hsivonen: neat parlor trick, I guess |
| 10:15 | <annevk> | othermaciej, if origin is a unique identifier the result is Origin: null |
| 10:16 | <annevk> | and my idea was that it would support preflights as well |
| 10:16 | <annevk> | because that was the plan for Level 2 of their protocol anyway |
| 10:18 | <Hixie> | ok well i've dealt with all the websocket feedback that is not on the hybi list and all the feedback on the hybi list up to the 28th of this month |
| 10:18 | <Hixie> | all that's left is GIANT threads of pain |
| 10:18 | <Hixie> | i guess i go through and delete the process ones first |
| 10:18 | <othermaciej> | annevk: should there be a "force no preflight" flag anyway to define XDR sanely? |
| 10:18 | <othermaciej> | annevk: I guess XDR just doesn't allow sending any requests that would cause preflight, so nevermind |
| 10:19 | <othermaciej> | Hixie: I tried to move discussion into the technical threads |
| 10:19 | <Hixie> | yeah that helps a lot, indeed |
| 10:20 | <Hixie> | i like the subthread with the subject line "Process, was: Technical feedback. was: Process" |
| 10:20 | <othermaciej> | Hixie: I have some potentially bad news, which is that I came up with a way to do the handshake that is both much more secure and likely much easier to use in existing server software |
| 10:20 | <Hixie> | oh? |
| 10:20 | <othermaciej> | Hixie: is it too late to consider changes to the handshake? |
| 10:20 | <Hixie> | depends how much of an improvement it is |
| 10:20 | <Hixie> | what is the improvement? |
| 10:21 | <othermaciej> | ok, so as I understand it, the security goal of the "exact binary match" requirement on the first part of the header is to reduce the risk of abusing unmodified vanilla HTTP servers, or non-HTTP resources |
| 10:21 | <zcorpan> | othermaciej: thanks |
| 10:21 | <Hixie> | othermaciej: more or less, yeah |
| 10:21 | <othermaciej> | so there's two problems with the current setup: |
| 10:21 | <annevk> | othermaciej, you can prevent sending a preflight by preventing making requests that result in one |
| 10:22 | <annevk> | (you can force a preflight if you want) |
| 10:22 | <othermaciej> | 1) Hardcoding not just the status line, but also a few of the initial headers, is apparently a pain in the ass to work into existing HTTP stacks in servers (I'm willing to take their word for it). |
| 10:22 | <Hixie> | i don't buy that at all, but i have heard it, yes |
| 10:22 | <othermaciej> | 2) The handshake response consists exclusively of fixed contents, and literal character-for-character echoes of parts of the handshake request |
| 10:23 | <Hixie> | right |
| 10:23 | <othermaciej> | this means that if you can trick any server into echoing back exact text of choice in response to a WebSocket request, you are hosed |
| 10:23 | <othermaciej> | a better method would be requiring something in the response that proves you saw the request, but is not predictable in advance |
| 10:23 | <Hixie> | yes, though i'm not aware of any case where it is possible, and i've looked |
| 10:23 | <othermaciej> | so here is my proposal: |
| 10:24 | <Hixie> | woah woah |
| 10:24 | <Hixie> | no |
| 10:24 | <Hixie> | we don't want to require that the server parse the request |
| 10:24 | <Hixie> | in fact in the common case the server won't parse the request at all |
| 10:24 | <othermaciej> | - Include a nonce in the request |
| 10:24 | <othermaciej> | - Server includes a hash of the nonce plus the request origin in the response status line |
| 10:25 | <othermaciej> | - Only the status line is strictly constrained, not response headers |
| 10:25 | <othermaciej> | This is clearly more robust against cross-protocol attacks |
| 10:25 | <Hixie> | unless you're aware of a web service that can be tricked into sending back the handshake, that seems unnecessarily complicated |
| 10:26 | <Hixie> | right now in the most common case a websocket server will send the handshake before the client does |
| 10:26 | <othermaciej> | it's actually pretty trivial |
| 10:26 | <othermaciej> | cross-protocol attacks do happen and it's hard to predict them |
| 10:26 | <Hixie> | it's not as trivial as not doing anything :-) |
| 10:26 | <othermaciej> | witness recent firefox-based attack against IRC |
| 10:27 | <Hixie> | i agree that they happen, but as far as i've been able to tell, what we have currently is sufficient |
| 10:27 | <othermaciej> | what I described is far more robust against cross-protocol attacks, and likely easier to do in the context of integrating with an existing Web server |
| 10:27 | <Hixie> | actually i don't see why it's any more secure |
| 10:27 | <othermaciej> | again, anything where the necessary handshake response is predictable is much more robust |
| 10:27 | <Hixie> | why can't you just cause the server to echo back the right hash? |
| 10:27 | <othermaciej> | because you can't predict the correct handshake response |
| 10:27 | <Hixie> | why not? |
| 10:28 | <othermaciej> | because you (the JS-level attacker) do not know the nonce |
| 10:28 | <Hixie> | oh the UA makes up the nonce, ok |
| 10:28 | <othermaciej> | it is generated by the UA |
| 10:28 | <Hixie> | that seems like a lot more complexity than what we have now |
| 10:28 | <Hixie> | i agree it's easy for experienced programmers |
| 10:28 | <othermaciej> | it doesn't even have to be a cryptographically secure hash, in fact, it might be an improvement even if you don't hash the nonce at all |
| 10:28 | <Hixie> | and even more non-experienced ones |
| 10:28 | <Hixie> | s/more/most/ |
| 10:29 | <Hixie> | (or at least many0 |
| 10:29 | <Hixie> | but it is still more work than nothing |
| 10:29 | <Hixie> | i'm not aware of any protocol where you can cause the server to echo back the handshake or even get close |
| 10:30 | <Hixie> | especially given how constrained the client's part of the handshake is |
| 10:30 | <othermaciej> | and putting the unpredictable part of the required handshake response in the status line makes it slightly more robust against header injection attacks on normal HTTP services |
| 10:30 | <othermaciej> | right, the client can only control the URL part |
| 10:31 | <othermaciej> | however, what I described is secure at a stronger level than "I'm not aware of any hackable services currently" |
| 10:31 | <Hixie> | agreed, but it's not enough of an improvement to throw away the half-dozen or so implementations |
| 10:31 | <Hixie> | (if you had suggested this six months ago, it'd be in without question) |
| 10:32 | <othermaciej> | why don't we check if server and client implementors think it's enough of an improvement? |
| 10:32 | <Hixie> | go for it |
| 10:32 | <othermaciej> | afaik the only client implementation that has actually shipped is Chrome, and they specifically said they weren't looking to prematurely lock in the protocol |
| 10:32 | <Hixie> | i'm certainly happy to improve matters if people are willing to rewrite their code |
| 10:32 | <Hixie> | though i really don't like requiring that the server have to do work in the handshake |
| 10:32 | <Hixie> | isn't there some way we can get around that? |
| 10:33 | <othermaciej> | I posted a vague form of my suggestion on the hybi list |
| 10:33 | <othermaciej> | maybe I should pull it out of the thread and/or post it on whatwg |
| 10:33 | <annevk> | man, all this hybi crap in my inbox |
| 10:33 | <othermaciej> | maybe also get abarth's opinion |
| 10:33 | <annevk> | and now you guys are spamming this channel with it as well :p |
| 10:34 | <Hixie> | actually the more i think of this the less i like it... i don't like making the server have to read the client's data |
| 10:34 | <Hixie> | currently you can make a really simple server that completely ignores the server if you want to do something simple (similar to eventsource) |
| 10:34 | <Hixie> | er, ignores the client |
| 10:34 | <othermaciej> | Hixie: if a server accepts requests from multiple origins, doesn't it have to read the client's data anyway? |
| 10:34 | <Hixie> | yes, but that's likely to be much rarer |
| 10:36 | <othermaciej> | but the fact that it's needed in that case makes me think it is not such a huge burden |
| 10:36 | <Hixie> | i didn't say it was a huge burden, i said it was a burden |
| 10:36 | <Hixie> | right now you can literally never read a byte from the client |
| 10:36 | <othermaciej> | the part that the server has to read, check and echo-back isn't even in the fixed-order-and-capitalization part of the request, it's in the freeform part |
| 10:37 | <othermaciej> | is it not required for servers to check correctness of the client part of the handshake? |
| 10:37 | <Hixie> | no |
| 10:37 | <Hixie> | they can totally ignore the client |
| 10:37 | <othermaciej> | so a server could respond with WebSocket data even if you don't include Upgrade: WebSocket Connection: Upgrade? |
| 10:37 | <Hixie> | yes |
| 10:38 | <othermaciej> | wouldn't such a service be at risk of being exploited via XHR? |
| 10:38 | <Hixie> | comnnechow? |
| 10:38 | <Hixie> | er |
| 10:38 | <Hixie> | how? |
| 10:38 | <Hixie> | try connecting to damowmow.com:11111 |
| 10:38 | <Hixie> | how can XHR exploit that? |
| 10:39 | <othermaciej> | If it does not check the handshake request, I bet I can send it a GET with some preformatted messages as the body |
| 10:39 | <othermaciej> | even if I can't get the results back, that's still an integrity violation |
| 10:39 | <Hixie> | ? |
| 10:40 | <othermaciej> | if the service accepts commands of some kind via WebSocket that have side effects, rather than just reporting data, you could use XHR to abuse it if it does not check the handshake request |
| 10:40 | <Hixie> | if the server ignores the client, there's really not much to abuse |
| 10:40 | <surkov> | othermaciej: thanks for the link, I looked at the Firefox code and we do nothing with aria-hidden. And it sounds it goes with the spec :). However I'm agree it's not clear why ARIA hidden is at all. |
| 10:40 | <othermaciej> | at least in a browser that supports CORS |
| 10:41 | <othermaciej> | surkov: it doesn't sound to me like that is correct per the actual spec |
| 10:41 | <Hixie> | if the server ignores the client handshake but does listen to frames, then yes, you could send frames, just like you could if you just used zombies to send data there |
| 10:41 | <Hixie> | that doesn't seem like a particular problem |
| 10:41 | <annevk> | XHR cannot do GET with a body |
| 10:41 | <annevk> | unless the UA is broken |
| 10:42 | <othermaciej> | it's a problem if the server uses Cookies from the request but does not otherwise check correctness |
| 10:42 | <surkov> | othermaciej: the spec sais aria-hidden="true" should be on hidden elements, aria-hidden="false" on visible elements so aria-hidden does affect on nothing |
| 10:42 | <othermaciej> | annevk: good point - do any cross-site POSTs count as "simple requests" |
| 10:42 | <annevk> | yes |
| 10:42 | <annevk> | if the Content-Type header matches <form enctype> allowed values |
| 10:43 | <Hixie> | othermaciej: yes, if you read cookies you should make sure you're getting a websocket handshake. but then we're far past "ignoring the client", and checking the handshake is not a burden any more, since you're already parsing it and everything. |
| 10:43 | <othermaciej> | so if you're not checking correctness of the handshake request you presumably don't check the method either |
| 10:43 | <othermaciej> | Hixie: it seems to me that if you are completely ignoring the client, you don't really need a full duplex connection |
| 10:44 | <Hixie> | othermaciej: *shrug* |
| 10:44 | <othermaciej> | if you listen to the messages, then you'd better check the handshake |
| 10:44 | <Hixie> | i doubt most servers will |
| 10:44 | <othermaciej> | the spec should at least mention this in security considerations, even if it does not mandate rejecting a bad handshake |
| 10:45 | <othermaciej> | if most servers will not, then we effectively have an insecure protocol |
| 10:45 | <Hixie> | not much we can do about that as far as i can tell |
| 10:45 | <othermaciej> | it's always possible to make a buggy server, and indeed we can't prevent that |
| 10:46 | <othermaciej> | but: |
| 10:46 | <othermaciej> | a) the spec could require the server to check the handshake for correctness, even if we know some won't listen |
| 10:46 | <Hixie> | sure, i can add that, at least for the case where you read cookies |
| 10:47 | <othermaciej> | b) even if it does not require it, the spec could recommend checking the handshake for correctness in the case where you look at any credentials and/or perform any side effects in response to messages |
| 10:47 | <othermaciej> | c) my nonce proposal would actually force servers to read the handshake and process it (though it can't force them to check it is really correct, I suppose) |
| 10:48 | <othermaciej> | if a server truly ignores all input, then it could work just as well over EventSource with less trouble, so I am not sure WebSocket has to make that use case extra easy |
| 10:49 | <Hixie> | i think requiring the non-sensitive cases to be harder just to secure the sensitive cases is making the wrong tradeoff, personally |
| 10:49 | <Hixie> | what i'd really like to do is throw out the HTTP compatibility altogether |
| 10:49 | <Hixie> | and go back to ports 81 and 815 |
| 10:50 | <othermaciej> | I think the sensitive use cases are some of the most important |
| 10:50 | <Hixie> | and then just have people use port 443 as they will anyway |
| 10:50 | <othermaciej> | chat is clearly a case where you care about integrity, not just confidentiality |
| 10:50 | <othermaciej> | (i.e. you don't want random third parties to be able to forge chat messages as you) |
| 10:51 | <othermaciej> | I think security is one area where I would be very hesitant to cut corners, even if it makes things easier for the use cases where you don't need any security |
| 10:52 | <Hixie> | well if we really want security to that level, we should design the handshake with that in mind and stop using HTTP |
| 10:52 | <Hixie> | trying to retrofit it into HTTP isn't ideal |
| 10:53 | <Hixie> | and will always leave us vulnerable to the fake-websocket-via-form-post attack |
| 10:53 | <othermaciej> | retrofitting it into HTTP makes it easier to share a host:port with a web server |
| 10:53 | <Hixie> | i thought so too, but apparently not |
| 10:53 | <Hixie> | because it makes people think they should use their HTTP output code |
| 10:54 | <othermaciej> | well it's really the input side of the handshake that matters |
| 10:54 | <othermaciej> | i.e. the request from the client to the server |
| 10:55 | <othermaciej> | the server response could be anything, the fact that it takes the form of an HTTP 101 request is just following things to their logical conclusion |
| 10:55 | <othermaciej> | that being said, I think making the handshake response unpredictable would do more to improve security than making the handshake non-HTTP |
| 10:56 | <Hixie> | making the handshake non-HTTP could solve the entire attack scenario you described |
| 10:56 | <Hixie> | which is a real attack scenario |
| 10:56 | <Hixie> | unlike echoing the handshake, which is theoretical at this point |
| 10:56 | <Hixie> | so i'd say it's the other way around |
| 10:56 | <othermaciej> | actually, if a non-http handshake still allowed the server to ignore the client handshake request, it would do nothing to prevent my attack scenario |
| 10:58 | <Hixie> | nah, it'd be easy to design it in a way that it could... e.g. terminate the handshake with \n, so that the first frame would be corrupt |
| 10:59 | <othermaciej> | then you would have to hard fail on a bad frame instead of ignoring it and moving on - does the protocol require that currently? |
| 10:59 | <Hixie> | if you're writing a server lazily, that's by far the easiest thing to do |
| 11:00 | <Hixie> | the spec does explain how you can go the extra mile and ignore unknown frames, but it's extra code, like checking the handshake |
| 11:00 | <othermaciej> | if the frame boundary is a fixed sentinel, then it's easiest to scan for the sentinel |
| 11:00 | <Hixie> | we could arrange for the failure to be with a length-delimited frame and for the length to be gigantic |
| 11:00 | <Hixie> | by flipping the meanings of the high bits in the frame typesa and the length marker |
| 11:02 | <Hixie> | if we do your nonce idea, we could put the nonce in a specific header that would only be included with websockets |
| 11:02 | <Hixie> | so that if you can't find it, you can't send it |
| 11:02 | <othermaciej> | request-wise you mean? |
| 11:02 | <Hixie> | yeah |
| 11:02 | <Hixie> | that might make it more likely that the server implementors would fail if they can't find it |
| 11:02 | <othermaciej> | I agree that it should go in a request header that is only sent by WebSocet |
| 11:03 | <othermaciej> | er *WebSocket |
| 11:03 | <othermaciej> | I think I will ask abarth for his opinion on these issues |
| 11:04 | <othermaciej> | both whether the attacks I described are worth worrying about, and whether a nonce mechanism would be an effective defense |
| 11:13 | <Hixie> | one of my concerns with requiring that authors read the handshake is that one of the advantages of them NOT reading the handshake is they won't just echo back the origin |
| 11:13 | <Hixie> | i'm worried that authors will just do that instead of echoing back only their own origin |
| 11:16 | <othermaciej> | servers that accept connections from multiple origins actually *do* have to do that, after checking the origin, but you are right that it may affect the likelihood of making a mistake in the single-origin case |
| 11:18 | <othermaciej> | though of course you could write the server-side algorithms to say otherwise (i.e. have different ones for single-origin and multi-origin case, where the former only sends the fixed allowed origin after separately comparing it to the handshake origin) |
| 11:19 | <Hixie> | that's more or less what the spec does |
| 11:19 | <Hixie> | the parsing is in a separate (later) section |
| 11:19 | <othermaciej> | people using stock tools for this (like mod_pywebsocket) might be less likely to make that mistake, if the framework asks you to declare allowed origins to it up front |
| 11:20 | <othermaciej> | then the framework could make sure to both check against your list and echo back |
| 11:20 | <othermaciej> | I guess the main risk there would be if the framework has an "allow any origin" mode, authors might switch that on inadvertantly |
| 11:20 | <Hixie> | or indeed if they default to that :-) |
| 11:21 | <Hixie> | given how easy it is to write a websocket server, i don't know how much point there is to a websocket framework really |
| 11:21 | <Hixie> | (not having to parse the header is a big part of that) |
| 11:22 | <othermaciej> | well, if you want something that operates on a large scale, you probably need some sort of framework, even if not for parsing the header |
| 11:22 | <othermaciej> | anyway - frameworks should probably either default to failing if you don't specify allowed origins, or default to allowing the same origin as the WEb sever they are running inside, if their purpose is to share a host:port with an existing web server |
| 11:26 | <hsivonen> | what's blocking bytes in JS? |
| 11:26 | <annevk> | TC39 |
| 11:26 | <annevk> | doh |
| 11:32 | <Hixie> | othermaciej: btw, re having acks in the protocol, it's relatively easy to add them at the application level, but it turns out to be much harder to add them at the websocket level. Basically all you need is to number your messages, and tell the server what the last message was you got when you reconnect. |
| 11:33 | <Hixie> | othermaciej: but if you do that at the websocket level, you've no way to know if the script _actually_ received the message |
| 11:33 | <othermaciej> | Hixie: right - I'm wondering what the practical benefit (if any) would be of doing it at the websocket level |
| 11:33 | <othermaciej> | obviously, at the websocket level you could only generate transport-level acks, not guarantee actual end-to-end delivery to the app at either end |
| 11:33 | <Hixie> | yeah |
| 11:34 | <Hixie> | one thing that would help is having a flag in the onclose event to say whether it was an orderly close or not |
| 11:34 | <othermaciej> | I'm wondering if a clean shutdown handshake is something that benefits from being at the protocol level |
| 11:34 | <Hixie> | TCP already does that for us, no? |
| 11:34 | <othermaciej> | it sounds like if you don't use one at the app level, you have to do the same kind of "lingering close" dance as HTTP servers, or you may lose mssages |
| 11:35 | <othermaciej> | some of the content on the thread implies that the TCP close handshake is broken, and http servers have to work around it in crazy ways |
| 11:35 | <othermaciej> | I do not have enough expertise to check the accuracy of those claims |
| 11:36 | <othermaciej> | obviously you can do a close handshake at the subprotocol level if you want, but if every subprotocol has to do it to be remotely correct, then maybe it should be in the base protocol |
| 11:36 | <Hixie> | i guess i'd have to understand the use case better |
| 11:37 | <Hixie> | to have an opinion |
| 11:37 | <othermaciej> | apparently, if you just do a normal close of your socket when you are done sending, in some cases it can make the client drop data that it has already ACKd at the TCP level |
| 11:38 | <othermaciej> | in other words, you might lose the last few messages even if there is no actual disruption of service |
| 11:38 | <othermaciej> | Web servers do something crazy that I don't understand to work around this |
| 11:38 | <othermaciej> | it would be nice if protocol reliability could just rely on TCP-level acks, but besides the close issue, there's the problem that OS TCP stacks apparently don't expose how much has been ACK'd |
| 11:39 | <othermaciej> | which seems like a waste... |
| 11:39 | <othermaciej> | TCP is supposed to provide a reliable stream, but the next level up has to reinvent reliability |
| 11:39 | <Hixie> | wait, back up |
| 11:39 | <Hixie> | who's closing? |
| 11:39 | <Hixie> | client or server? |
| 11:39 | <othermaciej> | the server |
| 11:39 | <Hixie> | and why? |
| 11:39 | <Hixie> | ah |
| 11:39 | <othermaciej> | the server has sent the final message it intends to |
| 11:39 | <othermaciej> | closes the socket |
| 11:39 | <othermaciej> | that can make the client lose the last few messages |
| 11:39 | <Hixie> | so the server thinks it's done but it wants to make sure it gets all the client's messages? |
| 11:40 | <othermaciej> | (apparently) |
| 11:40 | <Hixie> | well there's no way to do that except at the application layer, since you don't know what the app wants to send but hasn't sent yet |
| 11:40 | <othermaciej> | not messages from the client |
| 11:40 | <othermaciej> | what people claim is this: |
| 11:40 | <othermaciej> | - the server sends some messages to the client |
| 11:40 | <othermaciej> | - the server gets TCP-level ACKs |
| 11:40 | <othermaciej> | - the server closes the socket |
| 11:41 | <othermaciej> | in this case, TCP requirements can cause the client to forcibly drop the last few messages |
| 11:41 | <Hixie> | oh i see |
| 11:41 | <othermaciej> | and you have to do some "lingering close" trick to avoid it |
| 11:41 | <Hixie> | wow, really? |
| 11:41 | <Hixie> | that's, ah, stupid |
| 11:41 | <Hixie> | how about we fix TCP |
| 11:41 | <othermaciej> | it sounds like a huge bug in TCP to me |
| 11:41 | <othermaciej> | but I think "fix TCP" is out of the range of the practical |
| 11:41 | <annevk> | someone asked about TCP5 from us |
| 11:42 | <foolip> | Hixie: cool, glad you enjoyed it |
| 11:42 | <annevk> | jokingly maybe |
| 11:42 | <othermaciej> | whereas "shutdown handshake" is viable |
| 11:42 | <hsivonen> | Hixie: did you happen to find out and document what exactly WebKit does with initial about:blank? |
| 11:42 | annevk | forgot who it was |
| 11:42 | <foolip> | Hixie: it turned out that the new RDF extraction algorithm is a bit b0rked, will send mail about that tonight hopefully |
| 11:42 | <Hixie> | hsivonen: not in any more detail than what the spec says now |
| 11:42 | <Hixie> | foolip: cool |
| 11:42 | <othermaciej> | I wonder if SCTP fixes this problem |
| 11:42 | <hsivonen> | Hixie: ok. |
| 11:43 | <hsivonen> | clearly, what the spec says now isn't what WebKit does |
| 11:43 | <hsivonen> | http://hsivonen.iki.fi/test/moz/about-blank-load.html |
| 11:44 | <hsivonen> | this whole about:blank has been so sad. I reached my timeout of fixing it the right way on the critical path of HTML5 parser enablement |
| 11:44 | <hsivonen> | so I'm going to paper over it for now |
| 11:44 | <hsivonen> | but I'd still like to fix it the right way once the HTML5 parser is on by default on trunk |
| 11:44 | <othermaciej> | Hixie: the "Reliable message delivery" subthread had the explanations of the socket close issue |
| 11:44 | <othermaciej> | http://www.ietf.org/mail-archive/web/hybi/current/msg01030.html |
| 11:45 | <othermaciej> | http://www.ietf.org/mail-archive/web/hybi/current/msg01044.html has more details |
| 11:45 | <hsivonen> | (that is, even what the spec says now and what the spec says plus load event are too much on the critical path) |
| 11:46 | <hsivonen> | fwiw, the above demo alerts "Different body" in Gecko, WebKit and Trident |
| 11:46 | <hsivonen> | and "Same body" in Opera |
| 11:46 | <othermaciej> | hsivonen: does the spec require too much relative to what WebKit does, or too little? |
| 11:46 | <hsivonen> | othermaciej: breaks enough test cases that poking at about:blank is going to be a test case whack-a-mole project on its own right |
| 11:47 | <othermaciej> | I am surprised that this echoed "Different body" |
| 11:47 | <hsivonen> | getting the HTML5 parser on by default is big enough a test case whack-a-mole project already |
| 11:48 | <othermaciej> | hsivonen: I figured out why it says "Different body" in WebKit |
| 11:48 | <othermaciej> | hsivonen: it's not because the about:blank load is async, it's because the load event listener runs before the second script |
| 11:49 | <hsivonen> | othermaciej: does the event loop spin or do you fire a sync load event? |
| 11:50 | <othermaciej> | hsivonen: I don't know code-wise why it happens (either explanation is plausible), but I verified that the end() function runs before the second script by adding more alerts |
| 11:50 | <foolip> | http://dev.w3.org/rdfa/specs/rdfa-dom-api.html |
| 11:50 | <hsivonen> | othermaciej: ok. thanks |
| 11:51 | <othermaciej> | hsivonen: I believe we do fire a load event from the middle of parsing without spinning the event loop |
| 11:52 | <othermaciej> | foolip: I am amused that the "Triple" interface has 6 things in it... |
| 11:52 | <hsivonen> | othermaciej: eww. I really don't want to go down that road. |
| 11:52 | <othermaciej> | hsivonen: I just think that is how our code happens to work - no idea if this is required |
| 11:52 | <othermaciej> | hsivonen: I think it is actually as a result of DOM insertion, not parsing, that the load event fires |
| 11:53 | <hsivonen> | othermaciej: ok. I still want to avoid sync events while the parser is on the call stack |
| 11:53 | <othermaciej> | and I can see the wisdom of that |
| 11:53 | <othermaciej> | I honestly have no idea if this behavior is needed for Web compat |
| 11:53 | <othermaciej> | I'm just trying to describe what we do |
| 11:54 | <hsivonen> | sure. thanks |
| 11:54 | <Dashiva> | So the IETF doesn't like cool URIs? Interesting |
| 11:54 | <annevk> | that's nothing new |
| 11:54 | <annevk> | though tools.ietf.org generally does |
| 11:54 | <annevk> | so I use that |
| 11:55 | <foolip> | othermaciej: well, (object, datatype, language) is really all part of the object, and children is just a bit odd. I assume this won't be the final draft. |
| 11:55 | <MikeSmithX> | othermaciej: about the H:TML draft, I will get an announcement out to public-html shortly |
| 11:55 | <MikeSmithX> | sorry for the delay, I made quite a lot of changes over the weekend |
| 11:56 | <hsivonen> | whoa. the load event is sync in IE8, too |
| 11:58 | <Hixie> | othermaciej: btw, the two framing types is a result of targetting novice authors. SPDY is intended to be implemented by experts only. |
| 11:59 | <Hixie> | othermaciej: also, it's really easy to do multiplexing if your subprotocol supports it, just use a shared worker |
| 11:59 | <othermaciej> | Hixie: at this point I'm a little frightened of the thought of novice authors implementing the protocol by hand - I really hope people make good frameworks for Perl/Python/Ruby/Java/etc |
| 12:00 | <Hixie> | why? |
| 12:00 | <Hixie> | the protocol is trivial |
| 12:00 | <othermaciej> | it seems like there are many opportunities for subtle mistakes, when you dig into the details |
| 12:01 | <Hixie> | i've tried to minimise those |
| 12:01 | <Hixie> | obviously it's impossible to make a protocol idiot-proof, but it's a lot harder to screw up than most |
| 12:02 | <othermaciej> | it's easier to make an API (more) idiot-proof than a protocol, so I hope people do so |
| 12:03 | <othermaciej> | for multiplexing, yes, you could have clients coordinate via a SharedWorker or a shared iframe |
| 12:04 | <othermaciej> | it also seems to me that transparent multiplexing could be added down the line (between the UA and the server, invisible to the JS client code) |
| 12:04 | <othermaciej> | since the handshakes allow custom headers, and since you could introduce new frame types |
| 12:04 | <Hixie> | yes, indeed |
| 12:05 | <othermaciej> | voluntary multiplexing also doesn't work if your clients might be running from different origins |
| 12:05 | <othermaciej> | but sharing a connection in such a case is scarier security-wise |
| 12:05 | <othermaciej> | bugs in doing framing become much more severe issues |
| 12:05 | <Hixie> | well, shared workers will be cross-origin capable in due course |
| 12:05 | <Hixie> | which would solve that issue |
| 12:06 | <othermaciej> | I think transparent multiplexing would be cool, but it seems to me that it could be a 2.0 feature if deployment experience with WebSocket shows it is useful |
| 12:06 | <Hixie> | indeed |
| 12:06 | <othermaciej> | likewise for transparent compression |
| 12:06 | <othermaciej> | or whatever |
| 12:06 | <Hixie> | yup |
| 12:08 | <annevk> | what's the idea with the frame types though? lots of people seem to have in mind non-browser use cases, will they fork some of the frame types? |
| 12:09 | <Hixie> | no idea |
| 12:09 | <Hixie> | non-browser use cases seems tupid to me |
| 12:09 | <Hixie> | s/seems tupid/seem stupid/ |
| 12:09 | <Hixie> | i mean, just use TCP |
| 12:09 | <Hixie> | websockets is a terrible protocol if you're not trying to use this with JS |
| 12:09 | <Dashiva> | Hixie: I think the idea is to reuse existing services made for browsers in websocket |
| 12:10 | <Hixie> | in that case, there won't be forked frame types |
| 12:10 | <annevk> | well, stupid or not, the people on the hybi list wanna do it |
| 12:11 | <Hixie> | othermaciej: oh, the reason the fixed part of the handshake is more than one line long is to ensure that you have to cause the server to echo something with a newline in it (which you can't send in the request) |
| 12:11 | <annevk> | i'm not sure it's very productive to label them stupid |
| 12:11 | <annevk> | that's prolly also what part of the clash is coming from |
| 12:12 | <annevk> | they have completely different use cases in mind |
| 12:12 | <Hixie> | i have yet to see a good reason to use websocket rather than TCP for something where there's no browser as possible client |
| 12:12 | <othermaciej> | Hixie: I see - in that case, I think a nonce would definitely remove the benefit of having a newline in the fixed part |
| 12:12 | <Hixie> | (indeed i've yet to see a reason at all) |
| 12:12 | <Hixie> | othermaciej: yes |
| 12:12 | <Hixie> | othermaciej: probably |
| 12:12 | <othermaciej> | I could imagine using WebSocket if you have browser clients *and* other clients |
| 12:13 | <annevk> | i think the reason for these server developers is that they can provide a easy-to-use library to their customers |
| 12:13 | <Hixie> | sure |
| 12:13 | <Hixie> | but then you wouldn't invent new frame types |
| 12:13 | <Hixie> | annevk: can't they do that with TCP too? |
| 12:13 | <annevk> | they want to interoperate |
| 12:13 | <annevk> | with other servers and new clients |
| 12:14 | <annevk> | from that perspective it makes sense to have a standard protocol |
| 12:14 | <Hixie> | TCP is a standard protocol? |
| 12:14 | <annevk> | yes, but they want an abstraction |
| 12:14 | <annevk> | just like HTTP is an abstraction |
| 12:14 | <annevk> | i don't see how this is very hard to get... |
| 12:15 | <Hixie> | websocket isn't an abstraction |
| 12:15 | <Hixie> | it's a minimal browser origin model security layer |
| 12:15 | <annevk> | it will be an abstraction of some kind once we have send(Stream) |
| 12:15 | <annevk> | well, and UTF-8 support is already an abstraction, imo |
| 12:18 | <Hixie> | i don't think "abstraction" means what you think it means |
| 12:19 | <annevk> | higher-level? |
| 12:19 | <Hixie> | seriously, you can do everything websockets does in like 10 lines of documentation if all you want is a convention of using UTF-8 or something like htat. |
| 12:19 | annevk | doesn't really care what term we use |
| 12:20 | <Hixie> | i don't understand why you would use websocket |
| 12:20 | <Hixie> | unless you specifically cared about browsers |
| 12:20 | <Hixie> | i understand using it for something where browsers is a use case and you also want to handle non-browser clients |
| 12:21 | <Hixie> | but for something where you don't have browser clients? |
| 12:21 | <Hixie> | it's silly. |
| 12:21 | <hsivonen> | Hixie: even for cutting through firewalls? |
| 12:22 | <annevk> | Hixie, it seems like you don't even try to understand their concerns |
| 12:22 | <Hixie> | hsivonen: websocket doesn't do anything special to cut through firewalls. |
| 12:23 | <othermaciej> | I think a use case with both browser and non-browser clients is legitimate |
| 12:23 | <Hixie> | annevk: please enlighten me |
| 12:23 | <othermaciej> | you may well not want to offer two forms of your service |
| 12:23 | <Hixie> | othermaciej: absolutely |
| 12:23 | <othermaciej> | I could also imagine that once you have that infrastructure, you may want to reuse the client and server code for some cases that don |
| 12:23 | <othermaciej> | t also involve a browser client |
| 12:23 | <othermaciej> | I am not sure those should get consideration on the level of a primary use case |
| 12:24 | <Hixie> | that's like saying "ok, i've deployed IMAP, now I want to be able to run my MUD using IMAP" |
| 12:24 | <othermaciej> | I could also imagine that you may want to talk an extended version of your protocol to a non-browser client rather than having a whole different protocol |
| 12:24 | <othermaciej> | I would bet someone has actually run a MUD over IMAP :-) |
| 12:24 | <Hixie> | and they're silly :-) |
| 12:25 | <othermaciej> | people also run back end business-to-business data messaging over HTTP |
| 12:25 | <hsivonen> | HTTP over WS-* over Web Socket |
| 12:26 | <Hixie> | people do a lot of silly things |
| 12:26 | <Hixie> | that doesn't stop them being silly |
| 12:27 | <annevk> | well, it seems to me they want something akin to HTTP for bidirectional communication |
| 12:28 | <annevk> | they also think that deploying a new protocol is costly |
| 12:28 | <Hixie> | yes, i have several people say those things a lot |
| 12:29 | <Hixie> | have seen, rather |
| 12:29 | <hsivonen> | annevk: if they want bidirectional HTTP for B2B back end integration, what does it have to do with Web Socket? |
| 12:29 | <annevk> | it seems they don't believe that deploying two protocols will work so they want WebSocket to also accommodate use cases / requirements they have |
| 12:53 | <Hixie> | othermaciej: seems like the orderly close could be done easily just by having an echo feature of some kind |
| 12:53 | <Hixie> | othermaciej: either at the application level or in WS itself if we wanted to require all implementations to do it |
| 12:53 | <othermaciej> | Hixie: echo feature? |
| 12:54 | <Hixie> | yeah where the side that wants to close the connection sends a packet saying "this is close attempt X" for some value of X, and the other side replies "close X", and if the first side receives a "close X" with the value of X that it sent, and it still thinks it wants to close, then it closes. |
| 12:54 | <Hixie> | without lingering. |
| 12:56 | <annevk> | but the side that sends close X does not know when it can close? |
| 12:56 | <annevk> | because wasn't the concern that if it closes to early "close X" would not arrive |
| 12:58 | <Hixie> | the side that sends close X will know it can close when the other side closes. |
| 13:00 | <annevk> | in that case one side could just do the closing attempt right? |
| 13:00 | <annevk> | no need for confirmation |
| 13:00 | <Dashiva> | Then there might be data lost in transmission |
| 13:02 | <annevk> | A says close, B closes on arrival of that message, A knows B closed |
| 13:02 | <annevk> | so A can close |
| 13:05 | <Dashiva> | Hixie's example said "and it still thinks it wants to close", though. |
| 13:05 | <Dashiva> | I guess that might not be a necessary step |
| 13:05 | <Hixie> | yeah i guess you could just do it that way |
| 13:06 | <Hixie> | actually no |
| 13:06 | <Hixie> | you need the two-way handshake |
| 13:06 | <zcorpan> | hmm looks like tests that i wrote 4 years ago have the same style as tests i write today |
| 13:06 | <othermaciej> | Hixie: I believe that would be a fine orderly close mechanism, but I don't understand the TCP issue super well |
| 13:06 | <Hixie> | otherwise if A says to "close" to B, and B sends data to A then closes, B wouldn't see what A said |
| 13:06 | <Hixie> | er |
| 13:06 | <Hixie> | A wouldn't see what B siad |
| 13:06 | <zcorpan> | except i probably try to automate tests more now |
| 13:07 | <annevk> | Hixie, good point |
| 13:07 | <annevk> | you win :) |
| 13:07 | <othermaciej> | Hixie: the reason I think it should be considered for the base protocol is that WebSocket is broken for any app-level protocol where you don't do this |
| 13:07 | <Hixie> | othermaciej: depends on the protocol |
| 13:07 | <othermaciej> | Hixie: not just "no acks" broken but "might gratuitously lose data even though everything seemed fine" broken |
| 13:08 | <annevk> | zcorpan, heh |
| 13:08 | <Hixie> | othermaciej: if the server is just sending a stream of updates "stock AAPL up $1" "stock MSFT up $5" etc, then you don't care about lost packets |
| 13:08 | <Hixie> | othermaciej: it very much depends on the subprotocol |
| 13:08 | <othermaciej> | Hixie: if the server initiated the close, then it seems wasteful for the server to order the client to discard the last few packets |
| 13:08 | <othermaciej> | Hixie: even if the client being a few messages out of date might not be a critical problem |
| 13:09 | <zcorpan> | 6 out of 8 have been fixed from http://zcorpan.1go.dk/test/opera-bugs/ |
| 13:09 | <Hixie> | agreed |
| 13:09 | <Hixie> | in that case the client would close |
| 13:09 | <Hixie> | not the server |
| 13:09 | <othermaciej> | Hixie: it seems like that is what's happening with this TCP issue - not just that you don't know for sure what got delivered, but that you are actually telling the client to discard data that it already received |
| 13:09 | <annevk> | you could put it in the base protocol and allow the server to close regardless if it doesn't care |
| 13:09 | <Hixie> | but the client wouldn't want an orderly close, especially if e.g. the websocket object is already GCed |
| 13:10 | <Hixie> | if we can come up with some thing simple enough that can be ignored if the server doesn't need it, it makes sense to add it to the base protocol |
| 13:11 | <othermaciej> | I actually don't know the bare minimum required for a proper orderly close handshake over TCP |
| 13:11 | <annevk> | it seems you could just use the highest byte as a special closing message |
| 13:11 | <annevk> | that needs to be returned |
| 13:12 | <othermaciej> | I wish someone on the thread had explained how you would solve the problem with a proper close handshake instead of a lingering close - like at least one example of something that works |
| 13:12 | <annevk> | so 0xFF |
| 13:12 | <Hixie> | i wonder if we need the number X from my example |
| 13:12 | <annevk> | as a standalone closing frame |
| 13:12 | <Hixie> | maybe we can just do 0xFF 0x00 |
| 13:12 | <Hixie> | and if you receive an 0xFF frame, you know the other side wants to close |
| 13:12 | <Dashiva> | Hixie: If you want to support changing your mind about closing, you need it, don't you? |
| 13:12 | <annevk> | you don't even need 0x00 I think |
| 13:12 | <Hixie> | and you can send an 0xFF to say ok |
| 13:12 | <Hixie> | annevk: i don't want to add a third kind of frame |
| 13:13 | <Hixie> | Dashiva: yeah, but it's not clear we need that |
| 13:13 | <annevk> | boring :) |
| 13:18 | <othermaciej> | foolip: maybe I am dumb, but if RDFa is fundamentally a graph structure, that seems like a poor API for it |
| 13:19 | <hsivonen> | how are HTML notications in http://dev.chromium.org/developers/design-documents/desktop-notifications/api-specification supposed to work with D-Bus or Growl notifications? |
| 13:19 | <hsivonen> | the spec talks about the browser rendering them as a browsing context |
| 13:20 | <hsivonen> | but who really want that except in a Chrome OS -like environment where there's nothing but the browser? |
| 13:20 | <hsivonen> | *wants |
| 13:20 | <Hixie> | they're not, as i understand them |
| 13:20 | Hixie | has similar concerns |
| 13:20 | <foolip> | othermaciej: I agree, it's not terribly useful |
| 13:20 | <Hixie> | hsivonen: also a concern for iphone or android environments where the OS has a built-in notification system that is pure-text or close to it |
| 13:21 | <Hixie> | ok i should go sleep |
| 13:21 | <Hixie> | nn |
| 13:21 | <othermaciej> | in particular, you'd expect the children of an RDFa graph node / triple to have the same subject as the triple's *object*, not the same subject as its subject |
| 13:21 | hsivonen | thinks it would be good to start out with a simple icon + plain text API that maps to system notification mechanisms |
| 13:21 | <othermaciej> | it also seems like you would really want to be able to query by subject, object or predicate, not just by type... |
| 13:21 | <hsivonen> | what mailing list am I supposed to whine on about the notication API? |
| 13:22 | <hsivonen> | aside: it's rather amazing that Growl still isn't part of Mac OS X itself |
| 13:22 | <hsivonen> | amazing from a practical POV that is |
| 13:22 | <hsivonen> | not amazing from a NIH attitude POV |
| 13:22 | <othermaciej> | hsivonen: you could use webkit-dev, to complain about what's implemented, since the code is in WebKit, but fwiw I think Chrome is the only browser shipping with it enabled |
| 13:22 | <othermaciej> | for proposing a standard version of this and proposing changes to that, I dunno |
| 13:22 | <othermaciej> | HTML is not really an obstacle for Growl |
| 13:23 | <othermaciej> | IIRC it uses WebKit to render notifications |
| 13:23 | <hsivonen> | othermaciej: does chrome send stuff to growl or d-bus on Mac/Linux? |
| 13:23 | <othermaciej> | hsivonen: I don't know |
| 13:23 | <hsivonen> | ok |
| 13:24 | <othermaciej> | non-Chrome WEbKit vendors/devs were not fully sold on the suitability of this API or the value of shipping it without sufficient cross-vendor discussion |
| 13:24 | <othermaciej> | but I expect they implement it all internally and do not use any system or third-party notification services |
| 13:25 | <hsivonen> | I see |
| 13:25 | <hsivonen> | does Windows have a system-wide notification service that doesn't involve registering a tray icon first? |
| 13:31 | <zcorpan> | onvolumechange didn't work at least |
| 13:32 | <zcorpan> | but addEventListener worked |
| 13:34 | <othermaciej> | it's a bug I guess |
| 13:35 | <othermaciej> | per HTML5 it should clearly be on HTMLElement and HTMLDocument |
| 13:36 | <zcorpan> | yes |
| 13:36 | <zcorpan> | and window |
| 13:37 | <othermaciej> | I need to catch up on this fullscreen thread at some point |
| 13:37 | <zcorpan> | feature testing says it's on window but not document or element |
| 13:37 | <zcorpan> | in webkit |
| 13:38 | <zcorpan> | which is not so useful since volumechange doesn't bubble :) |
| 14:41 | <annevk> | so to get an.ne I need to a have a registered company in Nigeria named "an" |
| 14:41 | <annevk> | that seems like too much trouble |
| 14:42 | <ray> | man, uganda doesn't have any silly restrictions like that |
| 14:45 | <AryehGregor> | annevk, surely you could just bribe the right official? |
| 15:00 | <zcorpan> | "Markup conformance requirements that need to be tested and give them a stable identifier that will persist across drafts of the specification." - http://www.w3.org/TR/2010/NOTE-test-methodology-20100128/ |
| 15:02 | AryehGregor | wonders how many thousands of distinct conformance requirements there are in HTML5. |
| 15:03 | <Philip`> | That's easy, just use the text of the conformance requirement as the identifier |
| 15:04 | <AryehGregor> | I guess if the text changes, you've changed the conformance requirement anyway . . . |
| 15:05 | <Philip`> | AryehGregor: I counted 223 requirement statements for <canvas> a while ago |
| 15:05 | <Philip`> | so there's going to be quite a lot across the whole spec |
| 15:05 | <AryehGregor> | Is that counting something like "When X occurs, user agents must execute the following algorithm:" as one requirement or lots? |
| 15:06 | <Philip`> | Lots |
| 15:07 | <Philip`> | (I suppose it's more about testable points than about conformance requirements) |
| 15:08 | <AryehGregor> | There are what, like 8,000 tests for CSS2.1? And HTML5 is how much longer, twenty times as long? |
| 15:08 | <AryehGregor> | :/ |
| 15:09 | AryehGregor | is ballparking |
| 15:09 | <annevk> | last estimate was 50000 tests needed |
| 15:09 | <annevk> | maybe that was optimistic |
| 15:10 | <othermaciej> | HTML5 has lots of features, many different facets to test for each, very detailed requirements for most of them, and some nontrivial interactions among different features |
| 15:11 | <othermaciej> | so probably the level of test coverage needed is even higher than comparison of length to CSS would imply |
| 15:11 | <othermaciej> | though to be fair, CSS is also pretty damn complicated |
| 15:11 | <annevk> | CSS is prolly more complicated |
| 15:11 | <annevk> | most of HTML5 is written in a pretty straightforward way |
| 15:11 | <annevk> | CSS has very complex interactions |
| 15:11 | <AryehGregor> | You couldn't test a lot of HTML5 requirements in a cross-browser way, could you? You'd need something more like Mozilla's mochitests, that can synthesize input and whatnot. |
| 15:11 | <othermaciej> | CSS has some very complex interactions by design |
| 15:12 | <othermaciej> | HTML5 has a fair number of complex interactions by accident of history |
| 15:12 | <othermaciej> | there are many HTML requirements that would be hard to test if the browser itself is your only test tool |
| 15:12 | <othermaciej> | that doesn't mean you can't do it in a cross-browser way |
| 15:13 | <AryehGregor> | How would you do it, then? Except manually, of course. |
| 15:13 | AryehGregor | doesn't want to see anyone try running 100,000 tests manually :P |
| 15:13 | <othermaciej> | one possible way is to run an external program to synthesize input events, and possibly capture output |
| 15:14 | <othermaciej> | people have made such tools that work with any given browser, for example for testing Web sites or for general QA of any native application with a GUI |
| 15:14 | <zcorpan> | i generated about 15000 tests for a css feature |
| 15:14 | <AryehGregor> | "Generated"? |
| 15:15 | <othermaciej> | of course for any conformance requirement that can be tested by scripting against the DOM, that's the best way to do it |
| 15:15 | <zcorpan> | yeah, i wrote some python scripts |
| 15:16 | <zcorpan> | although i wanted to generate more for interaction with svg |
| 15:17 | <AryehGregor> | So how many substantively different things did these 15,000 tests actually test? |
| 15:19 | <zcorpan> | i tested different combinations of percentages, lengths and keywords, visibility:hidden/visible, and the different values for the feature, for a number of different elements |
| 15:19 | <zcorpan> | including invalid cases |
| 15:19 | <zcorpan> | oh and with different images |
| 16:01 | <Huvet> | gah, I'm going crazy with all the different html parsing libraries... I want three things: parse broken html -> remove all tags except a list I specify -> get all text blocks that remain |
| 16:02 | <Philip`> | I guess this is why people give up and use regexps |
| 16:02 | <Huvet> | the only way I see of doing this, is to parse with html5lib, serialize to html, parse with lxml.html.clean and clean up, then parse again with html5lib, and select out all the text from there with xpath |
| 16:02 | <Huvet> | ... and that's a mess :) |
| 16:02 | <Huvet> | yeah :) |
| 16:03 | <Philip`> | Why can't you parse with html5lib with lxml treebuilder, then do whatever manipulations you need to the tree structure, then serialise as text? |
| 16:04 | <Huvet> | because the tree I get from the lxml treebuilder is not the format lxml.html.clean, expects... I get 'lxml.etree._ElementTree' object has no attribute 'rewrite_links' when trying to clean that document |
| 16:04 | <Huvet> | so it seems there are more methods on html trees somehow |
| 16:05 | <Philip`> | Oh, right |
| 16:05 | <Philip`> | Do you have to use lxml.html.clean, rather than implementing the functionality you need yourself using the normal lxml API? |
| 16:05 | <Huvet> | no, I'll switch as long as it works :) |
| 16:06 | <Huvet> | I'm screenscraping pages, and have found that a good way is to strip all tags except div, and then look for the longest text string that's left |
| 16:06 | <Huvet> | that's (most often) the article text |
| 16:06 | <annevk> | should be pretty easy to go through a tree and dump elements you do not like and append their content to the parent? |
| 16:07 | <annevk> | or some such |
| 16:07 | <annevk> | maybe with some different branches depending on the element |
| 16:07 | <Philip`> | It'd be easier with a SAX-like API since you could trivially filter out unwanted tags |
| 16:07 | <jgraham> | The seperation between lxml.etree and lxml.html is a real pain |
| 16:08 | <Huvet> | good ideas, all of them |
| 16:08 | <Huvet> | jgraham: yeah, I was hoping for a lxml.html.frometree(doc) |
| 16:08 | <jgraham> | Huvet: Have you tried looking at the implementation of the lxml.html thing and seeing if you san port it to vanilla lxml.etree? |
| 16:09 | <Huvet> | jgraham: I think that's a bit over my head, I'm not that used to lxml |
| 16:09 | <Huvet> | http://codespeak.net/lxml/api/lxml.html.clean-pysrc.html |
| 16:10 | <Huvet> | 700 lines |
| 16:10 | <jgraham> | Huvet: You could rather inefficiently walk the tree and rebuild it in lxml.html Elements |
| 16:11 | <jgraham> | Or you could patch html5lib asnd see what breaks :) |
| 16:12 | <Huvet> | I guess the best way is what annevk said... except the "pretty easy" part ;) |
| 16:13 | <Huvet> | get the lxml tree and walk it and drop nodes as I go along |
| 16:18 | <jgraham> | Huvet: You have to be a bit careful because of the .tail |
| 16:19 | <jgraham> | See lxml.html.drop_tree |
| 16:23 | <Huvet> | *reading* |
| 16:53 | <JonathanNeal> | Heyo. |
| 17:05 | <no_mind> | has html5 got something special for centering a div ? |
| 17:06 | <annevk> | we're not in the business of styling ;) |
| 17:06 | <annevk> | you want CSS |
| 17:06 | <annevk> | something like margin:0 auto; plus an explicit width |
| 17:06 | <annevk> | or some fiddling with table layout |
| 17:06 | <no_mind> | ok, so which channel is suitable for css ? |
| 17:10 | <annevk> | #css on irc.w3.org, though that's mainly for the CSS WG |
| 17:11 | <AryehGregor> | There's also #css here. |
| 17:11 | <AryehGregor> | That's unofficial. |
| 18:07 | <zcorpan> | hmm, chrome doesn't support wave in <audio>? |
| 19:37 | <JonathanNeal> | Anyone know how often the http://html5gallery.com/ guys update |
| 20:16 | <annevk> | reading http://unicode.org/draft/reports/tr46/tr46.html I really wonder how IDNA2008 got through |
| 20:16 | <annevk> | where is the upside? |
| 20:16 | <annevk> | it sounds insane |
| 20:16 | <annevk> | let me repeat that |
| 20:16 | <annevk> | insane |
| 20:40 | jgraham | reads section 1.2 decides that "insane" is probably being kind |
| 20:47 | <Dashiva> | Surely all valid comments were taken into consideration |
| 20:48 | <Dashiva> | It's just that imperfect beings such as us can't comprehend the trascendental perfection |
| 21:17 | <Huvet> | thanks for the help figuring this out Philip`, annevk, and jgraham: http://dpaste.com/153474/ |
| 21:17 | <Huvet> | input: an URL to an article, output: the article text |
| 21:30 | <jgraham> | Huvet: You can write doc = html5lib.parse(html, treebuilder="lxml") |
| 21:30 | <jgraham> | Rather than explicitly creating a parser that is never reused |
| 21:31 | <Huvet> | ah, great, fixing right away |
| 21:32 | <jgraham> | That is probably not documented anywhere |
| 21:33 | <gsnedders> | We have documentation? |
| 21:33 | jgraham | would tend to write the filter as a list comprehension or a generator expression |
| 21:33 | <jgraham> | like texts = (x.strip() for x in doc.xpath("//text") if x) |
| 21:34 | <jgraham> | (but it doesn't matter) |
| 21:36 | <Huvet> | yeah, I heard that from another python guru too... but I kinda like the idea that I'm "filtering away the empty texts" and it says "filter" there |
| 21:37 | <Huvet> | and yeah, you desperately need documentation |
| 21:37 | <Huvet> | I would set that as my main priority if I where you |
| 21:44 | Philip` | imagines the main priorities should be things like writing documentation and improving the sanitizer, and spec compliance should be somewhere near the bottom of the list |
| 21:44 | <jgraham> | gsnedders: Well we do, there are a few docstring and the old, lost documentation |
| 21:44 | <jgraham> | But it is abysmal, I grant you |
| 21:45 | <gsnedders> | jgraham: I know, I know... |
| 21:45 | <gsnedders> | Philip`: But what's the fun of that? |
| 21:47 | smaug___ | still doesn't understand why the draft changed to have async back()/forward() |
| 21:48 | <annevk> | Philip`, the whole point is spec compliance |
| 21:49 | <Philip`> | Users don't care about spec compliance |
| 21:49 | <Philip`> | Maybe users aren't the point, but they'd probably disagree |
| 21:50 | <jgraham> | http://code.google.com/p/html5lib/wiki/UserDocumentation |
| 21:50 | <jgraham> | Now it just needs to be right and good |
| 21:53 | <Huvet> | great! |
| 21:54 | <Huvet> | things that many documentations fail to do is provide examples... you could just include things that people have done with html5lib right in the docs |
| 21:54 | <Huvet> | that would help most people get started |
| 21:54 | <Huvet> | and I mean from url to string |
| 21:55 | <Huvet> | not only the parser-specific thing in between |
| 22:00 | <Huvet> | you should move to the whatwg wiki with all docs imo |
| 22:44 | <Lachy> | foolip, yt? |
| 22:45 | <Lachy> | foolip, there's a bug in your live microdata tool with support for additional-name |
| 22:46 | <Lachy> | when there are multiple additional-name properties used, they should be comma separated when the vcard is generated, just like you do for street-address |
| 22:48 | <annevk> | Hixie, they didn't like mappings |
| 22:49 | <annevk> | or maybe you mean something different from what I said earlier in that thread... |
| 23:02 | <Lachy> | foolip, same bug with itemprop="type" within "tel" |
| 23:12 | <annevk> | aah |
| 23:12 | <annevk> | IDNA2003 is tied to Unicode 3.2 and does not do bidi |
| 23:12 | <annevk> | though do you really want bidi in URLs?! |
| 23:17 | <annevk> | http://www.macchiato.com/unicode/idna/security-issues is a good document on the IDNA2008 mess |
| 23:56 | <Lachy> | My first attempt at using microdata seems to be a success. I just marked up my contact page using the vcard profile. http://lachy.id.au/about/contact |
| 23:56 | <Lachy> | although tedious, it was actually quite easy |
| 23:57 | <Lachy> | the one thing I found annoying was that I kept mistyping itemtype="..." instead of itemprop="..." |
| 23:59 | <Lachy> | foolip, that page of mine nicely illustrates those bugs in your tool that I mentioned above. |