| 01:13 | <Lachy> | Hixie, why does it matter if an image is stretched or not, for the purpose of conformance? |
| 01:13 | <Hixie> | why does it matter if a tag is closed or not, for the purpose of conformance? |
| 01:14 | <Hixie> | in almost all cases, stretching an image is a mistake. in the remaining cases where it is intentional, it's dubious practice. this argues for the author being notified of the problem. |
| 01:15 | <Hixie> | same as with anything else that is a conformance error |
| 03:39 | <kangax> | Could anyone point to an SVG to Canvas converter? |
| 08:48 | <hsivonen> | MikeSmith: yeah, it's just that one jar file |
| 08:48 | <MikeSmith> | hsivonen: yeah, I got it figured out finally |
| 08:49 | <MikeSmith> | I was using "jar -r" to run it |
| 08:49 | <MikeSmith> | and that caused it to ignore the datatype library despite the fact I had it in my classpath |
| 08:50 | <hsivonen> | MikeSmith: the -jar switch sucks |
| 08:50 | <MikeSmith> | yeah |
| 08:50 | <MikeSmith> | I should have known better than to try it |
| 08:52 | <MikeSmith> | anyway, I did manage to be able to run it, but not without fatal errors |
| 08:52 | <MikeSmith> | running against the HTML5 schema, I get java.lang.StackOverflowError |
| 08:53 | <MikeSmith> | at com.sun.msv.grammar.ExpressionCloner.onChoice(ExpressionCloner.java:37) |
| 08:54 | <MikeSmith> | anyway, I'm giving up on it |
| 08:55 | <MikeSmith> | and instead just writing a stylesheet to pre-process the schema and combine all the choice=combine stuff |
| 09:06 | <hsivonen> | MikeSmith: msv is no good with the default stack size of hotspot |
| 09:07 | <hsivonen> | -XX:ThreadStackSize=2048 |
| 09:10 | <MikeSmith> | hsivonen: OK, trying now |
| 09:12 | <MikeSmith> | getting same error even with that switch |
| 09:13 | <MikeSmith> | but anyway, the idea is kind of a no-go regardless, due to that fact that it's going to restructure the whole schema |
| 09:14 | <MikeSmith> | the only thing I really want is to just consolidate the @combine=choice stuff, which I think can manage to do with XSLT |
| 10:18 | <Lachy> | oh, I wish what I wrote in IRC didn't get dragged into the thread on the mailing list :-(. I chose not to respond on the list for a reason. |
| 10:22 | <Hixie> | i hope mike is happy: http://www.whatwg.org/specs/web-apps/current-work/#fetching :-) |
| 10:25 | MikeSmith | smiles |
| 10:25 | <MikeSmith> | Hixie: cool |
| 10:27 | <MikeSmith> | "At a time convenient to the user and the user agent" is an interesting phrase |
| 10:30 | <Lachy> | heh. It makes it sound like my browser should book an appointment with me to do the download :-) |
| 12:21 | <Hixie> | nn |
| 22:26 | <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}" |
| 22:26 | <Hixie> | and that that is never allowd inside a link |
| 22:27 | <Hixie> | (in a link it should just give the text that is appropriate for the link, e.g. alt="View image" if it's a link to the image) |
| 22:29 | <Hixie> | this seems to handle all the cases that allowing alt="" to be omitted does, while verly mildly improving the accessibility of those images, and being slightly more compatible with legacy UAs |
| 22:29 | <Hixie> | (it affects some legacy pages, though not many, and certainly no more than the missing-alt-altogether case would) |
| 22:40 | <takkaria> | seems like a wise decision |
| 22:47 | <Lachy> | Hixie, why use curly braces instead of square brackets? |
| 22:48 | <jcranmer> | Lachy: it's more exotic |
| 22:48 | <jcranmer> | and probably less likely to conflict |
| 22:49 | <Lachy> | ok, makes sense |
| 23:02 | <Hixie> | Lachy: [] are used a lot already |
| 23:02 | <Hixie> | Lachy: {} not so much |
| 23:02 | <Hixie> | Lachy: iirc <> is used even less, but that causes problems in xml or something |
| 23:02 | Hixie | logs on to his vpn to get the numbers |
| 23:03 | <jcranmer> | < >, if anyone remembers |
| 23:05 | <Hixie> | ok here are the stats as percentages of total pages scanned |
| 23:05 | <Hixie> | pages that had an img that wasn't in a link and had a value that followed the pattern [...]: 0.45% |
| 23:05 | <Hixie> | pages that had an img that wasn't in a link and had a value that followed the pattern (...): 0.13% |
| 23:06 | <Hixie> | pages that had an img that wasn't in a link and had a value that followed the pattern {...}: 0.035% |
| 23:06 | <Hixie> | pages that had an img that wasn't in a link and had a value that followed the pattern <...>: 0.033% |
| 23:07 | <Hixie> | most common alt={...} value was alt={alpha}, most of which it seems came from pages created by one particular conversion tool |
| 23:08 | <jcranmer> | I'm surprised (...) is that low |
| 23:09 | <Hixie> | number of pages with <img>: 94% |
| 23:09 | <Hixie> | number of pages with <img alt>: 82% |
| 23:09 | <Hixie> | number of pages with <img alt> with non-empty alt: 77% |
| 23:10 | <Hixie> | number of pages with <img> that had at least one without an alt="": 67% |
| 23:11 | <Hixie> | number of pages with <img alt> and that had all their <img> with alt="": 27% |
| 23:11 | <Hixie> | number of pages that had at least one <img> element but no <img> elements with alt="": 11% |
| 23:12 | <jcranmer> | which comes out to somewhere between 29%-71% of images that don't have alt |
| 23:12 | <Lachy> | ok, well, it nicely solves the problem of distinguishing between legitmate and guessed alt text, so it seems like a reasonable solution |
| 23:13 | <Hixie> | most of the alt=""s with the pattern <...> seemed to be mistakes, e.g. 0.0015% of pages had alt="span style='background-color: #CCFFFF'>Visa</span>" |
| 23:13 | <Lachy> | so what would authoring tools like Dreamweaver be requried to insert by default? Would alt="{image}" be ok? |
| 23:14 | <Hixie> | if the author knows what the image is, then alt="{...}" is never "ok" |
| 23:14 | <jcranmer> | I think apache's autoindex uses "[ TXT ]" as alt.. |
| 23:14 | <Hixie> | but yeah, i guess that would be a reasonable default for the case where today they just omit alt="" or have alt="" empty without probable cause |
| 23:15 | <Lachy> | yeah, I know that. But by default when a user just drags and drops an image into the WYSIWYG editor, and doesn't enter anything for alt text into the prompt |
| 23:15 | <jcranmer> | actually, just "[TXT]" |
| 23:15 | <Hixie> | jcranmer: second most common [...] alt value was [DIR] 0.085% (first was [new] 0.095%, third was [NEW] 0.066%) |
| 23:16 | <jcranmer> | [DIR] is used in apache's autoindex |
| 23:16 | <Hixie> | jcranmer: [TXT] was 0.024% |
| 23:16 | <Hixie> | less common than [cpp] and [flash] |
| 23:16 | <Hixie> | and [*] |
| 23:17 | <Hixie> | most common (...) values were (+), (-) and (?) |
| 23:17 | <Lachy> | what would [cpp] be used for? |
| 23:17 | <jcranmer> | \[[A-Z]+\] is quite possibly autoindexing |
| 23:17 | <jcranmer> | I don't know what IIS uses, if anything |
| 23:17 | <Hixie> | (0.038%, 0.037%, and 0.0095% respectively) |
| 23:18 | <Hixie> | yeah apache's autoindexing was well represented in these results |
| 23:18 | <Hixie> | [spoiler] was common too |
| 23:18 | <jcranmer> | what does [] look like if you exclude apache, which is probably a valid use case? |
| 23:19 | <jcranmer> | although it would have to be ~30% of all stuff to change the rankings |
| 23:19 | <Hixie> | valid how? |
| 23:19 | <Hixie> | not sure what you mean |
| 23:20 | <webben> | Hixie: Hmm what turned out to be wrong with using an attribute to signal the poverty of alt text, rather than resorting to odd syntax inside the alt attribute? |
| 23:20 | <webben> | especially given the use-case is automatic insertion rather than hand-authoring |
| 23:21 | <Hixie> | jcranmer: the [...] values were (roughly in order): [new], [DIR], [NEW], [ ], [*], [b], [img], [i], [url], [u], [email], [quote], [flash], [fixed], [spoiler], [cpp], [strike], [TXT], [IMG], [ICO], [M], ... |
| 23:22 | <jcranmer> | five of which are definitely apache |
| 23:22 | <Hixie> | webben: it seems more likely to be misused |
| 23:22 | <Hixie> | webben: e.g. through ignorant copy-paste |
| 23:22 | <Hixie> | webben: also, coming up with a name was difficult |
| 23:22 | <jcranmer> | another seven of which seem to be BB-code |
| 23:23 | <webben> | I'd have thought exactly the opposite was the case. |
| 23:23 | <jcranmer> | [img alt="[b]SEE THIS[/b]"] ? |
| 23:23 | <webben> | that a weird syntax inside alt is utterly opaque |
| 23:23 | <jcranmer> | although the non-existence of [/b] does seem to invalidate that theory... |
| 23:24 | <webben> | Hixie: Is there a list of proposed names anywhere? |
| 23:24 | <Hixie> | webben: not a convenient list, no |
| 23:25 | <Lachy> | webben: noalt, important |
| 23:25 | <Lachy> | I can't remember the others |
| 23:25 | <webben> | yeah, well, I agree those aren't good names ;) |
| 23:25 | <Hixie> | webben: what kind of proposal did you have in mind? <img alt="..." alt-is-not-actually-a-description-but-a-category="true"> ? |
| 23:25 | <Hixie> | webben: (with a better name obviously!) |
| 23:26 | <webben> | well, you wouldn't need the ="true" (presumably?) but yeah. |
| 23:27 | <Hixie> | that was basically my importantimage="" proposal, but nobody could come up with a good attribute name. |
| 23:28 | <webben> | missing-text-equivalent |
| 23:28 | <Dashiva> | please-sir-can-i-have-some-more-validation |
| 23:29 | <Hixie> | webben: <img alt="Photo" missing-text-equivalent> vs <img alt="{Photo}"> seems like a tossup as to which is better |
| 23:29 | <webben> | that name's still probably not ideal, but I think the former is easily better. |
| 23:30 | webben | would suggest testing it with some newbie authors and asking them what they think these syntaxes mean |
| 23:30 | <webben> | actually that's not a fair test |
| 23:30 | <webben> | since that clues them in that {} is a syntax, which is counter-intuitive |
| 23:31 | <Hixie> | heh |
| 23:32 | <Hixie> | i wish i could remember why i had decided to look at alt={...} rather than importantimage="" |
| 23:32 | <Hixie> | there was some more serious problem than the name, iirc, but i don't recall what |
| 23:33 | <Dashiva> | (You could use self-documenting decisions, that way you won't have to document anything) |
| 23:33 | <Hixie> | not sure what that would mean here :-) |
| 23:34 | <Hixie> | the decision wasn't written down anywhere, i just did it |
| 23:35 | <Lachy> | if we documented every decision, that would take the fun out of rehashing old arguments! |
| 23:39 | <Dashiva> | Hixie: I just felt like taking a jab at self-documenting code. |
| 23:39 | <Hixie> | heh |
| 23:42 | <Hixie> | webben: missing-text-eqivalent doesn't really convey the right message, i'm not sure it actually helps vs {...} |
| 23:42 | <webben> | Hixie: is " alt-is-not-actually-a-description-but-a-category" the right message? |
| 23:42 | <Lachy> | Hixie, are you speccing the {...} feature now? |
| 23:43 | <Hixie> | the message is alt-is-not-actually-a-description-but-a-category-because-we-do-not-know-what-the-image-actually-is |
| 23:43 | <Hixie> | Lachy: i'm looking at it. it's one of the folders with the most messages |
| 23:44 | <webben> | Hixie: alt-is-category-only ? |
| 23:44 | <Hixie> | webben: i guess the reason i prefer {...} is that if we're going to come up with some mostly opaque syntax, i'd rather pick the most compact |
| 23:45 | <Hixie> | webben: that's pretty long, and still doesn't really help, i mean, what's a category? does that mean i can just do this on all my images? etc. |
| 23:46 | <webben> | I think the what's a category question is answered by the alt content itself. |
| 23:47 | <Lachy> | I like the {} syntax better because it looks ugly enough to discourage authors from using it on all their images, yet simple enough to be used where appropriate |
| 23:47 | <Lachy> | would alt="{}" be considered non-conforming? |
| 23:48 | <webben> | While {} might discourage authors using {}, it doesn't make it clear the alt is suboptimal. Consequently newbies could easily take away the message that alt="Photo" is a good alt. |
| 23:49 | <webben> | missing-text-equivalent at least hints that something's wrong. |
| 23:49 | <Lachy> | and which of these regexes best matches the proposed syntax: /^\{.+\}$/ or /^\{[^\}]+\}$/ |
| 23:51 | <Hixie> | webben: the stats indicate that authors already think omitting alt altogther is fine |
| 23:51 | <Hixie> | webben: so i don't think this will make it any worse |
| 23:51 | <Hixie> | Lachy: i was just thinking /^\{.*\}$/ |
| 23:51 | <webben> | Hixie: I don't see the logical connection between those stats and the effect of any given example. |
| 23:52 | <Hixie> | webben: i'm saying that nothing could make the current authoring practices worse |
| 23:52 | <Lachy> | Hixie, so then alt="{}" would be conforming, even though it's almost completely useless to UAs since it says nothing about what type of image it is? |
| 23:52 | <webben> | I don't think not making it any worse is the bar we should be setting. ;) |
| 23:53 | <Hixie> | Lachy: alt="{image}" doesn't say anything about what it is either |
| 23:53 | <Lachy> | I guess those two could be considered equivalent then |
| 23:53 | <webben> | fwiw it could easily be worse. |
| 23:53 | <Hixie> | webben: i don't think having a few people stick misteriously named attributes on images is going to improve things either |
| 23:54 | webben | doesn't really see why not. |
| 23:55 | <webben> | if the problem is mysteriousness, then go for a big huge long name. |
| 23:55 | <Hixie> | then nobody will use it |
| 23:55 | <webben> | why would nobody use it? |
| 23:55 | <webben> | nobody would use it /accidentally/ ... which is precisely what you're trying to avoid |
| 23:56 | <Hixie> | it's a psychology thing -- people just don't seem to use long keywords, they shy away from them |
| 23:56 | <Hixie> | i don't know why |
| 23:56 | <webben> | We're not talking about hand-authoring here. We're talking about sites like Flickr processing thousands of images; and software like DreamWeaver written by professionals. |
| 23:56 | <Hixie> | i guess i'm not sold on the idea that the advantage of an attribute over just a compact syntax outweigh the disadvantages... the pros and cons on both sides seem pretty minimal |
| 23:57 | <webben> | that's the target audience of this attribute as I understand it. |
| 23:57 | <Hixie> | flickr output is hand-authored templates. |
| 23:57 | <Hixie> | it's still hand-authored. |
| 23:57 | <webben> | the templates are hand-authored; the output isn't. |
| 23:58 | <webben> | likewise someone writes the code for DreamWeaver |
| 23:58 | <webben> | s/hand-authoring/small-time authoring/ if you like |
| 23:58 | <Hixie> | my point is it's not like we can just ignore authoring because there's a computer involved -- it's still hand written at some point |
| 23:59 | <Lachy> | webben, even if the attribute were theoretically a better approach (which I'm not convinced it is), then there's still the big problem of finding an appropriate name that accurately represents its meaning for all the vaious use cases |