| 00:00 | <Philip`> | (At least we're getting past the stage where alt = tooltip :-) ) |
| 00:00 | <Philip`> | (except for most of the web, which is in quirks mode and will still work like that for most users) |
| 00:03 | <Philip`> | Hmm, IE8b2's inline search UI way more complex than in Firefox and Opera |
| 00:04 | <Philip`> | They both have a labelled box to type into, and Opera also has a close button, and that's it |
| 00:04 | <webben_> | Philip`: that's not it |
| 00:04 | <Philip`> | IE has all that, and previous and next buttons, and a meaningless icon button (for Highlight All Matches), and an Options drop-down menu for whole-word and case matching |
| 00:05 | <Philip`> | plus a little vertical bar after that, for no discernible reason |
| 00:08 | <Philip`> | Also, IE is the only browser (out of IE, Firefox, Opera, Safari, Chrome) where the scrollbar doesn't quite extend to the edge of the screen, so you have to move your mouse all the way across and then carefully pull it back by a single pixel before you can drag the bar |
| 00:08 | <webben_> | nm, thought you were talking about find generally. |
| 00:08 | <webben_> | I don't see why there should be different interfaces for different types of find operation though. |
| 00:09 | <Philip`> | Ah - Opera's normal ctrl+f dialog box is pretty ugly |
| 00:09 | <webben_> | what I find annoying about IE's find implementation is that you have to press the tab key to get focus on a found link |
| 00:09 | <Philip`> | and I didn't know Firefox's ctrl+f had all those extra buttons too |
| 00:09 | <webben_> | (oh, and you can't afaik just search for link) |
| 00:09 | <Philip`> | but at least it doesn't embed a dropdown menu in it :-) |
| 00:10 | <webben_> | Philip`: note also the difference in fx between ' (quickfind links) and " (find everything) |
| 00:10 | <webben_> | by contrast in other browsers, you can just press enter (or whatever) to follow the link |
| 00:11 | <Philip`> | By '"', do you mean '/'? (That's what key it seems to be on my copy) |
| 00:11 | Philip` | wasn't aware of the find-in-links at all |
| 00:11 | <webben_> | could be (i'm using Fx3 mac) |
| 00:12 | <Philip`> | I think Opera wins for find-some-text-somewhere-near-a-link-and-then-activate-the-link-by-keyboard because of the spatnav thing, so you just have to get close enough to the link and then it's easy to select |
| 00:14 | <webben_> | Opera wipes the floor with other browsers for keyboard navigation |
| 00:14 | <webben_> | (at least other visual browsers) |
| 00:14 | <webben_> | e.g. quick keys |
| 00:14 | <Philip`> | Oh, right, the vertical bar in IE's find toolbar is so that it can say "No matches found" a million miles away from where your eyes are focussing on the box you're typing into |
| 00:15 | <webben_> | would be nice if opera had a find-in-links feature too though |
| 00:16 | <Philip`> | webben_: I think it does, via the ',' key |
| 00:16 | <webben_> | oooh even more awesome :) |
| 00:18 | <Philip`> | (Hmm, Firefox and Chrome both make a ding sound and show some red stuff in the search box when there's no matches, which seems sufficiently obvious) |
| 00:18 | <webben_> | I guess an icon or something works for colorblind/deaf people too? |
| 00:18 | <Philip`> | (Opera at least puts the "No matches" text directly adjacent to the search text input) |
| 00:19 | <webben_> | that's craziness, related text should obviously be as far away from where you're looking as possible. |
| 00:19 | <Philip`> | webben_: Firefox says "Phrase not found" too, and Chrome says "0 of 0" too, so I guess that's sufficient |
| 00:20 | <webben_> | "0 of 0" seems a bit weird. |
| 00:20 | <Philip`> | webben_: That seems to be the principle behind IE's UI :-) |
| 00:24 | <Philip`> | Woah |
| 00:24 | <Philip`> | Chrome does something funny to the scrollbar when you search |
| 00:24 | <Philip`> | I think it's drawing a little horizontal line corresponding to the position of each match |
| 00:24 | <Philip`> | but I'm searching the HTML5 spec for "e" so the whole scrollbar is solid yellow and takes three seconds to draw |
| 00:25 | <Philip`> | ("41 of 149900") |
| 00:26 | <jruderman> | lol |
| 00:28 | <Philip`> | Actually, that's kind of neat - I can search for e.g. "database" and it'll show where the highest concentration of mentions is, which is probably where I want to be reading |
| 00:29 | <webben_> | that does sound neat :) |
| 00:31 | <Philip`> | Similarly I can search for "XHTML" and see that pretty much all of the body of the spec does not mention it once |
| 01:20 | <gsnedders> | Lachy: I need to get the photos off those who took them |
| 01:20 | <gsnedders> | Anyhow, I'm off |
| 09:42 | <Hixie> | othermaciej: note that google is fully funding someone to work 100% on writing html5, which is a pretty big commitment to standards itself |
| 09:42 | <Hixie> | othermaciej: also, gears has been doing a lot of work around making their apis compatible with html5's |
| 09:43 | <Hixie> | i don't know if any of it has shipped yet, but certainly html5 comes up a lot in their code reviews |
| 09:53 | <Lachy> | cool, Justin is pushing for someone to fork the spec. http://lists.w3.org/Archives/Public/public-html/2008Sep/0224.html |
| 09:54 | <zcorpan> | i've gotten webkit to (1) happily create the new document (2) freeze and (3) crash when playing with createDocument(x, y, document.doctype) |
| 09:54 | <zcorpan> | which one happens depends on y |
| 09:56 | <zcorpan> | writing web dom core is fun |
| 09:57 | <Hixie> | Lachy: btw for your study it would be good to have a third (control) group that had no image descriptions, and then compare which of the groups most ably completed the relevant task |
| 09:57 | <Hixie> | Lachy: (this is to test the hypothesis that detailed out-of-band image descriptions actually help blind users) |
| 09:57 | <aboodman> | I've decided to go straight for html6, personally. |
| 09:57 | <Hixie> | aboodman: i'll see you there in a couple of decades :-P |
| 10:00 | <zcorpan> | ok, DOMImplementation is done |
| 10:01 | <zcorpan> | or well hasFeature needs expanding |
| 10:01 | <heycam> | zcorpan, link? |
| 10:01 | <zcorpan> | http://simon.html5.org/specs/web-dom-core |
| 10:02 | <heycam> | thanks |
| 10:02 | <aboodman> | i saw on the blogosphere that ff 3.1 will have worker support |
| 10:02 | <aboodman> | it isn't clear which version though |
| 10:03 | <roc> | the current version |
| 10:03 | <zcorpan> | http://simon.html5.org/sandbox/bookmarklets/reveal-comments might be useful when reading web dom core |
| 10:04 | <roc> | BenT wrote he'll be updating the syntax to match the current spec before beta1 |
| 10:04 | <aboodman> | roc: as in the current html5 draft? |
| 10:04 | <roc> | yeah |
| 10:04 | <heycam> | nice bookmarklet zcorpan! |
| 10:04 | <aboodman> | cool |
| 10:04 | <roc> | of course, "the current version" is a variable, not a constant, so ... |
| 10:04 | <roc> | :-) |
| 10:04 | <aboodman> | right, i'm a little concerned about that |
| 10:05 | <zcorpan> | heycam: thanks :) |
| 10:05 | <roc> | well, this issue comes up whenever we do anything |
| 10:06 | <aboodman> | it's almost as if there is some fundamental design flaw in the way apis are versioned on the web :) |
| 10:06 | <aboodman> | sorry, couldn't resist |
| 10:06 | <roc> | well |
| 10:06 | <Hixie> | i hope people take justin up on his suggestion in http://lists.w3.org/Archives/Public/public-html/2008Sep/0224.html |
| 10:07 | <Hixie> | i could do with the motivation :-) |
| 10:07 | <roc> | my response to that is, "APIs are hard" |
| 10:08 | <aboodman> | i commend you guys pushing forward |
| 10:08 | <aboodman> | is there a schedule for FF 3.1 somewhere? |
| 10:08 | <roc> | sort of |
| 10:09 | <roc> | we were going to try to ship this year, but we won't do that now. Currently I think we're closing for beta1 end of this month, ship early next year |
| 10:09 | <annevk> | so does that also mean Mozilla will not introduce a second HTTP API in ECMAScript as I saw mentioned somewhere in one of the Workers bugs? |
| 10:09 | <roc> | annevk: I don't know |
| 10:10 | <roc> | ask bent |
| 10:10 | <aboodman> | ah, from the blagoweb, i got the impression 3.1 was upon us |
| 10:10 | <roc> | it's on a short leash. |
| 10:11 | <roc> | if you want to find out more, check mozilla.dev.plannng |
| 10:11 | <aboodman> | thanks |
| 10:11 | <roc> | or dial in to the project planning meetings, they're public access :-) |
| 10:12 | <roc> | and the wiki notes are posted to planet.mozilla |
| 10:12 | <Lachy> | Hixie, I considered a control group, but I figured it wouldn't matter since the questions were only going to be designed to make the user navigate the page, and their final answers didn't really matter. Only whether they used the longdesc="" to access the description |
| 10:13 | <Lachy> | but I suppose it could also be extended to test the effectiveness of long descriptions |
| 10:13 | <Hixie> | well there's no point having them even if they navigate to them if they don't actually help |
| 10:13 | <Hixie> | of course to do this we'd have to find a page with actually useful longdesc=""s |
| 10:13 | <Hixie> | so as to not bias the study by making up artificial pages |
| 10:13 | <Lachy> | Joshue's videos already provided observational evidence that the descriptions are useful |
| 10:14 | <Hixie> | really? |
| 10:14 | <Hixie> | uri? |
| 10:14 | <aboodman> | roc: mailing list looks useful, thanks |
| 10:14 | <Hixie> | i don't recall seeing them be useful |
| 10:15 | <Lachy> | the user he was testing said that they helped him to understand the images better |
| 10:15 | <Hixie> | the user he was testing also said that summary was useless and then that summary was useful |
| 10:15 | <Lachy> | yeah |
| 10:16 | <Hixie> | i mean i have great respect for the guy, but people in usability studies are notorious for thinking everything is useful |
| 10:16 | <Hixie> | you should see some of our studies at google, where users are like "ooh that rocks" but when we do actual studies to see if it helps them, the features actually hurts them |
| 10:16 | <Hixie> | it's rather sad |
| 10:16 | <Hixie> | hurt, even |
| 10:16 | <Lachy> | that's true, and it's quite obvious that the guy's answers were being influenced by Joshue with the way the questions were asked |
| 10:16 | <roc> | I've heard of examples like that |
| 10:17 | <roc> | users like bling even when it slows them down |
| 10:17 | <Lachy> | can any of the studies Google has done on the issue be published? |
| 10:17 | <Hixie> | we haven't done anything on longdesc |
| 10:17 | <Hixie> | as far as i know |
| 10:17 | <Lachy> | ok. Could you? |
| 10:18 | <Hixie> | i'd love to, but i doubt it |
| 10:18 | <Lachy> | it doesn't seem likely that anyone from the accessibility community is interested in doing the one I proposed, nor any others |
| 10:18 | <Hixie> | we don't really have the infrastructure set up to do studies of non-visual users in their usual environment (which is the only real way to do these kinds of studies for those users) |
| 10:19 | <Hixie> | i'll mention it to our usability people though, maybe if they do another set of home studies for visually impaired users they can slide that in |
| 10:19 | <Hixie> | unlikely to happen any time soon though |
| 10:19 | <Lachy> | ok |
| 10:19 | <Hixie> | if at all |
| 10:20 | <zcorpan> | you could perhaps do remote studying if the user has a webcam |
| 10:20 | <Hixie> | (also i could never release the videos, for privacy reasons) |
| 10:21 | <roc> | Park Google Street View outside their houses and watch through the windows |
| 10:21 | <Hixie> | hah |
| 10:21 | <Lachy> | LOL |
| 10:22 | <Lachy> | the problem with a remote study is that the conditions can't be controlled well |
| 10:23 | <zcorpan> | but it's a lot cheaper (i guess) so you can do more |
| 10:24 | <Lachy> | I suppose I could email Joshue directly is see if he's willing to do it |
| 10:26 | <Hixie> | turns out that a lot of blind users don't have webcams. (weird, i know) |
| 10:27 | <zcorpan> | perhaps you could do studies without webcams |
| 10:27 | <Hixie> | it's hard to do studies without actually seeing the user |
| 10:27 | <zcorpan> | yeah |
| 10:27 | <Hixie> | half the data you get from a usability study is observing the user's body language |
| 10:27 | <Hixie> | anyway |
| 10:27 | <Hixie> | if you can get a study, i encourage you to do so |
| 10:28 | <Hixie> | anything is better than nothing |
| 10:28 | <Hixie> | even if not ideal |
| 10:29 | <Lachy> | perhaps a sample website could be set up, provide the questionnaire with it online, and get blind users to complete the study from home. That way we can see where they went from the logs and how they answered the questionnaire. The only problem is eliminating cheaters. |
| 10:31 | <Hixie> | Lachy: not a bad idea |
| 10:32 | Hixie | prepares for a flood of flame mail |
| 10:32 | <othermaciej> | Hixie: well I hope Google's actions come together and end up being pro-standards |
| 10:33 | <othermaciej> | Hixie: I certainly don't think any of the technical people involved (many of whom I know) are acting in bad faith |
| 10:33 | <Hixie> | othermaciej: i expect they will. there's a lot of good will, it's just not very well coordinated. Google is a very engineer-driven company, as opposed to manager-driven |
| 10:33 | <Hixie> | othermaciej: so engineers have to be converted to the standards way, as opposed to being told to "do standards" |
| 10:34 | <othermaciej> | I know that sometimes combination of business needs and randomness of priorities can lead to weird looking outcomes |
| 10:34 | <Hixie> | yeah |
| 10:35 | <Hixie> | that too |
| 10:35 | <Lachy> | Hixie, I expect you'll get a lot of responses trying to say how the problem longdesc solves is obvious. Although, in all cases I've seen, the information in the description is useful to everyone, not just those with ATs |
| 10:35 | <othermaciej> | I don't think it is the engineering side of Google that evangelizes other companies to code to Gears APIs but I wouldn't really know |
| 10:35 | <othermaciej> | in any case hopefully the relevant people are susceptible to public encouragement to do teh right thing |
| 10:35 | <Hixie> | othermaciej: is there any part of google that evangelizes other companies to code to Gears APIs? |
| 10:36 | <othermaciej> | Hixie: well, a number were held up as exemplars at Google I/O, with big formal announcements |
| 10:36 | <othermaciej> | e.g. MySpace |
| 10:36 | <annevk> | WordPress |
| 10:37 | <Hixie> | i might be mistaken, but i think google i/o was almost exclusively engineer driven |
| 10:37 | <Hixie> | but i might be wrong |
| 10:37 | <Hixie> | so i'll shut up now :-) |
| 10:37 | <aboodman> | no, there is a heavy dose of marketing at those events |
| 10:37 | <Hixie> | aboodman would know better |
| 10:38 | <aboodman> | this ship is going to take some time to turn around |
| 10:39 | <aboodman> | but it will turn |
| 10:39 | <Hixie> | annevk: some kind of caching on the web-apps-tracker would be really nice *pleading face* |
| 10:39 | <othermaciej> | I know Apple at times has misguided people who are for trying to push corners of Web technology in a not-entirely-open direction |
| 10:39 | <othermaciej> | it is work to keep them at bay |
| 10:39 | <Hixie> | annevk: right now there are like a dozen connections from html5.org to svn.whatwg.org and it's driving the load up way high |
| 10:40 | <othermaciej> | and making WebKit be a real open source project instead of bare-minimum passive-aggressive open source was itself a ship that took time to turn around |
| 10:40 | <Hixie> | yeah i bet that was a hell of a job |
| 10:41 | <annevk> | oh :/ |
| 10:41 | <Hixie> | annevk: i don't really understand what the cause is |
| 10:41 | <aboodman> | See the geolocation api as an example of the way I'd like things to work more often. |
| 10:41 | <Hixie> | annevk: it seems to happen every now and then |
| 10:41 | <aboodman> | which, btw, i don't think we ever got any apple feedback on ;) |
| 10:42 | <annevk> | I guess people link to it now and then in channels or so |
| 10:42 | Hixie | prods othermaciej for feedback on workers, too :-P |
| 10:42 | <othermaciej> | Hixie: oh yeah |
| 10:42 | aboodman | prods self |
| 10:42 | <Hixie> | annevk: yeah but it always seems to be a random set of revisions |
| 10:42 | <othermaciej> | I both owe direct feedback and owe more reminders to ap to give feeback |
| 10:42 | <annevk> | Hixie, oh ok |
| 10:42 | <othermaciej> | Hixie: you can imagine I have been somewhat distracted in light of recent eents and all |
| 10:42 | <annevk> | Hixie, is the frontpage less of an issue? |
| 10:43 | <annevk> | Hixie, because for the frontpage I don't really have an idea how to cache it properly |
| 10:43 | <Hixie> | annevk: like right now you're hitting web-apps for r2016, r1979, r2002, and r2035 |
| 10:43 | <Hixie> | annevk: well, for the front page you just need the log of recent messages, right? |
| 10:44 | <Hixie> | annevk: so you could just cache that for five minutes (only hit the server once every five minutes or something) |
| 10:44 | <Hixie> | annevk: but for per-revision pages, seems like you could cache those forever |
| 10:45 | <annevk> | the front page does svn log with a limit |
| 10:45 | <annevk> | an individual revision does svn log + svn diff |
| 10:46 | <annevk> | yeah, the per-revision pages are easier |
| 10:47 | <annevk> | hopefully I can do this tonight or tomorrow |
| 10:47 | <Hixie> | cool |
| 10:49 | <Hixie> | hey macdome |
| 10:49 | <eseidel> | hi Hixie, aboodman |
| 10:51 | <aboodman> | eseidel? up at 3am? SHOCKING |
| 10:51 | <eseidel> | aboodman: just got home :) |
| 10:51 | <eseidel> | hangin w/ some friends. beating Castle CRashers |
| 10:55 | <eseidel> | an now checkin in with my webkit peeps before betd |
| 10:57 | <zcorpan> | bah, acid3 tests doctype.internalSubset :( |
| 10:57 | <zcorpan> | in webkit it's always null |
| 10:57 | <zcorpan> | so clearly it's not needed for web compat |
| 10:59 | <zcorpan> | Hixie: i want to drop internalSubset from dom core. could you change acid3 to not rely on it? |
| 10:59 | <zcorpan> | assertEquals(doc.firstChild.internalSubset, null, "internalSubset wrong (first test)"); |
| 10:59 | <zcorpan> | assertEquals(doc.firstChild.internalSubset, null, "internalSubset wrong (second test)"); |
| 11:00 | <roc> | hey I just fixed that in Gecko |
| 11:01 | <zcorpan> | roc: oh? would you like to keep it in dom core then? |
| 11:01 | <roc> | I don't really care |
| 11:01 | <zcorpan> | ok |
| 11:01 | <annevk> | removing useless code seems like a win |
| 11:01 | <roc> | it is a bit disturbing that Acid3 tests for it not being present, but doesn't test for it being present |
| 11:02 | <annevk> | zcorpan, btw, you're not handling undefined in the IDL, should that really become "undefined" everywhere? |
| 11:02 | <zcorpan> | annevk: dunno |
| 11:02 | <zcorpan> | annevk: haven't looked at undefined yet |
| 11:02 | <Hixie> | i've made the test allow the property to be completely absent |
| 11:02 | <zcorpan> | Hixie: thanks! |
| 11:03 | <Hixie> | zcorpan: (bear in mind that we'll still have to define what it should do if present, just like e.g. body.vLink will be defined in the "obsolete DOM attributes" section in html5) |
| 11:03 | <zcorpan> | Hixie: yeah, my plan was to just drop it |
| 11:04 | <Hixie> | are UAs going to remove support? |
| 11:04 | <zcorpan> | dunno |
| 11:04 | <zcorpan> | roc? |
| 11:04 | <roc> | don't ask me, I just fixed the bug |
| 11:05 | <roc> | if you remove it from the spec and send us a patch to remove support, I'm pretty sure we'd take it :-) |
| 11:05 | <zcorpan> | :) |
| 11:05 | <zcorpan> | opera developers are always happy to remove code |
| 11:05 | <roc> | I'm not a DOM Guy, I just fixed the bug for fun |
| 11:06 | <roc> | all developers are always happy to remove code |
| 11:06 | <roc> | I hope |
| 11:07 | <Hixie> | all good ones, yes |
| 11:08 | <Lachy> | Hixie, which test number did you just update? |
| 11:08 | <Hixie> | (also some bad ones, q.v. debian's changes to ssl keygen...) |
| 11:08 | <Lachy> | in acid3 |
| 11:08 | <Hixie> | 71 |
| 11:08 | <Lachy> | ok, I'll update our copy on Opera's test server |
| 11:16 | <Lachy> | oh, did you update test #7 recently too? It had a change that wasn't in my local copy |
| 11:17 | <Hixie> | oh yeah |
| 11:18 | <Hixie> | hmm |
| 11:18 | <Hixie> | in <div><form></div><input> the input is obviously associated with the form |
| 11:19 | <Hixie> | but in <form id=a><div><form></div><fieldset form=a><input>, what is the input associated with? form#a, or the second form? |
| 11:20 | <Hixie> | also, how about <form id=a></form><fieldset form=a><div><form></div><input> |
| 11:22 | <Lachy> | Hixie, could acid3 be made available via svn or something, so that whenever you make a change, we can just do svn update, instead of having to copy and paste the changes manually? |
| 11:22 | webben_ | finds this vaguely amusing: http://www.css-zibaldone.com/articles/logo/creating.html : providing a D-link for a background-image. |
| 11:22 | <Hixie> | lachy: remind me for acid4 |
| 11:22 | <Lachy> | ok |
| 11:22 | <Hixie> | Lachy: (i don't want to go through the pain of doing this for acid3) |
| 11:23 | <Lachy> | ok. In that case, just remember to notify me whenver a change is made so I can update our test server |
| 11:23 | annevk | decides to take a look at caching now |
| 11:23 | annevk | summons Python IO docs |
| 11:26 | Hixie | considers just dropping the fieldset association |
| 11:26 | Hixie | considers dropping form="" altogether |
| 11:27 | <zcorpan> | Hixie: without form='', how do you do forms for each row in a table? |
| 11:29 | <Hixie> | you don't, but with form="", i don't know how to make the parsing work |
| 11:29 | <Hixie> | especially if we have fieldset-scoping |
| 11:29 | <zcorpan> | we could drop fieldset-scoping |
| 11:30 | <Hixie> | yeah, that's one of the two things i just said i was considering :-) |
| 11:31 | <zcorpan> | i mean, i'd rather fieldset scoping was dropped than form='' was dropped :) |
| 11:32 | <Hixie> | dropped |
| 11:32 | <webben_> | can't you just make form= take priority over preceding form or fieldset, but not over proceeding form? |
| 11:32 | webben_ | maybe quite misunderstanding the problem. |
| 11:33 | <Hixie> | what would that do to the examples above? |
| 11:33 | <Hixie> | in <form id=a><div><form></div><fieldset form=a><input>, what is the input associated with? form#a, or the second form? |
| 11:33 | <Hixie> | and how about <form id=a></form><fieldset form=a><div><form></div><input> |
| 11:33 | <Hixie> | (and why?) |
| 11:35 | <webben_> | if </form> getting inferred before </div> there? |
| 11:35 | <webben_> | *is |
| 11:35 | <Hixie> | no |
| 11:36 | <webben_> | that's somewhat confusing |
| 11:36 | <webben_> | is that for legacy compat? |
| 11:36 | <Hixie> | yes |
| 11:36 | <Hixie> | yes |
| 11:36 | <Hixie> | (search for "form element pointer") |
| 11:41 | <webben_> | example 1) form=a takes priority over preceeding form, so input is associated with form=a; example 2) input is associated with form. |
| 11:41 | <Hixie> | why does it take priority? |
| 11:42 | <webben_> | to follow the apparent declared authorial intent mostly |
| 11:42 | <Hixie> | i mean, what is the algorithm used to determine that it takes priority? |
| 11:42 | <webben_> | oh |
| 11:42 | <Hixie> | are we walking the tree every time the parser inserts an <input> element? |
| 11:44 | <Hixie> | also, in case 2, does changing the id of either form change the association of <input>? |
| 11:44 | <Hixie> | (consider in particular the case where it changes the association of the <fieldset>, since the <input> is a child of the <fieldset> and not of either form) |
| 11:47 | <webben_> | Hixie: could the parser store something to indicate whether the nearest ancestor was a form= or form? |
| 11:47 | <webben_> | rather than walking the tree again to find out? |
| 11:48 | <Hixie> | the DOM can change while the parser is running |
| 11:48 | <webben_> | ah okay, then yes, it would involve walking the tree |
| 11:49 | <Hixie> | that's not really going to fly |
| 11:49 | <webben_> | presumably that's expensive, yeah |
| 11:49 | <Hixie> | also i don't really understand what the condition you are proposing is |
| 11:49 | <Hixie> | that would give different results in those two cases |
| 11:51 | <webben_> | Hixie: The thinking is something like: we want to associate an input with a form, but an input can't belong to two forms. So if nearest ancestor is form, it should belong to that. But if nearest ancestor is form= then the author has gone to trouble to specify which form it belongs to, |
| 11:51 | <webben_> | so it should belong to that. |
| 11:52 | <Hixie> | then wouldn't it be associated form form#a in both cases? |
| 11:52 | <annevk> | implemented caching, not sure it works |
| 11:52 | <Hixie> | cool, thanks |
| 11:52 | <hsivonen> | Lachy: fwiw, I think JF et al are right about the flaw of your longdesc user testing setup |
| 11:52 | <Hixie> | will let you know if i see peak load again |
| 11:53 | <webben_> | no it would be associated with form#a in the first case, since fieldset form=a is nearest ancestor |
| 11:53 | <Hixie> | webben_: in both cases, the nearest ancestor is a <fieldset form=a> |
| 11:53 | <hsivonen> | Lachy: otoh, longdesc has been out of the user testing *lab* in the real world for a decade and has failed in the ultimate lab |
| 11:54 | <webben_> | Hixie: then I'm misunderstanding the form element pointer stuff. |
| 11:54 | <webben_> | <form id=a></form><fieldset form=a><div><form></div><input> I thought <form> there was an ancestor of <input>? |
| 11:54 | <annevk> | I did not implement caching for the home page. For individual diff pages, I simply create a file each time a new diff is generated (identifier, from, to, context) and check before the diff is retrieved from svn.whatwg.org whether such a file exists |
| 11:54 | <Hixie> | webben_: play with hsivonen's live dom viewer to see the dom you would get from the parser |
| 11:55 | <Hixie> | webben_: the pointer is just set to the last <form> seen, and is reset to null by </form> |
| 11:55 | <annevk> | so changes to the formatting of the diff should not affect the cache |
| 11:55 | <webben_> | Hixie: yep, but that's why I thought <form> was the ancestor |
| 11:55 | <Hixie> | webben_: in the example you just quoted, the ancestors of input are, in reverse order, fieldset, body, html, #document |
| 11:56 | <annevk> | some algorithm is however certainly possible as we implemented this :) |
| 11:57 | <webben_> | oh okay, I don't understand that, but yeah in that case fieldset form=a is ancestor, points to form#a and therefore input belongs to form#a ? |
| 11:57 | <Hixie> | annevk: so what does opera do? |
| 11:58 | <annevk> | oh, I haven't looked into this |
| 11:59 | <Hixie> | opera gets different results for: |
| 11:59 | <Hixie> | <form id=a></form><fieldset><div><form id=b></div><input> |
| 11:59 | <Hixie> | <form id=a></form><fieldset form=a><div><form id=b></div><input> |
| 11:59 | <Hixie> | ...which seems like it would be expensive to do reliably |
| 11:59 | <Hixie> | and thus shouldn't be required by the spec |
| 12:00 | <Hixie> | (it involves attribute lookups on the ancestor chain during parsing) |
| 12:00 | <annevk> | well, caching is certainly working |
| 12:00 | <Hixie> | cool, thanks |
| 12:00 | <annevk> | contents of the caching folder is growing rapidly :) |
| 12:00 | <Hixie> | :-) |
| 12:00 | <Hixie> | who's using the page? |
| 12:01 | <Hixie> | googlebot? |
| 12:01 | <annevk> | no bots, they are forbidden per robots.txt |
| 12:01 | <webben_> | is this hsivonen's live dom viewer? http://parsetree.validator.nu/ ? |
| 12:01 | <zcorpan> | webben_: no, http://livedom.validator.nu/ |
| 12:01 | <Hixie> | http://livedom.validator.nu/ |
| 12:01 | <webben_> | is there a tools page where all these things are listed? |
| 12:02 | <Hixie> | damowmow.com/portal/ has a list of some of them |
| 12:02 | <Hixie> | on the right hand side |
| 12:02 | <annevk> | sorry for not doing this earlier as it was a twenty minute hack (adding about 10 lines of code) |
| 12:02 | <Hixie> | np |
| 12:02 | <webben_> | ah neat |
| 12:02 | <Hixie> | it wasn't serious, but it was becoming a minor annoyance :-) |
| 12:04 | <hsivonen> | Hixie: why does form="" affect parsing? isn't it resolved on the above-DOM layer? |
| 12:05 | <Hixie> | hsivonen: because of the form element pointer |
| 12:05 | <hsivonen> | Hixie: can't you just say that form='' overrides the form element pointer |
| 12:05 | <Hixie> | hsivonen: as the spec stood until about 12 seconds ago, form="" would never have any effect, because the form element pointer wasn't conditional on the attribute, and just always set the association |
| 12:05 | <hsivonen> | Hixie: and have the parser set the pointer always |
| 12:06 | <Hixie> | hsivonen: we can, but then we still don't get <fieldset> association, unless we want to crawl the ancestor chain at some point and decide how we decide what owns what |
| 12:06 | <hsivonen> | Hixie: so that the above-DOM layer looks at form='' first, form pointer second and containment third |
| 12:06 | <hsivonen> | oh. right |
| 12:06 | <hsivonen> | that sucks |
| 12:06 | <Hixie> | well for now i've dropped fieldset association altogether |
| 12:07 | <Hixie> | the main use case was table rows |
| 12:07 | <Hixie> | where it wouldn't help anyway |
| 12:07 | <hsivonen> | Hixie: but don't parsers have to crawl the ancestor chain for dynamically inserted form controls anyway? |
| 12:07 | <hsivonen> | s/parsers/browsers/ |
| 12:07 | <Hixie> | they do now, yes, but it's a single crawl at a well-defined time |
| 12:07 | <Hixie> | (insertion) |
| 12:08 | <Hixie> | and doesn't involve looking at attributes on the ancestors |
| 12:08 | <Hixie> | just looking for a form |
| 12:08 | hsivonen | tries to find Hixie's bug report in IRC logs |
| 12:08 | <Hixie> | <dl><dd></span> complained about a </p> iirc |
| 12:09 | <hsivonen> | Hixie: thanks |
| 12:09 | <hsivonen> | nope, that's not sufficient |
| 12:09 | <Hixie> | <dl><dt><dd><span></dd></dl> |
| 12:09 | <Hixie> | Error: End tag for p seen, but there were unclosed elements. |
| 12:09 | <hsivonen> | right. Thanks |
| 12:11 | <zcorpan> | <ol><li><span></li></ol> gives the same |
| 12:11 | <annevk> | not a single diff request with context other than 10 |
| 12:11 | <annevk> | well, within the last few minutes |
| 12:11 | <annevk> | I guess I should check again next week or so |
| 12:12 | <Hixie> | hsivonen: btw, why does the text field jump around when i do a text field validation? |
| 12:12 | <hsivonen> | Hixie: to order the submission data right |
| 12:12 | <Hixie> | it's really disconcerting |
| 12:13 | <hsivonen> | Hixie: would it be better to empty the textarea and stuff the data in a trailing input type=hidden? |
| 12:13 | <zcorpan> | hsivonen: or disable the textarea? |
| 12:13 | <Hixie> | well, first i'd ask why you have to do anything at all |
| 12:13 | <hsivonen> | zcorpan: that might be better |
| 12:14 | <Hixie> | but you really don't want to be depending on script for something like this |
| 12:14 | <Hixie> | s/but/and/ |
| 12:14 | <hsivonen> | Hixie: the other fields contain data that the validator has to have before it starts reading the document input |
| 12:14 | <zcorpan> | Hixie: the feature isn't available without script |
| 12:14 | <Hixie> | hsivonen: you can't buffer 512 bytes? |
| 12:14 | <Hixie> | hsivonen: or even 2MB? |
| 12:16 | <hsivonen> | Hixie: I *could*, but it's much nicer when IO streams |
| 12:17 | <hsivonen> | Hixie: (I do end up caching the data [as UTF-16 even] for show source) |
| 12:17 | <Hixie> | hsivonen: seems dubious to me. but if you really want to do it this way, then just have the textarea not be named, and copy it into a hidden field oninput and onchange |
| 12:18 | <hsivonen> | Hixie: ok. |
| 12:18 | <zcorpan> | file upload is trickier :) |
| 12:19 | <Hixie> | incidentally, XMLNS Filter doesn't appear to be a label like the other labels |
| 12:19 | <Hixie> | oh no |
| 12:19 | <Hixie> | the text field is jus disabled |
| 12:19 | <Hixie> | nevermind |
| 12:19 | <hsivonen> | Hixie: the field should be disabled when the HTML parser is selected |
| 12:20 | <hsivonen> | Hixie: is type=email staying? |
| 12:20 | <Hixie> | i have no plans to not merge it in |
| 12:20 | <Hixie> | which is as close to "yes" as i'm willing to commit :-) |
| 12:20 | <hsivonen> | Hixie: ok |
| 12:21 | <hsivonen> | Hixie: do you have plans to change normative references when it comes to non-ASCII characters in type=email? |
| 12:21 | <Hixie> | i have no plans either way |
| 12:22 | <Hixie> | i'm not aware of an issue |
| 12:22 | <hsivonen> | ok |
| 12:22 | <Hixie> | but i'm sure there's mail about it if there is one |
| 12:23 | <Hixie> | ok, one attribute down (form). About 150 to go. |
| 12:23 | <Hixie> | bed time |
| 12:23 | <hsivonen> | if there's an open-source Java library that implements exactly what type=email parsing requires, I'd like to know |
| 12:23 | <Hixie> | nn |
| 12:23 | <hsivonen> | nn |
| 12:24 | <annevk> | fixed a small bug |
| 12:31 | <annevk> | I had to specialcase revTo=0 |
| 12:32 | <annevk> | hsivonen, it will change |
| 12:32 | <hsivonen> | annevk: type=email? |
| 12:32 | <annevk> | hsivonen, IDN e-mail is under discussion at various places, though currently experimental RFCs only per my understanding |
| 12:33 | <hsivonen> | sigh |
| 12:33 | <annevk> | I would expect that to effect type=email long term, yes |
| 12:33 | <hsivonen> | I suppose I can't fix type=email next week, then |
| 12:33 | <annevk> | http://www.rfc-editor.org/rfc/rfc5335.txt |
| 12:33 | <annevk> | http://www.rfc-editor.org/rfc/rfc5336.txt |
| 12:33 | <annevk> | http://www.rfc-editor.org/rfc/rfc5337.txt |
| 12:33 | <hsivonen> | I've already postponed it for a *long* time |
| 12:33 | <hsivonen> | annevk: thanks |
| 12:33 | zcorpan | just specced createElement() |
| 12:35 | <annevk> | zcorpan, shouldn't it match the NCName production? |
| 12:35 | <zcorpan> | annevk: no |
| 12:35 | <annevk> | zcorpan, also, I sort of doubt that matches implementations, as I believe browsers have hacks for <div ...> and such |
| 12:35 | <zcorpan> | annevk: that's createElementNS |
| 12:35 | <zcorpan> | annevk: hmm |
| 12:35 | <zcorpan> | need to test that |
| 12:38 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0Ax%3Cscript%3E%0D%0Atry%20%7B%0D%0Avar%20e%20%3D%20document.createElement('%3Cdiv%20class%3D%22test%22%3E')%3B%0D%0Aw(e.tagName)%0D%0Aw(e.attributes%5B0%5D.name)%0D%0Aw(e.attributes%5B0%5D.value)%0D%0A%7D%20catch(e)%20%7B%0D%0Aw(e)%0D%0A%7D%0D%0A%3C%2Fscript%3E |
| 12:38 | <zcorpan> | ie doesn't work for me right now |
| 12:39 | <zcorpan> | opera, firefox and webkit throw |
| 12:39 | <annevk> | drop the DOCTYPE |
| 12:40 | <annevk> | and use something like <div> |
| 12:40 | <annevk> | works in Firefox (I'm currently using Opera with DOCTYPE override in effect, so there it never works.) |
| 12:41 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?x%3Cscript%3E%0Atry%20%7B%0Avar%20e%20%3D%20document.createElement(%27%3Cdiv%3E%27)%3B%0Aw(e.tagName)%0A%7D%20catch(e)%20%7B%0Aw(e)%0A%7D%0A%3C%2Fscript%3E |
| 12:41 | <zcorpan> | doesn't work in opera or webkit |
| 12:41 | <annevk> | interesting |
| 12:42 | <annevk> | maybe someone should slap the Gecko guys then :) |
| 12:42 | <zcorpan> | :) |
| 12:45 | hsivonen | replies to JF against his better judgment |
| 12:46 | <zcorpan> | should createElement() lowercase the argument? |
| 12:49 | annevk | is tempted to say yes |
| 12:50 | <hsivonen> | is it black-box-testable via localName? |
| 12:51 | <zcorpan> | hsivonen: yeah, you can see if "BR" creates a linebreak or not |
| 12:51 | <zcorpan> | hsivonen: and it should be testable via localName too |
| 12:53 | <Lachy> | hsivonen, re "I agree that Lachlan's research setup has the problem you described" from your latest mail to public-html. I already addressed the problem John described regarding the existing poor implementations by saying it could be done with newer, improved implementations. |
| 12:54 | <Lachy> | if even newer, improved implementations suffer from the same problem, then there isn't much hope for it in the wild |
| 12:56 | <hsivonen> | Lachy: the problem your setup has is that it doesn't test how people would behave in a hypothetical sitution if they haven't been able to develop routines in the hypothetical environment |
| 12:56 | <hsivonen> | Lachy: of course, testing if the hypothetical situation could be useful is pointless if there is no route form where we are to the hypothetical situation |
| 12:58 | <Lachy> | sure, but that's a fundamental problem with the whole idea of longdesc, because they haven't yet shown that they can even get there. They just seem to be basing their argument on the hope they somehow they will in some unspecified amount of time with some unspecified solution |
| 12:59 | <hsivonen> | Lachy: I think a decade of failure outside the lab is a much stronger argument that what could be obtained through your test setup |
| 13:00 | <Lachy> | hsivonen, sure. but the test setup has the advantage of being able to do it with better implementations than is currenlty widely deployed, and the ability to compare 2 different solutions |
| 13:01 | <Lachy> | it just annoys me how they keep ignoring the alternative solution of using ordinary links, which also has the advantage of making it available to everyone |
| 13:02 | <othermaciej> | does anyone have the intent of actually performing whatever the test is? |
| 13:02 | <Lachy> | othermaciej, we would need someone like Joshue who has the resources available to do it. But so far, no-one has volunteered to do it |
| 13:05 | <annevk> | oops, svn.whatwg.org will still get hits for svn log, even for diff pages |
| 13:05 | <zcorpan> | should createTextNode raise an exception if it doesn't match the Char production? |
| 13:05 | <annevk> | but svn log is probably not as problematic as svn diff |
| 13:06 | zcorpan | goes with "no" |
| 13:15 | <zcorpan> | what about createComment? should it throw for "foo -- bar" or "foo -"? |
| 13:16 | <jgraham> | WDBD? |
| 13:17 | <zcorpan> | jgraham: ? |
| 13:17 | <jgraham> | What Do Browsers Do? |
| 13:17 | <jgraham> | :) |
| 13:18 | jgraham | is just passing through on his way to a different desktop |
| 13:18 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0Ax%3Cscript%3E%0D%0Atry%20%7B%0D%0Avar%20e%20%3D%20document.createComment('foo--bar')%3B%0D%0Aw(e.data)%0D%0A%7D%20catch(e)%20%7B%0D%0Aw(e)%0D%0A%7D%0D%0A%3C%2Fscript%3E |
| 13:18 | <zcorpan> | opera strips the dashes |
| 13:18 | <jgraham> | So maybe I'm not making any sense :) |
| 13:18 | <zcorpan> | firefox throws |
| 13:18 | <zcorpan> | webkit allows it |
| 13:19 | <zcorpan> | i need to get ie working... |
| 13:19 | zcorpan | reboots |
| 13:19 | <jgraham> | Silent data loss sounds bad |
| 13:26 | Philip` | has filed a bug about Opera stripping slashes in createComment |
| 13:27 | <Philip`> | 312761 |
| 13:27 | <Philip`> | because it made my Live HTML5 Parser thing not work as desired |
| 13:28 | <hsivonen> | Philip`: I apply infoset coercion to make Gecko not throw |
| 13:32 | <Philip`> | Maybe someone should fork the HTML5 spec and put it on a wiki so anyone can edit it |
| 13:33 | <Dashiva> | htmlpedia, the web standard anyone can edit? |
| 13:33 | <Dashiva> | Might be hard to implement |
| 13:35 | <Philip`> | Not at all - you just edit the standard to match your implementation |
| 13:37 | <Philip`> | annevk: Have you committed the updated web-apps-tracker to SVN? |
| 13:37 | <annevk> | no, will do that later |
| 13:37 | <annevk> | tonight I hope |
| 13:37 | <annevk> | have to go now |
| 13:37 | <annevk> | well, I had to go -40 minutes |
| 13:49 | webben_ | isn't sure what the advantage of the mailing lists has been over bug trackers and wikis. |
| 13:50 | <webben_> | mailing lists make it much harder to follow chains of discussion that last months |
| 13:51 | <jgraham> | hsivonen: I assume David meant "something else that provides long descriptions for images" |
| 13:52 | <jgraham> | webben_: I'm not sure bug trackers are good for discussion around an issue |
| 13:52 | <hsivonen> | jgraham: yeah. So I realized just after hitting send. :-( |
| 13:52 | <hsivonen> | webben_: wikis make it even harder |
| 13:53 | <webben_> | jgraham: no bug trackers are good for tracking bugs :) |
| 13:54 | <webben_> | hsivonen: harder how? |
| 13:54 | <hsivonen> | webben_: AFAICT, wikis don't track the parts you have read, are organized by writer as opposed to reader, don't have good bozo filters, etc. |
| 13:55 | <webben_> | hmm. |
| 13:55 | <webben_> | seems like there's a space for some sort of hybrid |
| 13:56 | <webben_> | where stuff is organized by topic but tracks what you've read. |
| 13:58 | <Dashiva> | Kinda like a mailing list with threads |
| 13:58 | <webben_> | except threads tend to be very brittle |
| 13:59 | <hsivonen> | hmm. I guess I should also update my internal English dictionary do choose better between adjacent and juxtaposed |
| 13:59 | <webben_> | e.g. there are multiple threads about longdesc rather than one topic |
| 13:59 | <webben_> | and people don't tend to review what's already been said, so there's lots of repetition |
| 14:00 | <Dashiva> | Trust me, they don't do that on a wiki either |
| 14:00 | webben_ | hypothesises that they do it more because it's easier. |
| 14:08 | <Philip`> | I think it's more a limit of human ability to understand complex discussions that have been going on for months, and no technology is going to solve the problem |
| 14:10 | <Dashiva> | 1. See interesting thing. 2. Want to comment. 3. I'm important, gotta comment ASAP! No time to read old posts. 4. Hilarity ensues. |
| 14:12 | <webben_> | I think most of the misunderstandings aren't that complex. |
| 14:12 | <Philip`> | The misunderstandings make the discussion complex, though |
| 14:13 | <webben_> | But a lot of the misunderstandings derive from not having searched and read repetitive previous misunderstandings. |
| 14:13 | <jgraham> | webben_: See theHTML pages on the ESW wiki for evidence of htmlwg related wiki faliure |
| 14:14 | <webben_> | jgraham: I'd expect the HTML wiki to fail since discussion is happening in multiple places. |
| 14:14 | <webben_> | wiki + mailing list === even harder to follow previous thinking. |
| 14:16 | <zcorpan> | ie allows -- in comment |
| 14:17 | <zcorpan> | i don't want to check for Char anyway so it's possible to create comments that won't serialize, and at that point it's pointless to check for -- |
| 14:23 | <jgraham> | zcorpan: Sounds reasonable |
| 14:38 | <webben_> | hsivonen: http://lists.w3.org/Archives/Public/public-html/2008Sep/0233.html : the problem with the real-world lab is that it only tests the UIs that implementors happen to have implemented. |
| 14:39 | <webben_> | the real-world lab isn't a good test of what _could_ be implemented |
| 14:39 | <hsivonen> | webben_: the real world takes into account all the constraints implementors are under in the real world :-) |
| 14:39 | <hsivonen> | webben_: it tests what _would_ be implemented :-) |
| 14:40 | <webben_> | I see no reason to believe that. |
| 14:40 | <hsivonen> | webben_: so it shows that given the resource allocation constraints implementors have been under for the last decade, the status quo is what we got |
| 14:41 | <hsivonen> | webben_: results that are produced under real resource allocation constraints are practically interesting |
| 14:42 | <webben_> | you assume that has predictive power. |
| 14:42 | <webben_> | I don't. |
| 14:43 | <hsivonen> | webben_: my point is that in the case of longdesc, we don't need to *predict*, because we can see the results of a grand experiment that has already run its course |
| 14:43 | <webben_> | er... no you still need to predict |
| 14:43 | <webben_> | otherwise it would be a meaningless experiment. |
| 14:45 | <hsivonen> | webben_: well, I guess you can call it predicting that you'd assume longdesc continues to suck if it has sucked for a decade |
| 14:45 | <webben_> | yes, but I think that's an illogical prediction. |
| 14:46 | <hsivonen> | webben_: how long would you let longdesc go on and still assume that next year will be different? |
| 14:46 | <webben_> | (that is, if longdesc continues to suck, I think it would either be a) a set of historical contingencies or b) because of fundamental flaws. I don't think a particular set of contingencies has predictive power or automatically demonstrates fundamental flaws. |
| 14:47 | <webben_> | hsivonen: i don't think time is a relevant factor at all. |
| 14:47 | <webben_> | (fwiw implementations do appear to be improving) |
| 14:47 | <Dashiva> | Time is the most relevant factor of all |
| 14:47 | <hsivonen> | webben_: even if it were contingencies, the result is that it doesn't work |
| 14:47 | <webben_> | anything can be made not to work by contigencies. |
| 14:47 | <webben_> | that's the nature of contingencies. |
| 14:47 | <webben_> | they don't tell you _anything_ |
| 14:48 | <webben_> | you'd have to actually do a deep analysis of the contingencies to get useful information. |
| 14:48 | <hsivonen> | webben_: yes, but here we have a case where we know that a) the feature sucks inherently or b) contingencies *did* actualize |
| 14:48 | <hsivonen> | either way, the feature is ruined |
| 14:48 | <webben_> | only a) is meaningful if true. |
| 14:48 | <hsivonen> | unless you believe you can remove the contingencies and make it soar |
| 14:49 | <Dashiva> | You'd think that if the contingencies could be removed, 10 years would be enough |
| 14:49 | <webben_> | Dashiva: er... that's 10 years of contigencies |
| 14:49 | <hsivonen> | Dashiva: right |
| 14:49 | <Dashiva> | webben_: And 10 years that people could use to remove them |
| 14:49 | <hsivonen> | webben_: so how do you know they are contingencies instead of permanent constraints? |
| 14:50 | <webben_> | Dashiva: you don't "remove" historical contingencies. |
| 14:50 | <Dashiva> | webben_: You either do, or they're permanent |
| 14:50 | <hsivonen> | webben_: I'd love to define that some ideas would be great if only the stuff from Econ 101 didn't apply |
| 14:50 | <webben_> | Dashiva: no they're just happenings. |
| 14:50 | <Dashiva> | Either these contingencies can be removed, in which case 10 years have been wasted. Or they can't, in which case longdesc is inherently flawed. |
| 14:51 | <webben_> | hsivonen: That would involve an actual analysis of the flaws and whether any of the contigencies were related to their flaws, not just noting that something didn't happen. |
| 14:51 | <webben_> | "War got declared, therefore peace doesn't work." |
| 14:52 | <Dashiva> | War tends to get fixed in less than ten years |
| 14:53 | <hsivonen> | webben_: as far as I can tell, peace doesn't work given the economic incentives of the military-industrial complex |
| 14:53 | <jgraham> | Turning this around, what would you describe as good evidence that the long term cost/benefit of a feature does not work |
| 14:54 | <Philip`> | So we should give up trying for peace? |
| 14:54 | <Dashiva> | No, but we should take the realities into account while trying |
| 14:54 | <webben_> | jgraham: Actual analysis of costs/benefits. I don't think "time" is inherently relevant. |
| 14:54 | <hsivonen> | Philip`: no, but the structure of the military-industrial complex needs changing |
| 14:55 | <jgraham> | webben_: Time is relevant in that it gives us data to compare to our suppositions about the cost/benefits |
| 14:55 | <webben_> | jgraham: Time is not data in itself. |
| 14:55 | <Dashiva> | If the feature won't be useful for the next century because of contingencies, why spec it now and not in a hundred years? |
| 14:56 | <jgraham> | webben_: So? It is a necessary precondition for collecting real-world data |
| 14:56 | <webben_> | jgraham: Of course. But here time is being treated as data. |
| 14:56 | <hsivonen> | webben_: I'd expect an economist to be able to estimate the net present benefit of working longdesc |
| 14:56 | <webben_> | removing any need to actually analyze the data collected |
| 14:56 | <webben_> | i.e. why did war break out |
| 14:57 | <jgraham> | For longdesc time has shown that people are not that interested in writing them (hardly surprising) and that UAs are not that interested in implementing it (more surprising) |
| 14:57 | <jgraham> | It has also shown that when people do try to author it they get it wrong |
| 14:57 | <webben_> | jgraham: It's a lot more complex than that. |
| 14:57 | <webben_> | firstly, some UAs do implement it and implementations are, if anything, improving. |
| 14:58 | <webben_> | second, better authors have long been told to avoid it (unlike with alt). |
| 14:58 | <jgraham> | webben_: The first part is surely not that much more complex. People just aren't interested in providing detailed textual descriptions of their images |
| 14:58 | <webben_> | third, most images don't benefit much from long descriptions. |
| 14:59 | <webben_> | (see "third" above, never mind people not being interested in supporting multiple audiences where they would benefit) |
| 14:59 | <jgraham> | webben_: So ignoring everyhing else, it's not even that useful as a feature? |
| 15:00 | <webben_> | that doesn't follow. |
| 15:00 | <webben_> | "that useful" compared to what? |
| 15:00 | <Dashiva> | The alternatives |
| 15:01 | <jgraham> | Compared to not having it at all. Especially compared to the authors spending the same time on other acceibility work |
| 15:01 | <hsivonen> | webben_: as for "why did the war break out" analogies, can you identify some root thing that needs fixing and that is blocking longdesc like one can identify campaign financing as the first thing that needs fixing before many political problems can be fixed? |
| 15:01 | <webben_> | jgraham: the authoring time involved in longdesc is infinitesimal. the authoring time involved in writing text equivalents is substantial. |
| 15:02 | <jgraham> | I don't understand your point |
| 15:02 | <webben_> | jgraham: i.e. removing longdesc doesn't free up substantial time for doing other accessibility work. |
| 15:03 | <jgraham> | It does if you spend the time that you would have spent writing long replacements for images doing something else that is more useful |
| 15:04 | <webben_> | jgraham: er... you're confusing long description and longdesc. |
| 15:04 | <webben_> | jgraham: long descriptions for images is necessary when it's necessary |
| 15:05 | <webben_> | jgraham: removing or keeping longdesc doesn't do anything to change the necessity of long descriptions |
| 15:06 | <webben_> | hsivonen: Based on my experiences talking to implementors about HTML features, I'd say the lack of examples of how to implement it in the HTML4 spec was a contributing factor. |
| 15:06 | <webben_> | that much, at least, is something HTML5 could fix (if it chooses to keep longdesc at all) |
| 15:06 | <Dashiva> | But if longdesc is such a rare use, why does it need a special attribute? Why doesn't a link (potentially with ARIA associations) suffice? |
| 15:07 | <webben_> | Dashiva: what ARIA association? |
| 15:07 | <Dashiva> | One that fits the bill, the name isn't important |
| 15:08 | <jgraham> | webben_: You said it wasn't useful for most images. Therefore if an author spent the time that they would have spent on long descriptions on something else entirely like alt text or table headers or whatever that is likely to have a better payoff. |
| 15:09 | <jgraham> | Even if they do spend the time writing long descriptions burying them in an attribute that many UAs don't support seems like a collosal waste of time |
| 15:09 | <hsivonen> | webben_: what should HTML5 say about how to implement it? |
| 15:10 | <jgraham> | Being invisible it also increases the chance the longdesc will get out of sync with the image and so on |
| 15:10 | <jgraham> | Or go 404 |
| 15:11 | <Dashiva> | Good'ole invisible metadata |
| 15:11 | <jgraham> | londesc is the design I would choose if I wanted to minimise the chance of the feature suceeding |
| 15:38 | <webben_> | Dashiva: what's the difference between longdesc and this hypothetical ARIA association? |
| 15:39 | <Dashiva> | a) the link isn't invisible metadata (unless you make it invisible) and b) it lets accessibility stay in an accessibility spec and c) it avoids any potential confusion-causing overlap between the two |
| 15:40 | <hsivonen> | b may not be a great thing |
| 15:40 | <Dashiva> | hsivonen: In what way? |
| 15:41 | <webben_> | hsivonen: It could give examples such as indicating longdesc presence on hover with a cursor change or focus with an icon overlay; providing access via shortcut keys and/or context menus; and making the action be open a new browsing context with the URI if a different doc; or just moving focus if it's the same doc. |
| 15:41 | <webben_> | rather than just saying "oh, btw, you need to provide some sort of mechanism for this" |
| 15:41 | <hsivonen> | Dashiva: letting accessibility stay in a accessibility spec takes a bolt-on view to accessibility |
| 15:41 | <webben_> | hsivonen: That's not to say it should mandate a particular UI, but that it should give examples. |
| 15:42 | <Dashiva> | hsivonen: Well, in this case the accessibility is mapping the image to the link, the link is present to begin with |
| 15:42 | <hsivonen> | webben_: do you consider iCab's implementation a successful UI? |
| 15:42 | <webben_> | hsivonen: my one concern with iCab is keyboard focus, but then I think iCab has problems with keyboard interaction anyway. |
| 15:43 | <webben_> | hsivonen: What do you reckon? Do you reckon it's a bad UI? |
| 15:44 | <Dashiva> | Oh, and I forgot d) no attribute means people can't misunderstand and put plain text in it |
| 15:44 | <hsivonen> | webben_: making things discoverable only on hover doesn't seem like good UI design to me unless the appearance of the hoverable item otherwise suggests that it can reveal more stuff |
| 15:45 | <hsivonen> | the reason why images as links work is that the image itself usually suggests linkness sufficiently |
| 15:45 | <webben_> | is it? |
| 15:45 | <webben_> | I thought images as link work because people move the cursor round the screen until it shows a hand icon. |
| 15:46 | <webben_> | or, alternately, click until something happens |
| 15:46 | <Dashiva> | That's not images as links, that's any link |
| 15:46 | <webben_> | well, yes. |
| 15:47 | <zcorpan_> | <table summary='Layout table: the first cell contains↩ the type of the return value, the second contains a short description'↩ border='0'> |
| 15:47 | <zcorpan_> | dom3 core |
| 15:48 | <hsivonen> | webben_: I'm pretty sure people don't scan every decorative image for linkness usually but instead try to move the cursor over images whose content suggests linkness |
| 15:48 | <hsivonen> | webben_: do you scan every image just in case? |
| 15:49 | <webben_> | ditto longdesc presumably. |
| 15:49 | <hsivonen> | webben_: how do you suggest longdescness visually? |
| 15:49 | <webben_> | hsivonen: diagrams, charts, important photos |
| 15:50 | <hsivonen> | webben_: link-looking images have a much higher linkness rate than those have a longdescness rate |
| 15:51 | <csarven> | Is there currently even "longdescness"? |
| 15:51 | <Lachy> | so what is wrong with this solution then: <a href="longdescription"><img src="chart" alt="whatever"></a>? |
| 15:51 | <hsivonen> | csarven: there is but very, very rarely |
| 15:51 | <Dashiva> | Some would say it doesn't allow longdesc on link images. |
| 15:51 | <Lachy> | that makes it accessible to everyone, has the same discoverability as iCab's longdesc-icon-on-hover |
| 15:51 | <webben_> | Lachy: that would presumably suffer from hsivonen's issue. |
| 15:51 | <Lachy> | which issue? |
| 15:52 | <webben_> | Lachy: if you're going to hover over an image to see if it's a link, you can see if it would have a longdesc at the same time. |
| 15:53 | <webben_> | Dashiva: Is there a use-case for long descriptions on link images? I'm not sure that there is. |
| 15:53 | <Lachy> | webben_, sure, but people will more easily understand the hand icon than the icon that iCab uses. People know how to click a link and may not expect to check the context menu. |
| 15:54 | <zcorpan_> | Lachy: if i click on an image link, i don't expect to come to a page explaining the image |
| 15:54 | <Dashiva> | webben_: That's why I said "some would say" :) |
| 15:54 | <Dashiva> | I figured it merited mentioning even if I don't agree with it |
| 15:54 | <webben_> | this would seem to be something worth working out: what people expect if they click a chart or diagram or big photo. |
| 15:54 | Philip` | looks at a product on the Tesco web site, and gets a handy "XML parsing failed: syntax error (Line: 30, Character: 361)" failure |
| 15:55 | <Lachy> | also, it's common for charts to link to either larger or more detailed versions, which could be included in a page which also has more explanation |
| 15:55 | <webben_> | hmm actually that's a potential problem |
| 15:55 | <webben_> | yeah, I guess the usecase for link + longdesc would be |
| 15:56 | <Lachy> | zcorpan_, when you click an image link in wikipedia, you get a page with more information about that image (although that info generally isn't optimised for accessibility purposes) |
| 15:56 | <webben_> | <a href="chart.jpg"><img src="chart.jpg" longdesc="description.html" title="Chart of stuff"></a> |
| 15:56 | <webben_> | oh wait that's need an alt |
| 15:56 | <webben_> | <a href="chart.jpg"><img src="chart.jpg" longdesc="description.html" alt="Chart of stuff"></a> |
| 15:56 | <csarven> | webben Links (whether they embed an <img> or not) already has a representation and a user can scan the page and figure out what is a link. @longdesc on the other doesn't. It is hidden. |
| 15:57 | <webben_> | csarven: ? it's no more hidden than linkiness in iCab or JAWS 10. |
| 15:57 | <Lachy> | webben_, for that case, just use <a href="description.html">Mimg src="chart.jpg alt="Chart of stuff"></a> and include the larger version of the chart within description.html |
| 15:57 | <zcorpan_> | Lachy: maybe wikipedia is different because all wikipedia does is explain things -- generally i don't expect to come to a page that explains a word when i click on a text link |
| 15:57 | <Lachy> | s/Mimg/<img |
| 15:57 | <webben_> | Lachy: what if you want to link to the image? |
| 15:57 | <webben_> | should HTML5 advise authors not to link directly to images? |
| 15:57 | <Lachy> | webben_, for what purpose? |
| 15:57 | <zcorpan_> | (unless it's a word i don't know and the link points to wikipedia) |
| 15:58 | <Lachy> | webben_, can you describe a case where an author would want to link to both the image itself and a long description? |
| 15:59 | <webben_> | if they believed links are easier to use than context menus and wanted to give people easy access to a big image, I guess. |
| 15:59 | <zcorpan_> | couldn't the long description contain the image? |
| 16:00 | <Lachy> | webben_, that doesn't really answer the question, and the bigger image can be included in description.html |
| 16:00 | <webben_> | Lachy: not if you want to allow people to just save the image without using a context menu |
| 16:00 | <Lachy> | they still need to use the context menu anyway once they're viewing the image |
| 16:00 | <zcorpan_> | if you want both then it seems more understandable to have two links under the image "(large version, description)" |
| 16:01 | <webben_> | Lachy: they don't they can use the File menu |
| 16:01 | <webben_> | or the save keyboard shortcut |
| 16:02 | <Lachy> | webben_, I think that's just a hypothetical situation, and you're ignoring the fact that most users are already familiar with how to save an image within a page |
| 16:02 | <webben_> | "most users" ... are they really? |
| 16:02 | webben_ | would be interested if they are. |
| 16:02 | <webben_> | are you saying they're familiar with using context menus to manipulate images? |
| 16:03 | <zcorpan_> | some people i know weren't familiar with how to save images but they could figure it out on first try |
| 16:04 | <zcorpan_> | but perhaps they were smarter then the average user :) |
| 16:05 | <webben_> | or just more ui-canny. |
| 16:05 | <Lachy> | webben_, I'm sure you wouldn't doubt that more people would know how to save an image from a context menu than they would access a long description from it |
| 16:06 | <webben_> | Lachy: Yep, but I think the learning process involved in both seems much the same. |
| 16:06 | <webben_> | it's just that in IE, that isn't a context menu option, and there's no hint the image has a long description. |
| 16:07 | <zcorpan_> | you can save every image there is but every image doesn't have a long description |
| 16:07 | <webben_> | zcorpan_: that's the point of the hover/focus indicator? |
| 16:07 | <Lachy> | perhaps, but saving images is several orders of magnitude more common that accessing a long description, so people are likely to learn and remember it more easiliy than they would with longdesc |
| 16:07 | <webben_> | same as with links |
| 16:08 | <zcorpan_> | webben_: then the indicator needs to be understandable by average users :) |
| 16:08 | <webben_> | zcorpan_: just as with links |
| 16:08 | <webben_> | I think iCab's indicator does a reasonable job. could be a bit bigger maybe. |
| 16:08 | <zcorpan_> | perhaps a baloon saying "this image has a description - click here to open it in a new tab" |
| 16:09 | <webben_> | well, that could interfere with title |
| 16:09 | zcorpan_ | doesn't know about iCab's indicator |
| 16:09 | <Lachy> | regardless of the size of the icon, the icon itself is very meaningless |
| 16:09 | <Lachy> | I tested it and if you hadn't told me it was for long descriptions before I saw it, I wouldn't have had a clue |
| 16:10 | <zcorpan_> | webben_: why would it? |
| 16:10 | <webben_> | Lachy: would you have a clue what a hand icon means before experimenting? |
| 16:10 | <Lachy> | and the icon for when an image is a link and has a longdescription is even more confusing |
| 16:10 | <webben_> | zcorpan_: what, showing two balloons? |
| 16:10 | <zcorpan_> | webben_: yeah |
| 16:10 | <zcorpan_> | webben_: or one baloon with two lines |
| 16:10 | <Lachy> | the hand icon suggests that I should do something with my hand, and the obvious thing to do is either move the mouse or click it |
| 16:11 | <Lachy> | and since it has the index finger extended, that suggests clicking is more likely |
| 16:11 | <webben_> | if you're using a mouse yes |
| 16:12 | <webben_> | if you're using a touchpad, less so. |
| 16:12 | <Lachy> | if I'm using a touch pad, my index finger is still extended in much the same way as depicted in the icon |
| 16:12 | <webben_> | but it's not clicking all the time |
| 16:13 | <webben_> | (incidentally, my hand looks nothing like that when using a touchpad, but maybe I'm just odd) |
| 16:13 | Lachy | thinks this debate is pointless; goes to do something more productive |
| 16:14 | <webben_> | zcorpan_: maybe, not sure what that would look like. |
| 16:15 | <zcorpan_> | webben_: e.g. a baloon above or under the image and title as a normal tooltip |
| 16:16 | <webben_> | could work. |
| 16:17 | <webben_> | i'd be a bit scared of it interacting with weird ways with JS-based tooltips |
| 16:17 | <webben_> | *in weird ways |
| 16:17 | <zcorpan_> | icons in my systray can have both a balloon and a tooltip |
| 16:17 | <zcorpan_> | yeah but if you have a js-based tooltip then you could use that instead of longdesc |
| 16:18 | <webben_> | unless you're using it to work around limitations of title |
| 16:18 | <webben_> | or for some other weird reason |
| 16:21 | <webben_> | Dashiva: with (a) longdesc does not exclude also having a link (it just makes the relationship between URI and image programmatically determinable). a link does not exclude being hidden (and thus not accessible to users). |
| 16:22 | <Dashiva> | So you'd rather have redundancy? |
| 16:22 | <Dashiva> | That's even worse for avoiding link rot |
| 16:23 | <webben_> | Dashiva: do you mean specifying the URI twice by "redundancy"? |
| 16:23 | <Dashiva> | Yes |
| 16:23 | <webben_> | Dashiva: No, I'd rather the URI was specified once. |
| 16:24 | <webben_> | but linked to the image in a programmatically determinable way |
| 16:24 | <webben_> | I haven't yet seen any ARIA markup that does that for a description that isn't on the same page. |
| 16:24 | <webben_> | and the fate of describedby in HTML5 is less than clear anyways |
| 16:25 | <Dashiva> | You associate to the link on the same page, and the link associates naturally to the other page |
| 16:25 | <webben_> | Dashiva: if it was actually specified like that, then sure. |
| 16:25 | <webben_> | i.e. if it was clear to implementors that describedby pointing an a href means that the target page is the description. |
| 16:27 | <Dashiva> | Surely it would be clear to the users even without that? |
| 16:27 | <webben_> | only if they explored around the page |
| 16:27 | <webben_> | not if they navigating by image |
| 16:27 | <Dashiva> | They'd get an image which says "I'm described by this here element" |
| 16:27 | <Dashiva> | And if that element is a link, following it would be natural wouldn't it? |
| 16:27 | <webben_> | oh I see what you mean. |
| 16:28 | <webben_> | perhaps, but _if_ that is the natural behavior, why couldn't one specify that for the user agent? |
| 16:28 | <webben_> | either it is the natural behavior but wrong in some cases, or you can simply map the URI to the img? |
| 16:28 | <Dashiva> | One could, I'm just suggesting it would work without as well |
| 16:28 | <webben_> | it would work, perhaps, but less well. |
| 16:29 | <Dashiva> | webben_: Ah, but just describedby allows inline descriptions as well |
| 16:29 | <Dashiva> | If the element is something else, e.g. a paragraph or table |
| 16:30 | <webben_> | yes, i'm only talking about the specific case when describedby points to an element with an href. |
| 16:30 | <webben_> | not the general case where describedby points to an element. |
| 16:30 | <Dashiva> | And you'd want to put the URI directly in the image then? |
| 16:30 | <webben_> | I'm not sure what that means. |
| 16:30 | <Dashiva> | In the image elmeent's markup, instead of a separate link |
| 16:30 | <webben_> | not necessarily. |
| 16:31 | <webben_> | like I said, from my perspective, a link is fine as long as it can be associated programmatically with the image. |
| 16:31 | <webben_> | and it would be better if you could spec for UAs to minimize user effort. |
| 16:31 | <webben_> | (e.g. by treating the href target as the description) |
| 16:31 | <Dashiva> | I think I see three different cases. Link to on-page content, link to off-page content with visible link, link to off-page content with invisible link. |
| 16:32 | <Dashiva> | The last one being essentially longdesc |
| 16:32 | zcorpan_ | defines NodeList in terms of HTML5 "collection" |
| 16:32 | <webben_> | or <a href=""> that's hidden. |
| 16:32 | <Dashiva> | Exactly |
| 16:33 | <Dashiva> | So by using an association, we can get the same effect as longdesc, as well as the other two cases, with only a single attribute |
| 16:34 | <webben_> | yeah, I'm not arguing for longdesc intrinsically (although I think its faults have been overstated); I think programmatic association is useful. I'm just saying that we should hone the association as much as possible. |
| 16:34 | <webben_> | to make navigation as fast as possible. |
| 16:34 | <Dashiva> | That's a good thing. |
| 16:36 | <webben_> | Dashiva: Can you see any problem with a UA treating the href target of an element pointed to by describedby as the description, as opposed to the UA presenting the element itself as the description? (in the case where the element does have an href) |
| 16:36 | <Dashiva> | If page loading time (or cost) is important, perhaps |
| 16:37 | <webben_> | could you elaborate on that? |
| 16:37 | <Dashiva> | The user might want to be made aware if the description is a different resource |
| 16:38 | <webben_> | Dashiva: it could do that with the UI. |
| 16:38 | <webben_> | Dashiva: for example, Firefox or IE could map that uri exactly as they do longdesc |
| 16:38 | <webben_> | then JAWS could announce "Long description available" and the user could use their shortcut key to access it. |
| 16:39 | <webben_> | (this is assuming Firefox/IE are exposing it (IE8 is), rather than JAWS trying to dig it out of the DOM, however) |
| 16:39 | <webben_> | but at any rate that shows the UI that could be created. |
| 16:39 | <webben_> | or JAWS could say "same page description available" |
| 16:39 | <Dashiva> | Yeah, something like that should work |
| 16:41 | <Dashiva> | Do you think UAs would -not- do that, in the case where it was not specified? |
| 16:42 | <Dashiva> | It seems like value added then as well |
| 16:42 | <webben_> | It's entirely possible they might not. I think relying on UAs to implement things sensibly is over-optimistic. |
| 16:42 | <webben_> | if HTML5 assumes something can be inferred it should specify that assumption. |
| 16:43 | <hsivonen> | webben_: the spec should indeed have well-defined algorithms for inferences |
| 16:43 | <webben_> | especially for this sort of thing, where developer effort is likely to be concentrated on issues like "How the heck do we get our users access to the Microsoft Office Ribbon?" |
| 16:43 | <webben_> | (but really, for everything) |
| 16:44 | <webben_> | not specifying stuff got HTML4 into a lot of problems |
| 16:46 | <Dashiva> | Would this be the same assocation as between a figure and its legend, or is there a semantic difference? |
| 16:49 | <webben_> | Dashiva: a legend might just be a title like "Chart of commodity prices" mightn't it? |
| 16:49 | <webben_> | rather than (say) a paragraph summarizing the trends + a data table on a separate page |
| 16:51 | <Dashiva> | Yeah |
| 17:21 | <zcorpan_> | hmm... if i have text/html "<math><x:y>" and then do document.importNode(theMathElement, true) from another html document, should that raise INVALID_CHARACTER_ERR or not? |
| 17:22 | <zcorpan_> | or actually, the same question applies to a normal html element <x:y> |
| 17:32 | <zcorpan_> | copying a node between two documents should perhaps not do any checking at all if you copy to an html document |
| 17:35 | <Dashiva> | As long as it's all DOM nodes being moved around (i.e. no serialization) it seems a bit odd to do error checking |
| 17:37 | <csarven> | Does @scope only apply to <th> ? |
| 17:43 | <zcorpan_> | Dashiva: yes but the dom does error checking all over the place |
| 17:45 | <Dashiva> | zcorpan_: So raise the same exception that would be raised if you attempted to create the element within the destination document? |
| 17:45 | <zcorpan_> | Dashiva: the innerHTML getter in xml documents assume that the error checking that the dom does has taken place so not doing it when moving nodes between documents would break innerHTML and render the rest of the error checking useless |
| 17:45 | <zcorpan_> | Dashiva: yeah |
| 17:46 | <Dashiva> | I suppose that's equally consistent |
| 17:46 | <zcorpan_> | Dashiva: i think it only needs to check nodeName for elements and attributes against the Name production |
| 17:46 | <zcorpan_> | but i'm not sure |
| 17:46 | <hsivonen> | IMO DOM error checking is useless |
| 17:46 | <hsivonen> | either it should check *everything* like XOM or nothing |
| 17:46 | <zcorpan_> | hsivonen: should i check everything? |
| 17:46 | <csarven> | Is there any mechanism in HTML 4 or 5 that can be used to scope values locally? Sort of like prefix mappings in RDFa. For instance, when rel="license" is used in HTML 4 it is signifying the relationship between the current document and the destination resource. In this case, it is not about a particular section in the document. |
| 17:46 | <hsivonen> | zcorpan_: no, due to compat considerations |
| 17:47 | <zcorpan_> | hsivonen: yep right |
| 17:47 | <Dashiva> | Is it bad that I know the urls to most DOM specs by heart? |
| 17:48 | <zcorpan_> | hsivonen: i can't really remove the error checking either |
| 17:48 | <hsivonen> | zcorpan_: why? |
| 17:48 | <zcorpan_> | hsivonen: acid3 tests it :) |
| 17:49 | <hsivonen> | fun |
| 17:50 | <zcorpan_> | i've actually added more checks |
| 17:50 | <zcorpan_> | but perhaps i should try to remove checks instead |
| 17:50 | <Dashiva> | zcorpan_: It seems document.createElement('a:b') should work. Core3 says to check for the XML 'Name' production, which contains ':' as far as I can see |
| 17:50 | <zcorpan_> | Dashiva: yeah |
| 17:51 | <Dashiva> | So as you said, importing into a HTML document should work |
| 17:51 | <hsivonen> | actually, I revise my all or nothing stance to XML API checking |
| 17:52 | <hsivonen> | it also makes sense to check potentially user-entered values (text content, attribute values, perhaps PI data and comments) but not check application programmer-entered data (element and attribute names) |
| 17:53 | <hsivonen> | DOM has this exactly backwards, of course |
| 17:53 | <zcorpan_> | hsivonen: should i check against Char for text etc? |
| 17:54 | <hsivonen> | at this point of the API's life, probably not |
| 17:54 | <hsivonen> | I really don't know what to do with the DOM |
| 17:54 | <webben_> | csarven: Well, HTML5 currently says: "Hyperlinks created with the link element and its rel attribute apply to the whole page. This contrasts with the rel attribute of a and area elements, which indicates the type of a link whose context is given by the link's location within the document." |
| 17:54 | <webben_> | http://www.whatwg.org/specs/web-apps/current-work/#rel |
| 17:54 | <hsivonen> | I'm just ranting in with 20/20 hindsight |
| 17:55 | <hsivonen> | checking for Char before serializer would be bad for perf |
| 17:55 | <webben_> | csarven: No idea what UA behavior that's supposed to imply in terms of how a is scoped. |
| 17:55 | <zcorpan_> | hsivonen: indeed |
| 17:55 | <webben_> | csarven: eRDF uses HTML4 #id to scope rel, which (I think) breaks the HTML4 rel semantic. |
| 17:56 | <csarven> | True. |
| 17:58 | <zcorpan_> | i've added the following checks that weren't in dom3: doctype.publicId match XML publicChar, doctype.systemId not contain both ' and ", pi.target not contain "xml" or colon |
| 17:58 | <webben_> | csarven: so I guess you'd still need to use class="licence" with a defined algorithm if you wanted to guarantee correct processing. |
| 18:01 | <zcorpan_> | hmm i thought acid3 tested it but i can't find it |
| 18:07 | <zcorpan_> | would be nice to remove error checking from the dom |
| 18:08 | <zcorpan_> | it would be incompatible with ie's createElement('<div class="test">') though |
| 18:09 | <zcorpan_> | but perhaps we can specify that while we're at it |
| 18:10 | zcorpan_ | comments out the added error checks for now |
| 18:14 | <zcorpan_> | what's really sad is that you have to do two checks: once for Name and again for NCName |
| 18:15 | <zcorpan_> | and throw different exceptions |
| 18:15 | <zcorpan_> | i guess i can eliminate that and just check for NCName |
| 18:16 | <zcorpan_> | hmm i'll try to drop attribute nodes too |
| 18:17 | <Philip`> | http://www.singaporeair.com/saa/index.jsp - <META NAME="description" CONTENT=<fmt:message key="description" bundle=s"${mr}"/>> - oops |
| 18:18 | <Philip`> | (That slightly confusingly results in a ">" being rendered) |
| 19:38 | <nate_m> | Is the html5lib patch for lxml compatibility talked about at http://krijnhoetmer.nl/irc-logs/whatwg/20071113 online anywhere? |
| 19:39 | <Philip`> | nate_m: That was a long time ago - lxml ought to work properly in default html5lib now |
| 19:48 | <nate_m> | testing with lxml 2.1.1 and html5lib 0.11.1 fails |
| 19:49 | <Philip`> | Could you give an example of the code you're running that fails? |
| 19:53 | <nate_m> | Yeah, just a minute |
| 19:55 | <nate_m> | >>> from lxml import etree |
| 19:55 | <nate_m> | >>> import html5lib |
| 19:55 | <nate_m> | >>> from html5lib import treebuilders |
| 19:55 | <nate_m> | >>> parser = html5lib.HTMLParser(tree=treebuilders.getTreeBuilder('etree', etree)) |
| 19:55 | <nate_m> | fails |
| 19:55 | <jgraham> | nate_m: That's not expected to work anymore |
| 19:56 | <jgraham> | Try html5lib.HTMLParser(tree=treebuilders.getTreeBuilder('lxml')) |
| 19:56 | <nate_m> | Well I got that from the doc on the code.google.com site |
| 19:57 | <nate_m> | but i'll try the other |
| 19:57 | <jgraham> | Oh. That's probably my fault |
| 19:58 | <nate_m> | You version does work, but i suppose you know that |
| 19:58 | <nate_m> | it also seems that parser = html5lib.HTMLParser(treebuilders.getTreeBuilder('etree', lxml.etree)) works too. |
| 20:01 | <nate_m> | althought that really not the same as it is setting strict to the result of treebuilder.getTreeBuilder |
| 20:01 | <nate_m> | rather than tree |
| 20:02 | <jgraham> | We really have to change that API. I wonder how many people would complain |
| 20:03 | <jgraham> | (because the strict thing is useless but the tree thing is important) |
| 20:06 | <nate_m> | Thanks for the help |
| 20:38 | <Lachy> | hey, I started designing a new layout for the various HTML5 tools. http://html5.lachy.id.au/beta/ |
| 20:38 | <Lachy> | It's still very much a work in progress and nothing is functional yet. But I'm going to try and incorporate many of the tools we have spread across several different sites. |
| 20:48 | <webben_> | Lachy: looks handy :) |
| 20:53 | <Dashiva> | I see JF still thinks there's an infinite amount of time and resources for accessibility |
| 20:59 | <Hixie> | man this longdesc discussion is like the definition of putting the cart before the horse |
| 20:59 | <Philip`> | and the horse might not even exist |
| 21:01 | <Dashiva> | And the cart is too heavy for any known horse to drag |
| 21:03 | <webben_> | Hixie: Can you forsee any problem with speccing describedby where, if describedby pointing to an element with href, the target of the href should be understood as the description, rather than the content of the element? |
| 21:04 | <webben_> | because that could be a way of allowing much the same UI as longdesc allows but using an <a href=""> |
| 21:05 | <webben_> | and it _might_ be possible for UAs to make it backwards compatible with screen readers that support longdesc now. |
| 21:05 | <webben_> | while old visual browsers would still at least get the visible link |
| 21:06 | <Hixie> | webben_: what problem would it be solving? |
| 21:06 | <webben_> | Hixie: programmatic association of description with img. |
| 21:07 | <Hixie> | that's not a problem it's a solution |
| 21:07 | <jgraham> | So apart from anything else, I don't understand why it is that there is general agreement that only a very few people will ever bother with longdesc but it is being argued that those people will still have visual design constraints that will prevent then putting <a href="longdesc.html">longer description</a> in the figure's caption |
| 21:07 | <webben_> | oh, sorry, yes, rapid navigation. |
| 21:07 | <Hixie> | rapid navigation of what? |
| 21:07 | <Hixie> | i'm confused |
| 21:07 | <Hixie> | can you show me a page where there is this problem? |
| 21:07 | <webben_> | images |
| 21:08 | <webben_> | any page with an image and a description of the image |
| 21:08 | <webben_> | (off-page on on-page) |
| 21:08 | <webben_> | *or |
| 21:08 | <Hixie> | seems like the right solution is for the image to be hidden altogether from the user and for the description to be given inline |
| 21:09 | <Hixie> | why taunt the user by letting him know there's an image in the first place? |
| 21:09 | <webben_> | they might want to share the image. they might be referred to the image. |
| 21:10 | <webben_> | pulling the description inline from elsewhere could really mess up presentation of the page too |
| 21:10 | <Hixie> | do you have something more concrete? this seems very hypothetical. |
| 21:10 | <webben_> | replacing img with DOM from elsewhere seems rather hypothetical to me. |
| 21:10 | <Hixie> | who ever said anything about doing that? |
| 21:10 | <Hixie> | give me a url |
| 21:10 | <webben_> | what are you saying? |
| 21:10 | <Hixie> | and i will explain what i mean |
| 21:10 | <Hixie> | with that page as example |
| 21:11 | <Hixie> | (the url of a page with an image that is described) |
| 21:11 | <webben_> | righto |
| 21:11 | <Hixie> | (and described in a way that helps the user more than if the user didn't have access to a description) |
| 21:11 | <Hixie> | (it can be a fake demo page if you want) |
| 21:11 | <Hixie> | (since finding a real page that fufills those conditions is pretty hard) |
| 21:12 | <webben_> | indeed, thanks to people assuming graphics are easier follow |
| 21:18 | <webben_> | Hixie: actually the WAI longdesc example does this, since it has an actual link to the description from the same page as the chart: http://www.w3.org/WAI/wcag-curric/sam3-0.htm |
| 21:18 | <Hixie> | (wow that's horrific alt="" text) |
| 21:18 | <Hixie> | (and in a WAI spec no less) |
| 21:19 | <webben_> | the alt text is fine by HTML4's definition. |
| 21:19 | <Hixie> | Per HTML5, what is currently in longdesc="" for that page should just be in the alt="". |
| 21:19 | <webben_> | you can't put lists in alt |
| 21:19 | <Hixie> | so use <object> |
| 21:20 | <Hixie> | or, just put the description inline right next to the image, and use alt="", so that all users can benefit |
| 21:20 | <Hixie> | and not just those who have images hidden |
| 21:20 | <jgraham> | webben_: That longdesc is substantially more useful to me than the chart |
| 21:20 | <webben_> | jgraham: Me too. :) |
| 21:20 | <jgraham> | So why hide it in an attribute that almost no one can access? |
| 21:20 | <Lachy> | jgraham, webben_ agreed. The description helps *everyone* |
| 21:20 | <Dashiva> | I imagine many complex images have longdesc that's semantically a table. Which will then apparently need a separate @summary. Oh ho. |
| 21:20 | <Hixie> | of the four solutions proposed here -- inline text, alt="", <object> fallback, and longdesc="" -- longdesc is the worst solution here |
| 21:21 | <webben_> | jgraham: er... that's not what I'm arguing for is it? |
| 21:21 | <Lachy> | don't hide it from me, even if you want to put it on a separate page for design reasons or whatever. Just use a normal link |
| 21:21 | <Hixie> | or just put it inline on the page |
| 21:21 | <jgraham> | webben_: Er, I'm not paying much attention to be honest |
| 21:21 | <jruderman> | "Future browsers or other agents will provide an optional a link to the description file called "graph1.htm"." such optimism |
| 21:21 | <Hixie> | five solutions. inline text, <a href="">, alt="", <object> fallback, and longdesc="". longdesc="" is the worst. |
| 21:22 | <webben_> | jgraham: I'm talking about programmatic associations between the <a href="graph1.htm" and the img. |
| 21:22 | <Hixie> | both for visually impaired users and for everyone else. |
| 21:22 | <Lachy> | The 5th and 6th solutions are 5) <a href="desc"><img ...></a> and 6)<img ...> <a href="desc">more information</> |
| 21:22 | <jgraham> | <figure> |
| 21:23 | <webben_> | jgraham: longdesc happens to do that, but I'm talking about whether describedby could provide the same mechanism without repeating the uri. |
| 21:23 | <Lachy> | webben_, I don't understand how you want to use describedby |
| 21:23 | <jgraham> | In fact <figure> + <details> could be neat |
| 21:23 | <webben_> | Lachy: well in that case, you'd stick an id on the link and refer to it from img with describedby |
| 21:24 | <Hixie> | i would personally mark it up as <img src="graph.png" alt=""><p>Ice Cube Tray sales tend to be higher further South, and tend to decline in autumn.</p><details><legend>Data</legend><dl><dt>Far North</dt><dd>Sales were 3, 4, 2, and 1 ice cube trays from... |
| 21:25 | <Hixie> | no need to associate the image with the data -- in fact, no need to even show the image at all when the user can't view images |
| 21:25 | <Hixie> | it should be redundant with the text, thus alt="". |
| 21:25 | Lachy | agrees with Hixie, except s/autumn/spring/ |
| 21:25 | <Hixie> | the graph doesn't show spring. |
| 21:25 | <webben_> | I think the notion that you're going to persuade designers to put massive blocks of text alongside every graph and diagram is optimistic, to say the least. |
| 21:25 | <Hixie> | oh |
| 21:25 | <Hixie> | i see |
| 21:26 | <Hixie> | you're from the upside down part of the planet |
| 21:26 | <Lachy> | it doesn't show autumn either. It only shows months |
| 21:26 | <webben_> | fighting for links to text equivalents is hard enough |
| 21:26 | <Hixie> | webben_: i think the notion that you're going to persuade designiners to put those same massive blocks of text in a different page is even more fantastic. |
| 21:26 | <Dashiva> | We need an element to mark up seasons with, so it's clear what hemisphere the author is referring to |
| 21:26 | <Philip`> | Dashiva: What if you're on the equator? |
| 21:27 | <webben_> | Hixie: Oh, that's not so fantastic. |
| 21:27 | <Dashiva> | Philip`: Flip a coin |
| 21:28 | <Hixie> | webben_: so far i have the web on my side -- people tend to put information about their graphs inline, and tend not to give external descriptions. |
| 21:28 | <Hixie> | (though of course it's much more common for them to not do either) |
| 21:28 | <Hixie> | but if the author really wanted to put the text externally he could too |
| 21:28 | <webben_> | i've mainly seen people trying to _hide_ equivalents. |
| 21:29 | <Hixie> | <p><a href="graph.html"><img src="graph.png" alt="View trends..."></a></p> |
| 21:29 | <Hixie> | (with graph.html containing what i wrote above) |
| 21:30 | <webben_> | so can the spec say that Long descriptions should either be in <figure> or |
| 21:30 | <webben_> | linked via img link? |
| 21:30 | <Hixie> | which spec? |
| 21:30 | <Hixie> | wai? |
| 21:30 | <Hixie> | sure |
| 21:30 | <webben_> | HTML5 |
| 21:31 | <Hixie> | html5 has an entire top-level-section dedicated to how you mark up text |
| 21:31 | <Hixie> | section 4 |
| 21:31 | <Hixie> | i don't really see that we need to repeat it again |
| 21:32 | <webben_> | Section 4. is Web Browsers. |
| 21:34 | <Hixie> | section 4 is "The elements of HTML" |
| 21:35 | <webben_> | oh sorry, looking at the WD not the Editor's Draft. |
| 21:36 | <Hixie> | http://whatwg.org/html5 -- everything else is likely to be out of date :-) |
| 21:38 | <webben_> | hmm, this does make the image and its equivalent impossible to extract together. |
| 21:40 | <webben_> | I guess one could come up with microformats to make them extractable. |
| 21:40 | <Hixie> | it's not clear that many users care about extracting them together |
| 21:41 | <webben_> | you'd probably need it to facilitate something like Aurora. |
| 21:41 | <hober> | besides which, <figure> covers that case, I think |
| 21:41 | <webben_> | hober: except when <figure isn't used. |
| 21:42 | <webben_> | why isn't figure used for the Carouge coat of arms? |
| 21:44 | <webben_> | is the idea that figure can't be main content? |
| 21:44 | <webben_> | "which can be moved away from the main flow of the document without affecting the document's meaning." ... I guess so. |
| 21:46 | <webben_> | hober: so that won't work for Aurora, where the example is a weather chart which appears to be the main content. |
| 21:46 | <webben_> | IIRC. |
| 22:02 | <Hixie> | given: |
| 22:02 | <Hixie> | <!DOCTYPE html><form><input name=a><input name=item></form> |
| 22:02 | <Hixie> | <script> var a = document.forms[0].item(0); w(a.name); |
| 22:02 | <Hixie> | </script> |
| 22:03 | <Hixie> | s/w/alert/ |
| 22:03 | <Hixie> | what should the alert say? |
| 22:03 | <Hixie> | in IE the alert says "undefined" |
| 22:03 | <Hixie> | in every other browser, there is no item() method |
| 22:03 | <Hixie> | wtf is IE doing |
| 22:04 | <webben_> | that's freaky |
| 22:04 | <webben_> | does it do anything right with a? |
| 22:04 | <webben_> | e.g. a.tagName ? |
| 22:04 | <Hixie> | nope |
| 22:05 | <Hixie> | but alert(a) returns HTMLFormElement |
| 22:05 | <Hixie> | er |
| 22:05 | <Hixie> | HTMLInputElement even |
| 22:05 | <webben_> | that's um, extra freaky |
| 22:05 | <Hixie> | oh |
| 22:05 | <Hixie> | typeof a returns string |
| 22:05 | <Hixie> | (!) |
| 22:06 | <Hixie> | wtf is IE doing |
| 22:06 | <Hixie> | i'm going to ignore IE here |
| 22:06 | <jruderman> | it returns the string "HTMLInputElement"? that's not especially useful |
| 22:07 | <Hixie> | it's got to be a bug of some kind |
| 22:07 | <Lachy> | Hixie, for longdesc to be included, is this all that needs to be provided: 1. Use cases, 2. Evidence that UAs have implemented usable UI, 3. Evidence that authors have begun to use it properly on a significant scale, and 4. Proof that it's better than any of the other solutions for the use cases? |
| 22:07 | <hsivonen> | doesn't IE usually dodge these issues and alert "[object]"? |
| 22:07 | <Lachy> | did I miss anything? |
| 22:08 | <jruderman> | Lachy: i don't expect any of those to exist... |
| 22:08 | <Lachy> | jruderman, I realise they don't exist now. But I'm trying to explain in my next email what needs to be provided for longdesc to be considered for inclusion |
| 22:08 | <Hixie> | Lachy: we have to go through the same process as everything else, as described in my recent e-mail to public-html, and as given on the whatwg faq |
| 22:09 | <Hixie> | Lachy: which starts with establishing what the problem is |
| 22:09 | <Hixie> | Lachy: and then considering solutions to that problem |
| 22:10 | <Lachy> | ok, I'll rephrase what I have to incorporate that. I'm just trying to make it as clear as possible what they need to provide |
| 22:11 | <Hixie> | hsivonen: IE8 changed that, it starts returning actual class names for host objects |
| 22:11 | <Hixie> | Lachy: i already did that |
| 22:11 | <Hixie> | Lachy: and jf replied (completely missing the point) |
| 22:12 | <hsivonen> | Hixie: he didn't recognize "next best" as being part of the definition of opportunity cost |
| 22:12 | <hsivonen> | I guess I should clarify tomorrow |
| 22:15 | <Hixie> | i was impressed at how completely he failed at actually clearly describing a problem |
| 22:16 | <Hixie> | how answer to "Come up with a clear description of the problem that needs to be solved." was SIX paragraphs |
| 22:16 | <Hixie> | none of which actually gave a problem description |
| 22:17 | <Hixie> | he listed needs and requirements, without actually saying what he was trying to fix |
| 22:17 | <Hixie> | and as part of the _problem_ description, he asserted what the best solution was |
| 22:17 | <Dashiva> | Sometimes I wonder if there's actually a movement _for_ bolt-on accessibility because that way you're sure it's "real" accessibility and not "just" a side effect of language semantics. |
| 22:18 | <Hixie> | maybe |
| 22:18 | <Hixie> | my goal is to improve actual end-user accessibility |
| 22:18 | <Dashiva> | If said movement exists, they would fight you every step of the way |
| 22:18 | <Hixie> | i doubt such a movement is conscious |
| 22:18 | <Dashiva> | True |
| 22:19 | <Hixie> | but i do think that there are people who have that mindset |
| 22:19 | <Hixie> | it's sad, since they are having a net negative effect on global accessibility |
| 22:19 | <hober> | classic "road to hell paved with good intentions"... |
| 22:20 | <webben_> | Dashiva: Well, there was one fellow in HTML WG arguing to abolish the semantics of ordinary HTML elements and move all semantics to role or CSS or something. |
| 22:21 | <webben_> | (because of fears of presentational use of those elements contaminating the meaning) |
| 22:21 | <Dashiva> | Isn't that more of an argument to remove default styling? |
| 22:21 | <webben_> | it would be _an_ argument for it yes |
| 22:22 | <webben_> | I think that may have been an alternative he put forward |
| 22:22 | <webben_> | at any rate, the principle is that bolt-on is more reliable |
| 22:23 | <webben_> | I don't think JF's arguing that bolt-on is better though. |
| 22:23 | <hsivonen> | Cascading Semantic Sheets came up in the RDFa thread as well |
| 22:23 | <webben_> | just that design considerations will require bolt-on |
| 22:24 | <webben_> | (compare Dojo's "restyling" of widgets - i.e. using div and span - leading (in part) to ARIA |
| 22:24 | <Dashiva> | Well, I think there's a significant difference between bolt-on information (e.g. longdesc) and bolt-on associations (e.g. pointing to normally visible content) |
| 22:25 | <webben_> | longdesc doesn't have to point to invisible content. |
| 22:25 | <Dashiva> | No, but the implication order is switched |
| 22:25 | <Dashiva> | To have an association, you need the content to be present in the first place |
| 22:26 | <Dashiva> | longdesc puts it in an invisible place, so it's quite possible the content isn't available from other places |
| 22:26 | <webben_> | by the information do you mean the URI? |
| 22:26 | <webben_> | as opposed to the description? |
| 22:29 | <Dashiva> | I'm not sure what you mean |
| 22:30 | <webben_> | hmm. I'm not sure what you mean either. :) |
| 22:30 | <Dashiva> | Just that the content should not be created for accessiblity purposes |
| 22:31 | <webben_> | what content? descriptions? |
| 22:34 | <Dashiva> | webben_: All content, descriptions included |
| 22:36 | <webben_> | and it should instead be created for what purposes? |
| 22:36 | <Dashiva> | For being useful in general |
| 22:37 | <webben_> | if useful in general === communicating to human beings, then that would appear to be the same thing. |
| 22:38 | <Dashiva> | Yeah, if you assume page authors are angelic beings of perfection |
| 22:39 | <webben_> | I thought you were making a statement about what they "should" do. |
| 22:39 | <Dashiva> | No, I'm making a statement about what we should hope for |
| 22:40 | <Dashiva> | And if we can make regular joes write content for regular joes, and get accessibility included by default, that's a win |
| 22:41 | <webben_> | people with disabilities are regular joes. |
| 22:41 | <Dashiva> | No, they're regular joes with disabilities |
| 22:42 | <Dashiva> | The more special treatment we require for accessiblity, the less we will get (outside of content ruled by certain laws) |
| 22:43 | <webben_> | If you're just restating Hixie's point that a language should have as much accessibility-for-free built in, then sure. |
| 22:43 | <webben_> | *as much ... as possible |
| 22:43 | <Dashiva> | Not just that, but the parts that aren't built-in should be as close as possible |
| 22:44 | <Dashiva> | So to get back to the start, stuff that requires _new_ content to be made for accessiblity is bad |
| 22:44 | <webben_> | new content? |
| 22:44 | <webben_> | like what? |
| 22:44 | <Dashiva> | ... |
| 22:44 | <Dashiva> | Like longdesc, maybe? |
| 22:44 | <webben_> | longdesc isn't "content" |
| 22:45 | <webben_> | it points to content |
| 22:45 | <Dashiva> | Yes |
| 22:45 | <webben_> | by content, do you mean "code"? |
| 22:45 | <Dashiva> | No, I mean content |
| 22:45 | <Dashiva> | By putting longdesc in an invisible attribute, you place the assumption that the content it points to isn't interesting for anyone else |
| 22:45 | <webben_> | no you don't |
| 22:46 | <webben_> | that's the assumption developers of browsers have made |
| 22:46 | <webben_> | (well, some browsers) |
| 22:46 | <Dashiva> | If that wasn't the case, we wouldn't want to put it in an attribute, we'd put it in plain view for everyone |
| 22:46 | <webben_> | that's not at all obvious ... look at tile |
| 22:46 | <webben_> | *title |
| 22:47 | <webben_> | or indeed, IE displaying alt as tooltip |
| 22:47 | <Dashiva> | A tooltip is special UI |
| 22:47 | <webben_> | Dashiva: just as was supposed to exist for longdesc, yes. |
| 22:47 | <Dashiva> | You don't need speical UI for a link. We kinda invented those years ago. |
| 22:48 | <webben_> | I think that's premised on a single-model view of linking. |
| 22:49 | <webben_> | (that's not an unreasonable view of linking, but it's far from the only one) |
| 22:49 | <webben_> | it also doesn't really explain why we need a UI for advisory information |
| 22:50 | <Dashiva> | Well, turn it around. Why would you take an awesome accessibility resource and put it behind UI that doesn't exist yet? That seems like a very risky proposition. |
| 22:50 | <webben_> | Dashiva: Why use any new features? |
| 22:51 | <webben_> | all put interoperability at risk |
| 22:51 | <Dashiva> | Because when you frame it as accessiblity, you have to be twice as careful |
| 22:51 | <webben_> | or browser vendors might misunderstand what it's for? |
| 22:53 | <Dashiva> | You could see it as marketing. You get things done a lot easier by saying "You want this (and that way I get it too)" than just "I want this" :) |
| 22:53 | <Hixie> | Lachy: it actually _is_ the pipes screen saver (re your blog) |
| 22:53 | <webben_> | yeah, I'm not terribly impressed by the universalism school of accessibility marketing. |
| 22:54 | <webben_> | tends to lead to lots of effort spent making things work without JS and on old/broken browsers, and less attention to making things work for actual people. |
| 22:54 | <webben_> | (not that interoperability isn't a perfectly nice goal in its own right and all) |
| 22:55 | <Dashiva> | Take a cat herder view of our mandate, and things start to make sense :) |
| 22:57 | <annevk> | geez, >1000 log lines |
| 22:57 | <annevk> | longdesc spam? |
| 22:57 | <Dashiva> | This channel? |
| 22:57 | <Dashiva> | Mostly, yes |
| 22:57 | annevk | sighs |
| 22:57 | <Dashiva> | zcorpan talked some about dom core |
| 22:58 | <Philip`> | There might be some rubbish jokes in the log too |
| 22:58 | <webben_> | hixie talked about form and input stuff too |
| 22:58 | <annevk> | Philip`, I filter your lines :p |
| 22:59 | <Dashiva> | Maybe we need IRC threading |
| 22:59 | <annevk> | Philip`, I'll put the trackerlib update on html5 |
| 22:59 | <Dashiva> | There are experimental bots that do it, I hear |
| 22:59 | <csarven> | Or simply #tag a few lines! |
| 22:59 | <csarven> | That could let the reader scan the log lines for certain conversations. |
| 23:00 | <webben_> | @longdesc bla bla bla :) |
| 23:00 | <webben_> | or maybe "re longdesc bla bla bla" |
| 23:00 | <Dashiva> | csarven: Just search for \blongdesc\b or \balt\b and you've got your tags ;) |
| 23:00 | <csarven> | #readability #irc #logs |
| 23:00 | <annevk> | meanwhile, 1 person so far generated a diff with a different context (and maybe more people used it afterwards) |
| 23:01 | <csarven> | Dashiva I said "scan"ing the logs, not read every line ;) |
| 23:04 | <annevk> | zcorpan, why does getElementsByTagNameNS not throw? |
| 23:09 | <annevk> | Philip`, done |
| 23:15 | <Philip`> | annevk: You probably want to sanitise the 'source' variable, instead of passing user input directly to the shell via popen |
| 23:16 | <annevk> | Philip`, how is source user input? |
| 23:17 | <annevk> | hmm, I thought I killed that feature |
| 23:18 | <Philip`> | annevk: html5.org/tools/web-apps-tracker?source=|shell%20code| etc |
| 23:19 | <annevk> | killed |
| 23:20 | <Philip`> | Thanks :-) |
| 23:21 | <annevk> | Hixie, btw, svn log is still being hit; hopefully not intensive enough for it to be a problem, but if that turns out to be a problem as well let me know and I'll start caching that too |
| 23:29 | <annevk> | (svn complains about googlecode not having the right certificate) |
| 23:31 | <Lachy> | Hixie, do you mean that Google Chrome actually loads and executes the real sspipes.scr, or does it just emulate it somehow? |
| 23:32 | <annevk> | it loads and executes the real sspipes.scr |
| 23:32 | <annevk> | see blogs |
| 23:33 | <Philip`> | Lachy: http://src.chromium.org/svn/trunk/src/chrome/browser/about_internets_status_view.cc |
| 23:34 | <Lachy> | oh, cool. that mean it will also get the teapots :-) |
| 23:37 | <annevk> | zcorpan, it's complete mystery to me how createElementNS arrives at localName |
| 23:41 | <annevk> | zcorpan, getElementById should return the first element matching ID, I think |
| 23:41 | <annevk> | zcorpan, not just any |
| 23:41 | annevk | thinks zcorpan scans the backlog |