| 00:27 | <Hixie> | hsivonen: it doesn't change from whatever it used to be |
| 00:27 | <Hixie> | hsivonen: (spec says that somewhere) |
| 00:28 | <Hixie> | hsivonen: the space thing could be an oversight, spaces aren't very well handled |
| 00:42 | <hsivonen> | Hixie: ok. that means I have to store the mode from which I switch to trailing end :-( |
| 00:43 | <hsivonen> | btw, IBM says their experience with the ICU4J charset detector is that 6KB of text is needed |
| 00:43 | <hsivonen> | seems like a lot compared to half a KB |
| 00:43 | <Hixie> | needed for what? |
| 00:44 | <hsivonen> | Hixie: to get a good confidence in statistic-based encoding guessing |
| 00:44 | <othermaciej> | statistics-based heuristics are a pretty different thing from prescanning for meta tags |
| 00:45 | <hsivonen> | yes, they are |
| 00:45 | <hsivonen> | if I can help it, I'd prefer to avoid scanning the entire doc either way |
| 00:46 | <hsivonen> | rounded up to memory pages, the IBM figure yields an 8 KB buffer |
| 00:46 | <Hixie> | hsivonen: seems reasonable. the spec leaves it open to whatever the UA wants. |
| 00:48 | <hsivonen> | still, my reading of Gecko source suggests that chardet is only run on the first buffer and the impression I got was that Gecko buffers were closer to half a K |
| 00:52 | <Hixie> | quite possible |
| 06:51 | Hixie | sends a +1 e-mail |
| 08:43 | Lachy | disagrees with Hixie's +1 mail |
| 08:45 | <Lachy> | Hixie, the problem isn't the case sensitivity, it's the conflict caused by having more than one way to declare namespaces, regardless of case sensitivity |
| 08:52 | <Hixie> | i was agreeing with the fact that there is no need to have multiple ways to declare prefixes being "active" in the same place |
| 08:55 | <webben> | re longdesc, it's striking that the Mozilla bug commentators consider accessibility extensions as fulfilling the accessibility needs associated with supported longdesc in the UI: https://bugzilla.mozilla.org/show_bug.cgi |
| 08:56 | <Hixie> | nn |
| 08:56 | <webben> | *with supporting |
| 08:56 | <webben> | if this is the view developers are taking, then we need to take a much broader view of what UAs support |
| 08:57 | <webben> | sorry: https://bugzilla.mozilla.org/show_bug.cgi?id=1996 |
| 08:59 | <webben> | (I don't think such a holistic view of the UA ecosystem is unreasonable anyhow; but folks are sometimes dismissive of features currently requiring plugin/add-on support, which doesn't make any sense if mainstream development depends on such add-ons to provide end-user functionality |
| 09:34 | <hsivonen> | Hixie: can you explain how one might hit point 7. in the CDATA/RCDATA tree building: "If the next token is an end tag token with the same tag name as the start tag token, ignore it. Otherwise, this is a parse error." |
| 09:34 | <hsivonen> | can the parse error only be hit by scripting? |
| 10:06 | <hsivonen> | Hixie: I don't see the void elements that usually appear in head ever popped off the stack. They should all be accompanied by "Immediately pop the current node off the stack of open elements.", right? |
| 10:46 | <hsivonen> | Hixie: the reason why the CDATA/RCDATA is the way it is is to make script and style appending atomic from the scripting point of view, right? so I can greatly simplify things in a non-browser parser, right? |
| 12:40 | <hsivonen> | eww. the implicit </p> stuff is ugly |
| 12:48 | <annevk> | the tools will not generate </p> |
| 12:52 | <hsivonen> | the tools? |
| 12:52 | <annevk> | the tools that safe us |
| 12:52 | <hsivonen> | oh |
| 12:53 | <hsivonen> | annevk: anyway, I don't want the tree builder methods to call each other recursively to enable stack frame creation omission compiler optimizations |
| 12:54 | <annevk> | nice sentence |
| 12:54 | <hsivonen> | annevk: which means "acting as if" an end tag had been seen when I'm processing a start tag gets ugly |
| 12:55 | <annevk> | what is the big deal about creating a new token running that through the parser and then running the token you were processing again? |
| 12:56 | <hsivonen> | annevk: the "tokens" don't exist as objects |
| 12:56 | <hsivonen> | annevk: so doing that would mean calling the methods in a way that poisons the said compiler optimization |
| 12:58 | <annevk> | ah ok |
| 12:59 | <hsivonen> | this is of course moot if HotSpot doesn't do the said optimization but I remember reading that it does |
| 13:02 | <hsivonen> | this is one of those areas where I'm doing smart stuff if I guess the compiler behavior right and I'm doing stupid stuff if I guess wrong but verifying the guess takes more time than the wasted time caused by the guess being wrong |
| 13:46 | <annevk> | wow, check IE7 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%3Cbody%3E%3Cobject%20src%3D%22image%22%20type%3D%22text/html%22%3E |
| 13:47 | <annevk> | if you use a src= attribute on <object> it generates some type of data URI inside the data attribute?! |
| 14:02 | <Philip`> | It does the same with <object type="text/html" data="data:">, as long as you have "data:" (case-insensitive) at the start, replacing it with its own weird URI |
| 14:06 | <Philip`> | IE6 (at least when in Wine) does about the same except its data: thing is the same first 16 bytes as in IE7, then a more complete document ("<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML><HEAD><META http-equiv=Content-Type content="text/html; charset=windows-1252"></HEAD><BODY><P> </P></BODY></HTML>") |
| 14:09 | <annevk> | it would be nice if there was a dom view for the rendered view too |
| 14:09 | <annevk> | oh |
| 14:09 | <annevk> | it has a refresh button |
| 14:09 | <annevk> | duh |
| 15:44 | <annevk> | heh, the PNG group rejected APNG |
| 15:44 | <annevk> | didn't know that |
| 15:45 | <annevk> | "Voting has closed on the APNG proposal. There were 8 YES votes, 10 NO votes, no abstentions, and no ineligble votes cast. The proposal has failed and the APNG chunks are not registered." |
| 15:48 | <Philip`> | http://blog.vlad1.com/archives/2007/04/26/143/ has some comments on that (including "maybe see about publishing it as an unofficial spec through the WHATWG (if there is interest in that group)", though I have no idea what more recent plans are like) |
| 15:49 | <annevk> | I wonder if other vendors are going to adopt it. Such as Internet Explorer... |
| 16:08 | <annevk> | http://gjuyn.xs4all.nl/pnganim.html is also interesting |
| 16:42 | <webben> | Any thoughts on why previous attempts to improve on <img> failed where new attempts to create <video> and <audio> object would succeed? |
| 16:43 | <annevk> | <video> and such are being implemented? |
| 16:44 | <annevk> | well, I guess more that people are used to <img> |
| 16:44 | <gsnedders> | and using <object> and the like can get overly complex trying to embed video |
| 16:45 | <annevk> | hmm, more people don't get <dl> |
| 16:46 | <annevk> | yeah, especially for APIs |
| 16:46 | <annevk> | got to go |
| 16:50 | <Philip`> | Maybe <img> is almost good enough already, so the cost of changing it outweighs the benefits of improving it, whereas <video>/<audio> can be improved much more by changing them |
| 16:51 | <webben> | i thought <image> /was/ implemented (same as <img>) |
| 16:51 | <webben> | what was the other attempt to replace img? |
| 16:52 | <webben> | I mean there's TBL's original suggestion: http://lists.w3.org/Archives/Public/www-talk/1992NovDec/0106.html |
| 16:52 | <webben> | but that never made it into a spec AFAIK |
| 16:53 | <webben> | ah ... <fig> ? http://www.w3.org/MarkUp/html3/figures.html |
| 16:54 | <Philip`> | <image> wasn't an attempt to replace <img> - it was just an attempt to be nice to authors and error-correct their frequent misspellings of the tag name |
| 16:56 | <Philip`> | (...or at least I'm guessing that's what it was, and I'd be rather surprised if that wasn't true) |
| 16:58 | <gsnedders> | Philip`: that is true |
| 16:58 | <webben> | hmm <fig> works at least as well as the <pic> and <picture> varieties being proposed |
| 16:58 | <gsnedders> | Philip`: now my speculation: bug reports to browsers about <image> not working |
| 16:58 | <webben> | (at least judging by IE6 and Fx2) ... just doesn't display the image |
| 16:58 | <gsnedders> | webben: all seem to define specific types of image |
| 16:59 | <webben> | gsnedders: all what? |
| 16:59 | <webben> | <fig> seems to be generic |
| 16:59 | <gsnedders> | webben: picture, figure, etc. |
| 16:59 | <webben> | i think picture is intended to be generic too |
| 16:59 | <webben> | (from what I've seen of public-html proposals) |
| 16:59 | <gsnedders> | is a diagram stored in an image a picture? |
| 16:59 | <webben> | yes |
| 17:00 | <gsnedders> | yes, but the name suggests otherwise |
| 17:00 | <webben> | no |
| 17:00 | <webben> | it doesn't actually |
| 17:00 | <gsnedders> | (and I know the name of the element is irrelevant for semantics) |
| 17:00 | <webben> | no i mean "picture" is not a word that excludes "diagram" |
| 17:00 | <webben> | (or photo, or painting, or whatever) |
| 17:01 | <webben> | "I took a picture" , "I painted a picture" ... |
| 17:01 | <gsnedders> | in my head a diagram isn't a picture. |
| 17:03 | <webben> | http://www.google.co.uk/search?hl=en&q=define%3Apicture |
| 17:03 | <webben> | i think your head is wrong on this one ;) |
| 17:04 | <webben> | i agree that picture has some connotation of likeness vs abstraction |
| 17:04 | <webben> | but an abstract painting would still be a picture in common parlance |
| 17:04 | <webben> | so even that doesn't really hold up |
| 17:05 | <webben> | i think image actually excludes the idea of diagram more than picture does |
| 17:05 | <webben> | because an image actually means "copy" |
| 17:05 | <webben> | http://www.etymonline.com/index.php?term=image |
| 17:06 | <webben> | whereas picture ultimately refers to the act of painting |
| 17:06 | <webben> | http://www.etymonline.com/index.php?term=picture |
| 17:12 | <Philip`> | "figure" is generic enough that it usually includes tables as well as images, at least in TeX-like documents |
| 17:16 | <webben> | Philip`: yes figure is probably too generic ... although HTML5's figure seems intended to be used mainly for non-textual materials |
| 17:28 | <webben> | http://lists.w3.org/Archives/Public/public-html/2007Jun/1083.html doesn't make sense as a reason for <embed> not having alt since current UAs to have some support for alt on embed |
| 17:28 | <webben> | (as it sort of admits) |
| 17:35 | <Philip`> | Maybe <embed alt> is missing just because it's not specified anywhere and nobody thought of it when adding embed in HTML5? |
| 17:36 | <Philip`> | (Or maybe people are much more aware of such things than I am :-) ) |
| 17:41 | <Philip`> | Hmm... As far I can tell, Lynx and Opera show the embed's alt; Links and Firefox and IE and Safari don't |
| 17:48 | <zcorpan> | there is <noembed>... but if you need fallback use <object> |
| 17:49 | <Hixie> | hsivonen: the void elements aren't actually put on the stack. |
| 17:49 | <Hixie> | hsivonen: the CDATA/RCDATA stuff could hit an EOF token |
| 17:52 | <Philip`> | (w3m doesn't show the embed alt either) |
| 17:54 | <zcorpan> | Philip`: you have a test case for embed alt? |
| 17:55 | <Philip`> | data:text/html,<embed alt="alt"> |
| 17:55 | <Philip`> | That's about what I was testing :-) |
| 17:55 | <zcorpan> | Philip`: doesn't show anything in opera for me |
| 17:56 | <Philip`> | Oops... Try <embed alt="alt" src="404"> |
| 17:56 | <zcorpan> | ah. o9.5 shows it indeed |
| 17:57 | <Philip`> | (Half my tests were wrong, then...) |
| 17:57 | <webben> | Philip`: Have you checked Firefox and IE with the Microsoft's accessibility inspector (I haven't as yet) |
| 17:57 | <zcorpan> | and lynx |
| 17:57 | <webben> | IIRC HTML5 keeps <embed> for Flash |
| 17:57 | <Philip`> | Lynx shows the alt text, Links shows a "[EMBED]" link, w3m shows a "embed(404)" link |
| 17:58 | <webben> | zcorpan: in which case one use-case would be http://www.rnib.org.uk/wacblog/news/just-how-accessible-is-the-web-bbc-1s-click-investigates/ |
| 17:58 | <Philip`> | (IE and Safari still don't show any alt text, just a broken image icon (in IE) or a blank space (in Safari)) |
| 17:58 | <webben> | it's embedded in a discussion of why using invalid HTML can have unpredictable effects on accessibility |
| 17:58 | <Philip`> | (regardless of whether src is specified or not) |
| 17:59 | <webben> | Philip`: some of those text browsers can be quite configurable. |
| 17:59 | <webben> | Philip`: so that's not necessarily their only possible response |
| 17:59 | <Philip`> | webben: I haven't checked it with that (and I can't entirely easily, since rdesktop keeps crashing at random times when I try connecting to Windows...) |
| 18:00 | <webben> | Philip`: Fair enough. :) |
| 18:00 | <Philip`> | ((I blame my video drivers rather than rdesktop for that, since it used to work fine)) |
| 18:00 | <webben> | I think the main advantage is for Lynx though. |
| 18:01 | <webben> | in particular you can do <embed alt=""> |
| 18:01 | <webben> | (which in the particular use-case cited would have helped) |
| 18:04 | <webben> | Philip`: is your testcase online? |
| 18:05 | <Philip`> | No, but I could upload something quickly if it'd be useful |
| 18:05 | <webben> | Philip`: I suppose I can make one myself; no reason to trouble you unless you'd already done it :) |
| 18:09 | <Philip`> | Oh, Links is slightly odd |
| 18:09 | <Philip`> | http://canvex.lazyilluminati.com/misc/embedalt.html |
| 18:09 | <Philip`> | Links shows the alt text when you embed an image, but not when you embed something that doesn't exist |
| 18:10 | <Philip`> | Also, Opera doesn't like embedded images at all, since it wants me to install a plugin |
| 18:16 | <webben> | I'm using .swf as an extension in my test |
| 18:16 | <webben> | since AFAICT that's the only reason to use embed |
| 18:17 | <Philip`> | That's probably sensible |
| 18:17 | Philip` | doesn't have any easily-available .swf files |
| 18:19 | <webben> | oh ... i was just testing with a non-existent one |
| 18:19 | <Philip`> | Ah, I can steal the Live DOM Viewer's Flash file... |
| 18:19 | <webben> | http://www.benjaminhawkeslewis.com/www/test-cases/embed-alt.html |
| 18:19 | <webben> | maybe i need both |
| 18:19 | <Philip`> | http://canvex.lazyilluminati.com/misc/embedalt.html - now with a .swf |
| 18:20 | <Philip`> | Links shows [EMBED] for pass.swf and 404, and shows the alt text (or an empty space) for green.png |
| 18:21 | <Philip`> | (Lynx still always shows the alt text (or [EMBED] if there is none)) |
| 18:22 | <webben> | could you add one with a .swf extension that 404s |
| 18:22 | <webben> | it's possible UAs might react different for that |
| 18:22 | <Philip`> | Done |
| 18:22 | <webben> | cool :) |
| 18:23 | <Philip`> | Opera does act differently based on the extension; I can't see anything else that does |
| 18:24 | <Philip`> | (though I don't have Flash installed in any browser other than Opera) |
| 19:30 | <hsivonen> | Hixie: e.g. img is put on the stack and immediately popped. e.g. link is put on the stack and never popped (I pop it on my own) |
| 23:09 | <Hixie> | hsivonen: oh yeah, never noticed that. huh. send mail? |