| 00:02 | <Hixie> | jruderman: fixed the routing problem |
| 00:03 | <jruderman> | Hixie: which problem? |
| 00:03 | <jruderman> | Hixie: oh, the google maps thing with the mozilla office |
| 00:05 | <jruderman> | Hixie: now it directs people to building S rather than building K, but that's probably a lot harder to get right |
| 00:06 | <jruderman> | Hixie: thanks, now we'll lose fewer moco employees to pedestrian fatalities on the 101 freeway |
| 00:07 | <Philip`> | Why does Google Maps choose a certain route when there's an alternative that's two minutes shorter, and that it's happy to pick when I drag the route around a bit? |
| 00:07 | Philip` | isn't sure why it'd be optimising for anything except distance |
| 00:09 | <gavin> | it takes into account speed limits and such, doesn't it? |
| 00:09 | <gavin> | favors highways/major streets too, I think |
| 00:09 | <gavin> | I'm sure it's very complex |
| 00:09 | <Philip`> | Uh, speed limits for pedestrians? |
| 00:09 | <gavin> | oh, well |
| 00:09 | <gavin> | that's in beta! |
| 00:09 | <Philip`> | (This is the walking mode) |
| 00:09 | <Hixie> | jruderman: well the pin can be edited by users (and has been. a lot. maybe other people in your office are moving it to the wrong location. :-) ) |
| 00:10 | <jruderman> | Hixie: hehe |
| 00:10 | <codedread> | funny - i just noticed this pin editing thing 5 minutes ago |
| 00:10 | <Hixie> | jruderman: but the problem was that it ended on 101, and that has been fixed for the address you gave :-) |
| 00:10 | <Hixie> | Philip`: simplicity is a factor |
| 00:10 | <jruderman> | Hixie: did you fix it letting people put building pins on freeways, or did you just move that one pin? |
| 00:11 | <Hixie> | jruderman: i can't talk about what the actual fix is, because it's a two phase fix and the second phase hasn't shipped yet. |
| 00:11 | <Hixie> | ask me again in a few weeks |
| 00:11 | <jruderman> | you guys take the 'future products or services' way too seriously |
| 00:11 | <Hixie> | :-) |
| 00:12 | gsnedders | passes jruderman a future product or service |
| 00:12 | <Philip`> | Hixie: I suppose it could be, but the shorter route is only two extra steps, and I'm too lazy to travel an extra two minutes just for that |
| 01:08 | <Hixie> | Philip`: i'm not defending it, just saying what the reason is |
| 01:10 | <roc_> | I don't think the 101 problem was the pin location |
| 01:18 | <Hixie> | roc_: why not? (as far as i can tell, the pin location caused maps to decide the nearest street was 101.) |
| 01:19 | <roc_> | because even if the nearest street *is* 101 (and presumably there are valid locations for which that's true), it should know you can't stop there. |
| 01:20 | <roc_> | I'm not ripping on Maps, it's great and the problem is hard. Besides, I have friends who work on it |
| 01:20 | <Hixie> | oh i agree that it could try to avoid stopping on 101 in general |
| 01:21 | <roc_> | I only blogged about it because I thought it was hilarious. The Street View was particularly good :-) |
| 01:22 | Hixie | didn't know you'd blogged about it |
| 01:22 | <roc_> | ages ago |
| 01:23 | <Hixie> | ah |
| 01:24 | <jruderman> | i also tried to report it as a bug using email a long time ago, but telling hixie about it yesterday got it fixed quickly :) |
| 02:14 | <roc_> | http://developer.mozilla.org/web-tech/2008/09/04/web-workers-part-1/ |
| 02:16 | <Hixie> | i love how all the examples of workers are always really really inefficent implementations of solved problems :-) |
| 02:17 | <Hixie> | do any of the demos on whatwg.org/demos/workers work? |
| 02:17 | <roc_> | to be fair, compilers like to use fibonacci too |
| 02:18 | <Hixie> | oh i'm to blame as well |
| 02:18 | <roc_> | I wish for a compiler that can optimize fibonacci to the closed form |
| 02:18 | <Hixie> | one of my examples uses 11 workers to return a constant |
| 02:18 | <roc_> | I don't really know much about the workers work myself, so I couldn't answer your question other than by testing them |
| 02:18 | <Hixie> | k |
| 02:18 | <Hixie> | i'll grab a build once i'm back on my laptop |
| 02:19 | <Hixie> | (my linux box can't run ff3, doesn't have some required library) |
| 02:19 | <Hixie> | libgtk-x11 or something |
| 02:19 | <Philip`> | roc_: It ought to be easy for the compiler just to do pattern-matching to detect a Fibonacci function and replace it with an efficient library call |
| 02:19 | <roc_> | Philip`: yeah, but that's cheating |
| 02:19 | <Philip`> | (like what MSVC does with memcpy loops) |
| 02:19 | <Philip`> | (but pointlesser) |
| 02:20 | <roc_> | recognizing and solving general difference equations is possible, although probably equally useless in practice |
| 02:21 | <Philip`> | I guess the compiler would have to work out it needs a "if (n < 0) { for(;;); }" to get the right computation |
| 02:21 | <Lachy> | I finally got my public-html email backlog down to zero! -) |
| 02:22 | <Lachy> | now I can start on the 485 in the whatwg backlog :-/ |
| 02:45 | <BenMillard> | Hixie, there's a similar problem with ARIA examples for static web content: existing semantics in HTML4 are often adequate, or the ARIA becomes unnecessary when the feature is changed to follow a usable design pattern. |
| 02:45 | <BenMillard> | (Re: your comment about workers examples) |
| 03:24 | <BenMillard> | Hixie, I sent a follow-up to my review of "@headers issue resolved": http://lists.w3.org/Archives/Public/public-html/2008Sep/0163.html |
| 03:25 | <BenMillard> | the blog entry it links to has numerical analysis of the tables cited as supporting evidence versus corrected and redesigned versions I've done |
| 03:29 | <BenMillard> | time for lunch :P |
| 07:21 | <hsivonen> | Hixie: I guess in the case of Java the problem scenario is that someone has serialization code buried at the end of a pipeline somewhere |
| 07:22 | <hsivonen> | Hixie: and then they start sending HTML5 stuff through the pipeline |
| 07:22 | <hsivonen> | Hixie: and the output is wrong |
| 07:22 | <hsivonen> | Hixie: and ripping out 4 or 5 lines of code and replacing them with 2 lines of code referring to the serializer I wrote is onerous |
| 07:23 | <hsivonen> | as they'd need to discover and add Yet Another Jar |
| 07:23 | <hsivonen> | and perhaps convince their lawyers that code under the MIT license and copyright Mozilla Foundation is OK to use |
| 07:24 | <hsivonen> | I get an impression that the HTML5 content would end up in the pipeline in a semi-uncoordinated way |
| 07:25 | <hsivonen> | because if it were coordinated, one would think the serializer swapping could be coordinated, too |
| 09:50 | zcorpan | discovers document.implementation.createHTMLDocument |
| 09:58 | <annevk> | Hixie, http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-November/007719.html was my e-mail |
| 10:00 | <annevk> | Hixie, it's in the WF3 folder apparently o_O |
| 10:18 | <Lachy> | LOL! I like how John Foliot claims my proposed study of longdesc is flawed based on the fact that it will reveal the exact problems I designed to reveal. :-) |
| 10:19 | <Dashiva> | Seems quite in line with most commercial studies :) |
| 10:25 | <hsivonen> | one can read quite a bit of browser history in the UA string of Chrome |
| 10:26 | <hsivonen> | I wonder if we ever come up with a way to stop the growth of the UA string |
| 10:27 | <hsivonen> | does a typical HTTP GET request still fit on one IP packet? |
| 10:27 | <Dashiva> | Yeah, one day we'll have RealUserAgent instead |
| 10:27 | <Dashiva> | Since everything in the original UA string will be back-compat and talismans |
| 10:31 | <hsivonen> | is Netscape 6 the only browser in history that has swam against the UA string cruft stream? |
| 10:31 | <hsivonen> | Opera did recently, but it can still vary it per site, right? |
| 10:31 | <wilhelm> | No. Mine says "Opera/9.52 (X11; Linux i686; U; en)". |
| 10:31 | <wilhelm> | Yes. It identifies as other browsers on some sites. |
| 10:32 | <wilhelm> | We maintain a list. |
| 10:32 | <Dashiva> | Why on earth does it list X11... |
| 10:32 | <hsivonen> | Dashiva: well, it say U and en, too... |
| 10:33 | <Dashiva> | Yeah, but my windows version says that too |
| 10:33 | <hsivonen> | Chrome/1.0 now that would have been revolutionary :-) |
| 10:33 | <Philip`> | Does any browser ever *not* say "U"? |
| 10:33 | <Dashiva> | platform, U, language is always there |
| 10:33 | Philip` | doesn't know if they can be configured with rubbish encryption instead of U |
| 10:34 | <Philip`> | IE8b2 now sends a "UA-CPU: x86" header |
| 10:34 | <webben> | what? |
| 10:34 | <webben> | what for? |
| 10:35 | <roc_> | so that Web pages can send the correct x86 binaries for execution |
| 10:35 | <hsivonen> | webben: ActiveX install sites perhaps? |
| 10:35 | <roc_> | process separation rules |
| 10:35 | <webben> | hsivonen: http://blogs.msdn.com/ie/archive/2006/10/17/accept-language-header-for-internet-explorer-7.aspx#839384 seems so. |
| 10:37 | <Philip`> | Oh, IE7 sends UA-CPU too? |
| 10:40 | hsivonen | wonders if people who write about "token security" intended the pun... |
| 10:44 | <annevk> | so should I do my fragment tests again with ( or so as character instead of ? |
| 10:46 | <Philip`> | That should avoid the URL-parsing issues in (at least) Konqueror |
| 10:49 | <annevk> | does x' help with that too? |
| 10:49 | <annevk> | ' seems pretty harmless, and suffix it with x just in case |
| 10:50 | <annevk> | prefix, I mean, though i'll suffix it as well |
| 10:53 | <annevk> | so far same results in browsers |
| 10:53 | <annevk> | I think I'll leave it be |
| 11:44 | <hsivonen> | How many Windows ports of WebKit are there with different graphics layers? Safari, Arora, Chrome, AIR. Did the company that ported WebKit to Windows Mobile have a 5th graphics layer? |
| 11:44 | <hsivonen> | does AIR use the same Abode vector graphics renderer as InDesign and Acrobat? |
| 11:45 | <hsivonen> | does any of them actually delegate Bézier rasterization to GDI+ or WPF? |
| 11:53 | <roc_> | I don't know what AIR does |
| 11:53 | <roc_> | the others definitely don't |
| 11:53 | <roc_> | I'm pretty sure AIR doesn't either |
| 11:53 | <zcorpan> | should document.characterSet and document.charset be part of dom core instead of dom html? |
| 11:53 | <roc_> | GDI+ is crappy, WPF would be very hard to access |
| 11:59 | <hsivonen> | roc_: presumably the WPF renderer is C or C++. Don't they expose a C API for it? |
| 11:59 | <roc_> | they don't |
| 11:59 | <hsivonen> | roc_: that's odd. |
| 11:59 | <roc_> | no it's not |
| 11:59 | <hsivonen> | roc_: ok. strategically it may not be odd. |
| 12:00 | <roc_> | also, exposing APIs is costly |
| 12:00 | <roc_> | because then you have to support them to the end of time |
| 12:00 | <hsivonen> | yeah |
| 12:00 | hsivonen | just published an API |
| 12:00 | <roc_> | sucka |
| 12:03 | <annevk> | zcorpan, if they depend on charset sniffing might be easier in HTML |
| 12:04 | <annevk> | zcorpan, also, DOM Core already has various encoding features (all completely pointless of course, the DOM shouldn't deal with encoding) |
| 12:04 | <hsivonen> | zcorpan: does query string treatment depend on charset in XML? |
| 12:05 | <annevk> | eg, inputEncoding and xmlEncoding |
| 12:08 | <hsivonen> | which reminds me that I should extend Jing to pass the document's original encoding around totally in violation of sane layering |
| 12:09 | <zcorpan> | hsivonen: don't know |
| 12:10 | <zcorpan> | annevk: should i drop xmlEncoding and inputEncoding? only firefox supports those |
| 12:11 | <annevk> | oh really? ugh |
| 12:11 | <annevk> | XMLHttpRequest references one of them :/ |
| 12:11 | <annevk> | (that feature is not actually tested) |
| 12:11 | <zcorpan> | which one? |
| 12:11 | <hsivonen> | didn't DOM 3 specifiers look at what browsers already did? |
| 12:12 | <zcorpan> | hsivonen: evidently not |
| 12:12 | <annevk> | zcorpan, serializing Document for sending |
| 12:12 | <annevk> | hsivonen, nono, not at all |
| 12:12 | <hsivonen> | is the browser DOM exposed as a Java DOM anywhere? |
| 12:13 | <hsivonen> | is the Gecko DOM still available to applets or something? |
| 12:13 | <zcorpan> | annevk: xmlEncoding or inputEncoding? |
| 12:13 | <annevk> | input |
| 12:13 | <zcorpan> | ok |
| 12:13 | <zcorpan> | i'll drop xml* and see if anyone complains |
| 12:13 | <annevk> | hsivonen, there's this plan to make a new DOM spec for the Web |
| 12:14 | <annevk> | hsivonen, we keep the old spec around as standard for Java and to upset nobody, but the spec for browsers would be this other thing |
| 12:14 | <hsivonen> | annevk: my point is, will it break something that really assumes that the JDK DOM interfaces and the Web DOM interfaces match? |
| 12:15 | <annevk> | aah, dunno |
| 12:15 | <annevk> | they already diverge here and there so I don't think it matters much |
| 12:15 | <hsivonen> | I wonder if there will be demand for GWT wrapping the browser DOM in org.w3c.dom interfaces |
| 12:16 | <hsivonen> | I can imagine someone might want to be able to compile the same code on the server and on GWT |
| 12:16 | <zcorpan> | http://simon.html5.org/specs/web-dom-core |
| 12:17 | <hsivonen> | although GWT could probably fake the incompatible parts somehow |
| 12:18 | <zcorpan> | i've merged in dom2views |
| 12:18 | <zcorpan> | i'll drop all dom feature stuff except those that return booleans |
| 12:18 | <zcorpan> | (and are implemented) |
| 12:21 | <annevk> | dom2views is also merged in http://dev.w3.org/csswg/cssom-view/ |
| 12:21 | <zcorpan> | oh |
| 12:21 | <annevk> | including elementFromPoint |
| 12:21 | <zcorpan> | cool |
| 12:22 | <zcorpan> | dropped both |
| 12:23 | <annevk> | feel free to merge the exceptions from XMLHttpRequest and Web Workers in btw |
| 12:23 | <annevk> | if your spec moves fast enough we can just reference that then :) |
| 12:25 | <zcorpan> | done |
| 12:26 | <hsivonen> | ajaxian.com requires a New York Times -style registration in order to comment :-( |
| 12:28 | <hsivonen> | the MSDN custom tag namespace stuff is amusing |
| 12:28 | <hsivonen> | <HTML XMLNS:MY> |
| 12:28 | <hsivonen> | no URI value |
| 12:29 | <hsivonen> | is the documentation for creating MathPlayer and Renesis-compatible DOM nodes via script in IE? |
| 12:30 | <roc_> | hsivonen: Java can still access the Gecko DOM, I'm pretty sure |
| 12:31 | <roc_> | as can Flash |
| 12:31 | <hsivonen> | roc_: ok. |
| 12:31 | <roc_> | but not via the org.w3c.dom interfaces AFAIK |
| 12:31 | <hsivonen> | oh. |
| 12:31 | <hsivonen> | I expect the threading with Java is interesting |
| 12:32 | <roc_> | annevk: did you notice that we implemented ClientRect.width/.height on trunk? |
| 12:32 | <roc_> | the threading isn't really our problem |
| 12:33 | <roc_> | the Java plugin is moving to use NPRuntime scripting, the same plugin two-way scripting API that Flash uses |
| 12:33 | <annevk> | roc_, no, somehow missed that, was it a while ago? |
| 12:33 | <roc_> | I really have no idea how that looks on the Java side |
| 12:34 | <roc_> | annevk: actually very recent |
| 12:34 | hsivonen | was unaware of NPRuntime scripting |
| 12:35 | <annevk> | roc_, oh ok, I guess I need to add you or someone else to my bugzilla tracking preferences then :) |
| 12:35 | <roc_> | http://hg.mozilla.org/mozilla-central/rev/a612d3e553b2 |
| 12:36 | hsivonen | finds http://www.dessci.com/en/products/mathplayer/author/dynamic.htm#Scripting |
| 12:37 | <roc_> | Neil was really just trying to move scroll* and client* up to all elements, but also rolled in height and width |
| 12:37 | <annevk> | neat |
| 12:39 | <hsivonen> | will IE8 mode break these custom namespace ActiveX controls? |
| 12:39 | Philip` | wonders if it's possible for a CGI script to print raw HTTP headers via lighttpd, instead of it being parsed and reserialised before transmission |
| 12:41 | <roc_> | I'm still a bit nervous about returning fractional values from ClientRect. People see it and assume it's a bug. However, I still think it's the right thing to do and it doesn't seem to have caused any actual damage |
| 12:41 | <Philip`> | hsivonen: I think they're meant to still work in most cases, except for e.g. https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=333905 if you're using CSS to assign namespace behaviour |
| 12:43 | <hsivonen> | Philip`: can the <?IMPORT stuff be inserted via JS or does the parser need to see it literally? |
| 12:43 | <annevk> | roc_, the spec does say float :p |
| 12:44 | <hsivonen> | Microsoft, Renesis and DesignScience aren't particularly forthcoming about this |
| 12:44 | <Philip`> | hsivonen: Do you count document.write as being inserted via JS? |
| 12:44 | <hsivonen> | Philip`: I do |
| 12:44 | <hsivonen> | Philip`: although I'd like to have a purely parserless way |
| 12:45 | <hsivonen> | Philip`: document.write should be OK for packaging the V.nu parser as a JS shim |
| 12:45 | <hsivonen> | Philip`: however, for the HTML5 Live DOM, I'd like to have a fully scripted API |
| 12:47 | <Philip`> | gsnedders: It works fine if I put the <?import...?> in document.write |
| 12:47 | <Philip`> | Uh |
| 12:47 | <Philip`> | s/gsnedders/hsivonen/ |
| 12:48 | <hsivonen> | Philip`: OK. thanks |
| 12:48 | <hsivonen> | Philip`: do you know if it persists if the document contents are removed after that? |
| 12:49 | <hsivonen> | does IE even support emptying the document and inserting a new root? |
| 12:50 | <Philip`> | hsivonen: You can also do document.namespaces.add('v', 'http://www.w3.org blah blah it doesn\'t matter what you put here', '#default#VML'); |
| 12:50 | <hsivonen> | Philip`: excellent. thanks |
| 12:51 | <Philip`> | http://msdn.microsoft.com/en-us/library/ms535932(VS.85).aspx - woah, it's even documented |
| 12:52 | <zcorpan> | hsivonen: it does so long as the new node is html and you use replaceChild (iirc) |
| 12:53 | <hsivonen> | zcorpan: thanks. (the HTML5 Live DOM doesn't use replaceChild) |
| 12:54 | Philip` | discovers a new way to crash IE8 |
| 12:54 | <zcorpan> | hsivonen: or wait, you can empty the document and then append a new child, too |
| 12:54 | <zcorpan> | hsivonen: but you can't just empty the document and leave it empty |
| 12:55 | <hsivonen> | zcorpan: how can it force me to insert something and not leave it empty? |
| 12:59 | <Philip`> | http://philip.html5.org/tests/ie8/cases/document-close.html - yay for IE8 |
| 13:05 | <zcorpan> | hsivonen: it throws if you don't insert anything |
| 13:05 | <zcorpan> | hsivonen: and leaves it in the state it was before emptying |
| 13:06 | <hsivonen> | zcorpan: ah. |
| 13:06 | <hsivonen> | (without testing, I'm assuming this is one of those weird situations where the scripted view to the DOM and the engine understanding of the DOM are synced only upon spin through the event loop) |
| 13:08 | <zcorpan> | Philip`: what happens? |
| 13:10 | <Philip`> | zcorpan: IE8b2 just freezes permanently |
| 13:11 | <Philip`> | While trying to report the bug, something's broken Opera so it's using 100% CPU and making my fans very loud, but at least Opera is still being responsive |
| 13:12 | <Philip`> | (To be more specific, IE8b2 freezes permanently and uses 100% CPU too) |
| 13:13 | <Philip`> | (To be more accurate, IE8b2 freezes permanently and uses 100%-divided-by-number-of-CPU-cores CPU too) |
| 13:21 | <annevk> | btw, http://tc.labs.opera.com/html/img/usemap/001.htm demonstrates that name in combination with usemap is not affected, despite usemap taking a URL reference originally... |
| 13:22 | <annevk> | tested in Firefox 3, Internet Explorer 6, and Opera 9.5 |
| 13:25 | <zcorpan> | annevk: matches the spec |
| 13:25 | <annevk> | right |
| 13:26 | <annevk> | just wondering name can always be normalized or not |
| 13:26 | <annevk> | ^^ whether |
| 13:29 | <Philip`> | hsivonen: http://hsivonen.iki.fi/introducing-sax-tree/ - s/in and/in an/ |
| 13:30 | annevk | was just about to mention that |
| 13:41 | Philip` | wonders what's the most efficient way to read a load of HTML pages from disk |
| 13:41 | <Philip`> | I suppose the best way is to not actually read them from disk, so if I can compress them so they'll fit in RAM then that'd be good |
| 13:41 | <zcorpan> | can i drop normalize() and normalizeDocument() from dom core? |
| 13:41 | <Philip`> | but then I'll probably want more pages until it's too much to fit in RAM again :-( |
| 13:45 | <annevk> | zcorpan, prolly |
| 14:01 | <annevk> | hahaha, http://lists.w3.org/Archives/Public/public-html/2008Sep/0175.html |
| 14:02 | <annevk> | the original message was already pointless, and now it's more |
| 14:02 | <annevk> | amazing |
| 14:02 | zcorpan | drops setAttributeNodeNS |
| 14:02 | <hasather> | annevk: :D |
| 14:06 | zcorpan | adds Element.children |
| 14:07 | <annevk> | zcorpan, you have time to work on this now? |
| 14:07 | <annevk> | zcorpan, also, when say "add" you mean "add in local copy"? |
| 14:08 | <zcorpan> | annevk: yes and yes :) |
| 14:08 | <annevk> | great and not so great :) |
| 14:11 | <zcorpan> | hmm, children is an HTMLCollection |
| 14:12 | <zcorpan> | layering problem |
| 14:12 | <annevk> | I once heard Ian suggest HTMLCollection should be part of the DOM specs |
| 14:12 | <zcorpan> | but under another name? |
| 14:12 | <annevk> | no |
| 14:12 | <zcorpan> | ok |
| 14:13 | <annevk> | but having references from DOM Core to HTML5 and vice versa doesn't seem bad eiter |
| 14:13 | <annevk> | either* |
| 14:14 | <zcorpan> | i think dom core should be standalone |
| 14:14 | <zcorpan> | but for now i'll reference html5 |
| 14:14 | <annevk> | i agree with the sentiment, not sure if it'll work out |
| 14:18 | <zcorpan> | uploaded new revision |
| 14:22 | <annevk> | any chance you can do HTML5/XMLHttpRequest-style IDL fragments rather than oldschool-DOM-spec-style IDL fragments? |
| 14:23 | <annevk> | eg, dropping "raises(DOMException)", dropping a lot of space characters and newlines |
| 14:24 | <zcorpan> | yeah i'll clean it up second-pass |
| 14:25 | <annevk> | you should prolly also keep some notes in the source of what is left out for now |
| 14:25 | <annevk> | at least, I would find that useful |
| 14:27 | <zcorpan> | ok |
| 14:53 | <zcorpan> | r3: add comments about what is dropped; added Text, Comment, DocumentType, ProcessingInstruction |
| 14:53 | <zcorpan> | i think i have all interfaces now; is there something i've missed? |
| 14:56 | <annevk> | all the interfaces you want I assume? several interfaces appear to be dropped |
| 14:57 | <annevk> | DocumentPosition is needed fwiw; we recently had to add support for that |
| 15:00 | <zcorpan> | yeah. ok |
| 15:06 | <annevk> | http://validator.nu/?doc=http%3A%2F%2Ftc.labs.opera.com%2Fhtml%2Fimg%2Fusemap%2F002.htm ? |
| 15:06 | <annevk> | hmm |
| 15:07 | <zcorpan> | map is flow content |
| 15:08 | <zcorpan> | perhaps it should be changed to transparent phrasing? |
| 15:11 | <annevk> | I feel to see a good reason for why I should move the <map> out of the <p> |
| 15:15 | <annevk> | wow, fail |
| 15:21 | <annevk> | in case people were not convinced that proprietary is bad: http://uk.techcrunch.com/2008/09/04/startups-in-chaos-as-adobes-flashpaper-discontinues/ |
| 15:24 | <smedero> | It feels like an edge use-case but is there a reason to allow <map> inside of <p> for something like a sparkline with an image map that had pointers to expanded info about different data points? (http://en.wikipedia.org/wiki/Sparkline) |
| 15:24 | <smedero> | (i'm trying to bring up the whatwg list to see if that has been brought up before, but uh.. it is list.whatwg.org isn't responding for me...) |
| 15:26 | <smedero> | (ahh, now it is) |
| 15:27 | <zcorpan> | since <map> doens't behave like a block in the parser it feels unintiutive to disallow it in p |
| 15:28 | <zcorpan> | (and it's rendered inline) |
| 15:28 | <zcorpan> | (iirc) |
| 16:14 | <zcorpan> | Hixie: why is "pre, code { font-size: inherit;" in http://www.whatwg.org/style/specification ? |
| 17:10 | <Philip`> | How lovely - BeautifulSoup is giving me a <div> element whose parent is a <div> element whose only child is an <a> element |
| 17:12 | <Philip`> | Also, html5lib fails a zillion tests, so there's no way I can change anything without being quite likely to unknowingly introduce a regression |
| 17:42 | <Dashiva> | So earlier it was all "@headers is only used in generated content, so it doesn't matter that it's complex and easy to mess up" and today it's "but the USER wants to use @headers in handwriting, so we should let him" |
| 17:49 | <takkaria> | http://mail.gnome.org/archives/xml/2008-September/msg00018.html -- icky |
| 17:57 | <smedero> | Dashiva: Well it is also funny because Gez said he modified his example to "simplify the problem" |
| 17:58 | <smedero> | I don't think he redesigned it.... but it was modified in some form and I asked for a pointer the original so I can understand what was changed and I got zilch. |
| 17:58 | <smedero> | (it wasn't just changes to anonymize the data... columns and such were removed to "make it easier to understand") |
| 17:59 | <Dashiva> | Simplify the problem of getting people to accept it |
| 18:25 | <sicking> | annevk, ping |
| 18:37 | <smedero> | FWIW, Gez got me a pointer to the unmodified complexdatatable example: http://juicystudio.com/wcag/tables/altcomplex.html |
| 18:38 | <smedero> | (More or less, includes extra columns at the end...) |
| 18:42 | <hsivonen> | whoa. Renesis has an ASV compat Quirks Mode |
| 19:06 | <hsivonen> | how do I create an element in IE via JS with a particular scopeName and tagUrn? |
| 19:07 | <Philip`> | Maybe by declaring a prefix with namespaces.add(...) and then createElement('prefix:name')? |
| 19:07 | Philip` | doesn't know any other way |
| 19:08 | <hsivonen> | Philip`: thanks |
| 19:28 | <hsivonen> | Philip`: that works |
| 19:28 | <hsivonen> | to the point of getting scopeName and tagUrn right |
| 19:29 | <hsivonen> | can I associate the scope name with an ActiveX control without inserting an <object> into the document? |
| 19:33 | <hsivonen> | giving a clsid: URL as the third parameter of namespaces.add does not work |
| 19:37 | <Lachy> | I don't know how to make it any clearer to John Foliot, he seems to be totally missing the point of what I'm saying |
| 19:38 | <Lachy> | I don't get why he can't comprehend that the proposed study is about seeing how effective longdesc is for users that currently have the ability to access it, nor why he doesn't understand why that would be useful |
| 19:45 | <hsivonen> | it seems crazy if <?import has a JS equivalent but <object>-based ActiveX hook doesn't |
| 19:46 | <hsivonen> | Philip`: "in and" fixed. thanks |
| 19:47 | <hsivonen> | Philip`: HtmlParser Javadoc fixed locally. thanks |
| 19:56 | <Dashiva> | What? There are AT apps that don't expose longdesc? |
| 19:57 | <webben> | Dashiva: There are AT apps that don't do ... lots of things. |
| 19:58 | <webben> | Dashiva: JAWS has exposed it since version 4.something. |
| 19:58 | <webben> | although in some recent versions, you've had to enable announcements for it. |
| 19:58 | <Hixie> | Lachy: as far as i can tell he's not interested in improving accessibility, only in sounding like he's an expert and getting his ego stroked by getting his way |
| 19:58 | <webben> | Dashiva: that behavior appears to have changed back to announcing by default in current JAWS 10 Beta. |
| 19:59 | <Lachy> | Hixie, fair enough. But honestly, did you clearly understand what the purpose of my proposed study, and why it would be useful? |
| 20:00 | <Lachy> | I just want to make sure its not me who's missing something |
| 20:00 | <Dashiva> | webben: Wasn't it so that most JAWS users rarely, if ever, upgraded? So if it's gone in the latest version, it's not a big deal |
| 20:01 | <webben> | Dashiva: "most". I'm not sure that's true. Certainly the lag time for upgrades is greater for commercial AT at hundreds of $ a shot than for free web browsers. |
| 20:01 | <Hixie> | Lachy: yes |
| 20:02 | <Hixie> | Lachy: your proposal was exactly the kind of study we need to get objective data |
| 20:02 | <webben> | Dashiva: I'm not sure what the referent of "gone" is though. |
| 20:02 | <Dashiva> | webben: default announcement |
| 20:02 | <Hixie> | Lachy: though next time i would phrase your hypothesis to sound like you agree with the side that isn't yours |
| 20:03 | <Hixie> | Lachy: since the hypothesis doesn't matter (we get the same results either way) and the people who are clearly unable to understand how to do research would at least not get a knee jerk reaction against you |
| 20:03 | <Philip`> | Now all we need is infinite resources so we can carry out reliable user studies without worrying about their cost |
| 20:04 | <Dashiva> | Hixie: They'd probably knee-jerk just from the from address |
| 20:04 | <webben> | Dashiva: No. It's the other way round, I think. Default announcement has come _back_. |
| 20:04 | <Philip`> | Hixie: But then they'll say the hypothesis is self-evident and there's no point doing new studies on it |
| 20:04 | <Dashiva> | So it was added, removed and then re-added? Quirky |
| 20:05 | <Lachy> | Hixie, ok. I'll keep that in mind. I'm rewriting it as clearly as I possibly can so that there can be absolutely no confusion about what I mean |
| 20:05 | <webben> | Lachy: FWIW I agree that your proposed study would be a very good addition to information collected so far, though I don't think studies of this (human-tech interactions) sort tend to produce "irrefutable" results. |
| 20:05 | <Lachy> | webben, ok, fair enough. |
| 20:06 | <Hixie> | Philip`: then you just respond "well then you wouldn't object to a study would you" |
| 20:06 | <Hixie> | studies never provide irrefutable results |
| 20:06 | <Lachy> | webben, my point was that the results would take us from having only observation and hypothesis closer to having a theory |
| 20:06 | <Hixie> | they can always be refuted by more studies that contradict them |
| 20:06 | <webben> | Hixie: Absolutely. It's not my word. |
| 20:07 | <Philip`> | Hixie: They should object to resources being spent on that study instead of on something more interesting and informative and insightful |
| 20:11 | <hsivonen> | does IE support adding methods to Element prototype? |
| 20:11 | <Hixie> | as i understand it IE doesn't have prototypes |
| 20:12 | <hsivonen> | Hixie: IIRC, it does have for objects that don't count as host objects |
| 20:12 | <hsivonen> | like Array.prototype |
| 20:12 | <webben> | Lachy: I think a useful addition to your proposed study would be to try and work out, if there's a difference, why. |
| 20:12 | <hsivonen> | I know this stuff is not supported for ActiveX-based XHR DOM nodes |
| 20:12 | <hsivonen> | I guess I should just test |
| 20:13 | <Lachy> | webben, any suggestion how? |
| 20:13 | <webben> | Lachy: well, qualitative observation during the process and asking people at the end would help I guess. |
| 20:13 | <Hixie> | hsivonen: right i mean for host objects |
| 20:13 | <Lachy> | ok |
| 20:14 | <Hixie> | hsivonen: i take it your validator instance wouldn't be able to handle the load of a google blog pointing at it? |
| 20:14 | <hallvord> | hsivonen: AFAIK Element.prototype and friends is coming in the very latest beta of IE8 |
| 20:14 | <hallvord> | ..well, should have used past tense: came .. thing is I haven't tested it yet :) |
| 20:15 | <webben> | Lachy: e.g. this might uncover whether (for example) people don't use longdesc because they don't expect it to work because of bad UA implementation (as with the guy in Joshue's video) or whether (for example) they miss the description link because of their navigation strategy. |
| 20:15 | <Hixie> | hallvord: really? wow |
| 20:15 | <hsivonen> | Hixie: it probably wouldn't handle it :-( |
| 20:15 | <Hixie> | k |
| 20:15 | <webben> | Hixie: Couldn't Google host an instance of it (if that were okay with hsivonen)? |
| 20:16 | <hsivonen> | it would be interesting to see how badly it would melt down, though :-) |
| 20:17 | <Hixie> | webben: hsivonen might be able to port it to appengine, i don't know |
| 20:17 | <hsivonen> | Hixie: if you had appengine for Java... |
| 20:17 | <hsivonen> | which I suspect Google already has internally for deploying its own Java-based apps |
| 20:18 | <Hixie> | i don't think we've deployed any java-based apps on appengine |
| 20:18 | <Hixie> | i don't know what the plan is for that team, either, so i don't even know if java is on the cards :-) |
| 20:18 | <hsivonen> | Validator.nu is well-suited for scaling on an infrastructure that replicates the app automatically |
| 20:19 | <hsivonen> | after all, it doesn't need write storage except for logs |
| 20:19 | <hsivonen> | and it doesn't need a login mechanism |
| 20:20 | <hsivonen> | so it could be put on a cloud computing platform without the usual BigTable or Amazon SimpleDB lock-in issues |
| 20:20 | <hsivonen> | it does have the issue that it wants to do *a lot* of initialization up front to build read-only data structures that are shared among threads |
| 20:21 | <hsivonen> | I figured that Validator.nu on a usual day requires less CPU and RAM than one EC2 compute unit provides |
| 20:22 | <hsivonen> | so currently, it doesn't make sense to invest in automatic scaling on EC2 |
| 20:23 | <hsivonen> | hallvord: thanks. |
| 20:24 | <hsivonen> | I'm trying to come up with a way to route setAttributeNS calls to something else in IE without imposing a per-call cost on other browsers |
| 20:25 | <hsivonen> | Hixie: I've been speculating about what's next for App Engine |
| 20:26 | <hsivonen> | Hixie: and since Google has a small set of supported languages, Java is the obvious runner up after Python |
| 20:26 | <Hixie> | that does seem like a good guess |
| 20:26 | <Hixie> | (i really don't know what that team is doing) |
| 20:26 | <hsivonen> | Hixie: but I figured providing App Engine for Java would need new restrictions on the VM |
| 20:26 | <hsivonen> | and probably a class loading model that isn't transparently compatible with a normal JVM |
| 20:27 | <smedero> | mostly unrelated but there's a 20% project going to get Perl into App Engine... so there's a chance that Java could be a 20% as well. |
| 20:27 | <hsivonen> | but I wouldn't be too surprised if Google hacked up yet another environment that uses the Java language without the full JVM runtime semantics |
| 20:30 | <hallvord> | hsivonen: see |
| 20:30 | <hallvord> | http://www.microsoft.com/windows/internet-explorer/beta/readiness/developers-new.aspx#mutabledom |
| 20:30 | <hallvord> | http://www.quirksmode.org/blog/archives/2008/09/ie8b2_roundup.html |
| 20:30 | <hsivonen> | smedero: I'd expect Java to require more drastic VM hacking than Perl |
| 20:30 | <smedero> | indeed. |
| 20:30 | <hsivonen> | hallvord: thanks |
| 20:33 | <Hixie> | "comments are HTMLCommentElement interfaces and inherit from Element" lol |
| 20:34 | <Hixie> | "Early on, we had to decide if we wanted to implement a "fake" layer for the constructor/prototype objects that looked identical to the W3C model, or to expose what we had, warts and all." |
| 20:34 | <Hixie> | ...and they picked the warts... because of their commitment to standards? |
| 20:35 | <hsivonen> | "Object doesn't support this property or method" |
| 20:35 | <hsivonen> | sigh |
| 20:35 | <hsivonen> | I'd appreciate it if IE said which property |
| 20:36 | <Hixie> | this one |
| 20:36 | <Hixie> | duh |
| 20:39 | <hsivonen> | anyway, I think this HTML5 parsing thing can be programmed on top of IE eventually, although I'm failing ATM |
| 20:39 | <hsivonen> | my proof of concept does work: http://hsivonen.iki.fi/test/moz/ie-namespaces.html |
| 20:39 | <hsivonen> | now if WebKit rendered dynamically inserted SVG... |
| 20:41 | <webben> | hsivonen: What are you trying to do exactly? |
| 20:41 | <webben> | implement a HTML5 parser as an activex control? |
| 20:42 | <hsivonen> | webben: I'm trying to emulate createElementNS for MathML and SVG namespaces in IE7+MathPlayer+Renesis |
| 20:42 | <hsivonen> | webben: so that the Validator.nu HTML Parser when compiled with GWT could work in IE as well |
| 20:43 | <webben> | ah okay |
| 21:36 | <hsivonen> | reloading my test page crashes IE7 |
| 21:50 | <zcorpan> | hsivonen: iirc, attributes can't be namespaced in ie, though i don't know how the plugins handle it |
| 21:50 | <Lachy> | Hixie, webben yt? |
| 21:51 | <Lachy> | Hixie, webben, anyone else, could you review this before I send it? http://lachy.id.au/temp/study.txt |
| 21:55 | <webben> | Lachy: I think the distinction between a user agent requiring users to change their configuration to be aware of long descriptions (e.g. earlier versions of JAWS) and announcing them by default (e.g. current JAWS 10 Beta on reading, iCab on hover) is significant. |
| 21:56 | <webben> | although I realize John only says "natively support" in the quote. |
| 21:57 | <Lachy> | webben, I wasn't aware of that. What should I say about it? |
| 21:59 | <webben> | Lachy: I guess a prelude to this study would need to be some sort of agreement about what a decent implementation of longdesc might do and whether any current implementations do it. |
| 21:59 | <webben> | If none do, you'd need to introduce an test implementation that does (e.g. by hacking NVDA perhaps). |
| 21:59 | <Lachy> | I was just going to have the test run with each user's normal software and setup, to make it as realistic as possible |
| 22:00 | <webben> | realistic to what? |
| 22:02 | <Lachy> | to the way they use it use it normally |
| 22:02 | <Lachy> | it would be a bit unfair to have the test performed by a user who is unfamiliar with the software being used |
| 22:03 | <webben> | Lachy: I agree that it introduces other complications. But I don't think a test of bad implementations would tell one much about the actual point at issue (at least from my understanding of the point at issue). |
| 22:04 | <webben> | Lachy: So I guess I'm saying you _might_ have to take software users are familiar with and modify it somewhat. |
| 22:04 | <webben> | I'm not saying: make a brand new screen reader or browser or something ;) |
| 22:06 | <Lachy> | I don't like that idea, because that would require informing the user of what changes have been made, which would bias the results due to having additional information about the test that they would not otherwise have |
| 22:07 | <webben> | Lachy: Hmm. Couldn't you tell them that you've modified it but not tell them how? |
| 22:07 | <Lachy> | in what way would you want to modify it? |
| 22:07 | <webben> | for that matter, actually, what's wrong with them knowing about the feature? |
| 22:08 | <webben> | otherwise you're not just testing whether the feature can do a given task, but also the initial intuitiveness of the feature's presentation, which could bias the study in both directions |
| 22:09 | <Lachy> | because if the users didn't know about the longdesc before hand, and are supposedly representative of the general population, then informing them about the feature would influence the result |
| 22:09 | <webben> | e.g. people might think, hmm, what's this long description thing, must try that. or people might think, hmm, dunno what that is, better not try that. |
| 22:10 | <webben> | yes, but you're not trying to test people's knowledge of features, as far as I can tell. |
| 22:10 | <Lachy> | I'm trying to test how useful a feature is in practice given the current, near the top of the range ATs |
| 22:11 | <webben> | okay, but that's not the actual point being debated. |
| 22:12 | <webben> | Lachy: again, that's basically testing implementations not the concept. |
| 22:14 | <Lachy> | hmm. ok. So then we would have to set a baseline for the ATs that can be used. |
| 22:14 | <webben> | Lachy: yeah, exactly, it very much depends on working out what a "good" implementation would do. |
| 22:15 | <webben> | which isn't necessarily trivial. |
| 22:15 | <Lachy> | fair enough. I suppose that's fair given how we would test the proposed headers algorithm |
| 22:15 | <Lachy> | which would need modified UAs/ATs to do it |
| 22:15 | <webben> | that is to say, it's easy to distinguish very bad from better implementations, but hard to distinguish very good from better implementations. |
| 22:16 | <webben> | e.g. Firefox native longdesc implementation is pants. the longdesc firefox add-on clearly improves it. |
| 22:16 | <webben> | iCab is an improvement again (because of the on-hover indicator). |
| 22:17 | <webben> | - that's for sighted users. |
| 22:17 | <webben> | I'm pretty sure that defaulting to announcing longdesc is "better" than defaulting to not announcing it. |
| 22:19 | <Lachy> | I added a paragraph saying "We need to set a set of baseline feature requirements for the assistive technologies that can be used. I'll leave this for those who are more familiar with them," |
| 22:26 | <Lachy> | I sent it |
| 22:36 | <annevk> | 'Jonas Jacobi, Kaazing’s CEO, will be delivering a three day course through Kaazing’s partnership with SkillsMatter in London on October 6th, 2008. The course is entitled “Comet Evolved: HTML 5 Web Sockts & Server-Sent Events.”' -- http://thepeninsulasedge.com/blog/?p=156 |
| 22:36 | <annevk> | for features with no browser implementations, that's pretty impressive |
| 22:44 | <annevk> | hsivonen, http://www.tbray.org/ongoing/When/200x/2003/12/13/MegaXML (credit: tag) |
| 22:53 | annevk | added it to http://wiki.whatwg.org/wiki/Namespace_confusion |
| 23:17 | <Hixie> | we want to test implementations and not the concept |
| 23:18 | <Hixie> | because users interact with the implementations, not the concepts |
| 23:20 | <Lachy> | Hixie, yeah. But we should let them use the optimal implementation. If the beta of jaws 10 notifies the user by default as webben said, then that's fair enough |
| 23:21 | <Lachy> | making them use implementations they know to be flawed isn't likely to be accepted |
| 23:21 | <webben> | Hixie: Testing implementations is a worthwhile activity as long as one is clear about what that actually means. |
| 23:23 | <Lachy> | but I agree, modifying the implementation well beyond would be considered a typical setup to could bias the results too much, so there needs to be limits |
| 23:24 | <webben> | I suspect that radical implementations aren't necessary, but I'm not quite sure what other people's view of an optimal implementation would be. |
| 23:25 | <Lachy> | I would prefer it to be a near default setup, with additional options only set based on each users' normal configuration |
| 23:26 | <webben> | e.g. I think JAWS 10 Beta seems reasonable for a blind user (not sure about deafblind) and iCab 4.x seems reasonable for a mouse-wielding sighted fellow. |
| 23:26 | <webben> | the problem with JAWS 10 Beta is ... it's beta. |
| 23:26 | <Lachy> | how is iCab considered assistive technology? |
| 23:28 | <webben> | From my perspective, these are just tools and sets of tools users with various abilities use to consume content. |
| 23:28 | <Lachy> | but they need to be users for whom long descriptions are considered the most useful |
| 23:29 | <webben> | I don't think long descriptions are necessarily more useful to blind people than colorblind people etc. |
| 23:29 | <Lachy> | John's complaint is that since no-one uses longdesc on the web, and because it's a relatively new feature in ATs, most users don't know about it, nor query for it. |
| 23:30 | <Lachy> | While I see that as a fundamental flaw with its design, he seems to think there is hope for it |
| 23:31 | <webben> | longdesc (as opposed to long descriptions) is useful (well, in _theory_) to people navigating non-linearly or any other case where you might want automatic extraction |
| 23:32 | <Lachy> | but if the default configuration was to notify the user about its presence, then that could potentially fix one of the problems. But I'm still not sure how to fix the problem of authors not using it |
| 23:33 | <webben> | I think that's like trying to fix the problem of Flickr not using alt. |
| 23:33 | <webben> | Lachy: In so far as authors might _want_ to use it, they've repeatedly been given guidance not to use it because of broken implementations. |
| 23:34 | <webben> | I think that guidance was wrong (because facilitating programmatic association is helpful, I think). |
| 23:34 | <webben> | I also agree that providing links to things or including descriptions on the page is good. |
| 23:36 | <Lachy> | I'm just not convinced that longdesc has any advantages over ordinary links, and ordinary links have the benefit of being available to everyone |
| 23:38 | <webben> | Lachy: I'm quite interested, on behalf of _future_ user agents, in potential mechanisms to avoid redundancy during linear processing while still facilitating the automatic addition of context during non-linear processing. |
| 23:38 | <webben> | though I think link text is a much more important case for this than img/longdesc |
| 23:38 | <Hixie> | authors do use longdesc |
| 23:38 | <Hixie> | but they almost uniformly use it in harmful ways |
| 23:39 | <webben> | Hixie: I suspect if more implementations were like iCab there would have been less harmful use. Hard to prove though :) |
| 23:40 | <webben> | Hixie: It might be interesting to know why authors who did things wrong, did things wrong. |
| 23:41 | <webben> | the most confusing aspect of longdesc seems to be that it's a URI. I guess better naming might have helped there - descriptionref or something. |
| 23:42 | <Lachy> | what does iCab do exactly? |
| 23:43 | <webben> | Lachy: 1. If you hover over an img with longdesc it changes the cursor to a arrow with a little doc icon. (iCab uses cursor hints for various things.) |
| 23:46 | <webben> | 2. If you open the context menu on such an img, one of the options is Show long description of Image. If you click that, it opens the referenced URL in a new window. (not that keen on the new window as opposed to new tab business myself, but there we go) |
| 23:46 | <webben> | So it's roughly similar to (say) viewing an image in its own tab in Firefox. |
| 23:46 | <Hixie> | is the description more useful than just zooming the image and giving a high-contrast vie? |
| 23:46 | <Hixie> | view |
| 23:47 | <webben> | Hixie: I'd imagine that would depend on the image and the user. |
| 23:48 | <Hixie> | can you name a case where an author would create a description that was detailed enough that it was more useful than zooming the picture? |
| 23:49 | <webben> | well, where the picture isn't very good to start with would be one example. |
| 23:49 | <webben> | i'm not sure how good high-contrast conversions are. |
| 23:49 | <Hixie> | wouldn't a description in such cases be better given inline for everyone to enjoy? |
| 23:49 | <webben> | i.e. how bad the information loss is |
| 23:50 | <Hixie> | seems to me that whenever an image could be described in detail, that the description becomes generally useful and should just be an integral part of the page, not hidden away in a dedicated attribute |
| 23:50 | <Lachy> | webben, I don't think low such quality images are a typical use case |
| 23:51 | <webben> | Hixie: dedicated attributes are an integral part of the page. |
| 23:51 | <webben> | Hixie: Where are the visible links to open images in their own tab? Or print them? Or download them? Or copy them to the clipboard? |
| 23:51 | <Lachy> | I agree with Hixie. I think it would be better to encourage authors to provide information about images designed for everyone, which has the effect of helping those who can't see the image well either |
| 23:51 | <Hixie> | webben: there's no markup for those either |
| 23:52 | <webben> | Hixie: Sure there is. It's called src. |
| 23:52 | <Hixie> | webben: well then linking to a description on another page is called <a href=""> and including a description inline is called <p>...</p>. |
| 23:53 | <Lachy> | sure, but src isn't meant to be human consumable information. The image is |
| 23:53 | <webben> | Lachy: likewise with the description. |
| 23:53 | <Hixie> | webben: basic language design -- accessibility should be inherent, people don't think about it and if you make it separate they will screw it up. |
| 23:53 | <Hixie> | anyway |
| 23:53 | <Lachy> | <a href="description"><img src="foo"></a> |
| 23:53 | <Hixie> | longdesc="" has been shown to be a lost cause |
| 23:54 | <Hixie> | unless new information comes along, there's no point arguing it |
| 23:55 | <webben> | Hixie: Well, yeah I just don't buy the "shown" bit. Can't really help that. :) |
| 23:55 | <Hixie> | have you read http://blog.whatwg.org/the-longdesc-lottery ? |
| 23:55 | <webben> | yeah |
| 23:55 | <Hixie> | well if you don't think that shows it's a lost cause, i don't know what to tell you |
| 23:56 | <webben> | Hixie: Yes, I don't see how you can separate the concept from the implementations and the guidance given. |
| 23:56 | <webben> | *how you can't, rather |
| 23:57 | <Hixie> | doesn't matter what the implementations do |
| 23:57 | <Hixie> | over 96% _of images with longdesc_ have bogus longdesc |
| 23:57 | <webben> | I think that statistic is heavily determined by the implementations and the guidance given. |
| 23:57 | <Hixie> | there is no implementation stategy that can turn crap into usable content |
| 23:58 | <Hixie> | that statistic is actual web content. |
| 23:58 | <Hixie> | doesn't matter what causes it |
| 23:58 | <Hixie> | it's already caused. |
| 23:58 | <Hixie> | we could argue about whether to introduce a _new_ attribute |
| 23:58 | <Hixie> | and maybe implementations could support that better and we could avoid this problem |
| 23:58 | <webben> | Hixie: Oh, yeah, when I'm talking about the "concept", I'm talking about the "concept". |
| 23:59 | <Hixie> | however, one has to wonder why it would take 10 years for implementations of longdesc="" to come along, if it's such a great idea |
| 23:59 | <webben> | Hixie: iCab's implementation has been around longer than that. |
| 23:59 | <webben> | it's not a recent innovation I mean |
| 23:59 | <webben> | what i'm not clear about is when JAWS didn't read longdesc by default and why |