| 00:00 | <jgraham__> | Great. Now all we need is a short summary of the talk |
| 00:00 | <Lachy> | or how about we use this channel's topic: HTML5: Please leave your sense of logic at the door, thanks! |
| 00:01 | <jgraham__> | I would love to go with that but I don't know what effect it would have |
| 00:01 | <Lachy> | hmm, true. getting your hands dirty is fine |
| 00:02 | <jgraham__> | Given there has been quite a lot of negative blogging about HTML5 it might be best not to play up to that image (unless we could make it work for us, but given the short timescales and the logistical difficulties, it seems risky) |
| 00:02 | <Lachy> | ok, for the summary, we can just write 1 or 2 paragraphs that expand on that list of topics |
| 00:03 | <jgraham__> | Shall we both have a go and then edit them together somehow |
| 00:03 | <jgraham__> | Or google docs? |
| 00:03 | <Lachy> | sure, how does google docs help us work together? |
| 00:04 | <jgraham__> | (or write first then set up a collaborative document to edit) |
| 00:05 | <Lachy> | yeah, that would be better |
| 01:43 | Hixie | finally dives into the day's alt nonsense |
| 01:44 | <othermaciej> | oy vay |
| 01:44 | <Dashiva> | If you don't say something in 30 minutes, we'll send in a search time |
| 01:44 | <Dashiva> | *team |
| 01:45 | <othermaciej> | one day of that thread burned me out |
| 01:45 | <roc> | I haven't read a single message of it, but I can feel the pain from here |
| 01:49 | <Dashiva> | It's surreal at times. "We must make @alt mandatory to encourage good behavior via people desiring conformance" and then "Pages that aren't hand-written and don't get author input must resign themselves to being non-conforming" |
| 01:49 | <Lachy> | that alt thread is ridiculous. There were around 40-50 posts on it just today, and I just can't keep up with it |
| 01:49 | <Hixie> | the entire concept of requiring pages to be non-conforming |
| 01:49 | <Hixie> | is utterly non-sensical |
| 01:50 | <Hixie> | it's like having a minimum speed limit sign with a value higher than the speed limit sign next to it |
| 01:51 | <Dashiva> | The other thing that bugs me is that there seems to be an implicit assumption that AT aren't allowed to use the same techniques on non-conforming pages and conforming pages |
| 01:51 | <Hixie> | or a four way intersection with every exit marked with the "no entry" sign |
| 01:53 | <Dashiva> | (But if you hate people driving cars, that's not so unlikely ;) |
| 01:55 | <Philip`> | Hixie: It's sensical in some cases - e.g. if I want to make a page with tables for layout, then it's required to be non-conforming - so how is the distinction drawn between things that can be done in a conforming way and things that can't? |
| 01:56 | <Hixie> | you're not allowed to make a page with tables for layout |
| 01:56 | <Hixie> | and you should never do so |
| 01:57 | <Hixie> | that differs from this case, where there are people suggesting that in some cases, omitting alt (or giving bad alternate text) is what should happen |
| 01:57 | <Hixie> | despite making it non-conforming |
| 01:58 | <Philip`> | Ah, so it would be consistent if they said that when you want to make a page with omitted alt you should actually not make that page at all |
| 01:58 | <Hixie> | such an argument would not be persuasive |
| 01:59 | <Hixie> | but it would at least be consistent |
| 02:01 | Philip` | thinks "conforming" vs "non-conforming" is not a particularly useful way to look at pages - it's much more useful to look at a list of ways you can improve the quality of your page, and you should be disappointed when there are no suggestions left (because you've reached the limits of the conformance criteria) |
| 02:05 | <Hixie> | Philip`: yeah, maybe. |
| 02:05 | <Hixie> | Philip`: not sure how to formalise that though |
| 02:09 | <Philip`> | Require that conformance checkers have a friendly popup character saying "Hey! You might want to write & instead of & here, to make sure it will never confuse a browser. Click here for a detailed explanation!" instead of a red box saying "Error: Text after & did not match an entity name." |
| 02:09 | <Philip`> | That would help people think of it as advice rather than admonishment |
| 02:11 | <Hixie> | ye-es |
| 02:11 | <Dashiva> | Wouldn't that just raise even more resistance, for "watering out" the concept of conformance? |
| 02:11 | <Philip`> | Hixie: You don't sound convinced :-( |
| 02:17 | <roc> | why don't you just have the checker transform the document to make it transforming |
| 02:17 | <roc> | to make it conforming, I mean |
| 02:27 | <mpt> | because that wouldn't improve the Web |
| 02:27 | <mpt> | because if a checker can do it, a browser can do it too |
| 02:29 | <roc> | the author can check the transformed document to make sure it still matches the author's intent |
| 02:29 | <roc> | browsers can't do that |
| 02:30 | <mpt> | aha |
| 02:31 | <mpt> | That's something that could be tested -- what percentage of authors would bother to check the autocorrected output |
| 02:32 | <roc> | I'm assuming they'd at least view the page |
| 02:32 | <Lachy> | roc, there are utilities that do such things. e.g. HTML Tidy |
| 02:33 | <Philip`> | If it presented the autocorrected document as a big lump of code, they'd be unlikely to check it all; I imagine it wouldn't be nearly so bad if it printed a suggested correction (or several) beside each error message, so authors could use that as a guide for fixing their code semi-manually |
| 02:35 | <mpt> | And for the particular issue of alt text, showing them the page won't help (unless you show it lynx-style) |
| 02:36 | <mpt> | (btw, alt="[A picture of a cat looking at pictures of cats]"? oh dea) |
| 02:36 | <mpt> | r |
| 02:38 | Philip` | guesses that IE8 stopping using alt for tooltips will do a lot to decrease the usage of alt |
| 02:40 | <mpt> | iirc Microsoft's reasoning for doing alt= as tooltip in the first place was to increase use of alt= |
| 02:40 | <mpt> | (in IE3, I think it was) |
| 02:41 | <mpt> | at which it undoubtedly succeeded, but with the wrong sort of contents |
| 02:41 | <Dashiva> | Oh, what wicked webs we weave |
| 02:41 | <mpt> | and it's been a long, slow walk back |
| 02:42 | <Dashiva> | Maybe some more focus should be put on @importantimage (or @realalt) |
| 02:42 | <Philip`> | It does make sense to make metadata visible, so that people actually notice it and use it |
| 02:42 | <mpt> | title= is metadata. alt= is data. ;-) |
| 02:43 | <Philip`> | I'd say the data is the image :-) |
| 02:43 | <mpt> | That's alternative data |
| 02:43 | <Dashiva> | Is invisible data worse or less bad than invisible metadata? |
| 02:43 | <Philip`> | The alt text is describing the image data, hence it's metadata |
| 02:43 | <Philip`> | (for a loose sense of 'describing') |
| 02:44 | <mpt> | Minus 5 points for using "describing" and "alt text" in the same sentence |
| 02:44 | <Philip`> | Dashiva: Invisible data is usually SEO spam, so it's bad |
| 02:46 | <Dashiva> | wget needs an AI mode to detect which URLs with get parameters are duplicates, and which are successive pages of multipage content |
| 02:48 | <Dashiva> | (I just now stopped a gallery download at 600 MB, and discovered only 20 MB of it was images) |
| 02:57 | mpt | imagines a world full of blind people, and search engines that only understand images, not text |
| 02:58 | Philip` | can't imagine who is publishing those images in such a world |
| 02:58 | <Dashiva> | mpt: Couldn't you just take a screenshot of the text you wanted and search for that? :) |
| 03:03 | <mpt> | Dashiva, right, and then Google gets confused by all the SEO spam images that contain that word, while human visitors see only the text |
| 03:04 | <mpt> | (or hear, rather) |
| 03:07 | <Philip`> | Hmph, the page I found a while ago with a 10KB alt attribute on an image has been changed and no longer has that image :-( |
| 03:17 | <mpt> | A picture is worth a thousand decabytes? |
| 03:34 | <Lachy> | I have to find a way to work some of these into the presentaion :-) http://icanhascheezburger.com/tag/html/ |
| 08:39 | <Hixie> | wow, the e-mail i just sent was a reply to 41 e-mails of spiralling confusion |
| 08:48 | <hsivonen> | Hixie: IIRC Maciej said Safari uses QuickTime on Windows |
| 08:48 | <Hixie> | the details don't matter in this particular instance |
| 08:50 | <mcarter> | I wonder how many people in here reside somewhere near silicon valley? I don't suppose you guys ever get together for an html5 lunch? |
| 08:51 | <Hixie> | i'm in mountain view and would be up for #whatwg social outings, so long as i don't have to organise them :-) |
| 08:51 | <Hixie> | it hasn't happened so far though |
| 08:51 | <Hixie> | a number of us are in the area |
| 08:51 | <mcarter> | hmm, I'm in mountain view more than half the time |
| 08:52 | <mcarter> | I'll see about putting together a wiki somewhere for a social meeting |
| 08:52 | <mcarter> | i finally conquered IE tonight.. that is, just got sse working in IE with only a small caveat or two for a server-side implementer |
| 08:53 | <Hixie> | nice |
| 08:54 | <mcarter> | there's apparently no way to keep IE from downloading things that don't have content-type "text/html" or "text/plain", as far as I can tell |
| 08:54 | <Hixie> | as in it pops up a dialog box? |
| 08:54 | <Hixie> | when doing what? |
| 08:54 | <Hixie> | surely image/jpeg doesn't get downloaded |
| 08:54 | <mcarter> | well, i meant as an iframe src |
| 08:55 | <Hixie> | yeah i always hate it when browsers cause you to download stuff when an _iframe_ has content that isn't supported |
| 08:55 | <Hixie> | that's just dumb |
| 08:55 | <Hixie> | though i may have made html5 require that behaviour. oops. i'll have to check that out. |
| 08:55 | <mcarter> | i never noticed it until i tried to implement this sse stuff for IE |
| 08:56 | <mcarter> | I can't think of any other way to do it then to locally poll a plain text iframe, and parse the contents |
| 08:58 | <mcarter> | you can expect that feedback for TCPConnection on friday... particularly now that I've got a working demo |
| 08:58 | <mcarter> | and with that, i'm off to bed (do you ever sleep?) |
| 09:00 | <Hixie> | cool, nn |
| 09:00 | <Hixie> | i sleep around 4am - 1pm |
| 09:13 | <Philip`> | Hixie: "the ratio of the correct rendered width of each pixel to the actual width of each pixel in the image (i.e., the multiple by which the video's intrinsic width must be multiplied to obtain the rendered width that gives the correct aspect ratio)" - that seems like an abuse of the word "must" |
| 09:14 | <Hixie> | oops |
| 09:14 | <Hixie> | will fix |
| 09:25 | <Lachy> | Hixie, which video formats require pixelratio="" in the markup? |
| 09:26 | <Hixie> | h.263, at least |
| 09:26 | <Lachy> | ok. |
| 09:26 | <Hixie> | youtube also suggested it so that misencoded videos (very common apparently) can be fixed up without reencoding them (since that's really expensive) |
| 09:26 | <Lachy> | I thought all that info would have been specified in the container format, if not in the codec itself. |
| 09:26 | <Hixie> | yeah, me too |
| 09:27 | <Hixie> | i pushed back on it quite a bit but apparently anamorphic videos are quite common and common formats don't handle them |
| 09:27 | <Lachy> | wow. I thought only DVDs used anamorphic content, since they needed to scale to fit 4:3 and 16:9 TVs. |
| 09:27 | <Hixie> | Philip`: fixed |
| 09:28 | <Hixie> | intentionally anamorphic video is common in professional workflows |
| 09:28 | <Lachy> | ok |
| 09:28 | <Hixie> | when i was an amateur projectionist at university we had to deal with anamorphic lenses all the time for both 16mm and 35mm movies |
| 09:28 | <Hixie> | but pixelratio is more intended for misencoded videos |
| 09:29 | <Hixie> | they also asked for things like fixing up brightness and contrast, but i figured css filters were a better solution to that |
| 09:29 | <Hixie> | the last thing they really asked for which i thought made sense was a way to detect if the UA was throttling the download speed |
| 09:30 | <Lachy> | I thought youtube reencoded all videos anyway, since it has to convert them all to the right format for flash |
| 09:30 | <othermaciej> | how are you supposed to detect that? (the UA just admitting it?) |
| 09:30 | <Hixie> | right |
| 09:30 | <othermaciej> | why do they want to know that? |
| 09:30 | <Hixie> | video.throttling or video.isDownloadThrottled were the two proposals i had for attribute names |
| 09:31 | <othermaciej> | is it more useful info than whether a firewall or a traffic shaping kernel module are throttling the download speed? |
| 09:31 | <Hixie> | othermaciej: the spec allows UAs to artificially throttle downloads to prevent videos from being downloaded until the user wants them |
| 09:32 | <othermaciej> | Hixie: I guess I am asking what the use case for this information is |
| 09:32 | <Hixie> | othermaciej: but the argument is that video players (such as youtube's) aren't going to want to be sitting there saying "bandwidth too low! stalled!" when in fact it's just the UA that's blocking the download |
| 09:32 | <Hixie> | since they'd look silly :-) |
| 09:32 | <Hixie> | better to be able to say "download paused" in some way |
| 09:33 | <othermaciej> | in WebKit what we would likely do is load right away but not play the video until the user switches to that tab (if autoplay is set and it is in a background tab) |
| 09:34 | <Hixie> | (actually the throttling feedback was from the google video team's experience, not youtube. but there's little practical difference these days.) |
| 09:35 | <Hixie> | othermaciej: right but some people want to be able to tell their UA to just not download the video at all yet, or to stop downloading it |
| 09:35 | <Hixie> | the example given in this e-mail was a 3 hour clip on google video, where the user wants to stop the download after 5 minutes are downloaded |
| 09:35 | <Hixie> | so he right clicks and chooses "pause download" or whatever the UA (probably opera) provides |
| 09:36 | <Hixie> | now google video's player doesn't want to say "eep! your connection died!" it just wants to say "(download paused)" |
| 09:36 | <othermaciej> | so is throttled just supposed to represent stopping/pausing the load, or does anyone actually want to keep loading but at reduced bandwidth? |
| 09:37 | <othermaciej> | (not sure we care about a way to stop short of closing the page but that seems like at least conceivably a good idea) |
| 09:38 | <Hixie> | well the spec already provides the bits-per-second-over-the-last-few-seconds information (bufferingRate) so you could distinguish the two cases (paused vs throttled) by seeing if that number was non-zero |
| 09:38 | <Hixie> | <Hixie> well the spec already provides the bits-per-second-over-the-last-few-seconds information (bufferingRate) so you could distinguish the two cases (paused vs throttled) by seeing if that number was non-zero |
| 09:39 | <Hixie> | and i'd be shocked if opera didn't want to support precise control over the download rate |
| 09:39 | <othermaciej> | sorry about the flaky connection here |
| 09:39 | <othermaciej> | really? does opera have download rate controls for other things? |
| 09:39 | <Hixie> | opera has ui to do everything under the sun |
| 09:39 | othermaciej | tries not to actually use Opera's UI when testing in it |
| 09:42 | <Hixie> | ok bufferingThrottled is probably the value that most closely fits in with the existing API |
| 09:43 | <Hixie> | i wish other video sites had sent feedback |
| 09:46 | <Hixie> | crap, that's all the video feedback i had |
| 09:46 | <Hixie> | that means <iframe> is next |
| 09:48 | <Hixie> | good |
| 09:48 | <Hixie> | ak |
| 09:49 | <hsivonen> | http://lists.w3.org/Archives/Public/wai-xtech/2008May/0163.html |
| 10:00 | <Hixie> | hsivonen: http://1997.webhistory.org/www.lists/www-talk.1993q1/0262.html |
| 10:00 | <Hixie> | http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html specifically |
| 10:01 | <Hixie> | wow, guido was involved in the web early |
| 10:01 | <hsivonen> | Hixie: thanks |
| 10:02 | <Hixie> | tbl's original reply to <img>: http://1997.webhistory.org/www.lists/www-talk.1993q1/0186.html |
| 10:03 | <othermaciej> | shades of his turn to the dark side |
| 10:03 | <Hixie> | that message contains the first example of alternate text, btw, as far as i can tell from his vague description of how it should work, except that it is terible alternate text if so... |
| 10:05 | <Hixie> | i don't think he realised that's what it was for though, or at least he didn't mention it was for that |
| 10:06 | <Hixie> | thank goodness we didn't go down THIS path http://1997.webhistory.org/www.lists/www-talk.1993q1/0202.html |
| 10:07 | <othermaciej> | img is so much better than either of those options |
| 10:07 | <Hixie> | ok i can firmly say that there is absolutely nothing in that thread talking about alternatives to visual media |
| 10:07 | <othermaciej> | (though with benefit of hindsight we might prefer if it had spelled out "image" and not been a void element) |
| 10:08 | <Hixie> | ooo, while we're at it: DanC saying that "most of the technical issues in the HTML spec have been ironed out": http://1997.webhistory.org/www.lists/www-talk.1993q1/0041.html |
| 10:09 | Hixie | notes that FIFTEEN YEARS LATER we're still fixing issues that were relevant and not resolved back then |
| 10:11 | <Philip`> | http://1997.webhistory.org/www.lists/www-talk.1993q3/0985.html |
| 10:11 | <Philip`> | Oh, http://1997.webhistory.org/www.lists/www-talk.1993q3/0461.html seems earlier |
| 10:13 | Philip` | doesn't see any earlier references on that site |
| 10:17 | <Hixie> | so it took 6 months for someone to suggest alt="", and even then it was for text browsers not blind users |
| 10:17 | <Hixie> | heh |
| 10:17 | <Hixie> | bolt-on indeed |
| 10:17 | <Philip`> | http://1997.webhistory.org/www.lists/www-talk.1993q3/0995.html would have been a nicer way of doing it |
| 10:18 | <Hixie> | yep |
| 10:18 | <Hixie> | the funny thing about that (which is what <object> does, btw) is that there is no way to omit vs not omit the alt attriute |
| 10:19 | <Hixie> | which means there's no way to distinguish inaccessible images from decorative images |
| 10:20 | <Lachy> | Hixie, re this comment from a few days ago "<Hixie> i think for explaining <meter> better we should have some pictures of gagues", I have such images that I used in a previous presentation, if you want them. |
| 10:20 | <Hixie> | sure! |
| 10:21 | <Lachy> | they're in these powerpoint slides. http://lachy.id.au/dev/presentation/developing-with-html5/ - I can send you the originals when I get home later this evening |
| 10:32 | <tomg> | ohh, http://code.google.com/doctype/ is nice |
| 10:35 | Philip` | didn't see much on it other than invalid HTML, failure to work in Opera, incorrect test results, and advocacy of yet another JavaScript library, but maybe he was looking too cynically :-) |
| 10:36 | <Hixie> | ooo, ppt opens in keynote |
| 10:36 | <Hixie> | Philip`: send comments to mark pilgrim :-) |
| 10:37 | <Philip`> | Hixie: I don't have any comments much more constructive than "the site doesn't work, and when it does work it's wrong" :-p |
| 10:37 | <Hixie> | :-) |
| 10:37 | <tomg> | iWork is brilliant |
| 10:37 | <hsivonen> | notes that Google is breaking the Web by moving addressing after the hash |
| 10:38 | <Hixie> | Lachy: i only saw one <meter> in that ppt and it was a rating example, not a gauge :-) |
| 10:39 | <Hixie> | hsivonen: yeah, i'm not a huge fan of that either |
| 10:40 | <Lachy> | I have others that weren't used in the presentation. I may have a gauge at home. |
| 10:40 | <Lachy> | if not, I'll make one. |
| 10:40 | <Hixie> | cool :-) |
| 10:41 | <hsivonen> | I wonder how Google search is going to index Google docreader using public HTTP spidering |
| 10:42 | <hsivonen> | that is, if someone else writes a similar reader, what happens to Web search? |
| 10:42 | <Philip`> | http://www.google.com/search?q=inurl%3Acode.google.com%2Fdocreader |
| 10:42 | <Philip`> | I think the answer to how it'll index it is "not very well" |
| 10:42 | <Hixie> | you don't have to use the ajax reader |
| 10:42 | <Hixie> | there's a separate view of the wiki that isn't ajax |
| 10:43 | <hsivonen> | Hixie: what if people out there link to the ajax reader? |
| 10:43 | <Hixie> | then the links don't contribute pagerank |
| 10:43 | <Hixie> | i didn't say it was a good idea :-) |
| 10:43 | <Hixie> | i was just providing further information |
| 10:43 | <hsivonen> | ok :-) |
| 10:44 | <Philip`> | Is there a way to access the non-AJAX version without disabling JS or copying-and-pasting the non-JS URL? |
| 10:45 | <Hixie> | i don't believe there are any links on http://code.google.com/doctype/ that don't rewrite themselves to point to the ajax reader, no |
| 10:45 | <Hixie> | but i don't know |
| 10:45 | <Hixie> | open in new tab seems to work |
| 10:46 | <tomg> | sigh. could someone throw away the british rail network please. |
| 10:46 | Philip` | notes that Googlebot follows <a href="window.location='foo'"> links, and seemingly no other search engine does |
| 10:47 | <Philip`> | Uh |
| 10:47 | <Philip`> | <a href="javascript:..."> |
| 10:48 | <Hixie> | how cunning of us |
| 10:48 | <Philip`> | as well as following any strings in <script>s that start with a '/' character, even if they're commented out |
| 10:49 | <Philip`> | (where 'strings' means quote-delimeted strings) |
| 10:49 | <Philip`> | s/incorrect spelling/correct spelling/ |
| 10:49 | <Hixie> | really? |
| 10:49 | <Hixie> | that seems like a bug |
| 10:49 | <Hixie> | do you have a test page showing this? |
| 10:52 | <virtuelv> | Philip`: does that mean it's possible to DoS googlebot? |
| 10:54 | <Philip`> | Hixie: http://canvex.lazyilluminati.com/bottest.html and http://canvex.lazyilluminati.com/bottest2.html and http://canvex.lazyilluminati.com/bottest3.html |
| 10:55 | <hsivonen> | I noticed that XTech caused me to forget to rerun the monthly V.nu stats for April |
| 10:55 | <Philip`> | and my logs show requests from Googlebot for http://canvex.lazyilluminati.com/misc/bottest-requests.txt |
| 10:57 | <Hixie> | Philip`: that's really odd |
| 10:57 | <Hixie> | Philip`: i've seen the code that picks urls and i don't understand how you re getting those results |
| 10:58 | <Philip`> | Oh, there's also NextGenSearchBot following all the links except for /1 on bottest3.html |
| 10:58 | <Philip`> | but that's the only one |
| 10:59 | <hsivonen> | hmm. I think Gez's latest email can lead to constructive discussion |
| 11:00 | <hsivonen> | but before I reply, I think I should write some code |
| 11:00 | <hsivonen> | because otherwise the mailing list will starve my code writing tasks |
| 11:00 | <Philip`> | Hixie: Well, don't ask me :-p |
| 11:04 | <hsivonen> | it's a shame that Google doctype doesn't have Opera 9.5 in its test matrix |
| 11:05 | hsivonen | didn't know <plaintext> had @align |
| 11:05 | <tomg> | yes |
| 11:05 | <Hixie> | hsivonen: it's a wiki :-D |
| 11:06 | <Hixie> | though, is 9.5 out yet? |
| 11:06 | <othermaciej> | Google doctype says some things that seem wrong |
| 11:06 | <hsivonen> | Hixie: FF3 isn't either |
| 11:06 | <tomg> | or IE8 :) |
| 11:07 | <othermaciej> | http://code.google.com/docreader/#p(doctype)s(doctype)t(DocumentParentWindowProperty) |
| 11:07 | <othermaciej> | I don't think it is correct to claim that no browser implements it |
| 11:07 | <othermaciej> | or rather, if that is true, why is it documented at all? |
| 11:08 | <othermaciej> | but I am pretty sure IE does actually in fact support it |
| 11:09 | <tomg> | as does Opera |
| 11:09 | <othermaciej> | also it seems odd that the DOM reference includes vendor extensions but the CSS reference seemingly does not |
| 11:09 | <othermaciej> | (except for broken vendor extensions that aren't prefixed) |
| 11:10 | <Hixie> | hsivonen: fair enough |
| 11:11 | <Hixie> | othermaciej: it's a wiki, feel free to edit it :-) |
| 11:11 | <othermaciej> | so 'accelerator', 'behavior' and 'layer-background-image' are included but not -webkit-box-shadow |
| 11:11 | <tomg> | can you add pages? |
| 11:11 | <Hixie> | othermaciej: i assume CSS stuff will be added in due course |
| 11:11 | <Hixie> | tomg: sure |
| 11:11 | <tomg> | oh yes |
| 11:11 | <othermaciej> | I certainly do not have the personal resources to do research on CSS properties |
| 11:11 | <Hixie> | othermaciej: as far as i know there's no policy to exclude prefixed extensions |
| 11:11 | <tomg> | that'll be the New Page link then ;) |
| 11:11 | <Hixie> | othermaciej: yeah join the club :-) |
| 11:12 | <tomg> | it'll be good to document Opera and WebKit stuff |
| 11:12 | <tomg> | they are both really lacking in documentation |
| 11:12 | <othermaciej> | it would be handy if it were marked which are part of what standard (if any) in addition to listing browser support |
| 11:13 | <othermaciej> | is there a bug tracker other than "it's a wiki, you can edit it"? |
| 11:13 | <tomg> | heh |
| 11:13 | <tomg> | yes it really needs a mass-import of DOM references and APIs |
| 11:14 | <Philip`> | Is there any HTML element for which the browser compatibility table is correct? |
| 11:14 | <othermaciej> | because I am willing to file bugs but not willing to do the research to personally fix them |
| 11:14 | <Philip`> | tomg: Why import, rather than just linking to MDC? |
| 11:14 | Philip` | prefers not having too many sources for the same information |
| 11:15 | <tomg> | er, because the MDC is for Gecko? |
| 11:16 | <othermaciej> | funny that someone made automated test cases for all of these but did not make the compat tables match |
| 11:16 | <tomg> | you'd have thought with making a cross-browser reference you'd want to at least start with a page about every CSS extension |
| 11:17 | <Philip`> | tomg: The MDC is (mostly) for standards, and the DOM references and APIs should be for standards too |
| 11:17 | <othermaciej> | tomg: wow, the html element tables are so wrong it is scary |
| 11:17 | <tomg> | yes |
| 11:18 | <othermaciej> | I love the one for the <video> element |
| 11:18 | <tomg> | errrrrrrrr |
| 11:18 | <tomg> | that needs some amending |
| 11:19 | othermaciej | wonders if "giant repository of incomplete and largely wrong information" is a useful service |
| 11:19 | <othermaciej> | but then again, people find wikipedia useful |
| 11:20 | <Philip`> | Are all the compatibility tables hard-coded into the wiki pages, so there's no way to run tests automatedly and update the tables? |
| 11:20 | <Hixie> | othermaciej: yeah, there's an issues database |
| 11:20 | <tomg> | nothing supports <video> does it> |
| 11:20 | <othermaciej> | Safari 3.1 supports <video> |
| 11:20 | <tomg> | oh. |
| 11:20 | <tomg> | yes |
| 11:20 | <othermaciej> | also supports styling it |
| 11:21 | <Hixie> | othermaciej: http://code.google.com/p/doctype/issues/list |
| 11:21 | <tomg> | that's the only one |
| 11:21 | <Hixie> | http://code.google.com/p/doctype/issues/entry to file a new one |
| 11:21 | <othermaciej> | Hixie: thanks |
| 11:22 | <Hixie> | Philip`: thanks for the links, i have learnt something new about google that i didn't before. :-) |
| 11:30 | <hsivonen> | Hixie: you aren't acking the self-closing flag on isindex. Why is that? |
| 11:30 | <Hixie> | isindex isn't valid anyway |
| 11:30 | <hsivonen> | so why produce one more error? |
| 11:30 | <Hixie> | you don't have to show it :-) |
| 11:31 | <Hixie> | if you want the spec changed send mail |
| 11:31 | <Hixie> | i don't really have a strong opinion |
| 11:31 | <Hixie> | i just didn't want to ack anything that wasn't valid |
| 11:31 | <hsivonen> | making the delta between normative and shown errors bigger is not nice for interoperable test cases |
| 11:31 | <Hixie> | (there's no real good reason for such wants) |
| 11:31 | <hsivonen> | you ack wbr |
| 11:31 | <Hixie> | doesn't wbr come along with a bunch of valid elements? |
| 11:32 | <Hixie> | as far as i recall i just did whatever was the smallest change |
| 11:34 | <hsivonen> | email sent |
| 11:35 | <annevk> | wbr should become valid anyway :) |
| 11:35 | <annevk> | or maybe just nobr, hmm |
| 11:35 | <hsivonen> | that too |
| 11:36 | <hsivonen> | speaking of test cases and the self-closing flag, we need to change the tokenizer test format |
| 11:36 | <hsivonen> | for backwards compat, we probably should make self-closing appear in JSON only when true |
| 11:36 | <annevk> | wtf is up with this ARIA debate |
| 11:37 | <annevk> | "Next steps for the ARIA syntax discussion" |
| 11:37 | <Hixie> | i think the next step is called "shipping" |
| 11:37 | <hsivonen> | lol |
| 11:38 | <hsivonen> | also, do we want test cases to track the self-closing flag on end tag tokens? |
| 11:38 | <annevk> | yeah, maybe it's better to not reply for a month or so than put energy into this |
| 11:39 | <Hixie> | i was telling hsivonen earlier that my recommendation is just to reply to the tag e-mail, quoting just the part that suggests a colon, and say, basically: "we have a requirement that the same script access to the attribute value work in XML and HTML without syntactical differences in the markup. this doesn't address that requirement." |
| 11:39 | <Hixie> | in no more than one paragraph |
| 11:39 | <Hixie> | without any fluff |
| 11:42 | <annevk> | "But I am also in the small minority of HTML authors who have read the spec and try to follow it." after he just said that <b> and <i> are obsolete and you need to use <span> instead... |
| 11:43 | <othermaciej> | if Google actually uses this bogus UA check code internally then I am very afraid: http://code.google.com/docreader/#p(doctype)s(doctype)t(ArticleUserAgent) |
| 11:46 | <hsivonen> | did someone already put hendry's vim script on the WHATWG wiki? |
| 11:48 | <Hixie> | othermaciej: what's wrong with it? |
| 11:48 | <othermaciej> | well, I filed a bunch of things I found wrong here: http://code.google.com/p/doctype/issues/detail?id=8 |
| 11:49 | <othermaciej> | I would expect there are also mistakes relating to browsers where I am less familiar with the UA string |
| 11:49 | <annevk> | Hixie, the blacklist is in AC as well for the theoretical case of another spec wanting to do something similar to XHR |
| 11:50 | <Hixie> | annevk: like what? |
| 11:50 | <annevk> | another type of XMLHttpRequest |
| 11:51 | <Hixie> | othermaciej: oh, those aren't major issues |
| 11:51 | <Hixie> | othermaciej: i thought you'd found major problems :-) |
| 11:51 | <annevk> | I don't think we should have that, but the spec could handle it in theory |
| 11:51 | <othermaciej> | using indexOf() to implement the check is pretty bad |
| 11:51 | <othermaciej> | as is identifying Safari as "khtml" |
| 11:51 | <annevk> | that's why the spec also defines the preflight request itself, etc. |
| 11:51 | <Hixie> | annevk: i don't understand why you'd ever want to allow all headers on an author-controlled cross-domain request |
| 11:52 | <Hixie> | othermaciej: *shrug* it doesn't break anything though |
| 11:52 | <annevk> | Hixie, but then we'd be stuck with Accept and Accept-Language ... |
| 11:53 | <Hixie> | othermaciej: i agree it's not perfect, don't get me wrong; but it's not stop-ship or anything |
| 11:53 | <Hixie> | annevk: so? we are anyway, no? |
| 11:53 | <annevk> | the current proposal handles arbitrary headers |
| 11:53 | <annevk> | though it requires a preflight request for those not in the whitelist nor in the blacklist |
| 11:53 | <annevk> | in the GET case |
| 11:54 | <othermaciej> | it's also pretty sloppy code in general |
| 11:54 | <othermaciej> | certainly not worthy of being held up as an example |
| 11:55 | <annevk> | hmm |
| 11:55 | <annevk> | Jonas' second case might be solved by simply converting \ to / |
| 11:56 | <annevk> | which I think is what some UAs already do... |
| 11:56 | <othermaciej> | if the utility functions are really used by google then they make good fodder for possibly APIs to add as native |
| 11:59 | <hendry> | hsivonen: not from the recent changes page i can see |
| 12:01 | <Hixie> | <Hixie> othermaciej: i agree it's not perfect, don't get me wrong; but it's not stop-ship or anything |
| 12:01 | <Hixie> | i agree it's not good sample code, certainly |
| 12:02 | <Hixie> | but this is just the first release :-) |
| 12:02 | <othermaciej> | I am guessing (perhaps wrongly) that since this stuff has goog.whatever all over it that it comes from some internal code snippet repository |
| 12:02 | <othermaciej> | thus I hope fixes make it back to the original |
| 12:03 | <othermaciej> | Hixie: I have found much more bogus UA checks in Google apps before though, so I guess it could be worse |
| 12:03 | <Hixie> | annevk: wait so you _can_ set arbitrary headers? i thought it was excluively whitelist limited. |
| 12:03 | <Hixie> | othermaciej: i don't know if this stuff is from a particular widely used framework, actually |
| 12:03 | <Hixie> | particularly |
| 12:04 | <BenMillard> | Lachy, on 13th May 2008 you wrote "what we really need for the alt discussion to get somewhere is a study that looks at the reasons why people use alt="" or alt="bogus, validator friendly content" or whatever. The difficulty is in figuring out how to perform such a study" -- http://krijnhoetmer.nl/irc-logs/whatwg/20080513#l-546 |
| 12:04 | <annevk> | Hixie, yes you can |
| 12:04 | <Hixie> | annevk: oh. then nevermind, the blacklist does take effect. |
| 12:04 | <annevk> | Hixie, hence the proposal from Jonas I guess to restrict it somehow to only what the server allows |
| 12:04 | <BenMillard> | Lachy, the approach I used for Collections of Interesting Data Tables could fit that? http://sitesurgeon.co.uk/tables/ |
| 12:04 | <othermaciej> | (I recall one trying to identify Safari based on having document.contains and lacking some method on element, which broke when we moved contains() from Node to Element to match IE) |
| 12:05 | <Hixie> | othermaciej: heh |
| 12:05 | <othermaciej> | Hixie: the sad thing is that it was then using this weird way of detecting Safari to make assumptions about completely unrelated things, like which editing APIs are present |
| 12:06 | <Hixie> | that's sad |
| 12:06 | <othermaciej> | I think someone got the idea that capability testing is better than UA testing but the message got garbled in transmission |
| 12:06 | <Hixie> | yeah really |
| 12:15 | <Lachy> | they were probably trying to work around the problem of browsers lying about user agent strings. But such detection is only necessary when you actually want to use the APIs your testing for. |
| 12:18 | <Lachy> | BenMillard, it could work. But, as I said a few minutes after that, how do you determine an authors reasons based solely upon what they did? |
| 12:20 | <hsivonen> | Lachy: you hire an economist :-) |
| 12:20 | <Lachy> | if the hypothesis is that validators insisting upon the alt attribute encourage people to simply make the validator happy, then what predictions can be made from that, which can be tested? |
| 12:20 | <Dashiva> | Lachy: That some useful images will have alt="" |
| 12:21 | <Dashiva> | (and alt="image" and alt="alt" and alt="stop bothering me stupid validator I hate accessibility" :) |
| 12:21 | <BenMillard> | Lachy, e-mailing every author whose markup I collect to ask why they did it that way might actually work, although I understand hsivonen's reservations about that |
| 12:22 | <BenMillard> | but what authors actually do is more relevant than why they do it, imho |
| 12:24 | <Lachy> | BenMillard, no, why they do it is more relevant when trying to defend a position that is itself a reason for why |
| 12:24 | <Lachy> | we already know roughly what authors do |
| 12:25 | <hsivonen> | you could ask people why in the hope that one of them does not lie |
| 12:25 | <hsivonen> | then you mitigate the risk of you not inventing all possible reasons |
| 12:26 | <hsivonen> | but once you have an array of possible reasons, you need to test if the actual behavior matches |
| 12:26 | <Hixie> | <iframe src="data:text/html,<!DOCTYPE HTML> <p>Hello <p title="cruel" <p>World"></iframe> |
| 12:27 | <Hixie> | that wouldn't be too bad, you'd only have to escape &, ", and maybe '. |
| 12:27 | <BenMillard> | hsivovnen, that makes sense |
| 12:27 | Hixie | is looking for ways to use iframe to embed comments without an http request and without it being ugly and unmaintainable (e.g. base64) |
| 12:28 | <Hixie> | othermaciej: dude, what's up with your network? i'd go batty if my ssh connections kept dropping |
| 12:28 | <BenMillard> | lachy & hsivonen, it's a question of whether the sponsorship I hope to get will cover that kind of work. hopefully it will, if it's useful to HTML5 accessibility |
| 12:30 | <Lachy> | maybe, instead of just asking "Why do you insert alt text?", which is very subject to lying, what if we instead presented a page to web developers and asked them to fix it, without actually telling them we're looking specifically at alt text. |
| 12:31 | <BenMillard> | Lachy, I don't understand what you and hsivonen mean by authors lying in this context |
| 12:32 | <Lachy> | We include a whole bunch of different errors, including several missing alt, then they have to fix the errors in the best way they can.. |
| 12:32 | <Hixie> | Lachy: what are we trying to learn? |
| 12:32 | <Lachy> | we're trying to learn what alt text use and *why* they use it. |
| 12:33 | <Hixie> | ah, interesting |
| 12:33 | <Hixie> | i predict most use it because they learnt that they were supposed to |
| 12:33 | <Hixie> | and that they forget to do so half the time :-) |
| 12:33 | <Hixie> | and have no idea how to do a good job |
| 12:33 | <Lachy> | so if validation is all they're trying to achieve, then we would expect authors to simply insert alt="" or alt="bogus". But if they actually care about accessibility, we would get real alt text |
| 12:34 | <BenMillard> | Hixie & Lachy, we can make educated guesses easily enough |
| 12:34 | <BenMillard> | part of my commercial work is retrofitting accessibility and training authors; usually they don't know alt even exists |
| 12:34 | <Hixie> | Lachy: anecdotally, it seems that they try (and mostly fail) to use it for its intended purpose |
| 12:35 | <Hixie> | BenMillard: indeed |
| 12:36 | <BenMillard> | I think Lachy is suggesting a more scientific (with a small "s") way to figure out what reasons are common and uncommon, along with typical levels of alt text quality |
| 12:36 | <Lachy> | there's still a few problems with my ideas. How do we set up appropriate controls and elimiate as many other issues as possile |
| 12:36 | <Lachy> | *possible |
| 12:36 | <Lachy> | BenMillard, I'm trying to make it as scientific as possible. Obviously, it needs improvement |
| 12:38 | <BenMillard> | Lachy, selection bias is an issue. anything that requires voluntary work (like correcting a sample page) will get bloggers, students, a few standardistas and maybe some HTML4all type peeps but no mainstream authors |
| 12:39 | <annevk> | hmm, copying over what HTML5 currently says does not seem like a good solution |
| 12:39 | <annevk> | and there's nothing else |
| 12:40 | <Lachy> | BenMillard, the sample only needs to consist of people who actually care about validation. People who don't care about validation are irrelevant, since they won't be affected by what the validator says. |
| 12:40 | <hsivonen> | Lachy: unless you are looking for spillover effects |
| 12:40 | <BenMillard> | Lachy, that doesn't quite match my experience. |
| 12:40 | <Lachy> | but there's still selection bias problems if we inadvertenly get a lot of people who care a lot about accessibility |
| 12:41 | <zcorpan> | couldn't it be possible to search in forums for people who ask about the alt attribute in the context of validation? although that only catches authors who validate *and ask*, not authors who validate and "fix" without asking |
| 12:41 | <Lachy> | so we would need some way of measuring the experience of each subject |
| 12:41 | <zcorpan> | but could still be interesting to look into |
| 12:41 | <BenMillard> | Lachy, I find websites (particularly in the public section) who "need" to comply with standards, hence validate, but whose developers don't really care about validation or accessibility |
| 12:41 | <Lachy> | cool, then they might be the kind of people we should target |
| 12:42 | <BenMillard> | zcorpan, I've considered collecting tutorials, forum topics, blog entries, national standards and suchlike to analyse where they contradict and where they line up |
| 12:45 | <Hixie> | this is one case where it would be important to define the predictions and how to determine whether they are right or not before collecting any data, i think |
| 12:45 | <zcorpan> | BenMillard: ok, cool |
| 12:45 | <Lachy> | Hixie, indeed |
| 12:46 | <Hixie> | ok bed time |
| 12:46 | <Hixie> | nn |
| 12:48 | <hsivonen> | nn |
| 12:49 | <annevk> | Hixie, the loadstart thing was called out some time ago |
| 12:49 | <annevk> | Hixie, and you said back then it didn't match the semantics of HTML5 video that well so you used a different name intentionally |
| 12:54 | annevk | wonders if the other Philip TAYLOR realizes he's alerting a string |
| 12:54 | <annevk> | (rather than testing any of the assertions made) |
| 13:01 | <annevk> | (i was wrong about Hixe saying something about loadstart above) |
| 13:03 | <Lachy> | a more accurate test case: javascript:<!--alert("FAIL");%0Aalert("PASS"); |
| 13:04 | <zcorpan> | annevk: btw, some of the tests on tc.labs rely on reparsing |
| 13:07 | <Lachy> | HTML4.01 states "The JavaScript engine allows the string "<!--" to occur at the start of a SCRIPT element, and ignores further characters until the end of the line. JavaScript interprets "//" as starting a comment extending to the end of the current line. This is needed to hide the string "-->" from the JavaScript parser." |
| 13:07 | <Lachy> | but it doesn't make any normative reference to any spec for JS or ECMAScript |
| 13:08 | <Lachy> | so that statement was probably just based on defacto behaviour back then too |
| 13:09 | <annevk> | zcorpan, ah, I guess I forgot about that when writing the tests, feel free to fix |
| 13:09 | <othermaciej> | the ES4 folks were reluctant to add an actual specification for <!-- comments |
| 13:09 | <othermaciej> | or at least Brendan was |
| 13:09 | <Lachy> | oh. why? |
| 13:10 | <Lachy> | is it supported in any JavaScript engines that are used outside of HTML? |
| 13:10 | <annevk> | I think it's because ES has use cases beyond the Web and therefore Web influences should be limited or something |
| 13:10 | <Lachy> | what about in ActionScript (which I think is based on ECMAScript) |
| 13:10 | <annevk> | I'm not entirely sure I like that approach. Fortunately CSS does define handling of <!-- and --> |
| 13:12 | <Lachy> | if it's not specced in ECMAScript and only applies to HTML+JS implementations, then maybe HTML5 should require support for it somehow |
| 13:16 | <annevk> | I think it is supported in the ES runtime as it works in external files too |
| 13:17 | <Lachy> | annevk, which ES runtime implementation are you referring to? |
| 13:19 | <hsivonen> | I'm thinking I may not want to be specwise correct on the handling of xmlns attributes |
| 13:22 | <Lachy> | hsivonen, in what way do you want to handle them differently? |
| 13:22 | <Lachy> | do you want to flag them with warnings? |
| 13:23 | <hsivonen> | Lachy: I think I want to drop them on the floor and synthetize ns mappings upon ns context change |
| 13:23 | <hsivonen> | which is what I do with <html> now |
| 13:34 | <Lachy> | how does that differ from the spec? I thought xmlns was ignored in text/html for the purposes of determining an element's namespace? |
| 13:34 | <Philip`> | Opera 9.2 doesn't treat <!-- the same as // |
| 13:34 | <Philip`> | (but 9.5 does seem to) |
| 13:34 | <Lachy> | although, I'm not really familiar with the mathml parsing section |
| 13:41 | <hsivonen> | Lachy: the spec says you put the xmlns attributes into the DOM instead of throwing them away and generating new clean ones |
| 13:52 | <annevk> | replied to the TAG crap |
| 13:56 | <annevk> | http://www.w3.org/mid/op.ua64w7nk64w2qv⊙aooc |
| 13:59 | <hsivonen> | annevk: thank you! |
| 14:04 | <zcorpan> | annevk: indeed, thanks |
| 14:05 | <zcorpan> | Philip`: how does 9.2 treat <!-- differently from // ? |
| 14:07 | <Philip`> | zcorpan: Hmm, I was mistaken - I forgot that <!-- resulted in the </script> being escaped and not ending the script element, which in Opera 9.2 causes the script to not run |
| 14:08 | <MikeSmith> | annevk: thanks for taking time to write the TAG reply |
| 14:08 | <zcorpan> | Philip`: ok |
| 14:10 | <Philip`> | zcorpan: Opera 9.2/9.5 is a bit funny on http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cscript%3E%0D%0A%3C!--%20foo%0D%0A%3C!--%20bar%0D%0A%2F%2F%20--%3E%0D%0A%3C%2Fscript%3E%0D%0A |
| 14:10 | <Philip`> | since the 'foo' line disappears from the DOM view |
| 14:13 | <zcorpan> | Philip`: oh wow, that's a bug |
| 14:13 | <zcorpan> | Philip`: thanks |
| 14:13 | <Philip`> | zcorpan: Crazy browser :-) |
| 14:16 | <hsivonen> | I think I've now implemented MathML tree construction... |
| 14:16 | <hsivonen> | perhaps I should sync test cases now... |
| 14:18 | <zcorpan> | Philip`: most browserse are :) |
| 14:20 | <MikeSmith> | hsivonen: thanks also (for TAG reply) |
| 14:21 | <hsivonen> | MikeSmith: you're welcome |
| 14:22 | <zcorpan> | i wonder if i should reply saying that the analysis doesn't bring up anything that wasn't considered 6 months ago, afaict |
| 14:22 | <zcorpan> | it claims to have new discoveries, but i don't see them |
| 14:22 | <zcorpan> | (other than a firefox bug that is unrelated to the colon) |
| 14:23 | <zcorpan> | (http://lists.w3.org/Archives/Public/www-tag/2008Apr/0242.html ) |
| 14:24 | <MikeSmith> | zcorpan: yeah, it would actually be helpful to point that out. lest others be left with the impression that the original decision that led to the implementations was not very carefully considered |
| 14:26 | <MikeSmith> | btw, for those who care, there's another chat with the Internet Explorer team at 10am US/Pacific today |
| 14:27 | <MikeSmith> | Chris Wilson said he will be on that |
| 14:27 | <MikeSmith> | http://blogs.msdn.com/ie/archive/2008/05/13/may-chat-with-the-ie-team-on-thursday.aspx |
| 14:28 | <Lachy> | MikeSmith, what timezone is US Pacific? |
| 14:28 | <MikeSmith> | PST |
| 14:28 | <MikeSmith> | GMT -5 I think |
| 14:28 | <Lachy> | nevermind, the blog gives the UTC time as well |
| 14:28 | hsivonen | thinks it's PDT this time of year |
| 14:29 | <Lachy> | it says 17:00UTC, so that makes it -07:00 |
| 14:29 | <MikeSmith> | GMT -8 actually |
| 14:29 | <Lachy> | must be DST |
| 14:29 | <MikeSmith> | yeah |
| 14:29 | <MikeSmith> | you guys are right |
| 14:29 | <Lachy> | ah, that's right. Pacific is on the west coast in the USA. |
| 14:30 | <Lachy> | I'm so used to the pacific being on the east where I'm from :-) |
| 14:30 | <BenMillard> | shortest distance is probably going North from here (UK) |
| 14:30 | <MikeSmith> | anyway, the MS online chat app they use for those chats blocks Opera and Safari and does not seem to work correctly in Opera or Safari even when you do UA header spoofing |
| 14:31 | <Lachy> | ok. I can use Firefox for it |
| 14:31 | <MikeSmith> | but it doesn't block Firefox or Minefiel |
| 14:31 | <MikeSmith> | Minefield |
| 14:31 | <MikeSmith> | Lachy: yeah, it seems to work as expected in FF3 and Minefield |
| 14:32 | <Lachy> | how long do they normally go for? |
| 14:32 | Philip` | finally manages to find the IE8 Tech Beta Survey |
| 14:32 | <Philip`> | They do quite a good job of hiding these things |
| 14:32 | <Lachy> | I have my podcast interview at 20:00 my time (UTC+2), and I need to do some revision beforehand. |
| 14:32 | <Lachy> | so I may have to skip it |
| 14:33 | <Philip`> | Hmm, Microsoft is nicer than Google since their survey admits that Opera exists |
| 14:34 | <MikeSmith> | Lachy: I think they last for one hour |
| 14:35 | <aaronlev> | othermaciej: do you know if your developers looking at ARIA have taken a look at the ARIA implementor's guide we're working on? |
| 14:36 | <Philip`> | http://www.microsoft.com/windowsxp/expertzone/chats/chatroom.aspx?ctl=hlp&lang=en-US says it ought to work in Safari 1.2 |
| 15:24 | <Dashiva> | ow |
| 15:24 | <Dashiva> | Lisa called you Anna, annevk :) |
| 15:26 | <Philip`> | Dashive: That's an easy mistake to make |
| 15:35 | annevk | wonders what setAttribute() bug Opera has |
| 15:37 | <Dashiva> | That table he made seems very cavalier about dismissing consistency with html |
| 15:37 | <Philip`> | annevk: http://www.w3.org/XML/2008/04/ARIA-Testing/ - "contrary to e.g. the definition of GetAttributeNode in the DOM specification, it matches the argument to GetAttribute against the local name, rather than the nodeName, of the attribute nodes it checks." |
| 15:37 | <annevk> | it seems PFWG members also have some weird notion of what they're working on "Losing the namespaces architectures seems to brake a lot of the original aim of what we set out to do." |
| 15:38 | <annevk> | it seems to me they set out to create a low-level accessibility API |
| 15:40 | <annevk> | Philip`, ah, that's probably a bug, though DOM Level 3 Core clearly states that using getAttribute() does not give predictable results in namespace aware environments |
| 15:42 | <annevk> | Dashiva, I replied to that e-mail on www-archive |
| 15:42 | <annevk> | Given Henry's latest I've the feeling I'm wasting my time though |
| 15:43 | <annevk> | He clearly lives in another world where namespaces are so important that pragmatism can simply be ignored and complex solutions are preferable over simple ones. |
| 16:12 | gsnedders | guesses he has broken his local copy of html5lib seeming nothing passes |
| 16:13 | <annevk> | hsivonen might have made some changes to the tests from what I've read |
| 16:14 | <virtuelv> | what happens if <script async> does a document.write? |
| 16:17 | <annevk> | same as injecting some script into the document with document.write does now |
| 16:19 | <virtuelv> | annevk: that's not at all clear |
| 16:19 | MikeSmith | happy to discover that Google Doctype is directly accessible through http://code.google.com/p/doctype/wiki/Welcome (as alternative to use DocReader interface) |
| 16:20 | <virtuelv> | annevk: my point being, given that I have a DOM that is "script async, foo1, foo2, foo3" |
| 16:20 | <virtuelv> | and assume the script does a document.write, and the document has parsed foo2 but not foo3 |
| 16:20 | <virtuelv> | does the write insert the content before foo1 or after foo2? |
| 16:25 | <MikeSmith> | Google Code wikis don't provide any way to view change history for a particular wiki page? |
| 16:25 | <annevk> | ok, I'm going through the 460 checkins now and summarizing them |
| 16:26 | <soypunk> | MikeSmith: I think the only way you can view the history of a wiki page is through SVN |
| 16:27 | <soypunk> | example: http://code.google.com/p/doctype/source/browse/wiki/ADisabledAttribute.wiki |
| 16:27 | <soypunk> | (well that's their web interface to SVN anyway...) |
| 16:28 | <soypunk> | (so I guess you have two routes. web or actually looking at SVN diffs.) |
| 16:29 | soypunk | grrs |
| 16:30 | <soypunk> | seems to be in Colloquy where it doesn't update the IRC nickname preferences. :/ |
| 16:30 | <soypunk> | seems to be a bug. |
| 16:35 | <gsnedders> | I have something that mostly works to replace charsUntil, jgraham__ |
| 17:04 | <gsnedders> | jgraham__: http://code.google.com/p/html5lib/issues/detail?id=69 — that's a "someone else can do this" issue :P |
| 17:15 | <annevk> | anyone know how to add a contact to your skype list? |
| 17:15 | <Lachy> | annevk, there should be a + button at the bottom of the window |
| 17:16 | <Lachy> | though it might be different on linux from what it is on mac |
| 17:16 | <annevk> | ah, indeed |
| 17:16 | <annevk> | that dialog looked so complex, i thought it was for something else :) |
| 17:18 | <MikeSmith> | annevk: which 460 changes you talking about? |
| 17:19 | <annevk> | http://html5.org/tools/web-apps-tracker?limit=460 |
| 17:19 | <MikeSmith> | annevk: might want to take a look at this too: |
| 17:19 | <annevk> | http://www.w3.org/html/wg/html5/diff/#changelog |
| 17:19 | <MikeSmith> | http://dev.w3.org/html5/pubnotes/FPWDdiff-colored.html |
| 17:22 | <annevk> | interesting stuff |
| 17:27 | <virtuelv> | baby lolcats, document.write has interop issues |
| 17:34 | <virtuelv> | This is a mess I wish I hadn't started testing |
| 17:36 | <Philip`> | virtuelv: The world will love you for it |
| 17:37 | <virtuelv> | Philip`: let's just say that in a test set of three browsers, no two are entirely consistent with each other |
| 17:37 | <virtuelv> | I just wish we could forbid all use of document.write outright |
| 17:37 | <Philip`> | virtuelv: If you only got three different results, that's pretty good going |
| 17:37 | <virtuelv> | Banner advertising is destroying the web |
| 17:37 | <virtuelv> | Philip`: in some cases I do, yes |
| 17:38 | <Philip`> | It's worse when browsers are not even consistent with themselves |
| 17:44 | <zcorpan> | annevk: s/formet/format/ |
| 17:44 | <zcorpan> | annevk: s/dataSet/dataset/ |
| 17:44 | <zcorpan> | btw, shouldn't pixelratio be on <video> as well as <source>? |
| 17:45 | <zcorpan> | and shouldn't <audio><source pixelratio> be disallowed? |
| 17:46 | <zcorpan> | Hixie: ^ |
| 17:56 | <virtuelv> | Philip`: it sucks even more than you can imagine |
| 18:02 | <annevk> | zcorpan, fixed those offline |
| 18:11 | <virtuelv> | there is enough wtf's in this thing to create an acid test all on its own |
| 18:34 | <zcorpan_> | Hixie: vLinkColor should be vlinkColor and likewise for aLinkColor |
| 18:52 | Philip` | sees "Q: [120] How are you doing with ACID3 ? A: Not really a relevant test for us right now. We're very focused on improving our standards compliance in CSS, HTML and DOM; the Acid3 test chases browser bugs. |
| 18:52 | <Philip`> | Our number has improved from IE7, but we're not really focused on it. If the author gets around to writing a guide to it, we might be able to break it apart more quickly." |
| 18:53 | <gsnedders> | Philip`: Where's that? |
| 18:54 | <Philip`> | gsnedders: The IE8 Experts chat thing |
| 18:54 | <gsnedders> | Philip`: Ah. that thing that claims to work in Saf1.2 and later but not your current browser when using Saf3.1.1 |
| 18:54 | <hober> | link? |
| 18:55 | <Philip`> | hober: http://www.microsoft.com/windowsxp/expertzone/chats/default.mspx |
| 18:55 | <Philip`> | but there's only a minute left |
| 18:55 | <Philip`> | gsnedders: You should get yourself a proper browser, like Minefield |
| 18:55 | <gsnedders> | Philip`: It only lists Saf1.2 or later as being supported on OS X :P |
| 18:56 | <gsnedders> | Philip`: But Minefield works (Fx 2.0 doesn't) |
| 18:57 | <zcorpan_> | acid3 doesn't need a guide for breaking it apart quickly |
| 18:59 | <gsnedders> | Philip`: Not that I can find anywhere to report a bug |
| 21:09 | <Hixie> | not a single reply to my e-mail to the tag |
| 21:09 | Hixie | is sad |
| 21:12 | gsnedders | gives Hixie a hug in compensation |
| 21:12 | <gsnedders> | (not that I expect Hixie wants a hug, but hey) |
| 21:14 | <Hixie> | well they could at least tell me i'm being rude or something |
| 21:15 | <Philip`> | Hixie: The email you sent yesterday? I would have thought they'd at least need a teleconference to set an action to respond, and another to then agree on the response |
| 21:15 | <Hixie> | aah |
| 21:15 | <Hixie> | good point |
| 21:15 | <Hixie> | i keep forgetting that people put up artificial barriers to progress |
| 21:30 | <gsnedders> | jgraham__: OK, you win. //comment()[normalize-space(.) = 'toc'] takes 0.021s |
| 21:30 | <gsnedders> | And I don't think I'll be using anything any more complex |
| 21:52 | <hsivonen> | my display broke... now do I buy from Apple or do I shop for alternatives... |
| 21:53 | <jgraham__> | gsnedders: Do you have any idea if the regexp thing actually is faster? |
| 21:54 | <gsnedders> | jgraham__: I dunno. Due to the insane number of error it causes, it may well be just that which makes it slower currently |
| 21:54 | <jgraham__> | hsivonen: For a desktop machine, I assume? |
| 21:55 | <jgraham__> | I read somewhere that apple displays have poor colour saturation |
| 21:56 | <jgraham__> | OTOH, buying displays in general is hard because the one piece of information that gives you some idea of the panel characteristics is the one that no one reveals |
| 21:57 | <hsivonen> | jgraham__: laptop actually but used like a desktop because apple doesn't have a desktop without integrated display between mini and pro |
| 21:57 | <hsivonen> | but yeah, I'm buying a desktop screen |
| 21:57 | <jgraham__> | That makes sense. |
| 21:58 | <jgraham__> | How much do you care about quality? If you care about size more than colour reproduction I expect non-Apple is the way forward. Otherwise it's a bit harder |
| 22:03 | <gsnedders> | jgraham__: Apple's actual desktop monitors are meant to be very good |
| 22:03 | <gsnedders> | But expensive. |
| 22:04 | <jgraham__> | gsnedders: I agree that they're good (and expensive). I did read somewhere that they have relatively poor colour saturation but that might not actually be true |
| 22:04 | <gsnedders> | I'd go for Dell's UltraSharp range — they use (in the 20", 24", and 30" cases) the same LCD panels as the Apple monitors, and tend to be otherwise just as good if not better, as well as being far cheaper |
| 22:04 | <gsnedders> | jgraham__: I've never seen that in any review, nor has it been my experience in the one I had :P |
| 22:05 | <gsnedders> | jgraham__: What they've used in the latest iMacs suffered from that, though, IIRC |
| 22:05 | <hsivonen> | I like quality but I don't need the best possible panel. at some point price and the looks of the case matter more |
| 22:05 | Hixie | got an apple cinema display for his mini |
| 22:05 | <Hixie> | and i'm very happy with it |
| 22:05 | <jgraham__> | Well I might be confused |
| 22:05 | <hsivonen> | the easy thing with apple is that you only need to pick a size |
| 22:05 | <Hixie> | sadly the mini can't drive the biggest cinema displays, but oh well |
| 22:05 | <gsnedders> | hsivonen: Well, the Apple one certainly looks better than the Dell one, though the Dell one is far from ugly. |
| 22:06 | <jgraham__> | (I ended up buying a HP LP2065 which isn't as big as I would like but has nice colours and is slightly affordable) |
| 22:06 | <gsnedders> | (It looks nothing special for a monitor, but it isn't easy to find huge flaws with though) |
| 22:06 | <hsivonen> | thanks. I'll look up Apple, Dell and HP |
| 22:06 | <gsnedders> | Hixie: Silly Apple not putting dual-link DVI on it! |
| 22:07 | <gsnedders> | Though I doubt the onboard graphics could cope with the resolution :) |
| 22:07 | <Hixie> | (we use dell ones at work, they're pretty good, lots of ports) |
| 22:07 | <jgraham__> | I /think/ I have a Dell Ultrasharp at work (an oldish 24" widescreen one) but its a little bright and hard to adjust |
| 22:07 | gsnedders | just re-implemented textContent for lxml: return u"".join(Element.xpath("child::text()")) :P |
| 22:08 | <jgraham__> | gsnedders: That's a more intelligent way of doing it than I thought of |
| 22:08 | <gsnedders> | jgraham__: XPath is really rather powerful. It saddens me that it doesn't support XPath 2.0, though :P |
| 22:09 | <gsnedders> | jgraham__: It's the first way I thought of doing it without manually looping over it (which I expect will be a thousandth of a second quicker) |
| 22:10 | <jgraham__> | gsnedders: I just used recursion, which is probably slower as you have to manually check for comment nodes |
| 22:15 | <gsnedders> | There isn't even a function to lowercase a string in XPath 1.0 |
| 22:17 | <gsnedders> | is @id case sensitive in HTML? |
| 22:17 | <hsivonen> | gsnedders: use translate() |
| 22:17 | <gsnedders> | hsivonen: Yeah, I know |
| 22:20 | <gsnedders> | Hmm, a string containing both ' and " cannot be represented in XPath 1.0 |
| 22:26 | <Lachy> | My podcast interview went well earliet |
| 22:27 | <Lachy> | *earlier |
| 22:27 | <Hixie> | cool |
| 22:27 | <Hixie> | what did you talk about? |
| 22:27 | <Hixie> | is it online yet? |
| 22:27 | <Lachy> | A lot of it was based upon the ALA article I wrote before |
| 22:27 | <Lachy> | not yet |
| 22:27 | <gsnedders> | work around for today: xpath_string = u"concat('" + u"', \"'\", '".join(id.split("'")) + u"')" |
| 22:28 | <Lachy> | I talked a lot about the community and empahsised that anyone can get involved with the blog, forum, mailing lists, etc. |
| 22:28 | <Lachy> | Then I discussed a few features that are available in browsers today or are being implemented |
| 22:29 | <Lachy> | like canvas and cross document messaging |
| 22:32 | <Lachy> | Then I did an interview with annevk about selectors api for standardssuck.org |
| 22:36 | <Hixie> | Lachy: cool |
| 22:36 | <Hixie> | i'm so glad y'all are doing these talks and interviews and stuff |
| 22:37 | <Lachy> | me too |
| 22:37 | <Hixie> | i'd never have the time to edit the spec if i had to do it :-) |
| 22:38 | <Lachy> | oh, I got some feedback from the podcast guy... |
| 22:38 | <Lachy> | He would like to see a page maintained that describes the current state of implementations of HTML5 features |
| 22:39 | <Lachy> | it would be good if there were someone here capable of maintaining such a page |
| 22:39 | <Hixie> | the annotations in the spec have that info |
| 22:39 | <smedero> | There is this: http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers |
| 22:39 | <Hixie> | you could probably write a page that uses those dynamically |
| 22:40 | <Lachy> | yeah, but the spec isn't such a friendly place to send people looking for implementation info |
| 22:40 | <Hixie> | sure but i mean we could make a separate page |
| 22:40 | <Hixie> | that presented the same info |
| 22:40 | <Hixie> | using the same back-end protocol |
| 22:40 | <Philip`> | Would be nice to have a basic test case for each feature so you can easily see which ones your browser supports |
| 22:40 | <Hixie> | and it could even support editing the info |
| 22:40 | <Lachy> | ok |
| 22:40 | <Hixie> | the annotation system supports listing test cases |
| 22:40 | <Hixie> | and demos |
| 22:40 | <Hixie> | too |
| 22:41 | <Lachy> | what would it take to write such a page? Is there some sort of API for it? |
| 22:43 | <Philip`> | http://dev.w3.org/html5/spec/toc-status.html / http://dev.w3.org/html5/spec/Makefile uses the API |
| 22:44 | <Hixie> | i don't think it's documented, but yes, there's an API |
| 22:45 | <Lachy> | cool. Anyone have time to write the script for it? |
| 22:46 | <hober> | I might give it a go this weekend, but don't quote me on that. |
| 22:47 | Lachy | makes a note to quote hober on the weekend about it. |
| 22:47 | <hober> | damn. |