/irc-logs / w3c / #html-wg / 2007-08-20 / end

Options:

# Session Start: Mon Aug 20 00:00:00 2007
# Session Ident: #html-wg
# [00:30] * Parts: hasather (hasather@80.203.71.22)
# [00:57] * Quits: heycam (cam@203.214.42.247) (Ping timeout)
# [01:08] * Quits: zcorpan_ (zcorpan@84.216.41.166) (Ping timeout)
# [01:18] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [01:23] * Joins: gavin_ (gavin@74.103.208.221)
# [01:24] * Joins: heycam (cam@130.194.72.84)
# [02:26] * Quits: aroben (adamroben@67.160.250.192) (Quit: aroben)
# [03:05] * Quits: tH (Rob@87.102.94.41) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
# [03:35] * Joins: olivier (ot@128.30.52.30)
# [03:37] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [03:41] * Joins: karl (karlcow@128.30.52.30)
# [04:14] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
# [04:45] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [04:50] * Quits: karl (karlcow@128.30.52.30) (Ping timeout)
# [04:53] * Joins: karl (karlcow@128.30.52.30)
# [04:56] * Joins: olivier (ot@128.30.52.30)
# [05:00] <mjs> is anyone else having trouble reaching dev.w3.org?
# [05:01] <karl> yep
# [05:02] <karl> mjs: I just passed the information to the system team. Though it is sunday you should not be working :p
# [05:03] <karl> it is being restarted
# [05:05] <karl> mjs: dev.w3.org working
# [05:06] <mjs> karl: seems happy now, thanks
# [05:07] <mjs> karl: web standards work is my hobby, not my job :-)
# [05:07] * olivier grumbles about apache2 not being a happy puppy lately
# [05:19] <mjs> karl: now I'm having trouble accessing the ESW wiki
# [05:20] * Joins: aroben (adamroben@67.160.250.192)
# [05:53] <olivier> mjs: esw wiki is being hammered by stupid bots again, it seems
# [05:54] <mjs> olivier: ugh
# [05:54] <olivier> load average: 45.87, 45.23, 29.87
# [05:54] <mjs> ok I'll stop editing for now
# [05:54] <olivier> hopefully it's just a short burst
# [05:58] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [06:16] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [06:21] * Joins: gavin_ (gavin@74.103.208.221)
# [07:01] * Joins: Zeros (Zeros-Elip@67.154.87.254)
# [07:26] <karl> http://www.w3.org/2000/09/dbwg/details?group=40318&public=1
# [07:26] <karl> Roy T. Fielding has joined the HTML WG
# [07:26] <sbuluf> on answer to the http thing
# [07:26] <sbuluf> see tag list
# [07:27] <karl> sbuluf: yes I have seen the tag list
# [07:28] <karl> "It isn't infeasible. It happens immediately after any such page
# [07:28] <karl> fails to render correctly, either in the form of an obvious error
# [07:28] <karl> message or a consistent save-as dialog, when that page is viewed
# [07:28] <karl> by the person authoring or maintaining the website. The problem
# [07:28] <karl> is not the standard, it is not the algorithm, and it is not HTML.
# [07:28] <karl> The problem is the ridiculously lame excuses that some vendors make
# [07:28] <karl> in the face of the predominant unreliable browser, MSIE, failing
# [07:28] <karl> to note errors when a page is tested." -- http://lists.w3.org/Archives/Public/www-tag/2007Aug/0034.html
# [07:29] <sbuluf> right
# [07:29] <Zeros> heh
# [07:29] <Zeros> catch 22
# [07:30] <Zeros> It would be interesting if browsers showed a "This page isn't valid, it may not render correctly" type dialog like MS Word would display about a damaged or corrupted file. I wonder how much error correction goes on in applications like that silently. What's an acceptable threshold?>
# [07:31] <karl> the reasoning is that "beware when you change things because you will break other applications (citizens) of the Web"
# [07:33] * karl has yet to reply the survey on design principles
# [07:34] <mjs> the premise that one browser displaying an error message would lead to content being fixed is clearly false
# [07:34] <hsivonen> browsers don't sniff for fun. they sniff because Apache has been uncooperative with fixing the problem: http://issues.apache.org/bugzilla/show_bug.cgi?id=13986
# [07:35] <karl> hehe mjs, I think that Roy is just saying that there is more than only Web browsers on the Web.
# [07:36] <mjs> he said "The problem is the ridiculously lame excuses that some vendors make in the face of the predominant unreliable browser, MSIE, failing to note errors when a page is tested."
# [07:36] <mjs> is he talking about some other vendors besides browser vendors?
# [07:36] <Zeros> mjs, If google caused dialog every time the page loaded that said "This page isn't valid and may not work correctly" it'd get fixed.
# [07:36] <karl> and the premise of content being fixed, we have at least one example where it has been done.
# [07:36] <Zeros> The dialog would get very annoying to users very quickly
# [07:36] <mjs> Zeros: yes, if google popped up a dialog like that, google would quickly get fixed
# [07:37] <karl> many stylesheets were identified as text/plain, Netscape sticked to text/css, webmasters fixed their web sites.
# [07:37] <mjs> to not pop up such a dialog
# [07:37] <Zeros> yes, they'd need to make the page valid
# [07:37] <Zeros> since the dialog would be generated by all the browsers
# [07:37] <mjs> karl: I spend all day dealing with sites that don't work in Safari where in many cases they clearly didn't do even the most minimal testing
# [07:37] <hsivonen> karl: standards mode only
# [07:38] <hsivonen> karl: text/css that is
# [07:38] <Zeros> Much like Word says a document is corrupted and data might be lost, or a music player warns about damaged mp3 files.
# [07:38] <mjs> karl: I conclude that Safari blocking users from seeing invalid content would have much more effect on Safari market share than on proportion of invalid content
# [07:39] <karl> hsivonen: which soften the previous absolute comment ;) practical extremism versus theoritical extremism? :)
# [07:39] <mjs> karl: I also regularly see pages that serve as text/html to IE and application/xhtml+xml to other browsers which are not well-formed XML and so fail in all non-IE browsers
# [07:39] <Zeros> I agree with that. All major browsers would need to do it at the same time for it to be effective and prevent market share shift to the one browser that just corrects silently
# [07:39] <mjs> if the magic of draconian failure doesn't work for XML, where it was designed in from the start, why should we spread that idea further?
# [07:39] <karl> yooohooo drifting the discussion
# [07:40] <Zeros> the issue with xml is much more complex than this
# [07:40] <sbuluf> the idea of strict parsing works. content would get fixed.
# [07:40] <Zeros> some browsers didn't do it, many web servers don't send the proper mime, appendix c, the whole thing is very murky
# [07:40] <mjs> I'm just providing evidence that visible dramatic failure in one browser does not automatically lead to web content being changed
# [07:41] <mjs> and anyone who thinks that is living in a fantasy world
# [07:41] <Zeros> I agree
# [07:41] <karl> mjs: not testable statement :)
# [07:41] <Zeros> The failure needs to be universal in all browsers
# [07:41] <sbuluf> obviously
# [07:42] <sbuluf> hence, roy's message
# [07:42] <Zeros> Draconian error handling is horrible though, I think a dialog with a warning is a much better approach.
# [07:42] <hsivonen> anyway, Apache had its chance to fix this. they didn't. browsers had to deal. now it is entrenched
# [07:42] * karl wonders if mjs is saying that all browsers implementing finally html5 in an interoperable way is a fantasy
# [07:42] <Zeros> Hiding the entire page from a user who needs the information when the browser /could/ error correct reasonably is just as silly as showing a yellow page like Gecko.
# [07:42] <Zeros> At least Webkit shows the page
# [07:43] <sbuluf> strictness works. nothing horrible about it. everything horrible if the opposite, though.
# [07:44] <mjs> sbuluf: making unsubstantiated assertions doesn't really move the discussion forward
# [07:44] <sbuluf> i agree.
# [07:45] <mjs> if you want to provide supporting evidence that strictness works, you could cite an example of where strictness has worked on the web
# [07:45] <mjs> I gave examples of where unilateral strictness causes harm to end users, or would cause harm
# [07:45] <Zeros> It's an interesting issue. I have a friend who adamantly thinks that adding formal error handling rules to HTML is just as good as making invalid HTML valid, since the rendering becomes consistent, even in the erroneous case.
# [07:46] <sbuluf> if i wanted to provide supporting evidence that stricness works, i would have done so.
# [07:46] <sbuluf> mentime, i did not mention "unuilateralness", not "the web".}
# [07:46] <karl> mjs: closed tables in netscape?
# [07:46] <mjs> are you just trolling, then?
# [07:46] <Zeros> Without the error handling rules though there's much lost in reverse engineering and other problems
# [07:46] <sbuluf> no. are you?
# [07:48] <mjs> at this point I think you are disrupting the conversation in an unhelpful way, even if you did not mean to initially
# [07:49] <karl> (drifting again)
# [07:49] <sbuluf> i think exactly the same about you.
# [07:49] <karl> hey kids
# [07:49] <karl> :)
# [07:49] <karl> each one of you in the corner for 5 minutes
# [07:49] <mjs> no thanks
# [07:51] <Zeros> I suppose if the "new html" wasn't backwards compatible it'd be trivial to achieve this goal. The new implementations would all have the strictness; you couldn't just send xhtml as text/html and avoid it.
# [07:51] <Zeros> That's completely against the goals of this working group though, and creates a million new problems.
# [07:51] <mjs> it depends on what kind of strictness you had in mind
# [07:52] <mjs> consider that SVG was designed with the intent of strictness from the start
# [07:52] <mjs> but a lot of looseness is required to successfully process SVG content on the web
# [07:52] * karl wonders what would happen if suddenly IE team decided to implement application/xhtml+xml
# [07:52] <mjs> due to that content targetting the quirks of early implementations
# [07:52] <karl> what would be the consequences for this WG and others.
# [07:53] <Zeros> mjs, that kind of looseness seems acceptable, you can't win every battle after all.
# [07:54] <mjs> Zeros: what if that looseness includes some of the same kinds of looseness that exists in HTML implementations?
# [07:55] <mjs> like, say, ignoring the Content-Type header for embedded images
# [07:55] <Zeros> mjs, assuming you meant some, not all, then that seems like a reasonable compromise.
# [07:56] <mjs> I am not sure what position you are advocating so I'm not sure whether I agree
# [07:57] <Zeros> I'm saying that strictness would be beneficial, but that the water is very murky. Forcing complete strictness in an attempt to correct all the "mistakes' of the past won't help users or authors. Future strictness and collaboration might though.
# [07:58] <Zeros> From previous discussions with sbuluf it always (and correct me if I'm wrong) that he wanted a whole new HTML, since that 'solves' all these issues. I think that goes much too far.
# [07:58] <Zeros> +seemed
# [07:59] <sbuluf> not just a new content format, but a whole new web altogether. that is off topic here, though.
# [07:59] <mjs> I think SVG demonstrates that inventing a whole new language with no backwards-compatibility issues won't necessarily lead to total strictness
# [07:59] <Zeros> good point
# [08:00] <mjs> in fact in the latest spec they backed off some strictness requirements from old specs because they turned out to be infeasible
# [08:01] <Zeros> The best short (and possibly long) term solution I think is advocacy and being careful what's preached. XHTML shows that promoting a new and improved anything is very dangerous.
# [08:02] <karl> "dangerous" is a bit strong :)
# [08:02] * karl never heard about anyone dying of XHTML
# [08:02] <Zeros> karl, well, it's a mess that probably can never be cleaned up.
# [08:02] <karl> yes but not dangerous.
# [08:03] * Quits: aroben (adamroben@67.160.250.192) (Quit: aroben)
# [08:03] <karl> and from the point of view of users and designers it is not a mess
# [08:03] <karl> only from the point of view of very-strict-spec-readers
# [08:03] <karl> it's where the disconnection is.
# [08:04] <Zeros> dangerous - likely to have adverse or unfortunate consequences; risky
# [08:04] <Zeros> seems fitting
# [08:04] <mjs> that Apache bug is an interesting piece of history
# [08:04] <karl> people use xhtml with text/html, sometimes, they pipe it in an XSLT processor, etc and it works. So for them nothing nothing dangerous.
# [08:05] <karl> some designers developer a market, and a business with XHTML served as text/html, a working business generating revenues.
# [08:06] <karl> and then suddenly groups of browser implementers say it is wrong to serve it as text/html, that is dangerous.
# [08:06] <karl> then designers reply... "hmm dangerous? why? I'm making revenues with that right now and it has not killed anyone"
# [08:06] <Zeros> karl, and why are they using XHTML? What are they gaining by sending xhtml that's not valid? They're not mixing markup languages, they're not using the xml parser in the browser, they gain nothing but the self satisfaction that they're using the "new html"
# [08:07] <karl> It's why there is a big misunderstanding between communities
# [08:07] <Zeros> The message of what xhtml is and why to use it got very lost
# [08:07] <karl> Zeros: They gained "money", they gained a "market", they gained "respect".
# [08:07] <karl> it's not only about technologies.
# [08:08] <mjs> so XHTML is all about brand value?
# [08:08] <Zeros> karl, that's totally unrelated to xhtml.
# [08:08] <karl> Zeros: as much as error recovery is not related to html, but to human behaviours and errors :)
# [08:08] <Zeros> I'd love to see anything that says a xhtml page of one company is going to produce more revenue or provide more impressions than one that's html4.
# [08:09] <Zeros> karl, maybe, but the fact that google is html or xhtml has absolutely no impact on who uses their service.
# [08:09] <karl> Zeros: look at the number of books which have been published on xhtml+CSS, on Web design agencies promoting quality through this switch, etc.
# [08:09] <karl> It is a market and a business.
# [08:09] <Zeros> How many more users do you think msn got when they moved to xhtml?
# [08:09] <mjs> I think the "money", "market" and "respect" are for the web designers who promise you great benefits by rewriting your site as XHTML
# [08:10] <karl> mjs: I didn't say the opposite
# [08:10] <Zeros> karl, I suppose
# [08:10] <mjs> karl: I didn't think you did; just clarifying to Zeros, who thinks the benefit is for businesses trying to reach end users
# [08:10] <mjs> which does not appear to exist
# [08:10] <Zeros> I agree
# [08:11] <karl> the benefits though for the Web as large
# [08:11] <karl> is that in the same trend
# [08:11] <karl> Many Web designers and Web agencies got the value of Semantics.
# [08:11] <karl> this is a by-product of the market developed around xhtml+css
# [08:12] <karl> we agree that it could have been done with html 4.01
# [08:12] <Zeros> yes, that's where I stand
# [08:12] <karl> but the fact is that it has happened with this engagement to xhtml+css
# [08:12] <Zeros> And I hope html5 can be used to prove that
# [08:12] <Zeros> karl, that doesn't prove cause and effect though, just time and place.
# [08:12] <karl> Zeros: not if you do not consider the authors, web designers and web agencies in our work.
# [08:13] <karl> if HTML 5 neglects them and shows the value they have in spreading the language
# [08:13] <karl> then we will fail
# [08:13] <Zeros> hmm
# [08:14] <Zeros> So we need to ensure that Orielly can sell books with HTML5 as a brand else we're not going to succeed
# [08:14] <karl> s/shows/do not show/
# [08:14] <Zeros> I can understand that I guess
# [08:14] <karl> Zeros: something like that. We have to offer values for Web designers.
# [08:15] <Zeros> The web is terribly complex
# [08:15] <karl> Don't forget they have a whole business created on the value of xhtml+css
# [08:15] <karl> with money
# [08:15] <Zeros> I think that goes back to my saying it's dangerous. All of this crosses so many boundaries and touches so many people.
# [08:15] <karl> and when you are working in a Web agency, you do not want to tell your customers "well, it was not exactly how we meant it".
# [08:15] <Zeros> Book sellers, designers, developers, users, companies, vendors
# [08:16] <mjs> as a standards body, we don't have that much control of branding
# [08:16] <karl> yes but that's a *reality* of the Web ;) (to copy a favorite sentence of some people)
# [08:17] <mjs> XHTML as a brand name for "semantics, CSS, no table layout, validation, clean design, etc" was created by self-proclaimed experts and educators
# [08:18] <karl> mjs: maybe, nowadays it became a fact.
# [08:18] <karl> as much as invalid html
# [08:18] <Zeros> I'll have to think more about that.
# [08:18] <olivier> "self-proclaimed experts and educators" is condescending, BTW. I know a lot of people, and they all genuinely started as advocates of something they thought made sense. Of course some of them made a business, others got an inflated ego
# [08:19] <olivier> but, hey, I see overblown egos everywhere...
# [08:19] <olivier> s/lot of people/lot of these people/
# [08:19] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
# [08:20] <sbuluf> http://chatlogs.planetrdf.com/swig/2006-07-16.html#T21-39-40 <--this might be of interest for some. just two lines.
# [08:20] <mjs> I only said "self-proclaimed" because I think being confused about what happens when XHTML is sent to a browser (and yes, many people are genuinely confused on this) places limits on one's expertise
# [08:20] * Joins: zcorpan_ (zcorpan@88.131.66.80)
# [08:20] <mjs> but I admit that many of those who created XHTML-the-brand are very knowledgeable about many areas of web technology
# [08:21] <sbuluf> then again, i have seen tim berners lee messages o the tag saying exactly the opposite, supporting the idea of extensibility, and so on
# [08:22] <olivier> fair point, mjs, a lot of people understand a lot about the document formats, but too little about protocols and delivery
# [08:22] <karl> sbuluf: because nothing is black and white. They are benefits sometimes. Myself I prefer to use xhtml (on the desktop) for a very simple reason.
# [08:22] <karl> XSLT
# [08:22] <mjs> microformats is another example of a technology that has had great success through branding
# [08:22] <karl> I don't have to jungle between two conversions HTML -> XHTML -> XSLT
# [08:22] <mjs> perhaps beyond the actual concrete benefits it has delivered so far
# [08:23] <olivier> jungle? :)
# [08:24] <karl> haha
# [08:24] <olivier> juggle perhaps :D
# [08:24] <sbuluf> karl, so woud i. i prefer to think that was a very unfortunate answer from danc, myself.
# [08:24] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [08:24] <karl> that was my Tarzan's dyslexia
# [08:25] <mjs> I only hope that HTML5 is ultimately successful in its branding
# [08:25] <karl> s/hope/do what is necessary for authors/
# [08:25] <mjs> perhaps part of it is for browsers to give credit to HTML5 when due for various improvements
# [08:26] <mjs> karl: I don't have a very large audience as a standards advocate, so I think I will stick to improving the spec and WebKit's implementation of it
# [08:26] <karl> mjs: and you do a good job at it
# [08:28] <mjs> it's too bad that Apache didn't pick application/octet-stream as the default type way back when
# [08:28] <mjs> that would be a better place for sniffing quirks than text/plain
# [08:28] <mjs> (still reading that bug)
# [08:29] * Joins: gavin_ (gavin@74.103.208.221)
# [08:30] <sbuluf> The 'X' -n 'XML' is supposed to be for extensible (TBL): http://lists.w3.org/Archives/Public/www-tag/2007Jun/0115.html
# [08:31] <sbuluf> the X in xhtml is for marketing (danc): http://chatlogs.planetrdf.com/swig/2006-07-16.html
# [09:17] * Quits: dbaron (dbaron@71.198.189.81) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [09:21] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [09:25] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
# [09:25] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [09:27] <hsivonen> the sample apps at http://about.validator.nu/htmlparser/ remove the XSLT reason not to use HTML5
# [09:29] * Joins: karl (karlcow@128.30.52.30)
# [09:29] * Quits: karl (karlcow@128.30.52.30) (Client exited)
# [09:53] * Joins: Thezilch (fuz007@68.52.119.203)
# [09:54] * Joins: ROBOd (robod@86.34.246.154)
# [09:55] <Hixie> re the aqbove discussion -- i've seen the usability studies. If Google started labelling sites with some sort of non-compliant markup as non-compliant, or popped up an alert for pages with HTTP Content-Type labelling errors, or some such, the users would quickly flock to yahoo or msn search.
# [09:56] <Hixie> i mean, like, google's userbase would drop from its current high double digits to single digits overnight.
# [09:57] * Joins: hendry (hendry@91.84.62.62)
# [09:59] <laplink> Hixie: That's interesting. Can those results be published?
# [10:02] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
# [10:17] * Quits: sbuluf (dhy@200.49.140.247) (Quit: sbuluf)
# [10:19] * Joins: sbuluf (qc@200.49.140.168)
# [10:24] * Joins: heycam (cam@203.214.42.247)
# [10:26] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [10:32] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [10:34] <Hixie> laplink: which results?
# [10:35] <zcorpan_> Hixie: of the usability studies
# [10:35] * Joins: mjs (mjs@64.81.48.145)
# [10:37] * Joins: gavin_ (gavin@74.103.208.221)
# [10:43] <Hixie> zcorpan_: oh the studies were regarding other things (like unannounced products), so no
# [10:43] <Hixie> my point was that users are fickle, not that google shas specifically tried catching marking non-compliant sites
# [10:46] <heycam> Hixie, i think your terminal settings are askew (i'm seeing U+007F characters where it looks like you would've been backspacing)
# [10:50] <Hixie> yeah, lag issues
# [10:50] <Hixie> for some reason my terminal starts acting weird when i have high lag
# [10:50] <heycam> that is a strange behaviour
# [10:51] * Parts: Lachy (Lachlan@124.170.99.178) (Leaving)
# [10:52] * Joins: Lachy (chatzilla@124.170.99.178)
# [10:57] * Joins: anne (annevk@81.68.67.12)
# [11:05] * Joins: beowulf (beowulf@87.198.168.38)
# [11:26] <hendry> does Safari 2+ correspond to AppleWebKit/413? re http://blog.whatwg.org/web-forms-20-cross-browser-implementation
# [11:32] <hsivonen> hendry: Safari 2.0.4 is WebKit 419.3
# [11:33] <hendry> hsivonen: thanks henri. are these mapping documented somewhere?
# [11:33] <hsivonen> hendry: I don't know
# [11:33] <hendry> hsivonen: ok, np :)
# [11:35] <anne> http://junkyard.damowmow.com/290 :)
# [11:39] <hsivonen> anne: did you notice http://junkyard.damowmow.com/291 ?
# [11:41] <anne> yeah, saw that later
# [11:43] * Joins: robburns (robburns@98.193.22.194)
# [11:43] * Quits: robburns (robburns@98.193.22.194) (Quit: robburns)
# [11:50] <anne> that was a short visit
# [11:50] * Quits: hendry (hendry@91.84.62.62) (Ping timeout)
# [11:50] * Joins: Lionheart (robin@66.57.69.65)
# [11:53] <anne> Lachy, actually, what Jason brings up as a potential accessibility problem is not actually something <input usemap> solves better than <img usemap>
# [11:53] * anne continues here as the irc.freenode.net connection is flaky
# [11:55] <Lachy> yeah, the fact that <img usemap> handles all the use cases was mentioned several times.
# [11:56] <anne> k, I'll just delete all those e-mails then
# [11:56] <Lachy> yeah, there wasn't really anything worth reading in them
# [12:09] <anne> hmm, it seems like it is time to update the tracker to make the input controls slightly larger
# [12:10] <anne> size=4 :)
# [12:11] <zcorpan_> anne: :)
# [12:13] <zcorpan_> anne: that's an issue, actually. in opera, <input type=number size=4> isn't large enough to fit 4 characters
# [12:18] <anne> form styling is a major pain
# [12:18] <anne> anyway, maybe Daniel can look into it?
# [12:18] * anne wonders if zcorpan_ is now based in Linkoping
# [12:18] * zcorpan_ is in linköping atm, but haven't moved quite yet
# [12:18] <zcorpan_> i'll file a bug
# [12:22] <anne> size= doesn't seem to function at all?
# [12:23] <zcorpan_> for type=number? works for me
# [12:23] <zcorpan_> anne: for the tracker you need to remove a css ruleset
# [12:24] <anne> ah, I see :)
# [12:26] <anne> fixed
# [12:40] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [12:45] * Joins: gavin_ (gavin@74.103.208.221)
# [13:07] <anne> heh, zeldman is great"
# [13:08] <anne> "Sensible new standards may yet emerge from the W3C, or from elsewhere, or they may not come at all. Some of this may matter before we ride hover cars."
# [13:09] <mjs> I've folded most of the design principles wiki feedback into http://esw.w3.org/topic/HTML/DesignPrinciplesReview now
# [13:09] <mjs> (and classified)
# [13:10] * Joins: icaaq (icaaaq@85.228.51.33)
# [13:10] <mjs> the only thing left is the huge volume of "Pave the Cowpaths" feedback
# [13:10] <mjs> I now wince whenever I see that phrase
# [13:10] * Joins: hendry (hendry@91.84.62.62)
# [13:11] * Parts: icaaq (icaaaq@85.228.51.33)
# [13:11] * Joins: icaaq (icaaaq@85.228.51.33)
# [13:14] <anne> heh
# [13:16] * Quits: Lachy (chatzilla@124.170.99.178) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072518])
# [13:20] * Joins: tH (Rob@87.102.94.41)
# [13:21] * Joins: robburns (robburns@98.193.22.194)
# [13:23] * Quits: robburns (robburns@98.193.22.194) (Quit: robburns)
# [13:31] * anne reads http://www.456bereastreet.com/archive/200708/the_html_5_circus_why_i_left_and_rejoined_the_w3c_html_working_group/#comment3
# [13:32] <gsnedders> I wondered whether to point that out to you and the others when that was posted
# [13:32] <anne> I got this from #whatwg
# [13:33] * Parts: icaaq (icaaaq@85.228.51.33)
# [13:36] <beowulf> interesting
# [13:37] <beowulf> i wonder who the people are who lack real-world web development experience?
# [13:38] * hsivonen notes that many people lack the experience of developing software that reads stuff from the Web or the experience of contacting sites to ask them the change to be compatible with a standards-compliant browser feature
# [13:39] <gsnedders> hsivonen: I've said before that I expect a lot would change if you made everyone go and write a browser and use it for a couple of weeks. heck, a day might be long enough.
# [13:39] <hsivonen> I see a certain degree of elitism in comment #32
# [13:40] * anne prolly has mostly experience in what hsivonen is hinting at though I've developed several sites and worked on several larger projects as well (mostly photoshop -> template mapping) in the past
# [13:46] <hsivonen> I find it curious that certain syntactic features that aren't exposed in the DOM are seen as threats to professionalism
# [13:49] <anne> certainly they have more real world experience and can tell us why that matters?
# [13:49] <anne> according to reliable sources I've only been doing this for a couple of months, after all
# [13:51] * gsnedders should leave the WG. He's too young to be meaningful.
# [13:51] <beowulf> i should leave, i'm too lazy
# [13:52] * hsivonen is still waiting for the pros to pick up the methods outlined in http://hsivonen.iki.fi/producing-xml/
# [13:53] <gsnedders> hsivonen: latest thing I did with XML used a serialiser :)
# [13:53] <beowulf> it would be great if we had a way of showing what draconian error handling looked like, and how it would be adopted on the web... oh wait...
# [13:56] * Joins: olivier (ot@128.30.52.30)
# [14:08] * Joins: karl (karlcow@128.30.52.30)
# [14:11] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [14:17] * Joins: m0rfar (morfar@81.229.58.186)
# [14:20] <anne> quotes from zeldman comments: "Another troubling thing about HTML 5 is that backwards compatibility with older versions is going to be next to impossible."
# [14:21] <zcorpan_> huh?
# [14:21] <anne> I didn't exactly get it either
# [14:28] * Parts: Lionheart (robin@66.57.69.65)
# [14:39] * Joins: Lachy (chatzilla@124.170.99.178)
# [14:47] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [14:48] <anne> hmm, http://www.whatwg.org/issues/top doesn't load well
# [14:52] * Joins: gavin_ (gavin@74.103.208.221)
# [15:06] <Philip`> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3Ea%20%26%23xd800%3B%26%23xdc00%3B%20b%20%26%23xd800%3B%20c%20%26%23xdc00%3B%20d
# [15:06] <Philip`> IE and Opera and Safari combine the surrogate pair, Firefox doesn't
# [15:06] <Philip`> (and Safari drops everything after an unpaired surrogate)
# [15:07] <Philip`> or at least it looks like that, if nothing confusing is happening
# [15:12] <Lachy> anne, what do you mean by it doesn't load well?
# [15:13] <anne> oh, maybe only two votes have been casted so far
# [15:13] * anne didn't consider that
# [15:13] <Lachy> yeah, though it looks like it's still trying to load cause it keeps an iframe with a persistent connection
# [15:13] <Lachy> it must update automatically
# [15:14] <Philip`> There was only one vote when I last looked
# [15:14] <Philip`> Try voting more :-)
# [15:14] * anne voted on one of his own e-mails to see if it worked
# [15:17] <Lachy> still only 2 votes. must be a delay
# [15:17] <anne> no, the one on top is my e-mail
# [15:17] <Lachy> Ruby in HTML?
# [15:18] <anne> iirc, yes
# [15:18] <Philip`> Did you get an 'unvote' button after voting?
# [15:18] <Lachy> oh, the second one is an email from me that zcorpan_ voted for
# [15:18] <Philip`> (I think zcorpan_ experienced problems with that)
# [15:19] <zcorpan_> yeah, i had a few days old firefox build
# [15:19] * Joins: thorny63 (thorny63@193.71.42.4)
# [15:19] <Lachy> there should be a vote button on the /issues/top page, so that others can also register their support for those issues easily
# [15:20] <Lachy> Hixie, see previous comment!
# [15:20] <Philip`> When Hixie say "This page will only be useful to you if you have a relatively modern JavaScript-enabled browser.", presumably "relatively modern" means "not more than two weeks old"
# [15:21] <Lachy> I haven't experienced any problems with Firefox 2, which is several months old
# [15:21] <zcorpan_> Philip`: actually the build i had was only 4 days old
# [15:21] <Philip`> Oh, okay
# [15:22] <Philip`> Maybe it's just that some builds of FF3 are a tiny bit buggy at times
# [15:22] * Philip` sees the issue list automatically updating itself
# [15:24] * Joins: karl (karlcow@128.30.52.30)
# [15:27] * Lachy voted for the placeholder attribute
# [15:28] * Joins: robburns (robburns@98.193.22.194)
# [15:28] <Lachy> there doesn't seem to be too much discussion of it on the whatwg list, though I suppose people on public-html are going to demand that it goes through the same rigorous process as everything else
# [15:29] <Philip`> "WebKit implements a placeholder=3D attribute" - ooh, 3D placeholder - that must look exciting
# [15:30] <Lachy> Hixie's script seems to be outputting the content of the mbox files directly, instead of decoding the characters :-) =3D is supposed to be an = character
# [15:31] <robburns> Philip: I think Safari is choking on the isolated surrogates. (it's a fairly recent feature addition).
# [15:31] <robburns> I added a <p>and some text and then it recovers
# [15:33] <Philip`> robburns: Oh, okay, looks like it's simply a rendering issue
# [15:34] <Philip`> It constructs the DOM with all the text
# [15:34] <robburns> Philip: The surrogate pair also works for me in Firefox 2.0.0.6
# [15:34] <Philip`> but if it tries drawing an unpaired surrogate then the rest of the line is skipped
# [15:34] * Parts: thorny63 (thorny63@193.71.42.4)
# [15:34] <Philip`> (but it does render the next line of the same piece of text)
# [15:34] <robburns> yeah, that look like what I see too
# [15:34] <robburns> really?
# [15:35] <Philip`> (at least in Safari on Windows)
# [15:36] <Philip`> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0AStart%3A%20%26%23xd800%3B%20Lorem%20ipsum%20dolor%20sit%20amet%2C%20consectetuer%20adipiscing%20elit.%20Nam%20eu%20purus.%20Curabitur%20luctus%20sagittis%20nibh.%20Nulla%20varius.%20Vivamus%20id%20ligula.%20Morbi%20nisl.%20Phasellus%20augue%20ligula%2C%20eleifend%20sit%20amet%2C%20tempor%20vitae%2C%20lobortis%20et%2C%20ante.%20Cras%20quis%20lorem%20pretium%20neque%20sodales%20c
# [15:36] <robburns> Oh, I'm on Mac. I'm not seeing the C or the D or any other replacement characters
# [15:36] <Philip`> draws the second and subsequent lines of wrapped text
# [15:37] <anne> thanks heycam, I suppose I could've done it myself...
# [15:37] <anne> although actually, probably not
# [15:37] <robburns> I'm getting
# [15:37] <anne> I'd have to look up Unicode nonsense first...
# [15:37] <robburns> Start:
# [15:38] <anne> hsivonen, http://about.validator.nu/htmlparser/ "does not run" as opposed to "do not run"?
# [15:39] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [15:39] <Philip`> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cbody%20onload%3D%22w%28uneval%28document.body.firstChild.nodeValue%29%29%22%3E%0A%26%23xd800%3B%26%23xdc00%3B%0A
# [15:39] <robburns> Philip: I'm getting
# [15:39] <Philip`> Firefox 2: one character rendered, log says "\n\uD800\uDC00\n"
# [15:39] <Philip`> Firefox 3: two characters rendered, log says "\uFFFD\uFFFD"
# [15:39] <robburns> Start tempor vitae, lobortis et, ante. Cras quis lorem pretium neque sodales c
# [15:40] <robburns> with a new line after Start and no visible character for the isolated surrogate
# [15:40] <Philip`> robburns: Okay, sounds the same as what I see - it just stops drawing from the surrogate up to the end of the line
# [15:42] <robburns> Philip: Yeah, I guess it should handle that situation better, but I'm not surprised if it doesn't draw a glyph for an isolated surrogate. The last url had just a single astral character with a lastResort glyph
# [15:43] <robburns> Philip: though Safari wasn't drawing that glyph, I only saw the lastResort glyph when I pasted it into BBEdit. Safari had just a square box
# [15:43] <Philip`> For normal surrogates, it sounds like everything except FF3 thinks &#xd800;&#xdc00; is one character
# [15:45] * anne wonders how to implement them
# [15:45] <robburns> Philip: Like I said, I think it's a pretty new feature on Safari. Safari 2.x wouldn't handle this (which is the latest actual release).
# [15:46] <robburns> But it sounds like almost every current browser does now.
# [15:46] <robburns> I didn't expect that.
# [15:47] <robburns> Unicode publishes some algorithms to go from surrogate pair to astral and also the reverse (IIRC)
# [15:48] <Philip`> The implementation problem is in fitting it into the tokenisation and tree-construction algorithms in a non-horrible way
# [15:48] <anne> not talking about those algorithms
# [15:48] <anne> talking about tokenization
# [15:49] <robburns> Oh, sorry
# [15:49] <anne> what Philip` said
# [15:49] * Philip` wonders how browsers handle incremental display of pages when it might cut a surrogate pair in half
# [15:50] <robburns> Philip: well when you have a surrogate, you know to expect another one or just toss out the one you got.
# [15:50] <robburns> right?
# [15:50] <anne> yes, that bit sounds simple and I got as far too :)
# [15:51] <anne> now implement it in html5lib
# [15:51] <Philip`> Oh, Opera just makes multiple text nodes, not caring whether it's cutting an entity in half
# [15:52] <Philip`> (e.g. one text node ends in "&#" and the next starts with "xdc00;")
# [15:52] <Philip`> at least in the Live DOM Viewer
# [15:52] <robburns> Philip: that doesn't sound good
# [15:52] <Philip`> (I can't use the Dead DOM Viewer because my server says Request-URI Too Large :-( )
# [15:53] <robburns> Philip: I saw the dead DOM/Zombie DOM viewer. How is that different?
# [15:54] <Philip`> It passes the data through a server, rather than using document.write(), which is occasionally useful since all browsers do some things differently in those cases
# [15:57] <robburns> I see
# [16:00] <robburns> I guess if Opera can still handle the character references that straddle text nodes that's not a problem.
# [16:06] * Quits: robburns (robburns@98.193.22.194) (Quit: robburns)
# [16:07] <Philip`> Perhaps it could be implemented somewhat like
# [16:07] <Philip`> General tokenisation stuff: Whenever a token is emitted, if the Surrogate Entity flag is set, then first emit a U+FFFD character token and reset the Surrogate Entity flag.
# [16:07] <Philip`> Numeric entity handler: If the value is D800-DBFF: { If the Surrogate Entity flag is set, emit a U+FFFD character token. Set the Surrogate Entity flag, and set the First Surrogate to the current value. }
# [16:07] <Philip`> If the value is DC00-DF00: { If the Surrogate Entty flag is not set, emit a U+FFFD character token. Else: combine with the First Surrogate, reset the Surrogate Entity flag, and emit the characterc. }
# [16:08] <Philip`> Uh, not sure why the last line got a little bit mangled when pasting it...
# [16:08] <Philip`> s/Entty/Entity/, s/characterc/character/
# [16:10] <anne> yeah, that might work
# [16:10] <anne> more flags :(
# [16:11] * Philip` wonders if he can convert the algorithm into a form that uses fewer flags
# [16:11] <Philip`> (like expanding out all the content model flags, so there's a separate set of states for each, and you just jump into the right state immediately after emitting an end tag)
# [16:11] <anne> hmm
# [16:12] <anne> prolly only need to duplicate a few
# [16:12] <Philip`> http://canvex.lazyilluminati.com/misc/states10.png
# [16:12] <anne> you could consume another character in the entitydate and attributeentity states maybe...
# [16:13] <Philip`> PCDATA and RCDATA are mostly duplicates
# [16:13] <Philip`> Oh, and CDATA is too
# [16:13] <Philip`> (except for the doctype stuff, which is PCDATA only)
# [16:13] <anne> does this also work for &surrogate;surrogate
# [16:14] <gsnedders> DanC: are you planning on pushing the Content-Type sniffing beyond an I-D?
# [16:18] <Philip`> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%26%23xd800%3B%3Cscript%3Edocument.write%28%27%5Cudc00%27%29%3C/script%3E
# [16:18] <Philip`> FF2 combines the pair, IE/Opera/Safari don't
# [16:20] <anne> I'm not sure how you can define HTML Content-Type sniffing without defining the HTML tokenizer and script execution
# [16:21] <anne> and the HTML parser prolly too
# [16:24] <zcorpan_> anne: for xhr?
# [16:24] <zcorpan_> just leave it undefined and have an informative reference to html5
# [16:25] <anne> no, for doing it in a separate document
# [16:26] <DanC> beyond I-D... you mean up the IETF standards track? well, I don't have any clear plans, but yes, one option is to take the HTML 5 rules and make them an IETF standard, part of or next to the HTTP and MIME specs.
# [16:27] <DanC> if the widespread implementations aren't going to get changed, the specs shouldn't continue to say what they say about text/plain.
# [16:28] * DanC hunts for hixie's "nearly a hundred tests"...
# [16:29] <hsivonen> while at it, it would be good to get the RFC that defines the ASCII default for all of text/* repealed
# [16:29] <hsivonen> it is used as the excuse for not fixing text/xml
# [16:30] <hsivonen> of course, text/html and text/css already violate the text/* rule
# [16:30] <anne> oh, you mean section 4.7... hmm
# [16:30] <anne> text/xml does too in practice
# [16:30] <anne> and text/javascript, etc.
# [16:31] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [16:31] <gavin> DanC: http://hixie.ch/tests/adhoc/http/content-type/ ?
# [16:31] <hsivonen> DanC: as an anecdote, the reality of text/xml and text/plain is so bad that I had to implement a checkbox in validator.nu that turns off RFC respecting and makes the service more useful
# [16:32] <hsivonen> for example, in the RFC-compliant mode, I had to barf on official DTDs served from w3.org
# [16:32] <DanC> there are two text/* defaults; one in email and one in http. I think the http one is getting fixed... http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-latest.html
# [16:33] * Joins: myakura (myakura@122.29.114.29)
# [16:33] <DanC> I think validator.w3.org has similar checkboxes; but that anecdote is worth adding to the thread in public-html, hsivonen
# [16:33] <DanC> yes, thanks, gavin
# [16:34] <gsnedders> DanC: not necessarily the standards track, even just publishing it as an experimental RFC
# [16:36] <DanC> I hope it won't get that far. I hope to actually get this problem fixed.
# [16:36] <anne> DanC, http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-latest.html#missing.charset is all I could find
# [16:36] <anne> DanC, that does not deal with the rules for text/css for instance
# [16:36] * DanC adds content-type tests to http://esw.w3.org/topic/HtmlTestMaterials
# [16:38] <gsnedders> DanC: you can't take independent submissions onto the RFC Proposed Standard status, only informational or experimental
# [16:38] <DanC> hmm... seems they haven't changed it yet: "When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP" -- http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-latest.html#canonicalization.and.text.defaults
# [16:38] <DanC> I wonder if it's considered an open issue.
# [16:38] <gsnedders> and for something like content-type sniffing, it is IMO border line between the two
# [16:39] <anne> when I talk to them I always get the feeling they are happy to wait until everything magically fixes itself
# [16:39] <gsnedders> anne: HTTP WG?
# [16:40] <anne> yeah and s/talk to/e-mail with/
# [16:40] <DanC> it's pretty clear to me that the content-type rules belong only in the HTTP spec and not in the HTML spec. But hixie has done a bunch of research and stuck the results in an HTML spec, so I'm opening lines of communication.
# [16:41] <anne> I believe the goal of the new version isn't necessarily getting two complete interoperable implementations either, so I'm not spending too much time on it
# [16:42] <DanC> I tried to get testing into the charter of the CALSIFY WG; result was disappointing. I wonder if the IETF approach to QA scales to the Web marketplace.
# [16:42] <DanC> (of course, it's hardly clear that the W3C approach is all that much better)
# [16:44] <gsnedders> (on a slightly related note, I've started work on an I-D regarding HTTP parsing)
# [16:44] <DanC> what authoring tools are you using, gsnedders ?
# [16:44] <gsnedders> DanC: xml2rfc, for now
# [16:44] <DanC> it blows me away that people abandon HTML so lightly
# [16:45] <gsnedders> easier to get in the correct format, though
# [16:46] <gsnedders> I have little issue with XML if nothing public will break if I screw up.
# [16:47] <DanC> i.e. the state-of-the-art in writing I-Ds with HTML is still by Jim Davis in 1998. http://www.econetwork.net/~jdavis/Software/Parser/html-parser.html
# [16:48] <DanC> writing web conference papers using HTML is in a similarly primitive state. I put quite a bit of effort into it. http://www.w3.org/2004/04/xhlt91/
# [16:49] <anne> cool, http://dev.w3.org/html5/html-design-principles/Overview.html now works correctly
# [16:49] <anne> thanks to #sysreq
# [16:49] <DanC> docbook has an excuse because its design predates HTML, but I don't see any excuse for the arbitrary differences between xml2rfc and HTML. e.g. why <t> rather than <div>?
# [16:50] <DanC> ah... nifty, anne.
# [16:50] <gsnedders> DanC: <t> is identical to <p> or <li>
# [16:50] <DanC> ok, why <t> rather than <p>?
# [16:50] <gsnedders> DanC: but yes, it is rather stupid creating a whole new language
# [16:50] <gsnedders> though marking up references isn't overly semantic in HTML, to be fair
# [16:51] * Joins: billmason (billmason@69.30.57.156)
# [16:51] <DanC> yes, for the bibliography, I think new XML markup is probably worthwhile
# [16:52] <DanC> my conference paper stuff has a sort of hcite microformat. it's pretty tedious.
# [16:53] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [16:58] <hsivonen> hcite-like stuff doesn't work as a hand-authored format. I used .bib for my thesis and generated hcite-like output
# [17:11] * Quits: zcorpan_ (zcorpan@88.131.66.80) (Ping timeout)
# [17:17] <DanC> gsnedders, "you can't take independent submissions onto the RFC Proposed Standard status". That's news to me. I'm pretty sure you can. In fact, I believe I have done so.
# [17:19] * Joins: johnst (johnst@83.89.44.198)
# [17:20] <DanC> 59 survey results in, up from 47 when I last checked. http://www.w3.org/2002/09/wbs/40318/dprv/results
# [17:22] <anne> http://www.html5.jp/
# [17:33] <Philip`> I like the "WAHTWG" image on there
# [17:49] * Quits: myakura (myakura@122.29.114.29) (Quit: Leaving...)
# [17:51] <Philip`> Lachy: Does 'placeholder' have any non-presentational value? (i.e. why isn't it CSS's responsibility, like <label style="display:placeholder" for="password">Password</label><input type="password" id="password">?)
# [17:51] <Lachy> it's not always equivalent to the label
# [17:53] <Lachy> for example: <label>Date: <input placeholder="YYYY-MM-DD"></label>
# [17:54] <Lachy> I also expect that there would be significant implementation complexity with that CSS approach
# [17:55] <Lachy> what does it mean when the input it refernces is a radio button or checkbox? What if it references a non-existent form field?
# [17:58] * Joins: Roger (roger@213.64.74.230)
# [17:59] <Lachy> hey Roger
# [17:59] <Roger> hey
# [17:59] <gsnedders> DanC: http://www.rfc-editor.org/indsubs.html
# [17:59] * DanC heads to a telcon...
# [18:00] <Lachy> so apparentl, according to that html5.jp site, we're now called the WAHTWG instead of the WHATWG http://www.html5.jp/common/img/topimg.gif "=_
# [18:00] <Lachy> :-)
# [18:00] <gsnedders> Lachy: waht?
# [18:01] <anne> wb Roger :)
# [18:01] <Roger> thanks
# [18:01] <Philip`> I suggest renaming to HAWT WG
# [18:02] <Lachy> I vote for "Having A Wonderful Time" http://acronyms.thefreedictionary.com/HAWT
# [18:02] <anne> "Roy Fielding has joined the HTML Working Group"
# [18:04] <Lachy> http://en.wikipedia.org/wiki/Roy_Fielding
# [18:07] <Philip`> http://en.wiktionary.org/wiki/hawt - "1. (obsolete) Anything." - that would be appropriate when starting XML5, CSS5, SVG5, HTTP5, RSS5, IRC5, and all other anything5s
# [18:08] <Philip`> It's a shame that we couldn't fix email since it doesn't have a nice acronym
# [18:08] <anne> ai, people are opposing "Secure by Design" claiming it's useless...
# [18:09] <anne> (see www-archive)
# [18:14] <Lachy> Joshue is claiming that security and accessibility are opposing principles, and he's worried about which one will take precedence
# [18:15] <Lachy> I have no idea how a secuirty issue could be in conflict with accessibility, but even if they theoretically were, security would, without a doubt, have to be placed first
# [18:16] <anne> would be nice if they explained stuff like that
# [18:17] <gsnedders> Philip`: RFC5882?
# [18:17] * anne wonders how http://lists.w3.org/Archives/Public/public-html/2007Aug/0739.html is useful to anyone
# [18:18] <Lachy> Roger, yt?
# [18:18] <Philip`> gsnedders: I think that name is insufficiently catchy
# [18:18] <Roger> Lachy: yes
# [18:18] <gsnedders> Philip`: shucks
# [18:18] <Lachy> I don't understand your objection to Solve Real Problems
# [18:19] <Roger> Everybody wants to solve real problems, but how do you define what a real problem is?
# [18:20] <Roger> It seems people have different definitions of that.
# [18:20] <mjs> hey everyone
# [18:20] <Lachy> by getting input from those who the problem supposedly affects, looking for exisiting sites to see if solutions to those problems are being attempted
# [18:20] <mjs> anne: fortunately no feedback to that effect has appeared where I can see it
# [18:21] <anne> mjs, you're cc'ed
# [18:21] <beowulf> Lachy: I think what Joshue is saying is that security generally makes accessibiity harder
# [18:21] <Lachy> but how?
# [18:22] <anne> reading http://www.w3.org/2002/09/wbs/40318/dprv/results#xsbd I think he might misunderstand what is meant
# [18:22] * Quits: ROBOd (robod@86.34.246.154) (Client exited)
# [18:22] <Roger> Lachy: Agreed, but what is a real problem to one person may not be perceived as one by another person.
# [18:22] <anne> maybe not everyone is aware of the web's defacto security model and all that
# [18:23] <Lachy> then the discussion needs to be about clarifying and demonstrating what the problem is
# [18:23] <Lachy> before any discussion of the solution proceeds
# [18:23] <Roger> I am looking over my answers right now
# [18:23] <anne> in practice you make an assumption as to what is meant and make a judgement about that, I think
# [18:23] <anne> well, most people seem to do that
# [18:24] <mjs> anne: I don't see any such email in my inbox
# [18:24] <Roger> I wonder why the changes to the design principles that were made on the wiki have not made it into the draft
# [18:24] <Roger> some of the suggested changes really improved them
# [18:25] <anne> mjs @ ... is on the cc list
# [18:25] <anne> Roger, maybe because some people want consensus first?
# [18:26] <Lachy> Roger, consider for example, the recent usemap discussion. I don't think that was about solving a real problem because no-one actually demonstrated a significant use case for using an image map for form submission. Since that's image map submit buttons aren't really used, there's not really a significant problem to solve.
# [18:26] <anne> or because mjs didn't get around to do it
# [18:26] * Joins: aroben (adamroben@17.203.15.195)
# [18:26] <Roger> anne: ok
# [18:26] <Roger> Lachy: Yes, that is a good example that I would agree with
# [18:27] <Lachy> now compare that with the placeholder post I sent a few hours ago, where I clearly outlined the use cases and the problems before even mentioning the solutions. That's what needs to occur
# [18:27] <mjs> if there's any principle that would potentially conflict with accessibility it would be anything calling for ease of authoring, especially if it was about end-user authoring
# [18:28] <mjs> but we don't seem to have any principles about usability or about the web being a read-write space
# [18:28] <mjs> anne: I see DanC's email but not the other one you mention
# [18:28] <Philip`> (Lachy: I think there are reasonable cases for using server-side image map form submission, like in http://krijnhoetmer.nl/irc-logs/whatwg/20070815#l-455 )
# [18:29] <Philip`> (but I'm not aware of reasons for client-side image map form submission)
# [18:30] <Lachy> yeah, but that's a map, which is inherently inaccessible to a blind user anyway (the arrows surrounding the map provide access for keyboard users)
# [18:31] <Philip`> Why does it matter that it's inaccessible?
# [18:32] <Philip`> as long as the reason for being inaccessible is not that the technology doesn't support accessibility
# [18:32] <Lachy> because if people were going to claim that a client side map would make it more accessible to blind users than the server side map, then they would be wrong
# [18:33] <Lachy> Philip`, right!
# [18:33] <Philip`> Hmm, I can't actually understand the sentence that I wrote
# [18:33] <Lachy> which sentence? I understand it fine.
# [18:36] <Philip`> I think I mean that server-side image maps solve a significant use case, which happens to be inherently inaccessible (like <img> or <audio> or <canvas>) but that's alright since the similar accessible use cases are already handled perfectly well by other solutions (like <img usemap>, or <ul> lists of city names, etc)
# [18:36] <Lachy> mjs, a good example to either replace or compliment the <br/> example in pave the cowpaths would be a description of how authors use Flash for embedding and controlling video, and how <video> has been introduced to address that use case natively.
# [18:37] <Lachy> Philip`, yes.
# [18:38] <Roger> Lachy: I think that would make it easier to understand.
# [18:39] <mjs> Lachy: indeed, one thing I forgot to ask about was more examples
# [18:39] <Lachy> Roger, which message are you responding to?
# [18:39] <mjs> Lachy: if you mail that one to the list (w/ HDP in the subject) I'll be less likely to forget
# [18:40] <Lachy> mjs, ok
# [18:40] <Roger> Lachy: flash vs <video>
# [18:40] <Lachy> oh, right
# [18:40] <Roger> if that is indeed paving a cowpath
# [18:40] <Roger> ?
# [18:42] <anne> not really
# [18:42] <Lachy> yes, it is. The cowpath (use case) is publishing video on the web with custom controls. The solution of using Flash would be the equivalent to the dirt path, <video> would be the pavers or asphalt used to pave it
# [18:42] <anne> making <embed> comforming for plugins would be one
# [18:42] * Joins: robburns (robburns@66.149.74.142)
# [18:42] <Lachy> <embed> is an example of not reinventing the wheel
# [18:42] <anne> hmm, fair enough I guess
# [18:42] <Lachy> ... and solving a real problem
# [18:43] <mjs> "pave the cowpaths" was originally intended to be specifically about sometimes allowing stuff that is already in content in a direct and literal way
# [18:43] <robburns> Lachy, the use-case for a server-side map for submitting forms is the same as the use-case for a client-side map for submitting forms
# [18:43] <mjs> I think broadening it to include studying the use cases implied by author practices is reasonable though
# [18:43] <robburns> Lachy: except the client-side map provides a better user-experience and has accessibility built right in
# [18:43] <anne> robburns, please provide an example for the latter, I don't think I understand how that works with <input usemap>
# [18:43] <Lachy> as it's used by microformats, Tantek said it's about "data publication behaviours", which is essentially use cases
# [18:43] <mjs> it could also use a new name, because something about the current one seems to set people off
# [18:44] <anne> robburns, especially in terms of form submission and how it's different from simply using <img usemap> (which works in more browsers)
# [18:44] <robburns> Well, the way its designed now, the author has to reproduce the maps both sides. But I think we could enhance it.
# [18:44] <Lachy> mjs, Consider Use Cases would put forth as a possible alternative name. It sounds reasonable.
# [18:44] <Lachy> though I do like pave the cowpaths
# [18:45] <anne> enhance it for what reason? what's the use case sites are currently hacking around?
# [18:45] <robburns> anne: but the enhancement would be mostly what it was meant to be in HTML 4.01 (admittedly with some interpolation)
# [18:45] <mjs> Lachy: a snippet of markup that you commonly see on the web isn't really a use case in itself, it's just an authoring practice that perhaps leads to discovering use cases when studied
# [18:45] <Lachy> robburns, see that map example that was pointed out earlier. I think the accessibility issues are solved nicely without a client side image map
# [18:45] <Philip`> s/interpolation/extrapolation/ :-)
# [18:45] <anne> it's not clear to me what problem you're trying to solve
# [18:45] <robburns> anne: It's the same use-case as the server-side map. Are you saying that you don't see a use-case for server-side?
# [18:45] <robburns> Lachy: do you mean with select?
# [18:46] <mjs> there's a multi-stage process, study authoring practices --> sample markup --> investigate use cases --> use cases --> design feature to address use cases --> spec
# [18:46] <Lachy> no, I mean the arrows surrounding the map for moving the map around and the numbers used for chaging the zoom level
# [18:46] <robburns> Philip: yes :-)
# [18:46] <mjs> there is both goodness in that whole process, and in the idea that sometimes the spec might match what authors do already
# [18:46] <anne> robburns, please read what I say :)
# [18:47] <Lachy> mjs, the use case for <br/> is to assist with the transition from XHTML1 to HTML5 without too many useless changes
# [18:47] <anne> Lachy, yes, that's more paving a cowpath than using <video> instead of Flash imo
# [18:48] <anne> same with <html xmlns=http://www.w3.org/1999>
# [18:48] <Lachy> I think they are both cowpaths that should be included, if the <br/> one is clarified
# [18:48] <Philip`> s/1999/1999\/xhtml/ :-p
# [18:49] <anne> oops
# [18:49] <Lachy> woot! Party like it's http://www.w3.org/1999 !
# [18:50] <robburns> anne: I did. I'm not sure which one you're talking about
# [18:50] <robburns> Lachy: are we talking about the IRC logs as a map?
# [18:51] <Lachy> robburns, what? I don't understand the question. Can you rephrase it?
# [18:51] <robburns> Lachy: I'm trying to find the example you're talking about
# [18:51] <anne> robburns, what use case are sites trying to work around that requires an addition? of a feature to HTML?
# [18:51] <Philip`> http://aikataulut.ytv.fi/reittiopas/en/?keya=pasila&a=17816&an=&bb=17838%3At1a2551837a6673309%3AKamppi%3A740%3A&bn=&keyb=kamppi&hour=22&min=23&vm=1&day=15&month=08&year=2007&va=2&;adv=
# [18:51] <Philip`> then "Show route"
# [18:52] <robburns> annne: I'm not convinced its an added feature to HTML
# [18:52] <robburns> anne: Firefox appears to do what I'd expect
# [18:52] <robburns> anne: though I don't have a server-side to play with submission at the moment
# [18:53] <anne> just use GET and you can see what's being submitted...
# [18:53] <Lachy> robburns, how does Firefox do what you expect with <input usemap>?
# [18:53] <Philip`> robburns: As I understand it, you expect <input type=image usemap=#m> to submit the form when you use its client-side image map; Firefox doesn't do that, it just jumps directly to the <area href>
# [18:54] <Lachy> and <area> without href don't submit the form either, they're just inactive regions that do nothing when clicked
# [18:54] <anne> it's not clear to me at all what <input usemap> provides over <img usemap> except maybe that it falls back to being a submit button; however, it seems that most sites already expect <input usemap> to act as a submit button
# [18:54] <hsivonen> Roger: it isn't expected that people would admit to trying to solve problems that are not real. I see the Solve Real Problems principle more as a warning to the community not to fuel questionable concerns.
# [18:54] <anne> (which creates a problem for people implementing <input usemap>)
# [18:55] <hsivonen> Roger: like no one admits to trolling, but still "do not feed the trolls" is sound mailing list advice
# [18:55] <Lachy> robburns, you can experent with image map form submission using the live dom viewer. Just use <form method=get action=""> to have it submit to itslef.
# [18:55] <Lachy> s/experent/experiment/
# [18:55] <robburns> Lachy: it adds @title hover-tooltips over each area defined. Which indicates to me its placing areas right where they belong, providing needed visual feedback. With CSS cooperation, it could be an excellent client-side UI feature for HTML apps.
# [18:56] <anne> Roger, why should "when possible" be removed? How do you deal with Flickr in that case?
# [18:56] <Lachy> robburns, do you want the form submission as well, or just following links like it currently does?
# [18:56] <robburns> anne: it provides a cleaner syntax. no hrefs necessary.
# [18:56] <anne> robburns, huh?
# [18:56] * Joins: ROBOd (robod@86.34.246.154)
# [18:56] <anne> robburns, example?
# [18:56] <Lachy> robburns, the form submission is the whole point of using <input>. If you just want the tooltips, then <img> is fine for your needs
# [18:56] <robburns> Lachy: submission. But I think it would be good if we sent the area ID over the wire instead of just the cooredinates.
# [18:57] * Parts: billmason (billmason@69.30.57.156)
# [18:57] <robburns> Lachy: this enhancement would make it so authors could only define the client-side and wouldn't have to replicate the work in handling coordinates on the server-side.
# [18:57] <anne> they can already do that using <img usemap>...
# [18:57] * anne ponders
# [18:57] <Lachy> It's still questionable what problem can't be solved with a) multiple <input type=image value="foo">, b) <select> or radio buttons c) <img usemap>
# [18:58] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [18:58] <robburns> Lachy: I really don't have the means to find examples. I could probably find image-slice-based solutions to this problem. But I don't have the resources to search through source and find things (unless you can point me somewhere).
# [18:58] <anne> just post some code
# [18:59] <anne> as I don't think it does what you say it does
# [18:59] <robburns> anne: I suppose you can make it work with <img usemap> by adding <button> around it?
# [18:59] <Lachy> you don't really need to look at the source to find examples. Just look at what the sites are doing from a users persepctive
# [18:59] <robburns> anne: for some reason that is invalid and given as a bad example in HTML 4.01 (not sure why maybe they're just being silly, but I would want to explore why they discouraged it so much)
# [19:01] <robburns> Lachy; I think most authors who need to do this do it with image slices (using GoLive and DreamWeaver an the like). At least that's what I've seen. But I think a single image with a map is a far better approach.
# [19:01] <robburns> I'm not even saying this is a horrible thing we have to lose. I just don't feel adequate research has been done before eliminating it.
# [19:01] <Lachy> robburns, if they're using it for form submission, present those examples
# [19:01] <anne> well, <input usemap> is not implemented in IE and Safari; it breaks pages in Opera and Firefox -> simple
# [19:02] <robburns> Lachy: Compare your recent post on the placeholder input suggestion to how we learned that <input usemap> was going away.
# [19:02] <anne> (there are zero good use cases addressed by <input usemap> that are not addressed by <img usemap>)
# [19:03] <anne> dropping <input usemap> seems pretty straightforwarded, but I'm still interested in seeing examples that show otherwise
# [19:03] <Lachy> robburns, I don't see your point? What specifically am I to look for in placeholder vs. usemap?
# [19:03] <anne> so far I haven't seen any except for the one I made up earlier with submit button fallback but that's not really useful
# [19:03] <robburns> Lachy: no implementation comparisons. A search for <input usemap> where usemap pointed to areas with href (when they don't require href with usemap). And announcement that its going away. Where's the adherence to principles? Where's the research? etc?
# [19:03] <Lachy> BTW, <button><img usemap></button> doesn't work
# [19:03] <Lachy> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cform%20method%3Dget%20action%3D%22%22%3E%0A%3Cbutton%20name%3Dtest%20value%3Dfoo%3E%3Cimg%20src%3Dimage%3E%3C/button%3E%0A%3Cmap%20name%3Dfoo%3E%0A%3Carea%20coords%3D%220%2C0%2C100%2C100%22%20href%3D%22http%3A//www.google.com/%22%3E%0A%3C/map%3E%0A%3C/form%3E
# [19:04] <robburns> anne: but the same thing could be said about <input type='image' > and <img> themselves.
# [19:04] <robburns> anne: Why keep <input type='image' > at all then?
# [19:04] <Philip`> <input type=image> is needed in order to support existing content, since people use it now
# [19:05] <Philip`> <input type=image usemap> isn't, since people don't
# [19:05] <Lachy> robburns, type=image does solve a problem. It allows users to submit a form using an image, for which there are lots of examples. Extending that to specifically using or requiring an image map does not
# [19:05] * Quits: Roger (roger@213.64.74.230) (Quit: Roger)
# [19:05] <anne> robburns, <input type=image> is used all over the place and sites rely on it working
# [19:06] <robburns> Lachy: what I'm saying to look for in those differences is how you're work was quite rigorous focussed on design principles, showed some use-cases and then made your proposal.
# [19:06] <anne> in general sites rely on <input usemap> _not_ working
# [19:06] <anne> pretty simple decision
# [19:07] <gsnedders> robburns: one of the design principles is also support existing content. supporting <input usemap> goes against that.
# [19:07] <robburns> Lachy: Hixie's on the other hand presented nothing except for some misguided Google searches for the wrong markup and then said that meant there was no justification for <input usemap>. And then everyone just jumps on the bandwagon without any request for supporting evidence. If anyone else tried to make much more effort at a proposal, no one would let them get away with it.
# [19:08] <robburns> anne: but you were talking about its redundancy. <input type='image'> is redundant with <img> in the same way that the usemaps are redundant.
# [19:08] <anne> misguided Google searches? hah
# [19:09] <anne> robburns, no, <input type=image> submits a form
# [19:09] <Lachy> robburns, the stats weren't the only reason for it being omitted. The reason was that within those examples, none of them demonstrated a convincing use case for it.
# [19:09] <gsnedders> robburns: in the same way? in what way does <input type=input> break things?
# [19:09] <robburns> gsnedders: no one has presented any evidence that there's no <input usemap> out there You just keep asserting it.
# [19:09] <gsnedders> robburns: find it.
# [19:09] <robburns> anne so does <input usemap> submits a form.
# [19:09] <robburns> Lachy: But Hixie only looked at the most bizarre cases
# [19:10] <anne> not if it has an associated map (that in the typical case breaks a page)
# [19:10] <anne> no, he studied the relevant cases...
# [19:10] <robburns> Lachy: Hixie didn't look for the cases where <input usemap> had areas with no href on them
# [19:10] <gsnedders> robburns: and if sites rely on it, why is it not supported in IE?
# [19:10] <robburns> Lachy: those would be the interesting use cases to look for.
# [19:11] <robburns> anne: only if you attach href to them and break the input map
# [19:11] <robburns> anne: no he didn't. That's clear
# [19:11] <Lachy> I believe he did originally, but decided to omit them because they would only be useless noise, since browsers don't do anything at all interesting with it.
# [19:11] <robburns> gsnedders: I don't know that its not supported in IE.
# [19:11] <anne> robburns, yes, only with href an image map does something interesting
# [19:11] <Lachy> robburns, that's why I've been trying to get you to find examples that use alternative solutions, because we know the usemap solution you're asking for doesn't exist
# [19:12] <robburns> gsnedders: I would also expect it to degrade gracefully
# [19:12] <anne> robburns, also, only with href will it break pages and therefore it's interesting to see if pages break for user agents implementing the feature
# [19:12] <robburns> gsnedders: so if it doesn't work in IE, it just means a worse user experience (and no accessibbility) perhaps.
# [19:12] <gsnedders> robburns: in pages looked it, it means a _better_ user experience
# [19:12] <anne> indeed
# [19:12] <robburns> Lachy: how oculd you know that
# [19:12] <robburns> s/oculd/could
# [19:13] <anne> by researching browser behavior?
# [19:13] <Lachy> by looking at what browsers do with <area> that don't have href and seeing that it makes the user experience worse and does nothing at all useful
# [19:13] <Lachy> ... in current implementaitons
# [19:14] <robburns> Lachy: it does in Firefox and it could provide much more in HTML5
# [19:15] <Philip`> robburns: Do you mean it does do something useful in Firefox?
# [19:15] <robburns> We're just going around in circles here. I haven't done research. It's clear non of you have done any research. It doesn't really help to just continuing the back and forth. I'll try to look into it a little. I just think it's remarkable to compare the proposal Lachy just made for placeholder with the non-rproposal we saw to change the draft to get rid of <input usemap>
# [19:15] <Philip`> I've never seen an href-less <area> do anything at all when you click on it, in any browser
# [19:15] * anne hopes robburns is finally going to show his example
# [19:15] <Philip`> (...except via onclick and stuff)
# [19:16] <anne> robburns, it's clear we haven't done research?
# [19:16] <robburns> Philip: are you saying when its part of a form, it doesn't submit?
# [19:16] <anne> oh well
# [19:16] <Lachy> robburns, we've done lots of research. Remember when I went through those 50 example pages looking at what each was using the usemap for? That took a lot of effort and I take offense when you dismiss my effort as not being research
# [19:17] <robburns> Lachy: yes those 50 example pages were part of Hixie's mistaken assumption that <input usemap> was exactly the same as <img usemap>. You were looking at the wrong pages.
# [19:18] <Philip`> robburns: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cmap%20name%3D%22m%22%3E%3Carea%20shape%3D%22rect%22%20coords%3D%220%2C0%2C200%2C100%22%20title%3D%22Area%22%3E%3C/map%3E%0D%0A%3Cform%20onsubmit%3D%22alert%28%27Submitted%21%27%29%22%3E%3Cinput%20type%3D%22image%22%20usemap%3D%22%23m%22%20src%3D%22image%22%3E%3C/form%3E
# [19:18] <Philip`> In Firefox 2 and 3 and in Opera 9.2, holding the mouse over the image shows the tooltip, and clicking does nothing at all
# [19:18] <anne> indeed, which is how <area> is defined
# [19:19] <robburns> See Hixie's email http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-August/012334.html
# [19:19] <anne> please do some research first robburns instead of guessing how things could theoretically work in Firefox; that's not really useful
# [19:19] <robburns> In Safari 3.0 I get a submission
# [19:19] <anne> what is useful here is that actual pages are being broken by supporting <input usemap>
# [19:20] <anne> robburns, exactly! Safari doesn't support <input usemap> so it works fine :)
# [19:20] <robburns> anne simma down
# [19:20] <anne> ?
# [19:20] <Philip`> Safari and IE ignore the usemap entirely, and treat it like a plain <input type=image>
# [19:20] <robburns> anne: it's working
# [19:20] <anne> what is working?!
# [19:20] * Joins: kingryan (rking3@208.66.64.47)
# [19:20] <robburns> Philip: what should I expect on clicking in your example?
# [19:21] <anne> ...
# [19:21] * Joins: Roger (roger@213.64.74.230)
# [19:21] <robburns> anne: Philip's example works in Safari 3.0
# [19:21] <gsnedders> robburns: that's because Saf doesn't support <input usemap>
# [19:21] <robburns> anne: I click, it submits
# [19:21] <Philip`> robburns: It "works" to the same extent that <input type="image" givemelotsofmoney="false"> "works"
# [19:21] <anne> robburns, yes, my point exactly
# [19:21] * anne isn't sure what robburns is missing here
# [19:22] <gsnedders> robburns: according to HTML4, there should be a tooltip saying "Area" on the image
# [19:22] <Lachy> robburns, by your logic, and I can claim that <input type=image magic=abracadabra!> works!
# [19:22] <robburns> Philip: what would I expect if it did work? Worked in the way you think it should?
# [19:22] <robburns> gsnedders: i know that
# [19:23] <robburns> Philip: Firefox provides a tooltip.
# [19:23] <anne> and doesn't submit...
# [19:23] <Philip`> Firefox/Opera provide a tooltip and don't submit the form
# [19:23] <Philip`> IE/Safari don't provide a tooltip and do submit the form
# [19:23] <anne> difference: one set of browsers supports <input usemap>
# [19:23] <Philip`> Whatever you expect to happen, it breaks in half the browsers
# [19:23] <robburns> Philip: I see.
# [19:24] * Quits: Roger (roger@213.64.74.230) (Quit: Roger)
# [19:25] <robburns> Philip: What I don't understand is that before you said adding a new feature that did work (basically 1) tooltips; 2) clicking submits the form; and 3) perhaps CSS enhancements) should be done with an entirely new proposal. Why wouldn't it just make sense to make this really useful in the way I'm suggestion and get the implementations fixed?
# [19:26] <anne> 1) it's not clear it's needed 2) <input usemap> breaks sites
# [19:26] <anne> something doesn't become "really useful" without convincing use cases; I haven't seen much so far
# [19:28] <Philip`> Currently, nothing provides a tooltip while also submitting the form. Any new content which relied on that behaviour would fail in every current browser - and it would fail differently in the two sets of browsers. [...]
# [19:29] <Philip`> Any attribute other than 'usemap' would fail equally in all browsers (by being ignored), which makes it much easier to degrade gracefully in a consistent manner
# [19:29] <robburns> Philip: I understand that, but as a new feature. As an enhanced user experience for HTML5, it makes sense to me to try to redirect implementations on this feature.
# [19:30] <robburns> Phlip: but that's the same for most any HTML5 enhancement.
# [19:31] <Philip`> As a new feature, it's unrelated to <input usemap>, and it seems actively harmful to try associating it with <input usemap> given the compatibility issues
# [19:31] <Lachy> robburns, your tooltip case would be slightly stronger if there was a browser that supported <area title> for <input usemap> and submitted the form. But since that doesn't exist, there's no reason that an author would do that
# [19:31] <robburns> Philip: in the two that submit it degrades gracefully in the sense that as soon as the enhancements are added, the user gets the enhanced user-experience.
# [19:32] <Philip`> and associating it with <input usemap> causes confusion, since it's unclear when people are talking about existing implementations or existing specifications or theoretical new behaviour models
# [19:32] <anne> it's still not clear what the use case is
# [19:32] * Parts: johnst (johnst@83.89.44.198) (Leaving)
# [19:32] <anne> server-side image maps are already a really small use case
# [19:33] <Philip`> robburns: <input type=image tooltipmap=#m> degrades gracefully in all browsers, and all > 2
# [19:33] <robburns> Lachy: I understand. However, what that means is that we should expect to find little use in the wild of that approach (since it doesn't work). However the major web designer tools provide all sorts of authoring tools to accomplish this in a more cumbersome way through image slices.
# [19:33] <Lachy> if we accept for the moment, that robburns is discussing usemap as an entirely new feature, the major problem with continuing this discussion is the lack of significant and convincing use cases
# [19:34] <Lachy> robburns, that's why it would have been pointless for Hixie to include such sites in the survey
# [19:34] <anne> image slicing? isn't http://www.alistapart.com/articles/sprites/ more useful for that?
# [19:34] * Joins: tH_ (Rob@87.102.85.245)
# [19:34] <robburns> Lachy: however if we assume that the drafts we have already have <input usermap> in them, instead we're discussing the need to find evidence and convince the WG to eliminate the feature (even though when implemented it provide significant usability enhancements, accessibility enhancements and paves a cowpath.).
# [19:34] <anne> it would be great if you provided clear use cases
# [19:35] <robburns> The case has to be made to eliminate the feature not to add it. I'm just trying to make the case for what great enhancements we could have with this existing feature.
# [19:35] <Lachy> anne, image slices means things like cutting up a huge graphic and laying it out with tables
# [19:35] <anne> I know what image slicing is :)
# [19:35] <Lachy> the case to eliminate the feature is based on the fact that there is no case to add it.
# [19:35] * Quits: tH (Rob@87.102.94.41) (Ping timeout)
# [19:35] * tH_ is now known as tH
# [19:36] <Lachy> oh, then I'm not sure what the relevance of the sprites article was
# [19:36] <anne> robburns, no you're not, you haven't provided use cases so far
# [19:36] <robburns> Lachy: a better case has to be made than that.
# [19:36] <robburns> anne: no I'm not what?
# [19:36] <anne> robburns, one was made, it was pointed out several times that this feature breaks sites
# [19:37] * Quits: beowulf (beowulf@87.198.168.38) (Ping timeout)
# [19:37] <anne> robburns, you're not making the case for what great enhancements we could have
# [19:37] <Lachy> robburns, you've described theoretical use cases, but you need to demonstrate that a) those use cases really exist. b) any existing solutions to those use cases have problems that need solving and c) usemap solves those problems
# [19:37] <robburns> anne: it doesn't break sites. two implementations are broken. However, having it work suddenly wouldn't break any sites. Where' your evidence for that?
# [19:37] <Philip`> The case for eliminating the current <input usemap> feature is (as I see it) completely unrelated to the case for adding a new feature which nobody implements yet and which could possibly use the <input usemap> syntax
# [19:38] <anne> robburns, define "having it work"
# [19:38] <robburns> Lachy: you're not asking for use-cases then, you're asking for real-world examples. There's a difference.
# [19:38] <anne> it already breaks sites per the current vague definition of HTML4
# [19:38] <gsnedders> robburns: "two implementations are broken" — according to what?
# [19:38] <Lachy> I'm asking for examples that demonstrate those use cases
# [19:38] <gsnedders> robburns: what is it broken according to?
# [19:39] <anne> this seems like quite a waste of time...
# [19:39] <robburns> anne: you claimed it breaks sits. I said no it doesn't. If a site tried to use this feature, They'd have a working site in Safari and IE. If Opera and FF suddenly added support. Those sites would work in more browsers (not break).
# [19:39] <robburns> anne: if browsers added other enhancements, the feature would just work better and better and better.
# [19:40] <gsnedders> robburns: it wouldn't work in Saf or IE. They ignore the usemap.
# [19:40] <anne> Opera and FF _have_ support
# [19:40] <robburns> gsnedders: according to Phlip's tests, Opera and FF do not submit the form
# [19:40] <anne> I don't understand what you're saying at all
# [19:40] <gsnedders> robburns: that's completely conformant to HTML 4.01
# [19:41] <robburns> gsnedders: also IE and Safari do not add the tooltip support (perhaps there's no mouse events at all)
# [19:41] <gsnedders> robburns: both are conformant behaviours.
# [19:41] <gsnedders> robburns: IE and Saf just ignore @usemap on |input|
# [19:41] <gsnedders> robburns: they don't get as far as even knowing there's a @title affecting it
# [19:42] <robburns> gsndedders: finally, I'd like to liaison with the CSS WG to add CSS image map support (this would work both with <input usemap> and <img usemap>). In this way the feature would get even better with time. I'm saying the feature needs to be given a chance.
# [19:42] <gsnedders> robburns: it's had a chance in the years since HTML 4.01 shipped, and since FF and Opera shipped support for it.
# [19:43] <anne> for what use cases? you keep talking about features...
# [19:43] <robburns> gnsedders: understood about the ignoring. The point is keeping it doesn't break anything. Adding the mouse events will suddenly bring an enhanced user experience. (in other words it can already be a server-side map with no client-side or accessibility support in those browsers), One day a new browser version and the site gets better.
# [19:44] <robburns> gsnedders: no it didn't have a chance. It got lost somewhere along the way. CSS completely overlooked the issue.
# [19:44] <Philip`> Why is there value in liaising with the CSS WG, rather than you simply proposing a feature to the CSS WG with no HTML WG involvement?
# [19:44] <Lachy> there are technical reasons for limited amount of CSS that can apply to <area> elements, and even some special casing for the cascade
# [19:44] <gsnedders> robburns: how does it being spec'd in HTML 5 and being supported by FF and Opera make any difference to it having a chance?
# [19:44] <robburns> gsnedders: I'll make you a deal. We dust it off give shiney new wheels. And in 10 years or 15 years if it's still not working when we're talking about HTML6, I'll drop the whole issue.
# [19:45] <robburns> Lachy: what are the technical limitations?
# [19:45] * Lachy goes to find them...
# [19:45] <robburns> Lachy: the areas just need mouse events. It's obviously got something like that in FF
# [19:46] <anne> one problem is that a map can be associated with different images at the same time
# [19:47] <robburns> Phlip: I think we should definitely liaison with CSS WG over this. Even if <input usemap> is gone, <img usemap> could use some CSS attention.
# [19:47] <robburns> anne: OK
# [19:47] <anne> it's not clear how that's better than CSS better supporting sprites for instance
# [19:47] <robburns> anne: I dont't see why that would be a prolbem.
# [19:47] <robburns> s/prolbem/problem
# [19:47] <anne> might just be an issue for focus traversal
# [19:47] <Lachy> robburns, http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011246.html - only cursor: applies to area and it inherits some properties from the <img>, rather than the <map>
# [19:49] <robburns> Lachy: I know CSS is inadequate now for the job. But I can't think of any technical issues that would prevent it from doing a better job with client-side image maps
# [19:50] <robburns> in the future. Even in the CSS3 time-frame
# [19:50] <anne> hopefully you can think of use cases by the time you get arround to proposing it ;)
# [19:50] <robburns> and again, this could even be done for <img usemap> if we do decide to drop <input usemap>
# [19:50] <robburns> :-)
# [19:53] * Quits: anne (annevk@81.68.67.12) (Ping timeout)
# [19:57] * Joins: mjs (mjs@17.255.105.171)
# [20:03] <Philip`> https://bugzilla.mozilla.org/show_bug.cgi?id=31188 - sounds like the Mozilla developers didn't even know they had implemented it
# [20:03] <Lachy> hmm. Steve makes a very good point aobut universal access vs. accessibility principle http://lists.w3.org/Archives/Public/public-html/2007Aug/0663.html
# [20:04] <Lachy> I would either merge Media Independence" and "Support World Languages" with Accessibility into Universal Access, or separate them all out into separate principles.
# [20:08] <Lachy> now we should report a bug and have them remove the behaviour, since it breaks real world sites
# [20:09] <Philip`> http://blog.johnath.com/index.php/2007/08/20/ssl-infoporn/ - from the final image, it looks like people don't actually all blame their browser when something confusing and unhelpful happens
# [20:13] <Lachy> the principles should be broken into 4 categories. Compatibility, Utility, Interoperability and Universal Access. The first 3 are already there, the Universal Access should include Support World Languages, Media Independence and Accessibility principles
# [20:26] * Joins: polin8 (polin8@64.81.134.176)
# [20:29] * Quits: polin8 (polin8@64.81.134.176) (Quit: :wq)
# [20:39] * Quits: hendry (hendry@91.84.62.62) (Quit: ciao)
# [20:43] * Joins: anne (annevk@86.90.70.28)
# [20:46] * Quits: robburns (robburns@66.149.74.142) (Quit: robburns)
# [21:01] * DanC braces for impact... "Roy Fielding has joined the HTML Working Group"
# [21:02] * Joins: robburns (robburns@98.193.22.194)
# [21:03] * Quits: robburns (robburns@98.193.22.194) (Quit: robburns)
# [21:10] <Philip`> Does http://canvex.lazyilluminati.com/misc/ref.html look like a useful style for an author-friendlier version of the spec? (It's meant to be more precise and more complete and less friendly than a tutorial, but more useful for non-implementors than the current spec)
# [21:11] <Philip`> (It seems easier to do a separate document and copy-and-paste suitable bits of the main spec, than to try to be clever and just cut bits out of the spec with CSS)
# [21:18] * Quits: laplink (link@193.157.66.214) (Quit: Leaving)
# [21:18] * Joins: laplink (link@193.157.66.214)
# [21:20] * Joins: billmason (billmason@69.30.57.156)
# [21:39] <anne> Philip`, it's quite nice
# [22:02] <anne> I'm not sure about other people, but I would classify Sam's proposal as unnecessary code bloat as it leads to more code paths, more QA cost, more complexity, etc.
# [22:07] <Lachy> Hixie, what are the security issues with sniffing text/plain as HTML?
# [22:07] * Joins: hyatt (hyatt@17.203.15.154)
# [22:10] <anne> example source code demonstrating XSS attack?
# [22:12] <Philip`> Lachy: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-May/011458.html was one example
# [22:13] <Hixie> what they said
# [22:14] <Lachy> ok. So I guess that means tough luck to those users with hardwrare like modems and routers that have built in config pages served as text/plain. An old one of my did that, had to use IE to configure it
# [22:15] <anne> it's also tough luck if a site does if(firefox) { ... }
# [22:16] <Hixie> no, i strongly believe that browsers should offer overrides to the user
# [22:16] <Hixie> i'm only talking about default behaviour
# [22:16] <Lachy> ok, so popping up a yellow information bar or something would be acceptable
# [22:17] <Hixie> right
# [22:17] <Lachy> although, perhaps not. I wonder how many users blindly install activex controls when that pops up?
# [22:18] <Hixie> you could do things like disable JS on such pages by default, requiring a second infobar to enable scripting
# [22:18] * jgraham suspects mpt would go spare at the thought of exposing MIME types to the user
# [22:18] * Quits: anne (annevk@86.90.70.28) (Ping timeout)
# [22:18] <jgraham> Or even content sniffing without MIME types
# [22:19] <mjs> I doubt I could get "This page was served with the wrong MIME type, should I actually show it to you or do you like these funny angle brackets" past Steve Jobs
# [22:19] * Joins: anne (annevk@86.90.70.28)
# [22:21] <mjs> but at least speccing specific rules for content sniffing has the potential to de-escalate the arms race and maybe phase it out some day
# [22:21] * Quits: hyatt (hyatt@17.203.15.154) (Ping timeout)
# [22:22] <Hixie> mjs: could you get "This page could be be attempting to impersonate you. Would you like to view it as HTML anyway?" past him?
# [22:22] <jgraham> Hixie: AIUI, that kind of security warning doesn't work.
# [22:23] <jgraham> People just click the "show me the content dammit" button
# [22:23] <jgraham> because they have no way of gauging whether the page is actually trying to do the evil thing
# [22:23] <Hixie> mjs: and hey, you got View > Text Encoding past him, why not get View > Interpret As past him?
# [22:23] <kingryan> it sounds like we need "damnit mode" for content types
# [22:23] <mjs> Hixie: I doubt it, security warnings tend to result in more annoyance than security, but I don't think that's accurate anyway, is it?
# [22:25] <mjs> Hixie: at worst the page could be the result of someone trying to impersonate the site it came from
# [22:25] <Hixie> jgraham: yeah, i would prefer the same approach as used now for character encodings
# [22:25] <mjs> Hixie: View > Interpret As might possibly fly, as long as the default was a reasonable level of sniffing
# [22:26] <mjs> but that doesn't help at all with potential security issues, only with the expert "I really want to see this processed differently" case
# [22:27] <mjs> probably too expert-y to be worth it
# [22:27] <Hixie> mjs: if by "reasonable level" you mean what's in the spec now, then sure, that's what i'm proposing
# [22:27] <Lachy> The View > Interpret As solution might be reasonable. There are existing bookmarklets and extensions that add similar functionality to Firefox
# [22:28] <mjs> I'm not sure we could remove the text/plain sniff for HTML
# [22:28] <mjs> but I am open to quantitative data on this front
# [22:29] <mjs> if there is networking hardware configured this way it would be a very tough sell
# [22:29] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
# [22:31] <Hixie> [24~(or something not far from the current spec that is derived from actual needs)
# [22:33] <mjs> I think there are few cases where "interpret as" would do something interestingly different than "View Source" in Safari
# [22:33] <mjs> syndication feeds would be the main case where that's true
# [22:34] <Hixie> i'm not convinced you need to do text/plain->html
# [22:34] <Hixie> firefox doesn't
# [22:35] <Hixie> i agree you need some limited text/plain->video (or rather, to binary)D download
# [22:35] * Joins: dbaron (dbaron@63.245.220.241)
# [22:36] <DanC> the video case is different, isn't it? I mean: when you know you're looking for video or an image, that's not "Determining the type of a new resource in a browsing context"
# [22:37] <DanC> is it?
# [22:37] <anne> it is, if you "download" one directly
# [22:37] <DanC> oh... sometimes you just follow a link and get video.
# [22:40] * Philip` wonders what Mozilla's security.requireHTMLsuffix pref is meant to do
# [22:40] <Philip`> (It's in http://lxr.mozilla.org/mozilla/source/netwerk/streamconv/converters/nsUnknownDecoder.cpp#78 but I can't find any cases that act differently depending on whether I've got it set)
# [22:41] <Hixie> i mean when you click on a link to a file that is text/plain
# [22:41] <Hixie> [24~this is very common on porn sites
# [22:54] * Joins: Lionheart (robin@66.57.69.65)
# [22:58] * Joins: hyatt (hyatt@17.203.15.154)
# [23:05] <Philip`> Hixie: Your email linked to http://www.whatwg.org/issues/ twice, and not to http://www.whatwg.org/issues/top
# [23:09] * Quits: Lachy (chatzilla@124.170.99.178) (Ping timeout)
# [23:11] * Joins: edas (edaspet@82.233.238.50)
# Session Close: Tue Aug 21 00:00:00 2007

The end :)