| 00:00 | <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 |
| 00:00 | <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. |
| 00:00 | <webben> | if {} is ambiguous, that may hint at a problem with the idea |
| 00:00 | <webben> | are there two concepts here that need seperating? |
| 00:01 | <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 |
| 00:02 | <Hixie> | s/it's/its/ |
| 00:02 | <webben> | I think you're underestimating that {} doesn't even look like code, and therefore is likely to be misused. |
| 00:02 | <webben> | one can't really dispute an attribute looks like code, even if it's not obvious what it does. |
| 00:02 | <Hixie> | why would it be misused more than now? |
| 00:03 | <webben> | it doesn't exist now. |
| 00:03 | <Hixie> | alt=[...] is used a lot |
| 00:03 | <Hixie> | alt={...} is not |
| 00:03 | <webben> | yeah, but not as code. |
| 00:03 | <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? |
| 00:03 | <Lachy> | webben, you're not making sense |
| 00:04 | <webben> | Hixie: Given folks don't normally see alt, that's not actually inconceivable. |
| 00:04 | <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" |
| 00:05 | <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 |
| 00:05 | <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. |
| 00:06 | <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 :-) |
| 00:06 | <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) |
| 00:06 | <Hixie> | e.g. bits of svg appearing in random places in html documents |
| 00:07 | <webben> | I think "bits of svg" are probably a lot more opaque than any of the names suggested for this thing. |
| 00:07 | <Hixie> | svg was just one example, it happens with everything |
| 00:08 | <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 |
| 00:08 | <webben> | Well, yeah, but you need to work out what makes things happen more, not just look at whether they happen at all. |
| 00:09 | <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 |
| 00:09 | <webben> | k ; have a good shop :) |
| 00:09 | webben | is probably heading to bed very shortly. |
| 00:10 | <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) |
| 00:11 | <Lachy> | Hixie, btw, did your Stargate Continuum DVD arrive yet? |
| 00:11 | <Lachy> | if so, what did you think of it? |
| 00:14 | <webben> | Lachy: I don't think importantimage was a good name; "" implies unimportant image; and it doesn't convey that something is missing. |
| 00:15 | <Lachy> | webben, please elaborate? |
| 00:15 | <webben> | sorry alt="" => decorative (unimportant) image. |
| 00:16 | <webben> | alt="something" => important image |
| 00:16 | <webben> | importantimage => no additional information |
| 00:16 | <Lachy> | the same is true for alt={} |
| 00:17 | <webben> | yes, but I'm suggesting why importantimage wasn't a good name |
| 00:18 | <webben> | missing-text-equivalent does at least add some information, though I'm still not precisely happy with it. |
| 00:18 | <Lachy> | oh, ok. I misread your message. I thought you said it was a good name |
| 00:18 | <webben> | "alt-is-hint-only" perhaps |
| 00:19 | <Lachy> | it's too long |
| 00:19 | webben | is thoroughly unconvinced that long is bad. It's actually a plus AFAICT. |
| 00:19 | <Lachy> | and there's a possibillity that some authors could inadvertently write alt-is-only-hint instead of alt-is-hint-only |
| 00:20 | <webben> | there's also a possibility authors could write {) |
| 00:20 | <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 |
| 00:20 | <webben> | or " { |
| 00:21 | <Lachy> | it's easier to spot a syntax error like that, than it is to spot incorrectly transposed words in an attribute name |
| 00:21 | <webben> | the former cannot be caught by the validator; the second can. |
| 00:22 | <webben> | sorry {) is not definitely invalid, but alt-is-only-hint definitely is. |
| 00:22 | <webben> | so at best a validator could issue a warning about the former. |
| 00:22 | <Lachy> | that's what the image analysis tool in the validator is for. |
| 00:26 | <webben> | I think having a non-verifiable syntax would not make for a more user-friendly image analysis tool. |
| 00:26 | <webben> | since then you're asking people to check syntax as well as equivalents. |
| 00:27 | <webben> | whereas you could have them fix the syntax then check equivalents |
| 00:31 | <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 |
| 00:32 | <webben> | {] |
| 00:32 | <Lachy> | and in this whole discussion, I've not seen anyone accidentally mistype {} |
| 00:32 | <webben> | on my keyboard at least } ] are the same key |
| 00:33 | <Lachy> | yeah, that's true, but still unlikely |
| 00:33 | <webben> | not sure why that would be unlikely |
| 00:33 | <Lachy> | have you ever seen it happen anywhere? If so, how freqently? |
| 00:34 | <webben> | i don't have much memory of typos and their frequency full stop |
| 00:34 | <webben> | let alone mental data on } ] in particular ;) |
| 00:35 | <Lachy> | so, in other words, you're just speculating and trying to put that forth as strong evidence anyway? |
| 00:35 | webben | thinks the whole discussion is very speculative. |
| 00:36 | webben | doesn't figure "there's also a possibility authors could write {)" is an especially strong statement either |
| 00:38 | <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. |
| 00:39 | <webben> | or rely on their eyes when this can be handled by code. |
| 00:40 | <Lachy> | so maybe there are ways of at least flagging mismatched braces as a warning in the validator then |
| 00:40 | <webben> | that's still a waste of their time. |
| 00:40 | <Lachy> | what? |
| 00:40 | <webben> | they'd need to manually inspect the braces |
| 00:41 | <Lachy> | so? Braces are used very infrequently within alt text anyway, so it's hardly a lot of time wasted |
| 00:42 | <webben> | that's worse, then they'd need to try and remember what that pesky developer said about braces |
| 00:42 | <webben> | and () is just like {} right? |
| 00:42 | <Lachy> | I don't understand your point |
| 00:42 | <webben> | well, not worse, but not good either. |
| 00:43 | <webben> | Lachy: Basically, it shifts a job that could be done more reliably by machines onto people. |
| 00:43 | <webben> | that's impractical. |
| 00:44 | <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 |
| 00:44 | <webben> | this isn't about "checking the accuracy of alt text" |
| 00:44 | <Lachy> | of course it is |
| 00:44 | <Lachy> | what else is it about? |
| 00:45 | <webben> | Let's say you have a source of photos coming into a system. |
| 00:45 | <webben> | so you have some code which inspects each one to see if it has some text to use as an equivalent |
| 00:45 | <webben> | if it does, it inserts the text; if not, it inserts alt="{Photo}" |
| 00:47 | <Lachy> | yeah, and...? |
| 00:47 | <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? |
| 00:49 | <webben> | I guess the image checker could group them |
| 00:49 | <webben> | but that would probably mean you'd end up with false positive |
| 00:49 | <webben> | *positives |
| 00:50 | <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? |
| 00:50 | <Lachy> | I don't see how you'd end up with any more false positives using alt="{...}" as you would with some attribute |
| 00:52 | <webben> | Lachy: Yeah. Maybe. Would get a lot more complicated if alt's were being autogenerated to contain more information |
| 00:52 | <webben> | e.g. {Photo tagged with 'cat'} |
| 00:54 | <webben> | in fact, the better your auto-generation of alts, the worse it would get. |
| 00:55 | <webben> | well, actually, I guess the checker could just group {} and non-{} together for separate checking |
| 01:01 | <Lachy> | webben, yeah, exactly how it would group alt="..." separately from some-special-attribute="" |
| 01:02 | <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 |
| 01:08 | <webben> | maybe |
| 01:09 | <webben> | well, it would if the validator also warned about it /and/ if {} weren't common for that set of alt's |
| 01:09 | <webben> | meh, this also means you'd need code to inspect provided equivalents for { } and decide what to do with it |
| 01:10 | <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. |
| 01:10 | <webben> | or is this actually the equivalent |
| 01:15 | <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 |
| 01:16 | <jcranmer> | any good pages with <video> for testing? |
| 01:17 | <takkaria> | jcranmer: wikimedia? |
| 01:18 | <takkaria> | jcranmer: http://www.double.co.nz/video_test/ also |
| 01:23 | jcranmer | goes through old CSS mailing list messages and laughs |
| 01:25 | <jcranmer> | "Let's drop #id as it's superfluous and writing foo\#bar is too hard for most users" |
| 01:29 | <jruderman> | yeah, let's make everyone write [id="baz"] so we don't have escape # |
| 01:30 | <jcranmer> | some of his suggestions get even crazier |
| 01:31 | <takkaria> | whose suggestions are these? |
| 01:32 | <jcranmer> | Dmitry Turin |
| 01:32 | <Lachy> | jcranmer, http://lachy.id.au/dev/markup/tests/html5/video/ |
| 01:32 | <jcranmer> | Lachy: thanks |
| 01:33 | jcranmer | notes that wikimedia didn't do anything obvious to get to a <video> tag |
| 01:34 | <Lachy> | jcranmer, got a pointer to that suggestion of his? |
| 01:35 | <Lachy> | the #id one |
| 01:36 | <jcranmer> | Lachy: material around 1/10-ish/2008 |
| 01:37 | <Lachy> | is that around January 10th? |
| 01:37 | <jcranmer> | er, yes |
| 01:37 | Lachy | has difficulty interpreting american date formats |
| 01:37 | <jcranmer> | sorry, I forget that not everyone uses American date format |
| 01:37 | <jcranmer> | 2008-01-10-ish |
| 01:38 | <Lachy> | no-one should ever use it. It's horrible, it has the numbers in a weird order |
| 01:38 | <takkaria> | Dmitry suggested dropping # *this year*? |
| 01:39 | <jcranmer> | Lachy: force of habit |
| 01:40 | <Lachy> | LOL! That's related to his SQL5 proposal :-) |
| 01:40 | <jcranmer> | for a moment, I thought he was the crackpot who wanted to wave all problems away magically |
| 01:40 | <jcranmer> | wrong crackpot, though |
| 01:40 | <Lachy> | or is it SQL 50? |
| 01:41 | <jcranmer> | 5 |
| 01:41 | <jcranmer> | SQL5, HTML6, Unicode7, Computer2 |
| 01:41 | <Lachy> | the domain he uses is sql50.euro.ru |
| 01:41 | <Lachy> | hmm, the page he linked to is gone |
| 01:42 | <Lachy> | http://lists.w3.org/Archives/Public/www-style/2008Jan/0188.html |
| 01:43 | <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.) |
| 01:43 | jcranmer | laughs at his Computer 2 stuff |
| 01:43 | <jcranmer> | it seems to me that he understands very little of TCP/IP |
| 01:43 | <jcranmer> | and certainly nothing of IPv6 |
| 01:44 | <takkaria> | I like that Computer 2.0 "It gives large jump in development of economy." |
| 01:44 | <jcranmer> | and some of those proposals are incapable of handling the future well |
| 01:45 | <jcranmer> | takkaria: I think he's using automatic translation |
| 01:46 | <takkaria> | I think he just speaks bad English |
| 01:46 | <jcranmer> | ah, here's something interesting |
| 01:46 | <Lachy> | I like his 6D mouse :-) http://computer20.euro.ru/site/computer20/en/author/6d_eng.htm |
| 01:46 | <jcranmer> | he's proposing to get rid of HTTP, FTP, SMTP, POP, etc. |
| 01:46 | <jcranmer> | replaced by |
| 01:46 | <jcranmer> | ... wait for it ... |
| 01:46 | <jcranmer> | SQL5 |
| 01:46 | <Lachy> | of course. makes perfect sense |
| 01:47 | <jcranmer> | apparantely because SQL5 supports "continue downloading of file at breakdown of connection" |
| 01:47 | <Lachy> | I don't see why you're laughing at these obviously fantastic proposals! ;-) |
| 01:48 | <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 |
| 01:49 | <takkaria> | he thinks people should communicate over XML, too |
| 01:49 | <takkaria> | but not actual XML, weird unquoted XML |
| 01:50 | <jcranmer> | you mean SGML without the wacky stuff? |
| 01:51 | <takkaria> | I really don't know what he means |
| 01:51 | <Lachy> | he wants more wacky stuff, like strange characters in tag names |
| 01:51 | <jcranmer> | well, obviously, he wants his stuff |
| 01:51 | <takkaria> | he's already started work on HTML6 too |
| 01:52 | <Lachy> | "I also propose to allow any spec-symbol &, ^, @, ~, %, $ in name of a tag for future extentions." |
| 01:52 | <jcranmer> | that &'ll be a fun one |
| 01:54 | <takkaria> | btw, there is almost an html5 browser that you can use |
| 01:54 | <takkaria> | well. s/an html5 browser/a browser using the html5 parsing algorithm/ |
| 01:55 | <takkaria> | no javascript, but at least it's an implementation |
| 01:55 | <takkaria> | it's not quite ready yet since I'm still hunting down bugs. :) |
| 01:56 | <jruderman> | wouldn't it be easier to shoehorn your html5 parser into gecko or webkit than make a new browser around it? |
| 01:57 | <takkaria> | I'm not writing a new web browser around it, it already existed |
| 01:57 | <takkaria> | the browser in question is NetSurf (http://www.netsurf-browser.org/) |
| 01:57 | <jruderman> | ahh |
| 01:58 | <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 |
| 01:59 | <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 |
| 02:01 | <jruderman> | i'm sure mrbkap would be happy to help you, so he doesn't have to do the whole thing himself ;) |
| 02:03 | <jcranmer> | IIUC, HTML 5 sandboxing works like this: |
| 02:03 | <jcranmer> | <iframe src="yada yada yada" sandbox="" /> ? |
| 02:04 | <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? |
| 02:05 | <takkaria> | jruderman: hmm, I've been wondering about implementing HTML5 in gecko, I don't know anything of gecko's yet yet though |
| 02:05 | <takkaria> | or, er, C++ |
| 02:05 | <takkaria> | s/gecko's yet/gecko's code/ |
| 02:05 | <jcranmer> | takkaria: layout and content are >50% of where it's at |
| 02:06 | <takkaria> | mm |
| 02:06 | <takkaria> | I would be especially interested in writing another HTML parser. :) |
| 02:06 | <jcranmer> | there |
| 02:06 | <jcranmer> | 's also a parser/htmlparser, but I can't profess knowledge about that, including, critically, its use |
| 02:07 | <jruderman> | takkaria: join #developers on irc.mozilla.org and look for mrbkap and bz |
| 02:07 | <takkaria> | I'll remember that for later |
| 02:07 | <jcranmer> | dbaron or roc would probably work well, too |
| 02:07 | <takkaria> | it's a few months away before I'll be up for doing anything of that sort |
| 02:07 | <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 |
| 02:08 | <jruderman> | https://bugzilla.mozilla.org/show_bug.cgi?id=373864 |
| 02:09 | <takkaria> | jruderman: also, thanks for the burning edge, I started reading it about roughly when it started and it's still in my feedreader. :) |
| 02:10 | <jruderman> | cool, so i didn't lose all my readers when i went dark for a month? ;) |
| 02:10 | <jcranmer> | I'm just the guy who works on mailnews code which rivals gsnedders in age |
| 02:10 | <jcranmer> | (some of which, in any case) |
| 02:11 | <takkaria> | mm, crufty C++ |
| 02:12 | <jcranmer> | I *wish* it were C++ |
| 02:12 | <jcranmer> | it's written in yet-another-person-implementing-C++-in-C-code |
| 02:13 | <jcranmer> | and the other part is written in C++ by someone who thought that 15 parameters was too few for a function |
| 02:14 | <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 |
| 02:14 | <takkaria> | s/tenety/twenty/ |
| 02:22 | <Lachy> | http://arstechnica.com/news.ars/post/20080801-newly-found-hybrid-attack-embeds-java-applet-in-gif-file.html |
| 02:23 | <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. |
| 02:24 | <Lachy> | but if that's all it is, then it could hardly be considered an exploit |
| 02:25 | <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>? |
| 09:40 | <jacobolus> | Hixie: re: WebSocket: did you ever read http://tools.ietf.org/html/rfc3093 ?? |
| 09:40 | <jacobolus> | it strikes me that we are finally making the dream a reality! |
| 11:06 | <Lachy> | Wow! http://adweek.blogs.com/adfreak/2008/07/then-well-grab.html |
| 11:09 | <webben> | hah :) |
| 11:20 | <Hixie> | i posted that image in #whatwg a few weeks back :-0 |
| 11:21 | <Lachy> | ok |
| 11:21 | <Hixie> | :-), even |
| 11:22 | <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. |
| 11:24 | <Hixie> | what's the codepoint of the first? |
| 11:24 | <Hixie> | look it up in the unihan table |
| 11:25 | <Hixie> | there are some translations there |
| 11:28 | <Lachy> | I'll have to find it again |
| 11:28 | <Lachy> | U+4B38 U+5385 |
| 11:29 | <Lachy> | where do I find the unihan table? |
| 11:33 | <heycam> | the first means "meal" |
| 11:33 | <heycam> | (i think) |
| 11:33 | <Lachy> | actually, I'd found the wrong letter. 餐厅 translates to restaurant. |
| 11:34 | <Lachy> | U+9910 looks very similar to U+4B38 |
| 11:35 | <Lachy> | individually, the 2 symbols translate to "meal" and "office", respectively |
| 11:36 | <Lachy> | I can't find the other 2 symbols in the picture, cause they're obscured by something in front of them |
| 11:36 | <heycam> | i'm pretty sure they're the same characters |
| 11:36 | <Lachy> | they look slightly different |
| 11:36 | <Lachy> | maybe it's just a different font |
| 11:36 | <heycam> | different font |
| 11:36 | <heycam> | yeah |
| 11:37 | <Lachy> | see, I never know with this weird language they all look alike to me anyway |
| 11:37 | <heycam> | :) |
| 11:40 | <Philip`> | That's why translation should be performed by competent people, not by non-competent people or non-people :-) |
| 11:51 | <Philip`> | (Someone says "The Chinese text on the banner (can1 ting1) is simply a generic term for "dining hall" or "cafeteria"") |
| 13:40 | <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. |
| 14:27 | jgraham | wonders what the advantage of alt={Photo} is over title=Photo if the idea is to provide a description |
| 14:30 | <Dashiva> | The idea is to satisfy the alt-must-be-mandatory crowd |
| 14:30 | <Philip`> | s/crowd/arguments/ |
| 14:32 | <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" |
| 14:32 | <jgraham> | (or both) |
| 14:32 | <Dashiva> | The arguments can be satisfied without mandatory alt, the crowd cannot |
| 14:37 | <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 |
| 14:37 | <jgraham> | Philip`: It could say Photo:My cat playing with string |
| 14:37 | <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 |
| 14:41 | <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) |
| 14:42 | <jgraham> | (this complete the set of 3 things that I have wondered about recently) |
| 14:44 | Philip` | wonders whether w3.org will continue being reregistered forever, until DNS eventually dies out |
| 16:53 | <takkaria> | voila, I have a build of an HTML5-parsing-algorithm-supporting browser |
| 16:57 | <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 :) |
| 16:58 | <takkaria> | I guess the step after that is "profit!!!" |
| 16:59 | <takkaria> | hmm, JFS isn't the filesystem you want if you want a directory containing 36k other directories |
| 17:58 | <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? |
| 18:17 | <takkaria> | jgraham: I can't imagine that hard at all |
| 18:17 | <takkaria> | the libxml2 interface is finished, yes, but it's not really that efficient |
| 18:18 | <takkaria> | one problem is that hubbub's emitted strings are (pointer,length) pairs, and libxml's are NUL-terminated strings |
| 18:18 | <takkaria> | so in order to set properties, some kind of strndup() has to be performed |
| 18:19 | <takkaria> | which is rather unfortunate |
| 18:20 | <takkaria> | this is what the timings look like at the moment: http://pastebin.com/m35aeca22 |
| 18:42 | <jgraham> | So hubbub is a factor of ~3 slower than libxml2? Room for improvement but not bad for new code |
| 19:20 | <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 |
| 19:28 | <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? |
| 19:30 | <Lachy> | but in a UTF-8 document, it would be resolved to "http://example.com/?foo=%E9%A4%90"; |
| 21:38 | <Hixie> | jgraham_: the advantage is that the UA can provide a clear indication that there is an image |
| 21:38 | <Hixie> | jgraham_: which it doesn't have to do if there is alt text normally |
| 21:40 | <Philip`> | Hixie: The UA could do the same if the spec defined the appropriate behaviour for <img title=...> instead of <img alt={...}> |
| 21:42 | <hsivonen> | jgraham_: thanks for pointing out the existing translation hints that translation engines could be using (but don't) |
| 21:44 | <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 |
| 21:44 | <Hixie> | Philip`: The title="" gives the caption/credit/etc of the image, not the kind of image |
| 21:44 | <hsivonen> | s/caegory/category/ |
| 21:54 | <webben> | hsivonen: I think it's probably more a sign of HTML being used as a UI language as well as a content language. |
| 21:54 | <webben> | at least for accessibility features |
| 22:31 | <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" |
| 22:57 | <Lachy> | still reading that, but it doesn't appear to be a major problem editing namespaces in places where prefixes really are effectively meaningless, such as within the DOM. But the big problems occur when you want to serialise it, where the prefixes suddenly become meaningful and there are conflicts |
| 23:00 | <Lachy> | some of the problems could possibly have been mitigated if prefixes had to be declared document-wide, and had to be unique |
| 23:05 | <Dashiva> | Wouldn't that ruin the whole "put some xml inside some other xml" thing? |
| 23:09 | <Lachy> | how so? |
| 23:10 | <Lachy> | you could still declare multiple namespaces, but it would prevent silly things like this <x:foo xmlns:x="a"><x:bar xmlns:x="b"/></x:foo> |
| 23:10 | <Dashiva> | Like if you're doing a feed, you'd have to extract all the namespaces used, and solve potential conflicts |
| 23:10 | <Lachy> | yes, you would have to ensure there are no conflicts |
| 23:11 | <Lachy> | but you get other problems, as outlined in that blog entry, when conflicts arise |
| 23:11 | <jgraham> | Hixie: Why would you want to put the caption / credit /etc. in @title rather than in a user-visible form using @figure |
| 23:11 | <Dashiva> | And while you could say it's not a supported feature, automatic renaming for conflicts would break things relying on the prefix |
| 23:12 | <jgraham> | In practice, i think that Philip`'s objection about tooltips is stronger, although given the IE behaviour with alt, not so much stronger |
| 23:12 | <Lachy> | even with namespaces as they are today, nothing should really ever rely on the prefix |
| 23:12 | <Dashiva> | Yeah, but that's very violated should |
| 23:13 | <Philip`> | jgraham: Because having a user-visibly-by-default caption/credit/etc is really ugly in cases like http://diveintomark.org/archives/2007/03/05/cc-dogs |
| 23:13 | <Philip`> | s/visibly/visible/ |
| 23:14 | <jgraham> | Hixie: I think the fact that there is an <img> tag allows the UA to indicate that there is an image. Once you know that there is an image and there isn't any textual alternative the title seems like it will provide the mst information about what you are missing out on |
| 23:14 | <Dashiva> | Lachy: Certain feed readers only working with no prefix or atom: to mention one ;) |
| 23:16 | <jgraham> | Philip`: The caption/credit on that page /is/ user visible. Even if you wanted to hide it @title wouldn't help, something like <details> would. |
| 23:17 | <jgraham> | (the fact that @title is used to indicate what happens when you click the image rather than to give a title is a bit sad but I'm pretty convinced that a screenreader user could work out what was going on on that page without any alt text) |
| 23:18 | <Philip`> | jgraham: It is visible, and hence it is really ugly, and so it'd be nicer if it wasn't visible |
| 23:19 | <Philip`> | and @title would help if it was split into lots of <img>s, or used an image map or whatever |
| 23:19 | <jgraham> | Philip`: I think it's a really poor example of where title might help :) |