/irc-logs / freenode / #whatwg / 2008-08-03 / end

Options:

# Session Start: Sun Aug 03 00:00:00 2008
# Session Ident: #whatwg
# [00:10] <Hixie> Lachy: [] are used a lot already
# [00:10] <Hixie> Lachy: {} not so much
# [00:10] <Hixie> Lachy: iirc <> is used even less, but that causes problems in xml or something
# [00:10] * Hixie logs on to his vpn to get the numbers
# [00:11] <jcranmer> < >, if anyone remembers
# [00:13] <Hixie> ok here are the stats as percentages of total pages scanned
# [00:13] <Hixie> pages that had an img that wasn't in a link and had a value that followed the pattern [...]: 0.45%
# [00:13] <Hixie> pages that had an img that wasn't in a link and had a value that followed the pattern (...): 0.13%
# [00:14] <Hixie> pages that had an img that wasn't in a link and had a value that followed the pattern {...}: 0.035%
# [00:14] <Hixie> pages that had an img that wasn't in a link and had a value that followed the pattern <...>: 0.033%
# [00:15] <Hixie> most common alt={...} value was alt={alpha}, most of which it seems came from pages created by one particular conversion tool
# [00:16] <jcranmer> I'm surprised (...) is that low
# [00:17] <Hixie> number of pages with <img>: 94%
# [00:17] <Hixie> number of pages with <img alt>: 82%
# [00:17] <Hixie> number of pages with <img alt> with non-empty alt: 77%
# [00:18] <Hixie> number of pages with <img> that had at least one without an alt="": 67%
# [00:19] <Hixie> number of pages with <img alt> and that had all their <img> with alt="": 27%
# [00:19] <Hixie> number of pages that had at least one <img> element but no <img> elements with alt="": 11%
# [00:20] <jcranmer> which comes out to somewhere between 29%-71% of images that don't have alt
# [00:20] <Lachy> ok, well, it nicely solves the problem of distinguishing between legitmate and guessed alt text, so it seems like a reasonable solution
# [00:21] <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>"
# [00:21] <Lachy> so what would authoring tools like Dreamweaver be requried to insert by default? Would alt="{image}" be ok?
# [00:22] <Hixie> if the author knows what the image is, then alt="{...}" is never "ok"
# [00:22] <jcranmer> I think apache's autoindex uses "[ TXT ]" as alt..
# [00:22] <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
# [00:23] <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
# [00:23] <jcranmer> actually, just "[TXT]"
# [00:23] <Hixie> jcranmer: second most common [...] alt value was [DIR] 0.085% (first was [new] 0.095%, third was [NEW] 0.066%)
# [00:24] <jcranmer> [DIR] is used in apache's autoindex
# [00:24] <Hixie> jcranmer: [TXT] was 0.024%
# [00:24] <Hixie> less common than [cpp] and [flash]
# [00:24] <Hixie> and [*]
# [00:25] <Hixie> most common (...) values were (+), (-) and (?)
# [00:25] <Lachy> what would [cpp] be used for?
# [00:25] <jcranmer> \[[A-Z]+\] is quite possibly autoindexing
# [00:25] <jcranmer> I don't know what IIS uses, if anything
# [00:25] <Hixie> (0.038%, 0.037%, and 0.0095% respectively)
# [00:26] <Hixie> yeah apache's autoindexing was well represented in these results
# [00:26] <Hixie> [spoiler] was common too
# [00:26] <jcranmer> what does [] look like if you exclude apache, which is probably a valid use case?
# [00:27] <jcranmer> although it would have to be ~30% of all stuff to change the rankings
# [00:27] <Hixie> valid how?
# [00:27] <Hixie> not sure what you mean
# [00:28] <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?
# [00:28] <webben> especially given the use-case is automatic insertion rather than hand-authoring
# [00:29] <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], ...
# [00:30] <jcranmer> five of which are definitely apache
# [00:30] <Hixie> webben: it seems more likely to be misused
# [00:30] <Hixie> webben: e.g. through ignorant copy-paste
# [00:30] <Hixie> webben: also, coming up with a name was difficult
# [00:30] <jcranmer> another seven of which seem to be BB-code
# [00:31] <webben> I'd have thought exactly the opposite was the case.
# [00:31] <jcranmer> [img alt="[b]SEE THIS[/b]"] ?
# [00:31] <webben> that a weird syntax inside alt is utterly opaque
# [00:31] <jcranmer> although the non-existence of [/b] does seem to invalidate that theory...
# [00:32] <webben> Hixie: Is there a list of proposed names anywhere?
# [00:32] <Hixie> webben: not a convenient list, no
# [00:33] <Lachy> webben: noalt, important
# [00:33] <Lachy> I can't remember the others
# [00:33] <webben> yeah, well, I agree those aren't good names ;)
# [00:33] <Hixie> webben: what kind of proposal did you have in mind? <img alt="..." alt-is-not-actually-a-description-but-a-category="true"> ?
# [00:33] <Hixie> webben: (with a better name obviously!)
# [00:34] <webben> well, you wouldn't need the ="true" (presumably?) but yeah.
# [00:35] <Hixie> that was basically my importantimage="" proposal, but nobody could come up with a good attribute name.
# [00:36] <webben> missing-text-equivalent
# [00:36] <Dashiva> please-sir-can-i-have-some-more-validation
# [00:37] <Hixie> webben: <img alt="Photo" missing-text-equivalent> vs <img alt="{Photo}"> seems like a tossup as to which is better
# [00:37] <webben> that name's still probably not ideal, but I think the former is easily better.
# [00:38] * webben would suggest testing it with some newbie authors and asking them what they think these syntaxes mean
# [00:38] <webben> actually that's not a fair test
# [00:38] <webben> since that clues them in that {} is a syntax, which is counter-intuitive
# [00:39] * Joins: jgraham_ (n=james@81-86-213-50.dsl.pipex.com)
# [00:39] <Hixie> heh
# [00:40] <Hixie> i wish i could remember why i had decided to look at alt={...} rather than importantimage=""
# [00:40] <Hixie> there was some more serious problem than the name, iirc, but i don't recall what
# [00:41] <Dashiva> (You could use self-documenting decisions, that way you won't have to document anything)
# [00:41] <Hixie> not sure what that would mean here :-)
# [00:42] <Hixie> the decision wasn't written down anywhere, i just did it
# [00:43] <Lachy> if we documented every decision, that would take the fun out of rehashing old arguments!
# [00:47] <Dashiva> Hixie: I just felt like taking a jab at self-documenting code.
# [00:47] <Hixie> heh
# [00:49] * Quits: Thezilch (n=fuz007@cpe-76-171-111-7.socal.res.rr.com) (Client Quit)
# [00:50] <Hixie> webben: missing-text-eqivalent doesn't really convey the right message, i'm not sure it actually helps vs {...}
# [00:50] <webben> Hixie: is " alt-is-not-actually-a-description-but-a-category" the right message?
# [00:50] <Lachy> Hixie, are you speccing the {...} feature now?
# [00:51] <Hixie> the message is alt-is-not-actually-a-description-but-a-category-because-we-do-not-know-what-the-image-actually-is
# [00:51] <Hixie> Lachy: i'm looking at it. it's one of the folders with the most messages
# [00:52] <webben> Hixie: alt-is-category-only ?
# [00:52] <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
# [00:53] <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.
# [00:54] <webben> I think the what's a category question is answered by the alt content itself.
# [00:55] <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
# [00:55] <Lachy> would alt="{}" be considered non-conforming?
# [00:56] <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.
# [00:57] <webben> missing-text-equivalent at least hints that something's wrong.
# [00:57] <Lachy> and which of these regexes best matches the proposed syntax: /^\{.+\}$/ or /^\{[^\}]+\}$/
# [00:58] * Quits: csarven (n=csarven@modemcable144.140-202-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
# [00:59] <Hixie> webben: the stats indicate that authors already think omitting alt altogther is fine
# [00:59] <Hixie> webben: so i don't think this will make it any worse
# [00:59] <Hixie> Lachy: i was just thinking /^\{.*\}$/
# [00:59] <webben> Hixie: I don't see the logical connection between those stats and the effect of any given example.
# [01:00] <Hixie> webben: i'm saying that nothing could make the current authoring practices worse
# [01:00] <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?
# [01:00] <webben> I don't think not making it any worse is the bar we should be setting. ;)
# [01:01] <Hixie> Lachy: alt="{image}" doesn't say anything about what it is either
# [01:01] <Lachy> I guess those two could be considered equivalent then
# [01:01] <webben> fwiw it could easily be worse.
# [01:01] <Hixie> webben: i don't think having a few people stick misteriously named attributes on images is going to improve things either
# [01:02] * webben doesn't really see why not.
# [01:03] <webben> if the problem is mysteriousness, then go for a big huge long name.
# [01:03] <Hixie> then nobody will use it
# [01:03] <webben> why would nobody use it?
# [01:03] <webben> nobody would use it /accidentally/ ... which is precisely what you're trying to avoid
# [01:04] <Hixie> it's a psychology thing -- people just don't seem to use long keywords, they shy away from them
# [01:04] <Hixie> i don't know why
# [01:04] <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.
# [01:04] <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
# [01:05] <webben> that's the target audience of this attribute as I understand it.
# [01:05] <Hixie> flickr output is hand-authored templates.
# [01:05] <Hixie> it's still hand-authored.
# [01:05] <webben> the templates are hand-authored; the output isn't.
# [01:06] <webben> likewise someone writes the code for DreamWeaver
# [01:06] <webben> s/hand-authoring/small-time authoring/ if you like
# [01:06] <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
# [01:07] <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
# [01:08] <Hixie> yeah i haven't yet seen a name that i'd be proud to have in a spec with my name at the top
# [01:08] <webben> Lachy: If the meaning is ambiguous, then that's true of {} too. If the meaning can be expressed, then it can be expressed in an attribute name.
# [01:08] * weinig is now known as weinig_
# [01:08] <webben> if {} is ambiguous, that may hint at a problem with the idea
# [01:08] * weinig_ is now known as weinig
# [01:08] <webben> are there two concepts here that need seperating?
# [01:09] <Hixie> {}'s advatnage is great compactness, its disadvantage is it's meaning is not intuitive. for an attribute to outweigh its corresponding verbosity disadvantage, it has to have a name that is intuitive
# [01:10] <Hixie> s/it's/its/
# [01:10] <webben> I think you're underestimating that {} doesn't even look like code, and therefore is likely to be misused.
# [01:10] <webben> one can't really dispute an attribute looks like code, even if it's not obvious what it does.
# [01:10] <Hixie> why would it be misused more than now?
# [01:11] <webben> it doesn't exist now.
# [01:11] <Hixie> alt=[...] is used a lot
# [01:11] <Hixie> alt={...} is not
# [01:11] <webben> yeah, but not as code.
# [01:11] <Hixie> you're saying that alt={...} would become more popular for other uses just because we introduce it as meaning something special for one use?
# [01:11] <Lachy> webben, you're not making sense
# [01:12] <webben> Hixie: Given folks don't normally see alt, that's not actually inconceivable.
# [01:12] <Hixie> re what you asked earlier... the concept here is "i don't know what this image is or will be, so i cannot provide a useful equivalent... here's a hint as to what kind of image it is, at least, so that you know it's not meant to be purely decorative"
# [01:13] <Lachy> it's possible that once this syntax starts showing up in poorly written tutorials, authors could misunderstand its purpose and begin using it more commonly, yet wrongly
# [01:13] <Hixie> webben: it seems pretty unlikely to me. We know that attributes that people use get copied and pasted around even without reason, too, so i don't see why it would happen any less to an attribute than to a special syntax in an attribute.
# [01:14] <Hixie> webben: maybe it's in fact more likely that authors who don't know about this would not know that the {...} syntax means anything, and would thus in fact not use it, as they think it's ugly :-)
# [01:14] <Hixie> webben: whereas they would see an attribute and know that it DID mean something, even if they didn't know what, and so WOULD use it (as we have seen happen with other things)
# [01:14] <Hixie> e.g. bits of svg appearing in random places in html documents
# [01:15] <webben> I think "bits of svg" are probably a lot more opaque than any of the names suggested for this thing.
# [01:15] <Hixie> svg was just one example, it happens with everything
# [01:16] <Hixie> hm, when we started this discussion i was pretty much neutral on the issue of importantimage="" vs alt={...} but now i'm definitely leaning more towards the latter
# [01:16] <webben> Well, yeah, but you need to work out what makes things happen more, not just look at whether they happen at all.
# [01:17] <Hixie> i'm gonna go shopping and will think more on this, but feel free to keep discussing it, i'll read any ideas that come up when i get back
# [01:17] <webben> k ; have a good shop :)
# [01:17] * webben is probably heading to bed very shortly.
# [01:18] <Lachy> I think the {} syntax would be accepted by the community better than importantimage="", because there were a lot of suggestions for using a similar approach with square brackets, and very little support for using importantimage (it was mostly ignored when it was suggested, depite repeatedly pointing to it)
# [01:19] <Lachy> Hixie, btw, did your Stargate Continuum DVD arrive yet?
# [01:19] <Lachy> if so, what did you think of it?
# [01:21] * Joins: csarven (n=csarven@modemcable144.140-202-24.mc.videotron.ca)
# [01:22] <webben> Lachy: I don't think importantimage was a good name; "" implies unimportant image; and it doesn't convey that something is missing.
# [01:23] <Lachy> webben, please elaborate?
# [01:23] <webben> sorry alt="" => decorative (unimportant) image.
# [01:24] <webben> alt="something" => important image
# [01:24] <webben> importantimage => no additional information
# [01:24] <Lachy> the same is true for alt={}
# [01:25] <webben> yes, but I'm suggesting why importantimage wasn't a good name
# [01:26] <webben> missing-text-equivalent does at least add some information, though I'm still not precisely happy with it.
# [01:26] <Lachy> oh, ok. I misread your message. I thought you said it was a good name
# [01:26] <webben> "alt-is-hint-only" perhaps
# [01:26] * Quits: Maurice (i=copyman@cc90688-a.emmen1.dr.home.nl) ("Disconnected...")
# [01:27] <Lachy> it's too long
# [01:27] * webben is thoroughly unconvinced that long is bad. It's actually a plus AFAICT.
# [01:27] <Lachy> and there's a possibillity that some authors could inadvertently write alt-is-only-hint instead of alt-is-hint-only
# [01:28] <webben> there's also a possibility authors could write {)
# [01:28] <Lachy> so using sentences for attribute names isn't really a good idea, especially when it's possible to transpose words without losing its meaning
# [01:28] <webben> or " {
# [01:29] <Lachy> it's easier to spot a syntax error like that, than it is to spot incorrectly transposed words in an attribute name
# [01:29] <webben> the former cannot be caught by the validator; the second can.
# [01:30] <webben> sorry {) is not definitely invalid, but alt-is-only-hint definitely is.
# [01:30] <webben> so at best a validator could issue a warning about the former.
# [01:30] <Lachy> that's what the image analysis tool in the validator is for.
# [01:34] <webben> I think having a non-verifiable syntax would not make for a more user-friendly image analysis tool.
# [01:34] <webben> since then you're asking people to check syntax as well as equivalents.
# [01:35] <webben> whereas you could have them fix the syntax then check equivalents
# [01:39] <Lachy> I'm not really convinced that it's likely for authors to mistype {} as {), because the keys are in different positions on the keyboard, and the braces are right next to each other
# [01:40] <webben> {]
# [01:40] <Lachy> and in this whole discussion, I've not seen anyone accidentally mistype {}
# [01:40] <webben> on my keyboard at least } ] are the same key
# [01:41] <Lachy> yeah, that's true, but still unlikely
# [01:41] <webben> not sure why that would be unlikely
# [01:41] <Lachy> have you ever seen it happen anywhere? If so, how freqently?
# [01:42] <webben> i don't have much memory of typos and their frequency full stop
# [01:42] <webben> let alone mental data on } ] in particular ;)
# [01:43] <Lachy> so, in other words, you're just speculating and trying to put that forth as strong evidence anyway?
# [01:43] * webben thinks the whole discussion is very speculative.
# [01:44] * webben doesn't figure "there's also a possibility authors could write {)" is an especially strong statement either
# [01:46] <webben> I do know I don't want to have to get time-poor editorial or QA staff to understand the ins and outs of this syntax when I could get it checked with a validator /before/ giving them more useful work of inspecting text that is supposed to be a text equivalent.
# [01:47] <webben> or rely on their eyes when this can be handled by code.
# [01:48] <Lachy> so maybe there are ways of at least flagging mismatched braces as a warning in the validator then
# [01:48] <webben> that's still a waste of their time.
# [01:48] <Lachy> what?
# [01:48] <webben> they'd need to manually inspect the braces
# [01:49] <Lachy> so? Braces are used very infrequently within alt text anyway, so it's hardly a lot of time wasted
# [01:50] <webben> that's worse, then they'd need to try and remember what that pesky developer said about braces
# [01:50] <webben> and () is just like {} right?
# [01:50] <Lachy> I don't understand your point
# [01:50] <webben> well, not worse, but not good either.
# [01:51] <webben> Lachy: Basically, it shifts a job that could be done more reliably by machines onto people.
# [01:51] <webben> that's impractical.
# [01:52] <Lachy> checking the accuracy of alt text isn't a job that can be reliably done by machines anyway, so having authors manually check those using braces along with all the others isn't that big a deal
# [01:52] <webben> this isn't about "checking the accuracy of alt text"
# [01:52] <Lachy> of course it is
# [01:52] <Lachy> what else is it about?
# [01:53] <webben> Let's say you have a source of photos coming into a system.
# [01:53] <webben> so you have some code which inspects each one to see if it has some text to use as an equivalent
# [01:53] <webben> if it does, it inserts the text; if not, it inserts alt="{Photo}"
# [01:55] <Lachy> yeah, and...?
# [01:55] <webben> why should humans be checking if the system can spell {Photo} correctly, rather than just getting a total of those with {Photo} and proceeding to check the ones that do have alt text?
# [01:57] <webben> I guess the image checker could group them
# [01:57] <webben> but that would probably mean you'd end up with false positive
# [01:57] <webben> *positives
# [01:58] <Lachy> you seem to be making assumptions about the UI of the image inspector. Given the {} syntax, why couldn't the image inspector group those with {Photo} together and provide a count, or whatever else?
# [01:58] <Lachy> I don't see how you'd end up with any more false positives using alt="{...}" as you would with some attribute
# [02:00] <webben> Lachy: Yeah. Maybe. Would get a lot more complicated if alt's were being autogenerated to contain more information
# [02:00] <webben> e.g. {Photo tagged with 'cat'}
# [02:01] * Joins: tantek (n=tantek@c-98-210-12-5.hsd1.ca.comcast.net)
# [02:02] <webben> in fact, the better your auto-generation of alts, the worse it would get.
# [02:03] <webben> well, actually, I guess the checker could just group {} and non-{} together for separate checking
# [02:06] * Joins: tantek_ (n=tantek@c-98-210-12-5.hsd1.ca.comcast.net)
# [02:06] * Quits: tantek (n=tantek@c-98-210-12-5.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
# [02:09] <Lachy> webben, yeah, exactly how it would group alt="..." separately from some-special-attribute=""
# [02:10] <Lachy> and if, in the process of inspecting the alt="..." group, the author sees a { in there, it would look like something that needed fixing
# [02:16] <webben> maybe
# [02:17] <webben> well, it would if the validator also warned about it /and/ if {} weren't common for that set of alt's
# [02:17] <webben> meh, this also means you'd need code to inspect provided equivalents for { } and decide what to do with it
# [02:18] <webben> e.g. does this mean the provided equivalent is actually not an equivalent but someone who actually knows the {} syntax and is assuming your just going to dump into an alt attribute.
# [02:18] <webben> or is this actually the equivalent
# [02:23] <webben> also, it's cutting into the strings people use for interpolation (e.g. YAHOO.lang.substitute uses {} ) http://developer.yahoo.com/yui/docs/YAHOO.lang.html
# [02:24] <jcranmer> any good pages with <video> for testing?
# [02:25] <takkaria> jcranmer: wikimedia?
# [02:26] <takkaria> jcranmer: http://www.double.co.nz/video_test/ also
# [02:30] * Joins: tantek (n=tantek@70-13-117-38.area2.spcsdns.net)
# [02:31] * jcranmer goes through old CSS mailing list messages and laughs
# [02:33] <jcranmer> "Let's drop #id as it's superfluous and writing foo\#bar is too hard for most users"
# [02:37] <jruderman> yeah, let's make everyone write [id="baz"] so we don't have escape #
# [02:38] <jcranmer> some of his suggestions get even crazier
# [02:39] <takkaria> whose suggestions are these?
# [02:40] <jcranmer> Dmitry Turin
# [02:40] <Lachy> jcranmer, http://lachy.id.au/dev/markup/tests/html5/video/
# [02:40] <jcranmer> Lachy: thanks
# [02:41] * jcranmer notes that wikimedia didn't do anything obvious to get to a <video> tag
# [02:42] <Lachy> jcranmer, got a pointer to that suggestion of his?
# [02:43] <Lachy> the #id one
# [02:44] <jcranmer> Lachy: material around 1/10-ish/2008
# [02:45] <Lachy> is that around January 10th?
# [02:45] <jcranmer> er, yes
# [02:45] * Lachy has difficulty interpreting american date formats
# [02:45] <jcranmer> sorry, I forget that not everyone uses American date format
# [02:45] <jcranmer> 2008-01-10-ish
# [02:46] <Lachy> no-one should ever use it. It's horrible, it has the numbers in a weird order
# [02:46] <takkaria> Dmitry suggested dropping # *this year*?
# [02:47] <jcranmer> Lachy: force of habit
# [02:47] * Quits: tantek_ (n=tantek@c-98-210-12-5.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
# [02:48] <Lachy> LOL! That's related to his SQL5 proposal :-)
# [02:48] <jcranmer> for a moment, I thought he was the crackpot who wanted to wave all problems away magically
# [02:48] <jcranmer> wrong crackpot, though
# [02:48] <Lachy> or is it SQL 50?
# [02:49] <jcranmer> 5
# [02:49] <jcranmer> SQL5, HTML6, Unicode7, Computer2
# [02:49] <Lachy> the domain he uses is sql50.euro.ru
# [02:49] <Lachy> hmm, the page he linked to is gone
# [02:50] <Lachy> http://lists.w3.org/Archives/Public/www-style/2008Jan/0188.html
# [02:51] <Lachy> it's unfortunate he chose the number 5 though. We've been using it to represent the spec versions that are actually good. (HTML5, XML5, HTTP5, DOM5, etc.)
# [02:51] * jcranmer laughs at his Computer 2 stuff
# [02:51] <jcranmer> it seems to me that he understands very little of TCP/IP
# [02:51] <jcranmer> and certainly nothing of IPv6
# [02:52] <takkaria> I like that Computer 2.0 "It gives large jump in development of economy."
# [02:52] <jcranmer> and some of those proposals are incapable of handling the future well
# [02:53] <jcranmer> takkaria: I think he's using automatic translation
# [02:54] <takkaria> I think he just speaks bad English
# [02:54] <jcranmer> ah, here's something interesting
# [02:54] <Lachy> I like his 6D mouse :-) http://computer20.euro.ru/site/computer20/en/author/6d_eng.htm
# [02:54] <jcranmer> he's proposing to get rid of HTTP, FTP, SMTP, POP, etc.
# [02:54] <jcranmer> replaced by
# [02:54] <jcranmer> ... wait for it ...
# [02:54] <jcranmer> SQL5
# [02:54] <Lachy> of course. makes perfect sense
# [02:55] <jcranmer> apparantely because SQL5 supports "continue downloading of file at breakdown of connection"
# [02:55] <Lachy> I don't see why you're laughing at these obviously fantastic proposals! ;-)
# [02:56] <Lachy> really? That'd it be great if I could still surf the web without having a working internet connection. Then I wouldn't have to complain to my ISP so frequently
# [02:57] <takkaria> he thinks people should communicate over XML, too
# [02:57] <takkaria> but not actual XML, weird unquoted XML
# [02:58] <jcranmer> you mean SGML without the wacky stuff?
# [02:59] <takkaria> I really don't know what he means
# [02:59] <Lachy> he wants more wacky stuff, like strange characters in tag names
# [02:59] <jcranmer> well, obviously, he wants his stuff
# [02:59] <takkaria> he's already started work on HTML6 too
# [03:00] <Lachy> "I also propose to allow any spec-symbol &, ^, @, ~, %, $ in name of a tag for future extentions."
# [03:00] <jcranmer> that &'ll be a fun one
# [03:02] <takkaria> btw, there is almost an html5 browser that you can use
# [03:02] <takkaria> well. s/an html5 browser/a browser using the html5 parsing algorithm/
# [03:03] <takkaria> no javascript, but at least it's an implementation
# [03:03] <takkaria> it's not quite ready yet since I'm still hunting down bugs. :)
# [03:04] <jruderman> wouldn't it be easier to shoehorn your html5 parser into gecko or webkit than make a new browser around it?
# [03:05] <takkaria> I'm not writing a new web browser around it, it already existed
# [03:05] <takkaria> the browser in question is NetSurf (http://www.netsurf-browser.org/)
# [03:05] <jruderman> ahh
# [03:06] <takkaria> NS currently uses libxml2, so all I have to do is to bind Hubbub (the C html5 parser I've been working on) to libxml2, and NS should work
# [03:07] <takkaria> hooking it into gecko looks like it would be hard work; WebKit looks slightly easier but I would think some fairly chunky rewriting would still have to take place
# [03:09] <jruderman> i'm sure mrbkap would be happy to help you, so he doesn't have to do the whole thing himself ;)
# [03:11] <jcranmer> IIUC, HTML 5 sandboxing works like this:
# [03:11] <jcranmer> <iframe src="yada yada yada" sandbox="" /> ?
# [03:12] <jcranmer> and, ideally, no matter how gobbeldy-gook (sp?) the source is, how virulent the JS, it shouldn't be able to mess up anything else in the document?
# [03:13] <takkaria> jruderman: hmm, I've been wondering about implementing HTML5 in gecko, I don't know anything of gecko's yet yet though
# [03:13] <takkaria> or, er, C++
# [03:13] <takkaria> s/gecko's yet/gecko's code/
# [03:13] <jcranmer> takkaria: layout and content are >50% of where it's at
# [03:14] <takkaria> mm
# [03:14] <takkaria> I would be especially interested in writing another HTML parser. :)
# [03:14] <jcranmer> there
# [03:14] <jcranmer> 's also a parser/htmlparser, but I can't profess knowledge about that, including, critically, its use
# [03:15] <jruderman> takkaria: join #developers on irc.mozilla.org and look for mrbkap and bz
# [03:15] <takkaria> I'll remember that for later
# [03:15] <jcranmer> dbaron or roc would probably work well, too
# [03:15] <takkaria> it's a few months away before I'll be up for doing anything of that sort
# [03:15] <jruderman> takkaria: they can tell you what they know about the existing html parser, how it hooks into the rest of gecko, and how much of it is likely to need rewriting
# [03:16] <jruderman> https://bugzilla.mozilla.org/show_bug.cgi?id=373864
# [03:17] <takkaria> jruderman: also, thanks for the burning edge, I started reading it about roughly when it started and it's still in my feedreader. :)
# [03:18] <jruderman> cool, so i didn't lose all my readers when i went dark for a month? ;)
# [03:18] <jcranmer> I'm just the guy who works on mailnews code which rivals gsnedders in age
# [03:18] <jcranmer> (some of which, in any case)
# [03:19] <takkaria> mm, crufty C++
# [03:20] <jcranmer> I *wish* it were C++
# [03:20] <jcranmer> it's written in yet-another-person-implementing-C++-in-C-code
# [03:21] <jcranmer> and the other part is written in C++ by someone who thought that 15 parameters was too few for a function
# [03:22] <takkaria> my other programming project is a roguelike game, written in C, whose code in places still looks like the VMS Pascal it was converted from tenety years ago
# [03:22] <takkaria> s/tenety/twenty/
# [03:30] <Lachy> http://arstechnica.com/news.ars/post/20080801-newly-found-hybrid-attack-embeds-java-applet-in-gif-file.html
# [03:31] <Lachy> if that exploit is merely renaming a java applet with a .gif file extension, and then relying on the fact that browsers ignore content type for <applet>, then I won't be surprised.
# [03:32] <Lachy> but if that's all it is, then it could hardly be considered an exploit
# [03:33] <Lachy> so the bigger question is, what markup needs to be used on the client side to make it run the file as a java applet, instead of an image, if it isn't <applet> or <object>?
# [03:43] * Quits: scotfl (n=scotfl@S0106001b114f914a.ss.shawcable.net)
# [03:44] * Joins: scotfl (n=scotfl@S0106001b114f914a.ss.shawcable.net)
# [03:45] * Joins: tantek_ (n=tantek@c-98-210-12-5.hsd1.ca.comcast.net)
# [03:45] * Quits: tantek (n=tantek@70-13-117-38.area2.spcsdns.net) (Read error: 104 (Connection reset by peer))
# [04:18] * Quits: tantek_ (n=tantek@c-98-210-12-5.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
# [04:20] * Quits: jruderman (n=jruderma@guest-225.mountainview.mozilla.com)
# [04:28] * Joins: jruderman (n=jruderma@guest-225.mountainview.mozilla.com)
# [04:59] * Quits: othermaciej (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [05:00] * Joins: othermaciej (n=mjs@12.172.70.3)
# [05:18] * weinig is now known as weinig|food
# [06:15] * Joins: aroben (n=aroben@unaffiliated/aroben)
# [06:16] * Joins: kfish (n=conrad@61.194.21.25)
# [07:02] * Quits: csarven (n=csarven@modemcable144.140-202-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
# [07:19] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 110 (Connection timed out))
# [07:24] * Parts: hdh (n=hdh@118.71.130.3) ("Konversation terminated!")
# [07:38] * Joins: othermaciej_ (n=mjs@12.172.70.3)
# [07:38] * Quits: othermaciej (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [07:57] * Quits: othermaciej_ (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [07:57] * Joins: othermaciej (n=mjs@12.172.70.3)
# [08:01] * Quits: othermaciej (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [08:02] * Joins: othermaciej (n=mjs@12.172.70.3)
# [08:31] * Joins: othermaciej_ (n=mjs@12.172.70.3)
# [08:31] * Quits: othermaciej (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [08:32] * weinig|food is now known as weinig
# [08:50] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
# [08:51] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
# [08:55] * Quits: jruderman (n=jruderma@guest-225.mountainview.mozilla.com)
# [08:57] * MacDome is now known as ecs
# [08:57] * ecs is now known as es
# [08:58] * es is now known as eseidel
# [09:01] * Joins: jruderman (n=jruderma@guest-225.mountainview.mozilla.com)
# [09:03] * Joins: othermaciej (n=mjs@12.172.70.3)
# [09:03] * Quits: othermaciej_ (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [09:42] * Joins: wakaba_ (n=w@25.164.210.220.dy.bbexcite.jp)
# [09:43] * Quits: Amorphous (i=jan@f049012047.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
# [09:45] * Joins: Amorphous (i=jan@f048043092.adsl.alicedsl.de)
# [09:57] * Quits: wakaba (n=w@77.165.210.220.dy.bbexcite.jp) (Read error: 110 (Connection timed out))
# [10:04] * Quits: eseidel (n=eric@c-67-180-49-110.hsd1.ca.comcast.net)
# [10:06] * Joins: MacDome (n=eric@c-67-180-49-110.hsd1.ca.comcast.net)
# [10:06] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [10:19] * Quits: MacDome (n=eric@c-67-180-49-110.hsd1.ca.comcast.net)
# [10:30] * Joins: othermaciej_ (n=mjs@12.172.70.3)
# [10:30] * Quits: othermaciej (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [10:31] * othermaciej_ is now known as othermaciej
# [10:31] * Quits: sverrej (n=sverrej@89.10.27.245) (Read error: 60 (Operation timed out))
# [10:37] * Joins: jacobolus (n=jacobolu@pool-71-119-188-52.lsanca.dsl-w.verizon.net)
# [10:46] * Joins: MacDome (n=eric@c-67-180-49-110.hsd1.ca.comcast.net)
# [10:48] <jacobolus> Hixie: re: WebSocket: did you ever read http://tools.ietf.org/html/rfc3093 ??
# [10:48] <jacobolus> it strikes me that we are finally making the dream a reality!
# [11:01] * Quits: Kuruma (n=Kuruman@h123-176-107-050.catv01.catv-yokohama.ne.jp) (Read error: 104 (Connection reset by peer))
# [11:07] * Quits: othermaciej (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [11:07] * Joins: othermaciej (n=mjs@12.172.70.3)
# [11:16] * Joins: Kuruma (n=Kuruman@h123-176-107-050.catv01.catv-yokohama.ne.jp)
# [11:19] * Quits: MacDome (n=eric@c-67-180-49-110.hsd1.ca.comcast.net)
# [11:19] * Quits: othermaciej (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [11:19] * Joins: othermaciej (n=mjs@12.172.70.3)
# [11:28] * Joins: sverrej (n=sverrej@89.10.27.245)
# [11:34] * Joins: maikmerten (n=maikmert@La060.l.pppool.de)
# [11:40] * Joins: svl (n=me@ppp-58-10-80-62.revip2.asianet.co.th)
# [11:42] * Quits: othermaciej (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [11:42] * Joins: othermaciej (n=mjs@12.172.70.3)
# [11:45] * Joins: othermaciej_ (n=mjs@12.172.70.3)
# [11:45] * Quits: othermaciej (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [11:49] * Quits: othermaciej_ (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [11:49] * Joins: othermaciej (n=mjs@12.172.70.3)
# [12:14] <Lachy> Wow! http://adweek.blogs.com/adfreak/2008/07/then-well-grab.html
# [12:17] <webben> hah :)
# [12:21] * Quits: jruderman (n=jruderma@guest-225.mountainview.mozilla.com)
# [12:28] <Hixie> i posted that image in #whatwg a few weeks back :-0
# [12:29] <Lachy> ok
# [12:29] <Hixie> :-), even
# [12:30] <Lachy> I tried to find the right letters in character palette. If these are the right ones: 䬸厅 then google translated the second symbol translates to office, but it couldn't translate the first.
# [12:32] <Hixie> what's the codepoint of the first?
# [12:32] <Hixie> look it up in the unihan table
# [12:33] <Hixie> there are some translations there
# [12:36] <Lachy> I'll have to find it again
# [12:36] * Quits: scotfl (n=scotfl@S0106001b114f914a.ss.shawcable.net)
# [12:36] <Lachy> U+4B38 U+5385
# [12:37] <Lachy> where do I find the unihan table?
# [12:38] * Joins: othermaciej_ (n=mjs@12.172.70.3)
# [12:38] * Quits: othermaciej (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [12:41] <heycam> the first means "meal"
# [12:41] <heycam> (i think)
# [12:41] <Lachy> actually, I'd found the wrong letter. 餐厅 translates to restaurant.
# [12:42] <Lachy> U+9910 looks very similar to U+4B38
# [12:43] <Lachy> individually, the 2 symbols translate to "meal" and "office", respectively
# [12:44] <Lachy> I can't find the other 2 symbols in the picture, cause they're obscured by something in front of them
# [12:44] <heycam> i'm pretty sure they're the same characters
# [12:44] <Lachy> they look slightly different
# [12:44] <Lachy> maybe it's just a different font
# [12:44] <heycam> different font
# [12:44] <heycam> yeah
# [12:45] <Lachy> see, I never know with this weird language they all look alike to me anyway
# [12:45] <heycam> :)
# [12:47] * Joins: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
# [12:48] <Philip`> That's why translation should be performed by competent people, not by non-competent people or non-people :-)
# [12:59] <Philip`> (Someone says "The Chinese text on the banner (can1 ting1) is simply a generic term for "dining hall" or "cafeteria"")
# [13:00] * Quits: svl (n=me@ppp-58-10-80-62.revip2.asianet.co.th) ("And back he spurred like a madman, shrieking a curse to the sky.")
# [13:02] * Quits: webben (n=benh@91.85.147.185) (Read error: 110 (Connection timed out))
# [13:03] * Joins: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
# [13:29] * Quits: sverrej (n=sverrej@89.10.27.245) (Read error: 110 (Connection timed out))
# [13:51] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
# [14:21] * Joins: othermaciej (n=mjs@12.172.70.3)
# [14:21] * Quits: othermaciej_ (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [14:48] <hsivonen> Re: HTML5 parsing in C++: the core of the Validator.nu parser is intentionally written in a subset of Java that can be mapped to C++ mechanically.
# [15:09] * Quits: jgraham_ (n=james@81-86-213-50.dsl.pipex.com) ("I get eaten by the worms")
# [15:28] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
# [15:35] * jgraham wonders what the advantage of alt={Photo} is over title=Photo if the idea is to provide a description
# [15:38] <Dashiva> The idea is to satisfy the alt-must-be-mandatory crowd
# [15:38] <Philip`> s/crowd/arguments/
# [15:40] <jgraham> that can be solved by the sentence "An <img> element must either have an alt attribute providing a textual equivalent for the image, or a title attribute providing a description of the image"
# [15:40] <jgraham> (or both)
# [15:40] <Dashiva> The arguments can be satisfied without mandatory alt, the crowd cannot
# [15:45] <Philip`> jgraham: I wouldn't want Flickr to say <img title=Photo> because it'd result in tooltips saying "Photo" and would make me think it was ugly and stupid
# [15:45] <jgraham> Philip`: It could say Photo:My cat playing with string
# [15:45] <Philip`> whereas <img alt={Photo}> only looks ugly and stupid to users without images and users with IE <= 7 (I think), and I'm not one of those users so I wouldn't care
# [15:49] <jgraham> (I'm also wondering if promoting URIs in classnames and/or attribute names is a good idea. It seems to me that URIs are too unweieldy to use as prefixes and URLs in particular are bad because they rely on the DNS system for registration, even though prefixes are permanent whereas domain registrations only last for a finite period of time)
# [15:50] <jgraham> (this complete the set of 3 things that I have wondered about recently)
# [15:51] * Joins: webben (n=benh@91.85.147.185)
# [15:52] * Philip` wonders whether w3.org will continue being reregistered forever, until DNS eventually dies out
# [16:02] * Joins: aroben (n=aroben@unaffiliated/aroben)
# [16:19] * Joins: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net)
# [16:46] * Joins: aroben_ (n=aroben@unaffiliated/aroben)
# [16:57] * Quits: aroben_ (n=aroben@unaffiliated/aroben) (Read error: 60 (Operation timed out))
# [17:02] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 110 (Connection timed out))
# [17:06] * Joins: jgraham_ (n=james@81-86-213-50.dsl.pipex.com)
# [17:07] * Quits: jgraham_ (n=james@81-86-213-50.dsl.pipex.com) (Client Quit)
# [17:07] * Quits: othermaciej (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [17:07] * Joins: othermaciej (n=mjs@12.172.70.3)
# [17:29] * Quits: webben (n=benh@91.85.147.185)
# [17:39] * Joins: svl (n=me@ppp-58-10-80-62.revip2.asianet.co.th)
# [17:46] * Quits: starjive (i=beos@213-66-217-32-no30.tbcn.telia.com)
# [17:46] * Joins: ROBOd (n=robod@89.122.216.38)
# [17:47] * Joins: hdh (n=hdh@118.71.130.3)
# [18:01] <takkaria> voila, I have a build of an HTML5-parsing-algorithm-supporting browser
# [18:01] * Quits: maikmerten (n=maikmert@La060.l.pppool.de) (Remote closed the connection)
# [18:05] <jgraham> takkaria: Next steps: ship it to a few hundred thousand users with a wide range of interests and get them to file some bugs :)
# [18:06] <takkaria> I guess the step after that is "profit!!!"
# [18:07] <takkaria> hmm, JFS isn't the filesystem you want if you want a directory containing 36k other directories
# [18:15] * Joins: maikmerten (n=maikmert@La060.l.pppool.de)
# [18:16] * Quits: maikmerten (n=maikmert@La060.l.pppool.de) (Remote closed the connection)
# [18:24] * Joins: maikmerten (n=maikmert@La060.l.pppool.de)
# [18:27] * Joins: MacDome (n=eric@c-67-180-49-110.hsd1.ca.comcast.net)
# [19:06] <jgraham> takkaria: So presumably you finished the libxml2 interface? How hard would it be to make a libxml2 build that used hubbub rather than the built-in thing to do the HTML parsing?
# [19:07] * Joins: csarven (n=csarven@modemcable144.140-202-24.mc.videotron.ca)
# [19:25] <takkaria> jgraham: I can't imagine that hard at all
# [19:25] <takkaria> the libxml2 interface is finished, yes, but it's not really that efficient
# [19:26] <takkaria> one problem is that hubbub's emitted strings are (pointer,length) pairs, and libxml's are NUL-terminated strings
# [19:26] <takkaria> so in order to set properties, some kind of strndup() has to be performed
# [19:27] <takkaria> which is rather unfortunate
# [19:28] <takkaria> this is what the timings look like at the moment: http://pastebin.com/m35aeca22
# [19:30] * Quits: svl (n=me@ppp-58-10-80-62.revip2.asianet.co.th) (Read error: 110 (Connection timed out))
# [19:32] * Joins: csarven- (n=csarven@modemcable144.140-202-24.mc.videotron.ca)
# [19:49] * Joins: jgraham_ (n=james@81-86-213-50.dsl.pipex.com)
# [19:50] <jgraham> So hubbub is a factor of ~3 slower than libxml2? Room for improvement but not bad for new code
# [19:53] * Quits: csarven (n=csarven@modemcable144.140-202-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
# [19:57] * Quits: jgraham_ (n=james@81-86-213-50.dsl.pipex.com) ("I get eaten by the worms")
# [19:58] * Joins: Maurice (i=copyman@cc90688-a.emmen1.dr.home.nl)
# [20:05] * Joins: scotfl (n=scotfl@S0106001b114f914a.ss.shawcable.net)
# [20:07] * Joins: jacobolus1 (n=jacobolu@pool-71-119-188-52.lsanca.dsl-w.verizon.net)
# [20:17] * Quits: jacobolus (n=jacobolu@pool-71-119-188-52.lsanca.dsl-w.verizon.net) (Read error: 110 (Connection timed out))
# [20:28] <takkaria> jgraham: by adding a really basic speedup to the test treebuilder I'm using, hubbub is 1.8s on html5, and I suspect there will be other simple optimisations that make it faster
# [20:36] <Lachy> if I'm reading the URLs section of the spec right, then given href="http://example.com/?foo=䬸" in a document encoded as ISO-8859-1, then that resolves to "http://example.com/?foo=?" because 䬸 can't be encoded in that encoding. Is that correct?
# [20:38] <Lachy> but in a UTF-8 document, it would be resolved to "http://example.com/?foo=%E9%A4%90"
# [20:43] * Joins: jgraham_ (n=james@81-86-213-50.dsl.pipex.com)
# [20:43] * Quits: jgraham_ (n=james@81-86-213-50.dsl.pipex.com) (Client Quit)
# [20:47] * Quits: Lachy (n=Lachlan@85.196.122.246) ("Leaving")
# [21:17] * Joins: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
# [21:26] * csarven- is now known as csarven
# [21:29] * Joins: aroben (n=aroben@unaffiliated/aroben)
# [21:32] * Joins: aroben_ (n=aroben@unaffiliated/aroben)
# [21:33] * Quits: aroben (n=aroben@unaffiliated/aroben) (Nick collision from services.)
# [21:33] * aroben_ is now known as aroben
# [21:45] * Joins: Lachy (n=Lachlan@85.196.122.246)
# [21:54] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 60 (Operation timed out))
# [21:57] * Quits: maikmerten (n=maikmert@La060.l.pppool.de) (Remote closed the connection)
# [22:05] * Joins: aroben (n=aroben@unaffiliated/aroben)
# [22:16] * Joins: weinig_ (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
# [22:21] * Joins: hasather_ (n=hasather@cm-84.215.63.253.getinternet.no)
# [22:26] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
# [22:34] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
# [22:36] * Quits: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
# [22:44] * Quits: weinig_ (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
# [22:46] * Joins: jgraham_ (n=james@81-86-213-50.dsl.pipex.com)
# [22:46] <Hixie> jgraham_: the advantage is that the UA can provide a clear indication that there is an image
# [22:46] <Hixie> jgraham_: which it doesn't have to do if there is alt text normally
# [22:48] <Philip`> Hixie: The UA could do the same if the spec defined the appropriate behaviour for <img title=...> instead of <img alt={...}>
# [22:50] <hsivonen> jgraham_: thanks for pointing out the existing translation hints that translation engines could be using (but don't)
# [22:52] <hsivonen> perhaps the tendency of people to look for layout features, accessibility features and translation control features by caegory is evidence that the semantic markup thing isn't going all that well
# [22:52] <Hixie> Philip`: The title="" gives the caption/credit/etc of the image, not the kind of image
# [22:52] <hsivonen> s/caegory/category/
# [23:01] * Joins: jruderman (n=jruderma@guest-225.mountainview.mozilla.com)
# [23:02] <webben> hsivonen: I think it's probably more a sign of HTML being used as a UI language as well as a content language.
# [23:02] <webben> at least for accessibility features
# [23:06] * Quits: Lachy (n=Lachlan@85.196.122.246) ("Leaving")
# [23:07] * Joins: othermaciej_ (n=mjs@12.172.70.3)
# [23:07] * Joins: Lachy (n=Lachlan@85.196.122.246)
# [23:07] * Quits: othermaciej (n=mjs@12.172.70.3) (Read error: 104 (Connection reset by peer))
# [23:16] * othermaciej_ is now known as othermaciej
# [23:17] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) ("Ex-Chat")
# [23:25] * Joins: roc (n=roc@202.0.36.64)
# [23:39] <hsivonen> http://nothing-more.blogspot.com/2004/10/loving-and-hating-xml-namespaces_21.html is particularly interesting, because the author has been "a Lead Developer, lording over MSXML and System.Xml development"
# [23:40] * Quits: Maurice (i=copyman@cc90688-a.emmen1.dr.home.nl) ("Disconnected...")
# [23:54] * Joins: aaronlev (n=chatzill@g228009089.adsl.alicedsl.de)
# [23:55] * Joins: sverrej (n=sverrej@89.10.27.245)
# Session Close: Mon Aug 04 00:00:00 2008

The end :)