| 01:51 | <Philip`> | takkaria: Why shouldn't <h a='©'> get turned into U+00A9? |
| 01:53 | <takkaria> | Y is U+0059 |
| 01:53 | <takkaria> | "If the character reference is being consumed as part of an attribute, and the last character matched is not a U+003B SEMICOLON (;), and the next character is in the range ... U+0041 LATIN CAPITAL LETTER A to U+005A LATIN CAPITAL LETTER Z, .... then, for historical reasons, all the characters that were matched after the U+0026 AMPERSAND (&) must be unconsumed, and nothing is returned." |
| 01:54 | <Philip`> | It matches © and then the last character is Y which is not ;, and the next character is ' which is not in those ranges so it doesn't get unconsumed |
| 01:55 | <takkaria> | ah, I've gone and misread the spec, haven't I? |
| 01:55 | <takkaria> | there's a good reason people go to bed before 2am, I see |
| 01:55 | <Philip`> | It's still before 2am now :-) |
| 01:56 | <Philip`> | There are good reasons to not go to bed before 2am too, such as having to write several hundred words before a deadline tomorrow |
| 02:00 | <takkaria> | yeah, agreed, but I think my habit of coding well into the night is not helpful in terms of the number of mistakes I make. :) |
| 02:03 | <Philip`> | You'll have to compute the tradeoff between increased productivity due to spend more time working on it, and decreased productivity due to having more bugs |
| 02:12 | <takkaria> | I find I get more done in the night but it's of lower quality |
| 02:12 | <takkaria> | during the day I take more care over details |
| 02:14 | <Philip`> | If you only worry about details then you'll never get any of the big stuff done at all |
| 02:14 | <takkaria> | yeah, and for this reason I tend to prefer coding at night |
| 02:14 | <jcranmer> | quality, quantity, and time of day have no correlation for me |
| 02:15 | <Philip`> | The internet didn't become popular by being very carefully coded and engineered in every detail |
| 02:15 | <jcranmer> | the key correlation appears to be between quality and quantity as dependent variables on the independent variable of "time since I started work on this" |
| 02:15 | <Philip`> | so clearly you should just hack everything together as quickly as possible :-) |
| 02:16 | <jcranmer> | where quantity and quality start high at t = 0, quality starts to dip, followed by quantity some time later, followed by both going to 0 |
| 02:16 | <jcranmer> | followed by a meteoric rise in quality and then a similar rise in quantity, with both forming a not-quite-in-phase cyclical graph |
| 02:17 | <jcranmer> | Quantity = max(A * cos (B * x) + C, 0) |
| 02:17 | <jcranmer> | Quality = max(A * cox (B * x + D) + C, 0) |
| 02:18 | <jcranmer> | s/(?<\w)x/t/ |
| 02:18 | <takkaria> | interesting |
| 02:19 | <jcranmer> | s/A/A(t)/, where A(t) is a function which smooths out the peaks somewhat |
| 02:19 | <jcranmer> | and B(t) is a function which induces non-constant recurrences between peaks and troughs |
| 02:19 | <jcranmer> | and C = 0 |
| 02:20 | <takkaria> | :) |
| 02:20 | <Philip`> | So you're basically saying that quantity and quality are defined by the undefined arbitrary functions A and B? :-) |
| 02:20 | <jcranmer> | A and B as constants are rough approximations |
| 02:22 | <jcranmer> | just like elementary physics problems use the approximation sin(x) = x for small values of x to simplify a differential equation to a linear one |
| 02:24 | <Philip`> | What frame of reference are you measuring t in? If you travelled in a relativistic spaceship, would you be any more productive? |
| 02:25 | <jcranmer> | Philip`: my frame of reference |
| 02:25 | <jcranmer> | or, should I say, the frame of my internal clock |
| 02:26 | <Philip`> | What would happen if you surgically extracted your internal clock and put it on the spaceship? |
| 02:26 | <jcranmer> | which experiences relativistic effects just from flying in an airplane :-) |
| 02:26 | <jcranmer> | (although neither General nor Special Relativity, but Joshua Relativity) |
| 02:29 | <Hixie> | jgraham: there are many cases where you want the image to just not be mentioned |
| 02:29 | <Hixie> | jgraham: and just replaced with its alternative text |
| 05:56 | <Hixie> | reading through alt="" e-mail, it seems my life would be a lot easier if i was an accessibility expert |
| 05:56 | <Hixie> | i could just say things without having to defend them with data |
| 05:57 | <Hixie> | i wonder how i become an accessibility expert |
| 05:57 | <roc> | gouge your own eyes out |
| 05:58 | <Hixie> | the first hit for "how to become an accessibility expert" on google is a powerpoint presentation "Become an Accessibility Expert in 50 min" |
| 05:58 | <Hixie> | no, many accessibility experts are not blind |
| 05:58 | <roc> | I didn't say it was the only way |
| 05:59 | <roc> | I bet you can do it in less than 50 minutes |
| 09:11 | <Dashiva> | Darths & Droids comes out in favor of text equivalents not being equivalent enough. I wonder if anyone will cite that :) |
| 09:56 | <jgraham> | Hixie: If you just want the image replaced by its alternate text i follows you know what the alternate text is so you put it in the alt attribute and there's no problem |
| 09:57 | <Hixie> | jgraham: my point is that you wouldn't necessarily even want the UA to (by default) inform the user that there is an image in that case |
| 10:05 | <jgraham> | Hixie: I don't disagree with that. It's the case where there is no alt attribute where a UA could announce there is an image and read the title attribute |
| 10:06 | <Hixie> | jgraham: it could always read the title attribute, that seems orthogonal |
| 10:08 | <jgraham> | Not really. If I have <img alt="XYZ Systems" title="XYZ systems logo"> I don't expect the UA to read both @alt and @title |
| 10:10 | <jgraham> | Whereas for <img title="XYZ Systems Logo"> reading Image, XYZ Systems Logo seems quite helpful |
| 10:10 | <Hixie> | <img title="XYZ Systems Logo"> is non-conforming |
| 10:10 | <Hixie> | and in both cases, the title="" attribute's value sucks |
| 10:11 | <jgraham> | We get o choose what is non-conforming :) |
| 10:11 | <jgraham> | Also, why does it suck? |
| 10:11 | <Hixie> | i chose it to be non-conforming :-) it has no reason to be conforming |
| 10:11 | <Hixie> | the title attribute doesn't help anything |
| 10:12 | <Hixie> | in that case |
| 10:12 | <Hixie> | i mean, it's not _wrong_ |
| 10:12 | <jgraham> | (it should be non conforming in this case because there is obvious alt text. But thre are cases like flickr where the photo is likely to have a title but no alternate text avaliable) |
| 10:13 | <Hixie> | yes, in those cases it would be fine for the UA to mention that there is potentially useful title="" text |
| 10:13 | <Hixie> | that's just part of whatever helpful stuff it wants to give |
| 10:14 | <jgraham> | What other helpful stuff does it want to give? |
| 10:15 | <jgraham> | The only other information likely to be avaliable is a category of image like Photo or Logo or whatever |
| 10:16 | <jgraham> | Is that really useful enugh to invent a whole microsyntex for alt that causes it to duplicate much of the functionality of @title? |
| 10:16 | <Hixie> | it might know what the image is through image analysis (e.g. it might notice the image is fully transparent or 1x1) or it might notice that the image is one that it has seen before on another page where it had alt="" text, or it might be one that it recognises has a face in it, or any number of other things |
| 10:16 | <Hixie> | i don't think alt="{photo}" is information that would ever be appropriate in title="" |
| 10:22 | <jgraham> | Hixie: if the UA notices something through image analysis it seems fine to present that alongside / instead of @title (assumng no @alt). I'm not sure that changes the fact that <img alt={photo}> isn't providing much useful informaion and, in particular is probably less useful than an image with a good title (which is often easier to enter in a CMS than a text alternative) |
| 10:22 | <Hixie> | i agree that the title, if available, would be fine information to make available |
| 10:22 | <Hixie> | in most cases (e.g. flickr) i imagine all such information would be on the page and not in the title="" |
| 10:23 | <Hixie> | title="" makes more sense for images that aren't the main topic of the page, in which case the alt="" text is usually available anyway |
| 10:24 | <Lachy> | Hixie, could you answer this question for me? http://krijnhoetmer.nl/irc-logs/whatwg/20080803#l-507 |
| 10:24 | <jgraham> | I guess if there really is no good alt text or any good title, having some way to indicate the type of the image might be useful though I would expect it to be wrong much of the time (consider sites that allow users to upload photos or 3D renerings) |
| 10:25 | <jgraham> | Hixie: flickr puts the title of the photo in @title |
| 10:25 | <Hixie> | Lachy: "yes" |
| 10:25 | <Hixie> | Lachy: (is the answer to the question. unknown characters become "?".) |
| 10:26 | <Hixie> | jgraham: yeah, it also puts it in alt="", and in the header, and all over the place |
| 10:26 | <Lachy> | Hixie, ok. Cause that didn't match the behaviour of Firefox or Safari. Was that intentional? (I didn't test IE yet) |
| 10:26 | <Hixie> | jgraham: listening to that site in a screen reader is like being in an echo chamber |
| 10:26 | <Hixie> | Lachy: they convert unknown chars to &12345; right? |
| 10:26 | <Hixie> | Lachy: oh wait |
| 10:26 | <Hixie> | Lachy: firefox switches to UTF-8 |
| 10:26 | <Philip`> | Lachy: Firefox seems crazy and switches between document-encoding and UTF-8 depending on what characters there are |
| 10:26 | <Hixie> | right? |
| 10:27 | <Hixie> | and the others se &12345; or something |
| 10:27 | <Hixie> | or is that just for form submission |
| 10:27 | <Philip`> | Safari changed recently, so nightly versions of WebKit probably do something different to 3.1 |
| 10:27 | <Lachy> | Hixie, demo: http://tinyurl.com/6na2xh |
| 10:27 | <Hixie> | anyway either way iirc i looked at what they did, decided they were all on crack, and made the spec say "?" because that's the only thing that makes sense |
| 10:27 | <Hixie> | yeah safari does the &12345; thing, firefox does utf-8 |
| 10:27 | <Hixie> | both are insane |
| 10:28 | <Lachy> | ok |
| 10:28 | <Philip`> | http://lists.w3.org/Archives/Public/public-html/2008Jun/0426.html |
| 10:28 | <Hixie> | (we might switch the spec to &12345; in cr, though i will fight it all the way :-) ) |
| 10:29 | <Lachy> | ok. I thought Firefox converting to UTF-8 seemed reasonable |
| 10:29 | <Philip`> | What about character sets that don't contain the "?" character? |
| 10:29 | <Hixie> | Lachy: on the server side you have no idea what the encoding is if it changed, so how are you supposed to tell? |
| 10:29 | <Hixie> | what's a valid use case for splitting an image into two or more pieces? |
| 10:29 | <Hixie> | Philip`: like what? |
| 10:30 | <Philip`> | Hixie: Like a hypothetical one I could make up to be awkward |
| 10:30 | Hixie | goes to add that encoding to the spec in the "must not support" column |
| 10:30 | <Hixie> | (hypothetically) |
| 10:31 | <Lachy> | Hixie, I just thought if it were defined to be UTF-8 for a specified set of document encodings, or else the document encoding for anything else then the server would know by looking at what the spec told it to expect |
| 10:32 | <Lachy> | but I don't mind it converting to ?, if that's compatible with the web |
| 10:32 | <Philip`> | Hixie: <p>We have had <img src=counter/1.gif><img src=counter/4.gif><img src=counter/3.gif> visitors since 1998</p>, since it's often unacceptable to require server-side image generation (because that's complex and inefficient), where the appropriate alt text is a single string "143" and is not three distinct digit strings |
| 10:33 | <Hixie> | lachy: what firefox does is look at the characters in the url and decide on the encoding based on whether it can convert them or not |
| 10:33 | <Hixie> | Lachy: it's not based on the document encoding per se |
| 10:33 | <Lachy> | oh, ok. That's definitely insane |
| 10:33 | <Hixie> | Philip`: any other cases? |
| 10:34 | <Philip`> | Hixie: Do you count slicing images to create image maps (without using <map>, because e.g. you want one slice to be replaced dynamically when you move the mouse over it) to be a valid use case? |
| 10:35 | <Hixie> | no, because in those cases you'd want the alternative text in each image, not all in one |
| 10:36 | <Philip`> | Repeat the whole text in each <img>? That sounds like it would be annoyingly repetitive to anyone who is reading the page without images |
| 10:37 | <Hixie> | no, you'd want each link to have its appropriate text |
| 10:39 | <Philip`> | What if the image is a smiley face and the nose changes colour when you move the mouse over it, and so the image is sliced up so it only has to download the small nose section when it updates? The appropriate alt text for the whole thing would be something like "Smiley face" or whatever, and there wouldn't be appropriate text for each individual <img> |
| 10:42 | <Lachy> | woah, Firefox will encode all characters as UTF-8 if there are any non-ISO-8859-1 characters elsewhere in the query string. e.g. ?© vs. ?䬸© |
| 10:42 | <Hixie> | Lachy: correct |
| 10:42 | <Hixie> | Philip`: seems contrived, but ok :-) thanks |
| 10:43 | <Philip`> | There are probably better examples but I can't think of them right now :-p |
| 11:44 | <nzkoz> | hsivonen: Are you around? |
| 11:45 | <hsivonen> | nzkoz: yes |
| 11:46 | <nzkoz> | hey, if you have a moment I have a few questions about the validator.nu service, I've noticed some changes in the responses lately (since its downtime) |
| 11:47 | <nzkoz> | Things like http://xrl.us/omobx which now only give a few errors (one of which is fatal( where previously it enumerated quite a few more? |
| 11:48 | <nzkoz> | was there a major change that happened that I should do some reseearch on? |
| 11:49 | <hsivonen> | nzkoz: I fixed paragraph end inference inside list items, at least |
| 11:50 | <hsivonen> | nzkoz: do you remember what the old errors were about? |
| 11:51 | <hsivonen> | nzkoz: I haven't changed the XHTML 1.0 schemas lately except to tweak xml:space issues. |
| 11:51 | <nzkoz> | let me dig up an old response |
| 11:54 | <Hixie> | why aren't my e-mails making the list |
| 11:54 | <Hixie> | lists |
| 11:54 | <Hixie> | why aren't my e-mails going anywhere |
| 11:54 | <Hixie> | wtf |
| 11:54 | <nzkoz> | hsivonen: previously we got back: Attribute “xml:lang” not allowed on element “html” at this point. |
| 11:54 | <nzkoz> | then additional errors |
| 11:54 | <nzkoz> | now that seems to be sufficient to stop parsing? |
| 12:00 | <nzkoz> | hsivonen: yeah, at least in the 4 old responses I've dug up, the difference appears to be it stops reporting errors after it hits an xml:lang, previously it continued |
| 12:01 | <hsivonen> | nzkoz: oh. good point. I seem to have a bad config for XML violations. |
| 12:01 | <hsivonen> | nzkoz: thanks. I'll fix. |
| 12:03 | <nzkoz> | hsivonen: cheers, glad I could help. I'm scripting the json api and it's really useful. We're using gzip compression and setting a user agent, I assume you'd notify us if it were causing trouble? |
| 12:04 | <hsivonen> | nzkoz: yeah, that's OK. |
| 12:11 | <Hixie> | 1893 pending messages! |
| 12:11 | <tusho> | <Hixie> i think i might make alt=”" required and say that when you don’t know what the image is, you have to say what kind of image it is (e.g. “uploaded image”, “photo”, “thumbnil”, or whatever) and put that in braces in the alt=”" attribute, as in alt=”{photo}” |
| 12:11 | <tusho> | seems reasonable |
| 12:11 | <tusho> | how does it interact with screen readers |
| 12:12 | <Hixie> | they say "image photo" or some such probably |
| 12:12 | <hsivonen> | does anyone happen to remember which element don't have class/id allowed in XHTML 1.0 and HTML 4.01? |
| 12:13 | <tusho> | Hixie: they pronounce punctuation |
| 12:13 | <tusho> | I believe |
| 12:13 | <tusho> | image opening curly brace photo closing curly brace |
| 12:13 | <Hixie> | hsivonen: i sent you an e-mail with an archive link which is not accurate -- when you get the mail, then look around the link i gave for the actual link |
| 12:14 | <Hixie> | tusho: well by the time people are doing this on any kind of regular basis, hopefully they'll have caught up with the spec |
| 12:14 | <Philip`> | tusho: In the default configuration? |
| 12:14 | <tusho> | Hixie: now THAT'S wishful thinking :) |
| 12:14 | <tusho> | Philip`: i -think- so |
| 12:15 | <Hixie> | this is all for the case where the accessibility story is a lost cause anyway -- the whole point is we have no useful alternative text |
| 12:15 | <tusho> | Hixie: decoration |
| 12:15 | <hsivonen> | Hixie: ok |
| 12:15 | <tusho> | often basically useless to the content images are used to spruce up an article |
| 12:16 | <tusho> | for a screen reader, they should just be ignored |
| 12:16 | <tusho> | thus alt="" |
| 12:16 | <Hixie> | i don't understand why my scripts can send mail but i can't |
| 12:16 | <Hixie> | wtf |
| 12:16 | <Hixie> | tusho: spec says they should al be alt="" (empty alt), unaffected by this {photo} thing |
| 12:17 | <tusho> | Hixie: but you said you might make alt= required |
| 12:17 | <Hixie> | for decorative images, it is required, and is required to be empty |
| 12:17 | <tusho> | oh, I see |
| 12:17 | <tusho> | I misread the quote |
| 12:17 | <tusho> | I thought you meant making the alt attribute being mandatory and non-empty |
| 12:17 | <Hixie> | no |
| 12:18 | <tusho> | ok :) |
| 12:18 | <Philip`> | Calling it 'the alt="" attribute' is confusing, since that looks the same as saying decorative images must have alt="" |
| 12:19 | <hsivonen> | nzkoz: fixed. (the errors about the id attribute not being allowed in the XHTML 1.0 schema may be bogus. I'll investigate.) |
| 12:21 | <nzkoz> | hsivonen: awesome, thanks a bunch. For future reference is this the best way to raise anything else I notice? or should I use the bugzilla or...? |
| 12:22 | <hsivonen> | nzkoz: bugzilla.validator.nu is the preferred way, since there's a risk of IRC remarks falling through the cracks |
| 12:24 | <nzkoz> | k, will do. Thanks again |
| 12:31 | <Philip`> | Hixie: "... one of the images must its alt attribute set ..." is missing a word |
| 12:32 | <Hixie> | fixed |
| 12:32 | <Hixie> | thanks |
| 12:42 | <Hixie> | wish i knew why my e-mail wasn't going anywhere |
| 12:42 | <Hixie> | oh well |
| 12:42 | <Hixie> | bed time |
| 12:42 | <Hixie> | hopefully e-mail will make its way out while i'm sleeping |
| 12:46 | <Philip`> | I got commit notices for r1971, 1973, 1983 and 1985, and none of the ones in between |
| 12:51 | <mcarter> | hello |
| 12:53 | <mcarter> | I don't suppose anyone has any idea what is supposed to happen (if there is a standard) when an HTTP/1.1 XHR response is half over when there is a page navigation. Should it a) shut the connection immediately, or b) wait for the rest of the response (though now irrelevant), and then re-use the connection |
| 16:37 | <gDashiva> | I went in the month-change archive trap -again- |
| 16:37 | <gDashiva> | s/went/fell |
| 16:38 | <Philip`> | It's an effective way to get an occasional respite from the list discussions |
| 18:19 | <zcorpan> | aha.. can we resolve the extensibility problem by making document.write work in xml? |
| 18:25 | hsivonen | notes that the XML community already has its own document.write(). It's called disabling output escaping in XSLT. |
| 18:25 | <gDashiva> | I thought the XML community didn't want document.write |
| 18:26 | <tusho> | document.write = no thanks |
| 18:26 | <Philip`> | You could implement by having the server only transmit bytes up to the end of </script>, then having document.write() send an XMLHttpRequest to the server to tell it what bytes it should subsequently transmit to continue the XML document |
| 18:26 | <tusho> | a nicer layer over the DOM = yez plz |
| 18:26 | <tusho> | mochikit style that is |
| 18:26 | <Philip`> | s// it/ |
| 18:26 | <tusho> | p(strong("hello"), " world") |
| 18:27 | <tusho> | maybe: with (DOM) { ... } |
| 18:27 | <Philip`> | tusho: Why not use thing.innerHTML = '<p><strong>hello</strong> world</p>' for that? |
| 18:27 | <tusho> | Philip`: The DOM is less prone to errors and programmatically cleaner. |
| 18:27 | <tusho> | Plus you can't construct an invalid tree with it. |
| 18:31 | <zcorpan> | tusho: can't construct an invalid tree with innerHTML either |
| 18:31 | <tusho> | ok, wrong words |
| 18:31 | <tusho> | still |
| 18:31 | <tusho> | my other points stand |
| 18:34 | <zcorpan> | i'm not convinced that p(strong("hello"), " world") or (DOM) { ... } is less prone to error than innerHTML, and programmatically cleaner is just an opinion :) |
| 18:35 | <Philip`> | zcorpan: Try setting attributes in innerHTML and having to escape and concatenate everything properly, and then it should be clear which way is cleaner and less error-prone :-) |
| 18:37 | <Lachy> | I'm opposed to introducing document.write() into XML. It's unfortunate that it even exists for HTML |
| 18:37 | <Philip`> | But it's really useful |
| 18:37 | <hsivonen> | Lachy: with a well defined XML5 parsing algorithm including script execution steps, we could define document.write() for XML |
| 18:37 | <Lachy> | it encourages poorly structured programming practices |
| 18:38 | <Philip`> | It encourages people to write HTML code that works and does what they want and makes them happy, even if someone might say it's poorly structured :-) |
| 18:39 | <Lachy> | and makes people work with the DOM by manipuating strings, instead of actually working with the DOM properly, and the fact that it injects characters back into the input stream is bad design |
| 18:40 | <Philip`> | Working with the DOM "properly" is really ugly and painful, so it's not surprising that everyone tries to avoid that |
| 18:40 | <Lachy> | innerHTML is reasonable, because at least it doesn't mess with the input stream |
| 18:41 | <Lachy> | and keeps markup errors in the string isolated to just the element it's appeneded to |
| 18:41 | <Philip`> | But then you need to create a container element to set innerHTML, and give it an ID and document.getElementById('whatever') it and think of a new ID for every time you do this, and try not to get confused by all the indirection |
| 18:42 | <Lachy> | to e.g. document.write() with an unclosed inline element will affect the rest of the document, unlike how it would work in innerHTML |
| 18:42 | <Lachy> | if you create a container element, then you don't need an ID, you already have a reference to it. |
| 18:42 | <gDashiva> | The DOM kinda shot itself in the foot by making long, unwieldy identifiers a feature |
| 18:43 | <Lachy> | if there's one already in the DOM, then sure, gEBId (or other selector) is needed |
| 18:43 | <Lachy> | also, document.write() violates the separation of script and markup principles |
| 18:43 | <hsivonen> | gDashiva: the DOM shot itself in many places in many ways |
| 18:44 | <Lachy> | gDashiva, agreed |
| 18:44 | <Philip`> | Those separation principles rely on indirection, and hence are confusing and annoying |
| 18:44 | <Lachy> | your arguments are confusing and annoying |
| 18:45 | <Philip`> | That's quite possible |
| 18:45 | <Lachy> | there's nothing wrong with a little bit of indirection. It makes code more modular and allows for better reuse |
| 18:45 | gDashiva | laments the lost opportunity for "So's your face" |
| 18:46 | <Lachy> | :-D |
| 18:46 | <gDashiva> | So instead of document.write, what about a document.emitNode() or something, would that make people happy? |
| 18:47 | <Lachy> | how would it work? |
| 18:47 | <Philip`> | document.writeWellFormedFragment()? |
| 18:47 | <Lachy> | would it append the given node to the script's parent element? |
| 18:47 | <gDashiva> | Lachy: Yeah |
| 18:48 | <Lachy> | what if the <script> is the root element? |
| 18:48 | <gDashiva> | Then you deserve whatever is coming |
| 18:48 | <gDashiva> | Or you could specify it to replace the script element |
| 18:48 | <zcorpan> | Lachy: you do the same as document.appendChild() would do |
| 18:49 | <Lachy> | what if it's a DocumentFragment, with multiple child nodes? then it still would solve the root element problem/ |
| 18:49 | Lachy | goes to test how document.appendChild works in browsers |
| 18:49 | <zcorpan> | again, do the same as fragment.appendChild() would do :) |
| 18:50 | <Lachy> | it throws an error |
| 18:50 | <gDashiva> | The thing I'm trying to clarify is if the problem is emitting markup vs emitting DOM, or if it's emitting itself that's the problem |
| 18:50 | <Philip`> | What if the script removes its own <script> element from the document, and then calls emitNode()? |
| 18:51 | <Lachy> | zcorpan, no, I meant if you did document.emitNode(fragment); where fragment is a DocumentFragment |
| 18:51 | <zcorpan> | Philip`: then you do the same as document.appendChild() would do ;) |
| 18:51 | <zcorpan> | Lachy: ah |
| 18:51 | <hsivonen> | if you don't like doc.write but want to do it, you can compile a parser into JS using GWT and parse strings without source text insertion support in the browser |
| 18:51 | <zcorpan> | Lachy: well then you act as if you did document.appendChild() multiple times |
| 18:51 | <Lachy> | yeah, that would throw an exception |
| 18:52 | <zcorpan> | depends on if there's a root element or not |
| 18:52 | <Lachy> | what is GWT? |
| 18:52 | <hsivonen> | Lachy: Google Web Toolkit |
| 18:52 | <zcorpan> | i guess it would insert the first element and then throw, but perhaps it could be specced so that if it throws, nothing happens |
| 18:53 | <Philip`> | hsivonen: But only crazy people would do that |
| 18:53 | <Philip`> | hsivonen: and only crazy people who don't care about performance |
| 18:54 | <hsivonen> | Philip`: actually, if I manage to ship a JS library for retrofitting HTML5 parsing into Firefox 3, Safari 3.1 and Opera 9.5, I'd expect people to use it as a fallback for the past generation when the then-current generation support HTML5 parsing natively |
| 18:54 | <Philip`> | hsivonen: How many tens/hundreds of kilobytes of JS code is it? |
| 18:54 | <hsivonen> | if using it is as simple as <body><script src=html5.js></script> |
| 18:55 | <hsivonen> | Philip`: 128 KB without gzip |
| 18:55 | <Lachy> | heh, Hixie's mail from 10:16 this morning finally arrived about 10 hours late |
| 18:56 | <Lachy> | the one about the alt attribute stuff |
| 18:58 | <hsivonen> | Philip`: 36 KB with gzip |
| 18:59 | <hsivonen> | Philip`: my footprint vs. execution speed choices are meant for Java and C++, so it's not optimal for JS footprint |
| 19:02 | <hsivonen> | http://derstandard.at/text/?id=1216918402134 |
| 19:03 | <hsivonen> | Miguel seems to prefer Microsoft-controlled environments over JS and SVG |
| 19:08 | <Philip`> | That does not seem unexpected |
| 19:13 | <zcorpan> | Hixie: what does <img src=x alt={> represent when the ua is configured to not show images? |
| 19:15 | <Lachy> | zcorpan, that's covered by the 2nd condition in the spec "If the src attribute is set and the alt attribute is set to a string with at least one character whose first character is not a U+007B LEFT CURLY BRACKET character ({) or whose last character is not a U+007D RIGHT CURLY BRACKET character (})" |
| 19:15 | <Lachy> | that's the confusing one I complained about, cause I had the same question initially, till I figured it out before sending my mail |
| 19:15 | <zcorpan> | Lachy: how am i reading it wrong? |
| 19:16 | <zcorpan> | the first character IS { so it's not covered by that case |
| 19:16 | <Lachy> | because the last character is not '}' |
| 19:16 | <Philip`> | "{" has a first character that is not "{" or it has a last character that is not "}", so it is covered by that case |
| 19:16 | <zcorpan> | Lachy: it says or, not and |
| 19:17 | <Lachy> | no, think of it like this:... |
| 19:17 | <zcorpan> | hmm |
| 19:18 | <Lachy> | if ( isset(src) && isset(alt) && (alt[first-letter] != '{' || alt[last-letter] != '}')) |
| 19:18 | <Lachy> | (that's just some sort of pseudo-code, don't try to run it) |
| 19:19 | Philip` | doesn't know of any languages in which "first-letter" is a valid identifier rather than a subtraction expression :-p |
| 19:19 | <Lachy> | Philip`, in CSS it is |
| 19:19 | <Lachy> | :-) |
| 19:19 | <Philip`> | But CSS doesn't have subtraction expressions, so that doesn't count :-) |
| 19:20 | <zcorpan> | doesn't it have calc() ? |
| 19:20 | <Lachy> | not yet |
| 19:20 | <Lachy> | unless someone specced a proposal for it that I missed. |
| 19:21 | <zcorpan> | http://www.w3.org/TR/css3-values/#calc ? |
| 19:21 | <Lachy> | oh |
| 19:21 | <Philip`> | When I say "CSS" I mean "real CSS like what you can actually use in real life and it'll work in sensible web browsers" |
| 19:25 | <Lachy> | Philip`, in that case, you can use IE's expression() |
| 19:26 | <hsivonen> | is the execution time of expression well defined? |
| 19:26 | <hsivonen> | what if an expression has side effects? |
| 19:26 | <Philip`> | Lachy: "sensible web browsers" |
| 19:26 | <Lachy> | hsivonen, exression isn't defined at all. It's only poorly documented in MSDN, like all of Microsoft's extensions |
| 19:26 | <Philip`> | hsivonen: It isn't |
| 19:27 | <Philip`> | You can have side effects, and it'll just do whatever IE's layout engine wants to do |
| 19:27 | <Lachy> | hsivonen, I expect that IE would probably crash. I know that when i was forced to use it once, any time I did something mildly complicated, IE crashed |
| 19:28 | <hsivonen> | great value for users then |
| 19:28 | <Lachy> | it's designed for simple expressions, and for that it works ok. but it's not really well designed or implemented at all |
| 19:30 | <Lachy> | plus, it creates an attack vector, if a site allows style attributes to be added by users in comments or whatever, without filtering out expressions |
| 19:33 | <Lachy> | hah! I thought the Knights Templar only existed in Indian Jones and the Last Crusade. http://www.theregister.co.uk/2008/08/04/knights_templar_pope/ |
| 19:35 | <tusho> | Philip`: {doesn't know of any languages in which "first-letter" is a valid identifier rather than a subtraction expression :-p} |
| 19:35 | <tusho> | lisp |
| 19:35 | <tusho> | dyland |
| 19:35 | <tusho> | *dylan |
| 19:35 | <Philip`> | tusho: Ah, so it's only crazy languages ;-) |
| 19:40 | <Lachy> | http://xkcd.com/297/ |
| 19:40 | <Lachy> | my pseudo-code above did use a lot of parenthesis too. :-) |
| 19:44 | <zcorpan> | + users or very low-bandwidth connections or who pay by the byte, or |
| 19:44 | <zcorpan> | i guess people will laugh at that in 10 years |
| 19:47 | <Lachy> | zcorpan, what? no-one has such poor connections these days. Even dial up is relatively cheap |
| 19:47 | <Philip`> | zcorpan: Ten years ago when people started using things like ADSL, I imagine they would have laughed at the idea of still having very low-bandwidth connections and paying by the byte in the present day |
| 19:49 | <Philip`> | but people are still willing to pay for really rubbish internet connections, mostly since there's no competition and they have no other choice |
| 19:49 | <zcorpan> | Philip`: yeah, i'm not sure why we still have very low-bandwidth and pay by the byte :) |
| 19:49 | <Lachy> | oh, I didn't realise you were quoting hte spec |
| 19:49 | <Lachy> | Hixie probably put it in as a bit of a joke |
| 19:50 | <jgraham> | Lots of mobile users have low bandwidth, poor connections and pay by the byte |
| 19:50 | <zcorpan> | what jgraham said |
| 19:50 | <Lachy> | well, by the kilobyte, maybe |
| 19:51 | <Philip`> | People are still willing to pay however much they pay for SMS messages - the price hasn't been driven to zero by the improvements in technology, because what's important is how much the service is worth to people, and that's fairly constant over time |
| 19:51 | <Lachy> | I suppose they still charge a lot for mobile and wireless connections these days |
| 19:52 | <jgraham> | Philip`: there are lots of plans with hundreds of free texts for only £extortionate monthly rates |
| 19:52 | <Lachy> | Philip`, people have been complaining about the price of SMS for a while |
| 19:52 | <Lachy> | it's the telcos that just won't listen |
| 19:52 | <jgraham> | Lachy: I don't recall that happening in the UK |
| 19:52 | <jgraham> | where SMS is very very popular |
| 19:52 | <Lachy> | I didn't say it wasn't popular. Just expensive |
| 19:53 | <Philip`> | Lachy: Why should they listen? |
| 19:53 | <Lachy> | Depending on your plan, it can still cost $0.20 per message |
| 19:53 | <Lachy> | ...in Australia |
| 19:53 | <Lachy> | though, at least some offer either unlimited or hundreds of free SMSs |
| 19:58 | <Philip`> | I guess the mobile operators looked at the internet running over standard telephone lines and decided that it was clearly a miserable failure since the telephone companies weren't being paid any more than for standard voice calls, and so they're still trying hard to avoid that mistake |
| 20:01 | <jgraham> | Philip`: I guess that's not true in the UK because there does seem to be actual competition between operators |
| 20:02 | <jgraham> | (well I mean it might be true that they prefer that scenario, but it's hard to imagine how they will be able to maintain it) |
| 20:02 | <jgraham> | s/that scenario/the current scenario/ |
| 20:03 | Philip` | knows almost nothing about mobile phones, since he's only ever had one (which is probably four or five years old now) and almost never uses it |
| 20:04 | jgraham | keeps losing his phone |
| 20:04 | <jgraham> | (well that is to say I did it and then didn't get another one) |
| 20:05 | <jgraham> | (because I hardly ever used it anyway and cool stuff like internet access is only sensibly priced if you also buy an expensive contract) |
| 20:18 | <zcorpan> | Hixie: the captca example is missing an end tag |
| 20:23 | <zcorpan> | given 4.7.2.1.10., alt is still not always required |
| 20:49 | <Hixie> | zcorpan: i agree that the patch isn't one we want, but thanks for the headsp |
| 20:49 | <Hixie> | zcorpan: (i trust your judgement in these issues) |
| 20:55 | <zcorpan> | Hixie: having many mods seems to be effective against spam |
| 20:56 | <zcorpan> | Hixie: we've only had spam once and two mods were on it pretty quickly :) |
| 20:57 | <Hixie> | nice |
| 21:00 | <zcorpan> | http://www.paciellogroup.com/blog/?p=84 |
| 21:07 | <Lachy> | "no co-operative exchange occured with WAI prior to the changes..." - Is he choosing to ignore excessive amount of discussion about the whole issue previously on public-html and the wai lists? |
| 21:09 | <Lachy> | maybe because this specific proposal wasn't discussed on the list recently, before it was added to the spec. But so what? It's a proposal. At least this gives us something to discuss |
| 21:09 | <Hixie> | well i'm glad that we're worried about process rather than what the spec says now |
| 21:09 | <Hixie> | that's at least a step in the right direction |
| 21:11 | <Lachy> | well, he said he hasn't had time to review it all yet. But I find it annoying having so many bureaucracy trolls |
| 21:16 | <Lachy> | I'm pretty sure this proposal will be much more well received than the last, since it actually ends up giving a lot more useful information about the image than something like noalt="", or some other reserved keyword like alt="_unknown" |
| 21:18 | <Philip`> | And because people who might have minor objections will keep quiet since they don't want to risk reanimating the issue |
| 21:19 | <Hixie> | hah |
| 21:19 | <Hixie> | didn't stop lachy! :-P |
| 21:20 | <Lachy> | Hixie, I think you should rephrase the "In a rare subset of these cases..." and "...if the site has received 8000 photos...". Those particular phrases caused quite a lot of controversy and don't seem to convey their intended meaning well |
| 21:20 | <Hixie> | yeah |
| 21:20 | <Hixie> | god point |
| 21:20 | <Hixie> | good even |
| 21:22 | <Lachy> | I think it should just focus on the specific conditions of when using {...} is acceptable. i.e. when the image is obtained without associated alt text, rather than trying to explain it through examples |
| 21:24 | <Hixie> | it also applies to inkblot tests and blind people's photos |
| 21:26 | <Lachy> | probably also applies to fixed weather cams or traffic cams, which just take and publish intermittent photographs without user intervention |
| 21:27 | <Philip`> | And coffee pot cams |
| 21:27 | <Lachy> | haven't seen one of those |
| 21:28 | <Philip`> | http://en.wikipedia.org/wiki/Trojan_room_coffee_pot |
| 21:28 | <Dashiva> | They're common in highly caffeinated nerd clubs |
| 21:33 | <Hixie> | ok Lachy, checked in your suggestions |
| 21:35 | <Hixie> | didn't change the e-mail thing, i don't see any reason why it would matter in that case, and it doesn't affect web page conformance anyway |
| 21:38 | <Lachy> | Hixie, missing ')' from the end of: If the src attribute is set and the alt attribute is set to a value that isn't matched by the previous two entries (not empty, not "{...}" |
| 21:38 | <Hixie> | oops |
| 21:39 | <Lachy> | and you didn't change it for the other one describing the case for when the src attribute is not set |
| 21:40 | <Hixie> | right, see e-mail |
| 21:41 | <Hixie> | i have GOT to start taking out the "***DHSPAN***" bits of subject lines i send! |
| 21:42 | <Dashiva> | What is that anyway? |
| 21:42 | <Lachy> | s/DHSPAN/DHSPAM/ == DreamHost SPAM, I figure |
| 21:42 | <Hixie> | yeah |
| 21:43 | <Hixie> | people who top-post tend to trigger my last spam line of defence |
| 21:43 | <Hixie> | which is spam assassin's "i don't think it's spam but it's suspicious so i'll label it as such anyway" |
| 21:43 | <Lachy> | Hixie, the email just says you changed the order of them, but you only did it for one. Since they conditions are the basically the same, except one is for when src is present and the other for when it's not, they should be written in almost the same way. |
| 21:44 | <Lachy> | so it should be changed to "If the src attribute is *not* set and the alt attribute is set to a value that isn't matched by the previous two entries (not empty, not "{...}" )" |
| 21:45 | <Hixie> | oh! |
| 21:45 | <Hixie> | i see what you're saying |
| 21:45 | <Hixie> | my apologies |
| 21:45 | <Lachy> | what did you think I was saying? |
| 21:47 | <Lachy> | "...display some sort of indicator that the image is not being rendered, if possible providing..." needs to be fixed grammatically. It should be "... rendered and, if possible, providing ..." |
| 21:49 | <Hixie> | ok all those are fixed now |
| 21:56 | <Lachy> | ok, that works even better the way you did it with the "otherwise" condition |
| 22:05 | <Lachy> | hmm, something is wrong with my IRC client. It just crashed several times in a row :-( |
| 22:06 | <Lachy> | ... and it did it again. Whenever I right click on it :-( |
| 22:06 | <Hixie> | d'oh |
| 22:06 | <Philip`> | Maybe it's a Mac application and they never imagined someone might right-click |
| 22:07 | <Lachy> | maybe there's something wrong with the profile or a plist or something. |
| 22:07 | <Lachy> | LOL |
| 22:07 | <Lachy> | I'm supposed to be able to right click on someones name and select to open a private chat with them |
| 22:09 | <Hixie> | hsivonen's data shows that even in the svg files he downloaded, there are html <font> elements :-) |
| 22:10 | <Hixie> | though it looks like that can likely be accounted for by the cases where <font> wasn't in the svg namespace? unclear |
| 22:10 | <hsivonen> | Hixie: I looked for the local name |
| 22:11 | <hsivonen> | I should rerun the analyzer excluding foreignContent stuff |
| 22:11 | <hsivonen> | foreignObject that is |
| 22:12 | <Philip`> | hsivonen: Do you record a list of which files match each of the features you're searching for? |
| 22:12 | <Lachy> | I never thought the HTML5 spec would ever teach me a new Norwegian word :-) |
| 22:12 | <hsivonen> | Philip`: i don't |
| 22:12 | <Hixie> | i'm hoping the norwegian word is correct |
| 22:12 | <Lachy> | according to Google Translate it is |
| 22:12 | <Hixie> | my norwegian friends have not yet responded! |
| 22:13 | <Lachy> | I'll look it up in my Norwegian dictionary for you |
| 22:13 | <Hixie> | yeah, but i used google translate to determine it, so... |
| 22:13 | <Lachy> | Hixie, in all your time living in Norway, did you learn much Norwegian? |
| 22:13 | <Hixie> | Lachy: not really |
| 22:13 | <Hixie> | Lachy: but i didn't try very hard |
| 22:14 | <Lachy> | ok |
| 22:14 | <Hixie> | hsivonen: i really wasn't expecting the conclusions you drew from that data. that's really interesting. |
| 22:14 | <Hixie> | hsivonen: i think i'll make <font> be triggered from attributes |
| 22:14 | <Lachy> | nor have I. I know enough to get me through shopping |
| 22:14 | <Lachy> | and that's about it |
| 22:14 | <hsivonen> | Hixie: what conclusions don't flow from the data? |
| 22:15 | <Hixie> | hsivonen: all the conclusions flow from the data |
| 22:15 | <Hixie> | hsivonen: i jsut wasn't expecting that data |
| 22:15 | <hsivonen> | ah. I thought you weren't expecting the conclusions given the data |
| 22:15 | <Hixie> | Lachy: i never found lack of norwegian knowledge to be a practical barrier to living in norway. |
| 22:16 | <hsivonen> | Hixie: anything particularly unexpected? |
| 22:16 | <Hixie> | hsivonen: that the svgwg proposal would actually break on more pages than the commented out proposal |
| 22:16 | <Lachy> | From my dictionay: *bilde* /subst/. n 1. picture |
| 22:16 | <Hixie> | also, the sheer number of metadata elements |
| 22:17 | <Hixie> | Lachy: not photograph? bummer. |
| 22:17 | <Lachy> | the example is "I took a picture of my daughter" |
| 22:17 | <Lachy> | I'll look up photo |
| 22:17 | <hasather_> | Hixie: that would be "fotografi" |
| 22:18 | <Hixie> | isn't that photography, as opposed to photograph? |
| 22:18 | <Lachy> | Hixie: *Photo* is either: fotografi, foto, bilde |
| 22:19 | <hasather_> | Hixie: oh, sorry, read that wrong, then it's "foto" |
| 22:19 | <Hixie> | bummer, i was hoping for something that looked nothing like "photo" :-) |
| 22:20 | <Hixie> | i'd have used french but it uses photo too |
| 22:20 | <Lachy> | Hixie, fotograph is the same as photograph |
| 22:20 | <hsivonen> | Hixie: you could use 'valokuva' for lang=fi |
| 22:20 | <Hixie> | aha! |
| 22:20 | <Hixie> | henri to the rescue |
| 22:20 | <Lachy> | I mean fotografi |
| 22:21 | <Lachy> | silly norwegians using an "f" instead of "ph" for an "f" sound is confusing ;-) |
| 22:21 | <Hixie> | hsivonen: lang=fi is "Finnish" right? (checking spelling) |
| 22:21 | <hsivonen> | Hixie: yes |
| 22:22 | <Hixie> | committed |
| 22:22 | <Hixie> | thanks |
| 22:25 | <Lachy> | I wish there was some way for the spec to dynamically update itself whenver Hixie makes a commit, so I don't need to keep reloading the whole thing |
| 22:25 | <Hixie> | hmmm... |
| 22:26 | <Hixie> | that could be arranged |
| 22:26 | <Lachy> | cool |
| 22:29 | <Hixie> | Lachy: when i make a commit, or when i make an edit even before committing it? |
| 22:31 | <Lachy> | commits would be sufficient, and would probably work better since the revision number would provide a way for it to ask the server for all updates since the last revision it received. |
| 22:31 | <Lachy> | so if I go offline for a little while, then I still get all the updates during that time when I return |
| 22:31 | <roc> | sigh |
| 22:31 | <Hixie> | my plan is just to reload the page |
| 22:31 | <Hixie> | not do DOM-level diffs |
| 22:31 | <Lachy> | oh |
| 22:31 | <Hixie> | which would be insane amounts of work :-) |
| 22:31 | <Hixie> | roc: sigh? |
| 22:31 | <Philip`> | Rather than automatically reloading and making readers very confused if the text they just read has vanished for no apparent reason, could it just pop up a notification box with a button to reload? |
| 22:32 | <Hixie> | (patches welcome though if you want to do DOM-level diffs) |
| 22:32 | <Lachy> | well, I wouldn't want an auto refresh for that. |
| 22:32 | <Lachy> | since if I'm reading a section, I don't want it to suddently disappear |
| 22:33 | <Hixie> | a notification would be fine too i guess |
| 22:33 | <Hixie> | oh hey i know how to do diffs |
| 22:33 | <Philip`> | Subscribe to commit-watchers with a mail client that pops up a notification box when you get new mail |
| 22:33 | <Lachy> | I wonder how DOM level diffs could be implemented. Might have to parse the old revision and the latest revision with html5lib, then diff the DOMs and send back the changes somehow |
| 22:33 | <roc> | http://derstandard.at/?url=/?id=1216918402134 ... it's Miguel de Icaza |
| 22:34 | <Hixie> | i could also do it client-side by parsing the new doc into a DOM |
| 22:34 | <Hixie> | and doing something clever with the two DOMs |
| 22:34 | <Philip`> | By "clever" do you mean "fragile"? |
| 22:34 | <Lachy> | Philip`, I'm on commit watchers, but I don't like reading it cause that whole syntax is not really readable |
| 22:35 | <Hixie> | roc: so sad to see someone so intelligent fall onto a treadmill like that |
| 22:35 | <Philip`> | Lachy: The presence of the email still serves as a notification that you should reload the spec if you're currently reading it |
| 22:36 | <Lachy> | if it's done server side, then that would reduce your bandwidth load, but increase processor load. But if it's done client side, then it increases everyone's bandwidth load and client side processing |
| 22:38 | <Lachy> | but I guess, walking the DOMs, and comparing the innerHTML of the block level elements, and then updating and flagging the ones that change would work. |
| 22:39 | <Philip`> | If one paragraph is added, how would you tell that all the subsequent paragraphs are unchanged (just offset) from the previous version? |
| 22:40 | <Lachy> | xmldiff might work http://www.logilab.org/859 |
| 22:40 | <Lachy> | it says it can work with DOMs |
| 22:51 | <Lachy> | xmldiff won't even install |
| 22:51 | <Lachy> | $ python setup.py install |
| 22:51 | <Lachy> | File "setup.py", line 23 |
| 22:51 | <Lachy> | from __future__ import nested_scopes |
| 22:51 | <Lachy> | SyntaxError: from __future__ imports must occur at the beginning of the file |
| 22:58 | <Hixie> | woah, did sam just say he was ok with the spec? |
| 23:03 | <Lachy> | nice. I like it when people can become happy with the spec, without making any specific changes for them. |
| 23:06 | <Philip`> | He only seems to be okay if you ignore the line where he said "Of course, the usuability of such an approach sucks" |
| 23:11 | <Hixie> | well yes |
| 23:11 | <Hixie> | but as he says |
| 23:11 | <Hixie> | that's the point |
| 23:12 | <Hixie> | though to be honest i don't see why it sucks so much, it's basically syntactically equivalent and actually has more features than raw element names (you get to pick your own disambiguation scheme, you can pick multiple names, there is better fallback, etc) |
| 23:14 | <Lachy> | Hixie, for the marked issues in the spec, we used to have a JavaScript that inserted "Big Issue: " at the beginning of each one. You could just enable that again |
| 23:15 | <Lachy> | or maybe change it to insert a ** or some other syntax |
| 23:18 | <Lachy> | Hixie, http://status.whatwg.org/mark-issues.js |
| 23:18 | <Lachy> | it was called as part of this script http://status.whatwg.org/annotate-web-apps.js |
| 23:18 | <Hixie> | ah |
| 23:18 | <Philip`> | Isn't it easier to write "Big Issue" in the source, rather than having JS that slowly traverses and dynamically updates the whole document at runtime on each client? |
| 23:19 | <Lachy> | Philip`, it could probably be done by the spec gen or something |
| 23:19 | <Hixie> | i don't really want the issues to say "big issue" though |
| 23:20 | <Hixie> | at least not to sighted users |
| 23:23 | <Lachy> | is there some almost-invisible character that would be noticed by screen readers that could convey the intended meaning? |
| 23:23 | <Philip`> | <font color=white>Big Issue:</font> |
| 23:24 | <Lachy> | Philip`, stylesheets could hide it |
| 23:24 | <Hixie> | wouldn't they hide it from screen readers too? |
| 23:25 | <Philip`> | (and then Google will ban you for making content visible to search engines and not to normal users) |
| 23:25 | <Lachy> | Hixie, not if you use position: absolute; left: -2000px; |
| 23:25 | <Hixie> | that's such a hack |
| 23:25 | <Hixie> | what's the officially right way to do this? |
| 23:25 | <Lachy> | for these in the stylesheet: p.note:before { content: 'Note: '; } p.warning:before { content: '\26A0 Warning! '; }, that probably could be inserted directly into the markup instead of using stylesheets too |
| 23:25 | <Hixie> | surely the accessibility experts have come up with a solution |
| 23:26 | <Lachy> | Hixie, unfortunately, the correct way to do it would have been display: none;, but screen readers decided to ignore such content |
| 23:26 | <Hixie> | i'll wait for gsnedders to come back and have him add stuff for those classes |
| 23:26 | <Hixie> | Lachy: yeah, i know, i was being sarcastic. :-) |
| 23:26 | <Hixie> | Lachy: the right solution is for screen readers to be replaced by actual speech browsers |
| 23:27 | <Hixie> | i should go eat lunch |
| 23:27 | <Hixie> | bbiab |
| 23:27 | <Lachy> | Hixie, I agree. But others who work in the accessibility field disagree, cause apparently users use the same screen reader for all their applications, not just web browsing |
| 23:28 | <Philip`> | It would be great if the market was large enough to support development of a real browser comparable to IE or Firefox but designed for a speech interface, but it doesn't seem to be |
| 23:28 | <Philip`> | Oh, actually that wouldn't be great - it would be best if the market disappeared entirely |
| 23:29 | <Lachy> | if there was such a browser that ordinary screen readers could hook into, that might work too, instead of trying to hack an accessibility API onto a browser predominately designed for visual users |
| 23:29 | <roc> | since 90% of the code is the same for a visual browser and a speech browser, it would make sense to share the code |
| 23:29 | <Lachy> | you mean if we exterminated all potential users of screen readers? Sure, that would work. It's a bit cruel though! |
| 23:29 | <jcranmer> | if there was a browser that wacked web developers senseless until they actually designed for non-visual users, that would help |
| 23:30 | <roc> | and then you have to ask yourself if it makes sense to have one build for visual and one for speech |
| 23:30 | jcranmer | would have to ask MarcoZ what the internet is like with a screen reader |
| 23:30 | <Philip`> | Lachy: I was thinking of a more ideal world where people don't have such disabilities, not one where we kill everyone who doesn't conform |
| 23:31 | <Philip`> | s/don't have/never acquire/ |
| 23:32 | <Philip`> | The problem is when there a lot of people who are affected by poor tools, but not enough to justify the development of good tools |
| 23:32 | <Philip`> | *when there are ... |
| 23:32 | <Lachy> | roc, separate browsers could share the same underlying code, but with UI built from the groud up to support different methods of usage |
| 23:33 | <roc> | yeah, ok |
| 23:33 | <jcranmer> | the Gecko screen reader browser! |
| 23:33 | <Lachy> | in my limited use of screen readers, I found that one of my biggest hassels was that the screen reader overrides many of the normal application keyboard shortcuts |
| 23:34 | <roc> | given that things like http://vimperator.mozdev.org/ exist, you probably build what's needed as a Firefox extension |
| 23:34 | <Lachy> | if the application itself was designed and built with a screen reader UI in mind, then such conflicts could be avoided |
| 23:34 | <jcranmer> | an XULRunner application might be better? |