| 00:03 | <othermaciej> | annevk: we already have hit testing ability in the engine to determine "where the caret would go if you clicked here in an editable area" |
| 00:03 | <othermaciej> | annevk: so it's not that tricky |
| 00:03 | <othermaciej> | we have that code because we already need to do that for actual editable areas |
| 00:04 | <roc> | yeah |
| 00:04 | <roc> | maybe we need two methods :-( |
| 00:05 | <annevk> | textRangeFromPoint and rangeFromPoint ? |
| 00:05 | <annevk> | the former does the caret thingie (no idea how to define that in prose yet) and the latter does the char -> element thingie |
| 00:06 | othermaciej | shrugs |
| 00:06 | <othermaciej> | SVG also has hit testing APIs |
| 00:07 | <othermaciej> | but only on elements that contain text (so hit testing to the element has to be done first as a separate step() |
| 00:08 | <annevk> | grmbl, the SVG spec is so complex and hard to navigate |
| 00:09 | <shepazu> | anne, are you looking for text selection stuff? |
| 00:09 | Philip` | thinks the HTML5 spec is more complex and harder to navigate |
| 00:10 | <hsivonen> | Philip`: at least the HTML5 spec comes as a single file so seaching on the page works |
| 00:10 | <shepazu> | we need more extensive indexing, which we're working on |
| 00:10 | <hsivonen> | I have to search the SVG 1.1 spec as PDF |
| 00:10 | <hsivonen> | because the multipage HTML version is a pain to work with in a random access manner |
| 00:10 | <Philip`> | http://www.google.com/search?q=site%3Aw3.org+inurl%3Atr%2Fsvg+purple |
| 00:11 | <othermaciej> | annevk: http://www.w3.org/TR/SVG/text.html#DOMInterfaces |
| 00:11 | <othermaciej> | getCharNumAtPosition is what I was thinking of |
| 00:11 | <othermaciej> | though getStartPositionOfChar, getEndPositionOfChar, and getSubStringLength provide the opposite direction |
| 00:12 | <othermaciej> | I think getCharNumAtPosition may not be compatible with DOM range notions of offset though |
| 00:13 | Philip` | wonders if Opera 9.5 has fixed the thing where search-as-you-type is incredibly slow, because it tries highlighting every occurrence in the 2MB file of the letter "e" when you're trying to start searching for "elephants" or whatever |
| 00:14 | <annevk> | i guess we don't need to worry about those methods... |
| 00:14 | <othermaciej> | yeah, I'm just mentioning them as prior art |
| 00:14 | <othermaciej> | not sure they are the best model to generalize |
| 00:14 | <weinig> | annevk: I am curious as to what your opinion is on what to do when not enough arguments are passed to a method like getRequsetHeader from the XMLHttpRequest Object spec |
| 00:15 | <Philip`> | (Aha, it has, by just making the search/highlighting much faster) |
| 00:15 | <annevk> | weinig, whatever Web IDL says should happen :) |
| 00:15 | <weinig> | annevk: ah, ok |
| 00:16 | <othermaciej> | normal practice is to just threat missing arguments as undefined rather than going out of your way to throw |
| 00:16 | <annevk> | weinig, at some point http://www.w3.org/TR/DOM-Bindings/ will be named "Web IDL" and when that happens I'll update XMLHttpRequest to explicitly point to it I guess so all that will be resolved automatically |
| 00:16 | <othermaciej> | so I'd say do that unless it is spec'd differently for some specific case |
| 00:16 | <othermaciej> | or undefined would be a type error |
| 00:17 | <othermaciej> | or would stringify or numberify as something that raises an error |
| 00:17 | <annevk> | or maybe caretRangeFromPoint() |
| 00:17 | <annevk> | that would make it explicit :) |
| 00:18 | <annevk> | and although arguably the name is not abstract enough as some UIs might not have a caret, it's very clear for authors |
| 00:18 | <roc> | sounds good |
| 00:19 | <annevk> | g'night all, will look into this more tomorrow |
| 00:24 | <Philip`> | Hixie: The "h1-h6" in the spec would look much nicer with an en-dash |
| 00:48 | Philip` | sees http://www.whatwg.org/specs/web-apps/current-work/multipage/section-sections.html#headings0 saying "&endash;" |
| 00:48 | <Philip`> | but the commit email had – instead |
| 00:48 | Philip` | wonders if it's just slow at regenerating |
| 00:50 | <Philip`> | Hixie: http://krijnhoetmer.nl/irc-logs/whatwg/20080418#l-201 |
| 00:52 | <Hixie> | yeah i was reading the archives |
| 00:52 | <Hixie> | there is no way for me to check something in that isn't what the site has |
| 00:52 | <Hixie> | because i check in the same file that apache serves |
| 00:52 | <Hixie> | so try reloading :-) |
| 00:53 | <Philip`> | I've reloaded multiple times, and it still says &endash; |
| 00:53 | <Philip`> | though the single-page version looks right |
| 00:53 | <Philip`> | and much nicer than those ugly hyphens - thanks :-) |
| 00:56 | <Lachy> | It's nice to see Microsoft have agreed to change their selectors api implementation. http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0189.html |
| 00:56 | <Hixie> | oh the multipage version always lags behind |
| 00:57 | <Hixie> | i have another host that generates it |
| 00:58 | <Philip`> | Hixie: Ah, right |
| 01:38 | <Hixie> | woah, my imap server just got way faster |
| 01:41 | <andersca> | nice |
| 01:42 | <bradee-oh> | Hixie: does this mean the frequency at which we can expect your batch email replies increased, as well? |
| 01:43 | <Hixie> | yes, but this is "way faster" compared to yesterday, not compared to last week |
| 01:43 | <Hixie> | these past few days my imap server got stuck in a swamp somewhere and was having trouble getting data out of the mud |
| 01:47 | <Philip`> | Maybe it was scared of the alt discussion |
| 01:56 | <Philip`> | Hixie: The multipage one still says &endash;, so that's quite a lot of lag... |
| 01:57 | <Hixie> | odd |
| 01:57 | Hixie | runs .update.sh again |
| 02:38 | <MikeSmith> | roc: was just reading your latest blog entry |
| 02:39 | <MikeSmith> | well put |
| 02:40 | <roc> | thanks, but I mostly just cribbed from #whatwg |
| 02:40 | <roc> | :-) |
| 02:41 | Hixie | blushes at the implication of the target of the link for "few people" |
| 02:47 | <MikeSmith> | fwiw, in the product-development organizations I've been in, I've found that experienced QA people are also grossly undervalued |
| 02:47 | <MikeSmith> | by experienced I mean experienced with a particular product |
| 02:48 | <MikeSmith> | they have whole lot of information in their heads that they've acquired through many instances of testing and troubleshooting that product |
| 02:53 | <roc> | we've got quite a few of those people. Not sure if they're undervalued or not. I hope not |
| 08:27 | <Hixie> | i wish i understood what the real problem was with this alt text issue |
| 08:27 | <Hixie> | i'm clearly missing something |
| 08:42 | <hsivonen> | Hixie: the underlying problem statements aka. use cases would indeed be more useful than a dogmatic syntax conclusion |
| 08:46 | <Hixie> | i tried to go that way with my recent e-mail |
| 08:54 | hsivonen | looks if the TAG thread needs a reply from me |
| 08:54 | <annevk> | I hope my reply is enough |
| 08:55 | <annevk> | though maybe I should have stayed out of it |
| 08:55 | <annevk> | it's not like they're going to affect anything |
| 08:56 | <hsivonen> | annevk: ah you replied already. thanks |
| 08:57 | <othermaciej> | which list? |
| 08:58 | <hsivonen> | othermaciej: www-tag |
| 09:00 | <annevk> | I can't believe people are suggesting to hurt copy-and-paste authors. Copy-and-paste is the nr1 feature of the Web platform. |
| 09:04 | <othermaciej> | whoever wants to hurt copy-paste authors should talk to the SVG WG |
| 09:05 | <annevk> | It was in that thread, exactly. Though not by someone from the SVG WG :) |
| 09:07 | <annevk> | The alt e-mail flame war is accomplishing exactly nothing it seems :( |
| 09:09 | <Lachy> | annevk, I wouldn't call it nothing, though it's very little. There was some discussion about how to gather data on the use of alt, which would be useful, though no results from that yet. |
| 09:12 | <hsivonen> | it has altered my software development priorities |
| 09:13 | <hsivonen> | although letting it alter the priorities may set a bad precedent if it seems that the way to get me to write software is to make spec discussions too unproductive |
| 09:13 | <om_sleep> | man, TAG people love the colon character |
| 09:13 | <hsivonen> | indeed |
| 09:14 | <hsivonen> | that's another dogma |
| 09:14 | <othermaciej> | like, they don't even care any more if it is even used as a namespace prefix separator |
| 09:14 | <othermaciej> | as long as there's colons |
| 09:16 | <Lachy> | some usability studies performed on sites like wikipedia that evaluated the very redundant use of alt="...", title="..." and image captions in their articles would be useful. |
| 09:16 | <hsivonen> | I guess at some point someone has to make the impolite point that if a TAG member can't get a reasonable code path condition written in 6 hours, how do they expect Joe Blow to get it right |
| 09:17 | <othermaciej> | because the Tools Will Save Us |
| 09:17 | <othermaciej> | and Everyone Will Just Use a Library |
| 09:17 | <hsivonen> | seriously, making a sniffer that has different paths for Firefox and Opera and an untested failure in Safari should be a red flag |
| 09:20 | <hsivonen> | Hixie: when a markup generator makes a linked thumbnail of a photo of unknown meaning, would you put the function of the link in alt? |
| 09:20 | <hsivonen> | alt=thumbnail 30 per page |
| 09:21 | <hsivonen> | 30 times |
| 09:21 | <hsivonen> | with current AT even that would be less bad than letting the crazy file name reading kick in |
| 09:24 | <Lachy> | I think some people are focussing too much on the spec saying "rare subset", rather than considering that the conditions need to be evaulated on an individual site basis. |
| 09:25 | <Lachy> | although I thought the spec said rare as a way to encourage people to avoid the situation if possible, people seem to be interpreting it as a loophole that people will aim for |
| 09:27 | <othermaciej> | "thumbnail" isn't good text for the link |
| 09:27 | <hsivonen> | it isn't |
| 09:27 | <othermaciej> | since the link surrounding a thumbnail doesn't lead to a thumbnail, it leads to the full photo page |
| 09:27 | <hsivonen> | but it's less horrible than reading out a GUID or some other hex name |
| 09:27 | <hsivonen> | right |
| 09:28 | <othermaciej> | I think <a title="photo page"> or something might be right |
| 09:28 | <othermaciej> | maybe even duplicate title or description there |
| 09:28 | <othermaciej> | I dunno |
| 09:28 | <hsivonen> | assuming that title isn't IMG3827.JPG |
| 09:30 | <othermaciej> | fair enough |
| 09:31 | <hsivonen> | I think the default behavior of Flickr Uploadr sucks, btw |
| 09:31 | <hsivonen> | it's a classic example of having a metadata field (title) and trying to fill it with *some* junk when the user is uncooperative |
| 09:32 | hsivonen | uses his own custom uploader |
| 10:04 | <Hixie> | hsivonen: based on impl experience we had when mozilla experimented with this, imho the src or parts of the src are never good alt text |
| 10:04 | <Hixie> | well, never is strong |
| 10:04 | <Hixie> | not often enough that it should be considered by the ua |
| 10:05 | <Hixie> | the point of thumbnails is to provide a quick overview of what is available |
| 10:06 | <Hixie> | if nothing but the image is known (i.e. no metadata at all) then you might as well just say alt="2" alt="3" etc |
| 10:06 | <Hixie> | as in: <p>Photos: <img src=... alt="1"> ... <img src=... alt="50"></p> |
| 10:06 | <hsivonen> | Hixie: shouldn't that be aria-posinset='2', etc.? |
| 10:06 | <Hixie> | with links, of course |
| 10:06 | <Hixie> | why? |
| 10:07 | <Hixie> | i think the aria thing is a classic example of second system syndrome |
| 10:07 | <hsivonen> | Hixie: to make the user experience consistent with other "items n of M" cases |
| 10:07 | <Hixie> | and people apply solution-looking-for-a-problem attitudes when they learn of it |
| 10:08 | <hsivonen> | Hixie: I wasn't looking for a use of ARIA here |
| 10:09 | <Hixie> | my last two lines weren't really related to your suggestion |
| 10:09 | <Hixie> | just a general observation |
| 10:09 | <Hixie> | but frankly even in this case i don't see much point |
| 10:09 | <Hixie> | it's a bunch of links |
| 10:09 | <Hixie> | people know how to deal with those |
| 10:09 | <Hixie> | what's the problem we're trying to solve? |
| 10:09 | <hsivonen> | in fact, I think this case happens to be one where the posinset/setsize design would actually make sense |
| 10:10 | <hsivonen> | in the more obvious cases, the current ARIA design kinda sucks |
| 10:10 | <hsivonen> | Hixie: the problem we are trying to solve is to convey that we have N links to photos and we don't know what those photos are about |
| 10:11 | <Philip`> | You should draw all the images onto a canvas and then use some JS code to map mouse coordinates onto links |
| 10:11 | <Philip`> | and then you wouldn't have to worry about alt text at all |
| 10:11 | <hsivonen> | if it is a set of N links, presumably it would be good for the UE to be the same as the AT presenting a set of N items in general |
| 10:13 | <hsivonen> | Please try out the new "Image Report" feature of Validator.nu and help me make the UI text suck less |
| 10:13 | <hsivonen> | there's a tension between instructing first-time users and making the UI non-crufty for repeat users |
| 10:15 | <Hixie> | hsivonen: i don't really see why N is especially more relevant in this case than in any other case of a set of links |
| 10:16 | <Hixie> | (and thus why the UA wouldn't automatically do all this clever processing itself) |
| 10:17 | <hsivonen> | Hixie: yeah, it's only relevant on paged flickr thumbnail pages |
| 10:17 | <hsivonen> | where the ARIA stuff would make it possible to spread the N links across several HTML pages |
| 10:17 | <hsivonen> | Hixie: but I agree that in general the assumption that the author should manage posinset/setsize sucks |
| 10:18 | <hsivonen> | see my feedback on public-pfwg-comment |
| 10:18 | <Hixie> | the image report is cool, though wordy. not sure how to reduce that though. |
| 10:20 | <Hixie> | I would have a warning if there's an image without alt="" saying "N images were not declared as decorative and yet had no alternative text specified; please see the _image_report_ to manually check that this is appropriate." or some such |
| 10:28 | <hsivonen> | Hixie: that might make the report more discoverable, yes |
| 10:28 | hsivonen | is annoyed at Leopard Screen Sharing not doing full screen |
| 10:28 | <hsivonen> | do I have to pay for Pro or something? :-) |
| 10:29 | hsivonen | wants VNC connections to appear in Spaces so that local and remote spaces look the same |
| 10:32 | <hsivonen> | anyway, if anyone has better UI text, Validator.nu pulls the UI text from the wiki at startup |
| 10:34 | <annevk> | I wonder if the wordy descriptions should go on a separate page with pointers |
| 10:34 | <annevk> | so that for frequent use you don't have to scan all those paragraphs |
| 10:34 | <hsivonen> | that's a possibility |
| 10:36 | <hsivonen> | I should show off the RTL support: http://html5.validator.nu/?doc=http%3A%2F%2Fhe.wikipedia.org%2Fwiki%2F%25D7%25A2%25D7%259E%25D7%2595%25D7%2593_%25D7%25A8%25D7%2590%25D7%25A9%25D7%2599&showimagereport=yes&showsource=yes#l244c238 |
| 10:39 | <annevk> | does the validator check <a> <img alt> </a> cases? |
| 10:40 | <hsivonen> | annevk: no, but it checks for <a> <img> </a> |
| 10:41 | <hsivonen> | annevk: when the alt attribute is present, linkness doesn't seem to need further considerations at least not in VO |
| 10:41 | <annevk> | if the alt attribute is the empty string as in my example it is probably an authoring error |
| 10:42 | <hsivonen> | at least with VO, not a worse authoring error than misapplying alt='' in general |
| 10:43 | <annevk> | i think that <a> <img alt> </a>, <button><img alt></button> (others?) should be non-conforming |
| 10:43 | <hsivonen> | moreover, the code currently doesn't distinguish <a><img alt=''></a> and <a><img alt=''> Redundant text</a> |
| 10:44 | <annevk> | (if there's text it's obviously a different case) |
| 10:45 | <hsivonen> | yeah, but it's also obviously more difficult to check for in SAX, hence, left undistinguished in the first version |
| 10:48 | <hsivonen> | Hixie: I'm not sure I want to add the warning you suggested since it changes the badge hunter effects of the feature |
| 10:52 | <annevk> | i was more thinking about it being a content model restriction |
| 10:52 | <hsivonen> | Ah. |
| 10:53 | <Lachy> | <a><img> text</a> could also be considered non-conforming, since the only logical alt text for it would be alt="" or alt="non-redundant text". Omitting alt in that case would obviously be an error |
| 10:53 | <hsivonen> | I think I'd still use the same code. |
| 10:53 | <hsivonen> | (as amended to distinguish the cases, that is) |
| 10:57 | hsivonen | wonders how dictionary-based Hebrew text-to-speech needs to be |
| 11:04 | <zcorpan_> | hsivonen: i think the image report is a bit unstructured visually; the sections blend together and it looks like one big blob of text. i think it would help with h3 { font-style:italic } or something |
| 11:06 | <zcorpan_> | and/or more spacing between the sections |
| 11:07 | <mpt> | Lachy, I worked on a page design this week where that markup pattern would have non-empty alt= text |
| 11:08 | <mpt> | Specifically, something like 'Owner: <a href="...+edit"><img alt="[Edit]" src="edit-icon" /> Rowley Birkin</a>' |
| 11:09 | <Lachy> | mpt, yeah, that would be the alt="non-redundant text" case I mentioned. |
| 11:10 | <mpt> | oh, right |
| 11:10 | <zcorpan_> | hsivonen: uh, actually, never mind... for some reason the headings aren't bold for me in opera |
| 11:10 | <mpt> | I was thinking we were still in the phase where <img> == <img alt=""> |
| 11:11 | <Philip`> | hsivonen: It took me quite a while to realise that the top list of images was ones with alt="" |
| 11:11 | <Philip`> | since it's not obvious that the "Omitted from non-graphical presentation" heading is associated with that table, and it's not obvious what that heading means anyway, and I don't want to read all the text |
| 11:12 | <hsivonen> | Philip`: would it help if h3 had a larger margin-top? |
| 11:13 | <Philip`> | (Also the <th>Image</th> should maybe have text-align:right since it looks quite unbalanced when the image directly under the heading is very narrow and right-aligned) |
| 11:13 | <Lachy> | mpt, the spec basically says alt="" means decorative, missing alt means key part of the content (not decorative), without any alt text available from any reliable source |
| 11:13 | <mpt> | ok, good |
| 11:14 | <Philip`> | hsivonen: I imagine that could help with making the heading seem associated with the text+table, rather than just with the text |
| 11:15 | <hsivonen> | Philip`: any suggestion on how to make it look that way? |
| 11:15 | <Philip`> | hsivonen: You already gave a suggestion that seems reasonable to me :-) |
| 11:16 | <zcorpan_> | hsivonen: i had rules in user.css that took away the boldness |
| 11:17 | <hsivonen> | zcorpan_, Philip` : is it better now after reload? |
| 11:18 | <Philip`> | hsivonen: Hmm, I think the <th>Image</th> needs some padding-right or something |
| 11:18 | <Philip`> | but otherwise it does look better |
| 11:18 | <hsivonen> | oh right |
| 11:19 | <hsivonen> | what about now? |
| 11:19 | <Philip`> | hsivonen: That looks more better now |
| 11:20 | <hsivonen> | ok |
| 11:20 | <Philip`> | Is it at all useful to say "From line 90, column 146; to line 90, column 301", instead of "Line 90, column 146"? |
| 11:20 | <Philip`> | I can imagine automatic syntax-highlighting tools caring, but not humans |
| 11:21 | Philip` | goes for a while |
| 11:21 | <hsivonen> | the location number matter if you want to correlate stuff with a text editor buffer manually |
| 11:22 | <zcorpan_> | hsivonen: yep, looks better now. (i now have body, label { font-weight:normal } in user.css instead of what i had before) |
| 11:22 | <hsivonen> | otherwise, you can check "Show Source" and use the links |
| 11:22 | <hsivonen> | zcorpan_: is that your user.css in general of for validator.nu in particular? |
| 11:24 | <zcorpan_> | hsivonen: for validator.nu in particular. the use of system fonts in your style sheets in combination of my font choise in windows makes everything go bold in opera otherwise |
| 11:24 | <hsivonen> | ok |
| 11:36 | <zcorpan_> | hsivonen: the image report is very useful |
| 11:36 | <zcorpan_> | hsivonen: good work :) |
| 11:43 | <zcorpan_> | hsivonen: i think the headings would require less thinking from the user if they just said "Images with alt=''", "Images without alt", etc |
| 11:44 | <hsivonen> | zcorpan_: thanks. and yeah, changing the headers like that might make sense |
| 11:44 | <hsivonen> | too bad I'll have to change the interfaces to do <code> in heading :-( |
| 11:46 | <zcorpan_> | hsivonen: might also be useful with a TOC at this point, not sure |
| 12:01 | <Philip`> | hsivonen: You can correlate stuff with a text editor buffer manually just with the start location, and press your text editor's "jump to closing angle bracket" key to find the end location |
| 12:04 | <Philip`> | hsivonen: "The img elements of the page (if any) ..." - you could remove the "(if any)", and replace the image report with "There are no img elements on the page." if there aren't any |
| 12:06 | <Philip`> | "Please review that the images in the group match the definition all what kind of images should appear in that group." - s/all/of/, or maybe s/.*/Please review that the images in each group match that group's definition./ which hopefully says the same but more concise |
| 12:12 | Philip` | wonders what happens if he pastes into IRC <a ... title="ויקיפדיה:הבהרה משפטית">הבהרה משפטית</a> |
| 12:12 | <Philip`> | Hmm, doesn't give the intended effect in my client, but http://krijnhoetmer.nl/irc-logs/whatwg/20080418#l-494 does |
| 12:13 | <Philip`> | Don't Hebrew HTML authors get horribly confused by their markup getting rendered like <a ... title="some text<"some text</a> ? |
| 12:56 | <Philip`> | http://www.google.com/search?q=%221+comments%22 - grammar are hard |
| 13:10 | <hsivonen> | argh. while I'm away writing alt-related software and docs, the thread just keeps growing |
| 13:46 | <hsivonen> | Philip`: fixed UI strings. thanks |
| 14:38 | <hsivonen> | bad the link function in WordPress is sad. it doesn't escape & |
| 14:52 | <hendry> | hsivonen: use http://packages.qa.debian.org/i/ikiwiki.html :) |
| 15:01 | <hsivonen> | hendry: Hixie only installs software that Dreamhost supports |
| 15:07 | <annevk> | hsivonen, wow, long post |
| 15:11 | <Philip`> | hsivonen: s/the market generator/the markup generator/ ? |
| 15:11 | <hsivonen> | oops. I blame speech-to-text |
| 15:11 | <Philip`> | Also s/in// in "pretend that in the case" |
| 15:12 | <hsivonen> | Philip`: thanks |
| 15:15 | <Philip`> | hsivonen: http://validator.nu/?doc=http%3A%2F%2Fwww.coalitionforjustice.net%2F shows 4 messages but http://validator.nu/?doc=http%3A%2F%2Fwww.coalitionforjustice.net%2F&showimagereport=yes only shows 3, which seems odd |
| 15:16 | <hsivonen> | Philip`: indeed. thanks. I'll investigate later. |
| 15:18 | <Lachy> | hsivonen, the tables in the image report need visible borders and it would help if the table headers were left aligned or centred, rather than right aligned. |
| 15:19 | <Lachy> | and make the th's bold or something to distinguish them from td's |
| 15:24 | <Lachy> | hsivonen, it seems to be quite usable, though I think the presentation needs some improvment. |
| 15:24 | <Lachy> | I wonder if it would be possible to have a feature that showed the images with some of their surrounding content to put them in context. |
| 15:32 | <Lachy> | hsivonen, it might be good to either treat alt=" " the same as alt="", or somehow indicate that the value only contains whitespace |
| 15:40 | <Lachy> | hsivonen, I think the description of Images with textual alternative should include something that says automated markup generated should not attempt to generate alternative text unless it has been obtained from a reliable (or at least human) source. |
| 15:49 | <zcorpan> | hsivonen: http://html5.validator.nu/?doc=http%3A%2F%2Fwww.accessify.com%2F&showimagereport=yes&showsource=yes is not very helpful... |
| 15:51 | <zcorpan> | hsivonen: why does it need to reparse in that case? |
| 15:52 | <Lachy> | maybe because the meta charset occured outside the limit of the preparse |
| 15:52 | <Lachy> | in any case, such error messages should probably include some quick way to say force override with this charset anyway |
| 15:53 | <Lachy> | and then have it revalidate |
| 15:54 | <zcorpan> | or the validator should just reparse :P |
| 15:54 | <Lachy> | it would also be useful if there was a quick way to view the image in full size, without having to select view image from the context menu |
| 15:55 | <Lachy> | zcorpan, no, fatal errors are great for forcing the author to fix the error :-) |
| 15:56 | <zcorpan> | Lachy: well perhaps the author was only set out to check the alt text |
| 15:57 | <Lachy> | ah, so you want a way to view image report only without validation |
| 15:58 | <Lachy> | forcing UTF-8 works. http://validator.nu/?doc=http%3A%2F%2Fwww.accessify.com%2F&charset=UTF-8&showimagereport=yes&showsource=yes |
| 15:58 | <Lachy> | it's intersting to see their incorrect use of alt text |
| 15:59 | <zcorpan> | yeah, although skipping over the validation messages is about as much work as unchecking a "validate" checkbox |
| 15:59 | <Lachy> | "accessify.com" image has alt="Accessify home page - latest news" is somewhat wrong. The image says nothing about news. |
| 16:00 | <Lachy> | and the 1x1px transparent gif with alt="site statistics" should have alt="" instead |
| 16:04 | <zcorpan> | http://html5.validator.nu/?doc=http%3A%2F%2Fflickr.com&charset=UTF-8&showimagereport=yes&showsource=yes looks reasonable |
| 16:14 | <hsivonen> | Lachy: why do the tables need borders? |
| 16:15 | <hsivonen> | Lachy: Philip` suggested right-aligning the image th, and I think it makes sense that way |
| 16:15 | <hsivonen> | Lachy: the th *is* bold |
| 16:16 | <hsivonen> | Lachy: context would be useful, yes. However, in a validator, the source location is the surrogate for context |
| 16:16 | <hsivonen> | Lachy: if you really want context, you need a browser extension |
| 16:17 | <hsivonen> | Lachy: I think alt=' ' needs further investigation whether it already is taken to mean something special |
| 16:17 | <hsivonen> | Lachy: the UI text is on a wiki :-) |
| 16:18 | <annevk> | some light colored border and maybe some amount of padding would help though, I think |
| 16:19 | <annevk> | (not necessarily on the side of the table, though) |
| 16:20 | <Philip`> | http://validator.nu/?doc=http%3A%2F%2Fwww.google.com%2F&showimagereport=yes#imagereport |
| 16:20 | <Philip`> | Is that a legitimate use of alt? |
| 16:20 | <annevk> | why not? |
| 16:21 | <Philip`> | The alt text for each image is not an alternative to that image, though the concatenation of alt texts on the page is an alternative to the concatenation of images |
| 16:22 | <annevk> | i suppose it would be weird if a single image failed to load |
| 16:22 | <billmason> | I don't understand why when I'm actually looking at google.com, it's one integrated image, not a concatenation. |
| 16:23 | <annevk> | prolly does browser sniffing |
| 16:23 | <Philip`> | Probably depends on cookies and logins and stuff too |
| 16:23 | <Philip`> | Also it does IP sniffing |
| 16:23 | <Philip`> | (so validator.nu gets google.fi) |
| 16:23 | <billmason> | Ah, that would make sense. |
| 16:23 | billmason | is sniffed out now |
| 16:24 | Philip` | can't work out which part of the spec is relevant for alt text for images which themselves just contain text |
| 16:25 | <annevk> | Google tries to save bytes with markup on the one hand, but on the other they could save quite a bit more if they really tried |
| 16:25 | <Philip`> | It's not the first case, since the text isn't more clearly stated when it's in the graphic |
| 16:25 | annevk | wonders what the deal is |
| 16:25 | <Philip`> | It's not the second since it's not an icon, it's not the third since it's not supplementary to surrounding text, it's not the fourth since it's not purely decorative |
| 16:25 | <Philip`> | It's not the fifth since it's not a critical part of the content |
| 16:26 | <Philip`> | It's not the sixth since it's not being emailed |
| 16:26 | <Philip`> | So the spec doesn't seem to tell me whether the image needs alt or what it should say |
| 16:27 | <billmason> | The second includes discussion of logos, which would seem to have some relevance. |
| 16:27 | <hsivonen> | Lachy: isn't the context menu easy enough for magnifying the image? |
| 16:27 | <hsivonen> | zcorpan: re: only checking alt: validation is the first step. :-p |
| 16:27 | <Philip`> | billmason: None of the three cases for logos applies either |
| 16:28 | <Philip`> | The Google logo isn't representing Google (like if it was a list of lots of search engines, using their logos to make them easily identifiable) - it's just the page heading |
| 16:28 | <Philip`> | It's not being used next to the company's name |
| 16:29 | <Philip`> | and it's not just decorative, since if you removed it then you wouldn't know what site you were on |
| 16:29 | <billmason> | I'm not sure I agree with your first statement. Particualy in light of your third. |
| 16:29 | <billmason> | If it's that critical, then its representative. |
| 16:30 | <Philip`> | I'm not sure I agree with your "If" statement |
| 16:31 | <billmason> | Well, then you will have to explain how it's not decorative, but at the same time doesn't stand for anything to me.... |
| 16:31 | <annevk> | hsivonen, "Fatal Error: Changing encoding at this point would need non-streamable behavior." is an open issue right? |
| 16:31 | <Philip`> | The image is critical to the page, because it's part of the page's text; its purpose is to be heading text, and not to be representing the organisation Google |
| 16:32 | <billmason> | Perhaps we have different definitions of "representing". |
| 16:32 | <Philip`> | It's not "being used to represent the entity ... such as a company, organisation, project, band, software package, country, or some such" |
| 16:33 | <billmason> | I think a marketing person would disagree that a logo doesn't represent the entity. A logo is generally a carefully considered product designed to to just that. Judging by the arguments over logo design I've experienced. |
| 16:34 | <Philip`> | Regardless of that, if they replaced it with black Comic Sans saying "WE HACKED YOUR SERVERS" then it certainly wouldn't be representing any such entity, and then there's still the problem that none of the cases mentioned in the spec seem to cover it |
| 16:36 | <hsivonen> | annevk: fatal error is a major design decision |
| 16:36 | <hsivonen> | annevk: making it more usable regardless is an open issue |
| 16:37 | <hsivonen> | Lachy, annevk: is the problem not having a border between table rows? |
| 16:37 | <hsivonen> | or columns, too |
| 16:38 | <billmason> | Such a change would mean you no longer have a logo. Right now I'm only asserting that the Google graphic is a logo. |
| 16:39 | <billmason> | I would argue that your example fits the current definition of icon: 'WE HACKED YOUR SERVERS' is a short phrase with an alternative graphical representation. |
| 16:39 | <Philip`> | I'd have to agree that the Google logo graphic is a logo |
| 16:41 | <Philip`> | but I think it's not so clear that the logo is "being used to represent the entity" - it's being used to tell people what site they're on and to make it prettier |
| 16:41 | <Philip`> | It does represent the entity, but it's not being used simply for that purpose |
| 16:42 | <Philip`> | billmason: Which of the sub-cases in the 'icon' section would apply? |
| 16:43 | <billmason> | Philip`: would apply to what? The hypothetical 'hacked' graphic? |
| 16:43 | <Philip`> | billmason: Yes |
| 16:44 | <billmason> | Probably "In other cases, the icon has no text next to it describing what it means; the icon is supposed to be self-explanatory. In those cases, an equivalent textual label must be given in the alt attribute." |
| 16:45 | <billmason> | I'm starting to dislike the word 'icon' though. It makes me leap to the assumption that the image will therefore be a little 16x16 image, or the like. |
| 16:45 | <Philip`> | That seems to me like an abuse of the spec's intent - that's supposed to apply to e.g. <img src=magnifying-glass alt=Search> |
| 16:46 | <billmason> | Yes, I agree. This is why I don't like the word icon here. |
| 16:47 | <Philip`> | The whole spec section is far too long to bother reading to work out what you're meant to do in any given case anyway, even if it did actually say clearly what to do in every given case |
| 16:50 | <billmason> | I would rather, I think answer that the 'hacked' image example is point 1 in the spec. It is a 'A phrase or paragraph with an alternative graphical representation', but the following text pulls you away from that by saying the image 'more clearly' represents, when in this example it equally represents. |
| 16:50 | <billmason> | So I'm finding the text a little blurry. |
| 16:50 | Philip` | agrees |
| 16:51 | <annevk> | hsivonen, fatal error is incompatible with HTML5... |
| 16:51 | <Dashiva> | But what if the vandals didn't change the alt? |
| 16:51 | <billmason> | Then it's nonconforming? :) |
| 16:52 | <Philip`> | Dashiva: I'm assuming these are vandals who care about accessibility |
| 17:00 | <hsivonen> | annevk: actually, HTML5 permits fatal errors |
| 17:04 | <annevk> | hmm true, does your parser allow the other variant too if you don't do the streaming model? |
| 17:05 | <hsivonen> | annevk: yes, the parser supports non-fatal behavior if you accept losing streaming |
| 17:06 | <Lachy> | hsivonen, the th's weren't bold. They are now. I assume the problem was the font-weight: inherit;, which now appears to be removed. |
| 17:06 | <hsivonen> | I'm not sure if keeping V.nu streaming is a bad call, but I'm not ready give up on streaming |
| 17:06 | <hsivonen> | Lachy: are you sure your browser cache is up-to-date? |
| 17:07 | <Philip`> | CSS5 should allow every element to have two parents, and if you set "inherit" then it chooses to inherit from one of the parents at random, with a small chance of inheriting from both mixed together, when the element is first created |
| 17:07 | <Lachy> | it seems to be now up to date now. I wasn't getting the light yellow background on the middle column earlier. Now I am |
| 17:07 | <hsivonen> | Lachy: I'm pretty sure I haven't changed the style sheet in the last hour |
| 17:07 | <hsivonen> | Lachy: you had a *really* old cached copy of the style sheet, then |
| 17:07 | <Lachy> | oh, ok. Maybe mine was cached |
| 17:08 | <Lachy> | had you set and cache related http headers on them, which would have caused it to be cached for me? |
| 17:08 | <Lachy> | like an Expires header |
| 17:10 | <hsivonen> | Lachy: nope: http://web-sniffer.net/?url=http%3A%2F%2Fabout.validator.nu%2Fstyle.css&submit=Submit&http=1.1&gzip=yes&type=GET&uak=0 |
| 17:12 | <annevk> | hsivonen, ah ok, for some reason i assume the parser didn't use streaming |
| 17:12 | <annevk> | maybe because of Schematron |
| 17:12 | <annevk> | assumed* |
| 17:13 | <annevk> | oops |
| 17:13 | <hsivonen> | annevk: Schematron will be gone at some point from HTML5 checking |
| 17:13 | <hsivonen> | annevk: but yeah, Schematron builds a private tree and doesn't stream |
| 17:13 | <hsivonen> | looks really ugly in a perf profiler :-) |
| 17:14 | <Lachy> | hsivonen, re magnifying images, it's not always immediately obvious which images are already shown full size, or which can be enlarged. So going to the context menu to view each image is time consuming |
| 17:14 | <hsivonen> | Lachy: good point |
| 17:14 | <hsivonen> | Lachy: I tried to pick a size that is large enough for an author to recognize photos |
| 17:15 | <Lachy> | would be nice to have some kind of zoom feature for significantly larger images |
| 17:15 | <hsivonen> | it may suck if you aren't the author and you try to figure out a large diagram |
| 17:15 | <Lachy> | but I suppose, for an author familar with the page, it's not so bad |
| 17:16 | <hsivonen> | Lachy: I considered using CSS :hover and :focus but then I cut that feature from the first release, because I couldn't figure out a nice way to tell CSS to zoom from current dimensions by a factor |
| 17:17 | <Lachy> | such a thing would have to be done with javascript |
| 17:17 | <hsivonen> | yeah |
| 17:21 | <hsivonen> | can JS query for the actual file dimensions? |
| 17:21 | <Lachy> | hsivonen, can you turn the Group Messages feature on by default. It's so much better than the ungrouped |
| 17:21 | <hsivonen> | the server size doesn't know the file dimensions and uses width/height from HTML |
| 17:22 | <hsivonen> | Lachy: I can't. Grouping doesn't work during load |
| 17:24 | <Lachy> | I wonder if you could somehow use the canvas APIs to determine the actual size of the image |
| 17:25 | <Philip`> | Lachy: You can't |
| 17:26 | <Philip`> | and when I last tried, it was impossible to find the image size on the client |
| 17:26 | <Philip`> | (because img.width/height always returns the rendered size, or 0 if it's not in the document) |
| 17:26 | <Lachy> | Philip`, ok. |
| 17:26 | <Philip`> | (at least in the compatible intersection of all browsers) |
| 17:27 | <Philip`> | so I ended up calculating sizes on the server instead, and sending <img _width="123" _height="456" style="max-width:100px"> so scripts could grab the real size |
| 17:28 | <Philip`> | (Can't use width="..." because getAttribute('width') in IE is equivalent to .width and returns the rendered size) |
| 17:29 | <Philip`> | (Web development is great fun) |
| 17:31 | <Philip`> | (Also I was putting the max-widthed images in a table, and Opera 9.2 does table layout as if the image was full size, which messes everything up, and I was having so much fun that I just gave up and let Opera have broken layout) |
| 17:31 | <Lachy> | hsivonen, this works: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3E%0Avar%20img%20%3D%20document.createElement(%22img%22)%3B%0Aimg.src%20%3D%20%22image%22%3B%0Aw(img.height)%3B%0Aw(img.width)%3B%0A%3C%2Fscript%3E |
| 17:33 | Lachy | has to go home now. Back soon. |
| 17:34 | Philip` | wonders why that didn't seem to work when he tried this a while ago... |
| 17:44 | <annevk> | (the example Lachy gave above only works for cached images) |
| 17:45 | <Philip`> | (That's easily fixable with onload) |
| 17:58 | <Lachy> | annevk, the example I gave would work for all images shown in the image report, if the function is executed onload, creates an image, and iteratively sets the src to that of each images in the report and retreives the dimensions. |
| 17:59 | <Philip`> | "Iteratively" sounds bad for performance - you want to do them in parallel |
| 18:00 | <Lachy> | ideally, you would catch the onload event for each individual image and retrive the dimensions imediately |
| 18:00 | <Lachy> | that will be possible with XBL, but no so easy now |
| 18:00 | <Lachy> | unless you can do <img ... onload="getDimensions();"> |
| 18:00 | <Lachy> | for each image |
| 18:07 | <Philip`> | <img onload> won't work, since it'll give the rendered size and not the real size |
| 18:07 | <Philip`> | so you have to use createElement('img') or new Image() |
| 18:10 | <Lachy> | Philip`, yes, that's why my above explanation said to create an img, and iteratively set the src to that of each image in the page. |
| 18:11 | <Philip`> | You can just create multiple imgs and set the source of them all, instead of iterating on one img |
| 18:12 | <Lachy> | you still need to create and set each one sequentially, but creating new img elements would be less efficient than reusing the same one. |
| 18:15 | <Lachy> | I assume multiple onload events from several images would be executed sequentially, since it's single-threaded, so reusing the same img for each wouldn't cause a conflict |
| 18:15 | <Philip`> | Network latency is seven zillion times more significant than CPU/memory usage for a handful of DOM objects |
| 18:15 | <Lachy> | yes, but every bit counts |
| 18:15 | <Philip`> | Every bit of network latency counts more; and if you're downloading one image at a time, compared to downloading half a dozen in parallel, that's going to be really slow |
| 18:16 | <Lachy> | but the network latency is irrelevant here, since you can't do anything with the image until it's loaded, and once it is, the script for each takes an insignificant amount of time |
| 18:17 | <Lachy> | the browser can still download multiple images simultaneosly, and use various techniques to speed that up. There's nothing a javascript can do about that |
| 18:18 | <Philip`> | The browser can't download multiple images simultaneously if your script is waiting for the first to call onload before you update img.src and tell it to download the next |
| 18:19 | <Lachy> | I think your misunderstanding how I envision the script working |
| 18:19 | <Philip`> | Possibly :-) |
| 18:20 | <Philip`> | Since you said you're reusing the same img, I assume you mean "var i = new Image(); i.src = '1'; i.onload = function () { process(i); i.src = '2'; i.onload = ... }" (except setting src/onload in the right order and setting up the chain in a loop) |
| 18:21 | <Lachy> | no, you got it wroing :-) |
| 18:21 | <Philip`> | I'll blame your description, then ;-) |
| 18:26 | <Lachy> | I'm putting together an example page to show it working, give me a few minutes |
| 18:29 | <bkardell> | I have a question about <link> in the working draft... |
| 18:30 | <bkardell> | There is a "prefetch" |
| 18:30 | <bkardell> | and you can specify type |
| 18:31 | <bkardell> | could it be used similarly to <script src="xx"> |
| 18:31 | <bkardell> | to load script? |
| 18:32 | <Philip`> | bkardell: Why not just use <script src="..."> instead? |
| 18:33 | <bkardell> | well - the reason isn't important for now |
| 18:33 | <bkardell> | the important part is that I don't understand from the text whether that is a valid case |
| 18:33 | <bkardell> | would it be? |
| 18:35 | <bkardell> | it allows type/media etc |
| 18:35 | <Philip`> | The spec doesn't tell UAs to do anything with <link rel=prefetch>, so (I think) they mustn't do anything that affects the document in any way (and so they can't e.g. run scripts) |
| 18:36 | <bkardell> | but they can attach stylesheets? |
| 18:36 | <bkardell> | which can attach via xbl? |
| 18:36 | <annevk> | through rel=stylesheet |
| 18:36 | <Philip`> | That's rel=stylesheet, not rel=prefetch |
| 18:37 | <Philip`> | (prefetch is just meant to tell the UA to download and cache the data so it can be used in the future with less delay) |
| 18:37 | Philip` | might be misunderstanding the question, though |
| 18:37 | <bkardell> | sure... it's kind of a complicated question I guess I may be having trouble expressing too |
| 18:38 | <bkardell> | let me try again.. I don't want to get hung up on the 'prefetch' piece |
| 18:38 | <bkardell> | I chose that one in my question because it specifies an "external resource" |
| 18:39 | <bkardell> | so I guess in simplest terms: could <link> not be used to load script? |
| 18:39 | <Philip`> | Like <link rel="script" href="example.js">? |
| 18:39 | <annevk> | <link> cannot atttach scripts like <script> can |
| 18:40 | <bkardell> | it seems syntactically very capable and as to why exactly one would want to - I'm just examining possibilities |
| 18:40 | <bkardell> | yes - precisely... |
| 18:40 | <Philip`> | There's not really anything to stop someone adding a <link rel=script> to HTML in the future, except that it would seem like a bad idea when there's already <script> |
| 18:41 | <bkardell> | does it really seem like a bad idea? |
| 18:41 | <annevk> | yes |
| 18:41 | <bkardell> | lol :) |
| 18:41 | <annevk> | (it's a rejected extension: http://wiki.whatwg.org/wiki/RelExtensions ) |
| 18:41 | <bkardell> | good deal Anne - that's exactly what I was looking for |
| 18:41 | <bkardell> | thanks!! |
| 18:42 | <Philip`> | It doesn't seem like a good idea (e.g. it doesn't allow interesting new features), and the default state for ideas is to be bad because otherwise the world would be flooded with too many things to implement :-) |
| 18:42 | <annevk> | the default state for proposals is bad |
| 18:42 | <annevk> | actually, the default state for proposals is rejection |
| 18:43 | <bkardell> | yeah - I agree with that philosophy the question was not to propose but to understand intent |
| 18:44 | <Philip`> | annevk: That shouldn't be true - the default state for proposals should be to be awaiting consideration |
| 18:44 | <bkardell> | I was trying to figure out essentially if this would be an effort like one to say <embed>, <object> and <applet> are kind of redundant |
| 18:45 | <bkardell> | thanks though anne - that's exactly what I was looking for |
| 18:45 | <annevk> | in general if a new feature does exactly the same as an existing feature it won't be introduced |
| 18:45 | <annevk> | and since rel=script was not supported anywhere there's no reason to add it |
| 18:46 | <annevk> | (as for <embed>, <object>, and <applet>; <applet> is obsoleted in favor of <embed> and <embed> and <object> are quite different) |
| 18:49 | <annevk> | Philip`, i guess the default outcome of said consideration is rejection then :) |
| 18:52 | <Lachy> | Philip`, http://lachy.id.au/dev/2008/image-dimensions.html |
| 18:53 | <Lachy> | hsivonen, feel free to rip off that script for the validator |
| 18:53 | <Lachy> | ... if and when you want to implement the zoom feature |
| 19:00 | <bkardell> | annevk: I must admit that I did not know <embed> and <object> - both still have recommended uses |
| 19:00 | <bkardell> | thought <embed> was out |
| 19:03 | <bkardell> | Don't have a lot of chance to use either so hopefully that doesn't seem too dreadfully stupid a comment |
| 19:05 | <annevk> | np |
| 19:25 | <Philip`> | Oops, I think I contributed to the alt email pile |
| 20:47 | <Hixie> | wow http://www.w3.org/mid/OF51C16334.62B43BA0-ON8625742F.004CBE78-8625742F.0051275D⊙uic |
| 21:24 | <Philip`> | Aha, I'm glad someone gave a specific example in response to my "there are other more legitimate reasons for having several img elements representing a single piece of text", since I couldn't actually think of any |
| 21:50 | <zcorpan_> | http://html5.dk/wordpress/2008/04/16/første-danske-bog-om-html-5/ -- danish book about html5 |
| 22:01 | <annevk> | if I interpret the Danish correctly there's no book yet but you can pre-order it or something? |
| 22:27 | <Hixie> | wtf are document.charset and document.defaultCharset |
| 22:31 | <othermaciej> | crazy XML things |
| 22:31 | <Hixie> | seems they're IE things for text/html |
| 22:31 | <Hixie> | i don't understand what they are supposed to do |
| 22:31 | <Hixie> | on setting in particular |
| 22:31 | <Hixie> | for .charset |
| 22:31 | <othermaciej> | oh |
| 22:32 | <othermaciej> | that's right |
| 22:32 | <othermaciej> | we have those APIs marked as IE extensions and I don't remember what they do |
| 22:32 | <Hixie> | "defaultCharset Property |
| 22:32 | <Hixie> | Gets the default character set from the current regional language settings." |
| 22:32 | <Hixie> | w.t.f. |
| 22:32 | <othermaciej> | Mozilla instead has characterSet |
| 22:33 | <othermaciej> | (which we also copied) |
| 22:33 | <othermaciej> | defaultCharset is read-only in our DOM |
| 22:33 | <othermaciej> | not sure that is the case for IE |
| 22:33 | <Hixie> | yeah i just looked at the patch that webkit uses |
| 22:33 | <Hixie> | to implement this |
| 22:33 | <Hixie> | didn't help much |
| 22:33 | <Hixie> | :-) |
| 22:33 | <othermaciej> | the crazy XML things are inputEncoding and xmlEncoding |
| 22:33 | <Hixie> | (in terms of what setting .charset does) |
| 22:34 | <othermaciej> | for a grand total of 5 attributes on Document relating to the document's character set |
| 22:34 | <Hixie> | first hit for [document.charset msdn] on google seems to be a security vulnerability report |
| 22:34 | <othermaciej> | I think if you set it, it will affect the default charset assumed for linked resources |
| 22:35 | <othermaciej> | and possibly also charset used for form submission and URL escaping |
| 22:35 | <othermaciej> | not sure about the latter two though |
| 22:35 | <Hixie> | charset Property |
| 22:35 | <Hixie> | "Sets or retrieves the character set used to encode the object." |
| 22:36 | <Hixie> | this documentation is worthless |
| 22:36 | <othermaciej> | IE's vaunted docs for their JS APIs are often maddeningly vague |
| 22:49 | <annevk> | hmm, you'd think that nonsense like charset shouldn't end up in the DOM |
| 22:51 | <Hixie> | so i wonder what a document like <script>alert(document.charset)</script><meta http-equiv="content-type" content="text/html;charset=iso-8859-2"><script>alert(document.charset)</script> does |
| 22:52 | <Hixie> | damowmow.com/playground/demos/001.html |
| 22:52 | <annevk> | in Mozilla document.carset is undefined even |
| 22:53 | <annevk> | in Opera it returns the empty string, and if you set it to some string you can retrieve that string later, but I'm not sure what the effect is |
| 22:55 | <Hixie> | it helps if i remove the default encoding |
| 22:55 | <Hixie> | sigh |
| 22:58 | <annevk> | Hixie, maybe these features can be removed given that Firefox 3 gets away with not supporting them? |
| 22:58 | <Hixie> | http://damowmow.com/playground/demos/charset/001.html seems to indicate that IE doesn't change the encoding |
| 22:58 | <Hixie> | etf |
| 22:58 | <Hixie> | annevk: well they support document.characterSet |
| 22:59 | <annevk> | ah, and Opera and Safari support all... |
| 23:04 | <Hixie> | my definition of defaultCharset is awesome |
| 23:31 | <gsnedders> | Hixie: goddamnit. just as I am trying to go to bed I see that comment and _have_ to look. |
| 23:32 | <gsnedders> | Hixie: Awesomness gone mad. |
| 23:38 | <hsivonen> | Hixie: did you test charset setting with IANA-unregistered but otherwise supported names? |
| 23:42 | <Hixie> | no |
| 23:43 | <Hixie> | i'm working on the mythical concept that only iana-registered names are supported, and that all supported names are iana-registered |
| 23:43 | <Hixie> | or at least that they will be by the time the spec is in cr |
| 23:43 | <gsnedders> | Ah, I see the realist Hixie showing through again :P |
| 23:45 | <Hixie> | if nobody does the work of registering them, i'll just set up a wiki page and change the spec to refer to that instead of iana |
| 23:46 | <Hixie> | so... |
| 23:46 | <Hixie> | which fires first |
| 23:46 | <Hixie> | onreadystatechanged, or DOMContentLoaded? |
| 23:47 | <gsnedders> | And also, what's a word that means "laughed at" that starts with a t? |
| 23:47 | Philip` | wonders if document.defaultCharset should return the same value every time you get it |
| 23:47 | <othermaciej_> | in Safari, we support all variants of IANA names with added or removed hyphens (and maybe some other punctuation) |
| 23:47 | <Philip`> | otherwise a mobile browser than returns "encoding associated with the user's current geographical location" might do odd things if you travel a lot |
| 23:47 | <takkaria> | gsnedders: as in "I laughed at him"? |
| 23:47 | <othermaciej_> | probably that is more than strictly needed for compatibility |
| 23:47 | <Philip`> | s/than/that/ |
| 23:47 | <gsnedders> | takkaria: "I was laughed at endlessly" |
| 23:48 | <Hixie> | teased |
| 23:48 | <Hixie> | and which happens first, onreadystatechanged, or onload? |
| 23:48 | <Philip`> | Tittered? |
| 23:48 | <Hixie> | othermaciej_: yeah i've received similar feedback from opera |
| 23:48 | <gsnedders> | teased is too specific |
| 23:49 | <Hixie> | Philip`: i see no reason why it shouldn't change each time |
| 23:49 | <gsnedders> | othermaciej: so what? all consecutive hyphens become a single hyphen? |
| 23:49 | <Hixie> | Philip`: e.g. if someone is playing with their settings |
| 23:49 | <Philip`> | gsnedders: The dictionary suggests "twitted" but I've never heard that before |
| 23:50 | <othermaciej> | gsnedders: for example, for the official name ISO_8859-1 we will also accept ISO88591 |
| 23:50 | <Philip`> | Hixie: <a href="#refsRFC2046">[RFC2646]</a> - s/0/6/ |
| 23:50 | <othermaciej> | (that's not one of the registered aliases) |
| 23:50 | <gsnedders> | othermaciej: ah, OK |
| 23:51 | <othermaciej> | or conversely, we'll accept latin-1, even though only latin1 is an official alias |
| 23:51 | <Hixie> | Philip`: fixed |
| 23:53 | <othermaciej> | (of course we don't treat any of those as real latin1) |
| 23:53 | gsnedders | wishes life was simpler than it is |
| 23:53 | <Philip`> | Hixie: There's another half a dozen of the same error elsewhere |
| 23:53 | <gsnedders> | (in terms of things like this) |
| 23:54 | <Hixie> | Philip`: where? |
| 23:54 | <Hixie> | Philip`: all the other 2046s seem right |
| 23:54 | <Philip`> | href="#refsRFC2318">[RFC2138]</a> |
| 23:54 | <Philip`> | href="#refsRFC2046">[RFC2646]</a> |
| 23:54 | <Philip`> | href="#refsRFC3490">[RFC3986]</a> |
| 23:54 | <Philip`> | href="#refsRFC3490">[RFC3987]</a> |
| 23:54 | <Philip`> | href="#refsRFC3490">[RFC3986]</a> |
| 23:54 | <Philip`> | href="#refsRFC3490">[RFC3987]</a> |
| 23:54 | <Philip`> | href="#refsRFC3490">[RFC3986]</a> |
| 23:54 | <Hixie> | othermaciej: iirc opera said they just strip out all -s and _s and various other punctuation before doing comparisons |
| 23:54 | <Hixie> | Philip`: ah ok |
| 23:54 | <othermaciej> | Hixie: that's basically what we do too |
| 23:54 | <Hixie> | Philip`: good times |
| 23:55 | <Hixie> | Philip`: i'll fix those when i do the refs |
| 23:55 | <othermaciej> | Hixie: both from the provided charset and the official charset names being compared to |
| 23:55 | <Hixie> | othermaciej: right |