| 00:01 | <masinter> | i'm tracking down more stuff about mime sniffing |
| 00:02 | <Philip`> | With all this sniffing, has anybody worked out what mimes smell like yet? |
| 00:02 | <masinter> | The Barth paper contains the claim "Once one browser vendor implements content sniffing, the other browser vendors are forced to follow suit or risk losing market share [1]", where [1] is not some study of market share of browser vendor behavior, but just some mozilla bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=175848 |
| 00:03 | <masinter> | well, seems like a pretty smelly reference |
| 00:05 | <masinter> | it's a pretty astounding claim, really, that browser market share depends on content type sniffing |
| 00:05 | <masinter> | rather than, say, performance, ease of use, conformant behavior when confronted with actually properly labelled content |
| 00:05 | <jgraham> | It's a pretty astounding claim that it doesn't |
| 00:05 | <masinter> | it doesn't what? |
| 00:06 | <jgraham> | Depend on content sniffing |
| 00:06 | <masinter> | i mean that it's a more significant factor than 100 other things |
| 00:06 | <jgraham> | It doesn't have to be |
| 00:06 | <jgraham> | It just has to be a sufficienty significant factor |
| 00:06 | <jgraham> | Which it is |
| 00:06 | <tantek> | it's the standard, if the browser doesn't show the web page (properly), or shows it in some broken way, the user tries a different browser, if the other browser appears to "work", the user sticks with it. |
| 00:07 | <masinter> | how significant a factor is it? |
| 00:07 | <jgraham> | Indeed, users couldn't care less about whether content is properly labelled or not |
| 00:07 | <tantek> | more significant than performance, pretty GUI, brand name, etc. |
| 00:07 | <Philip`> | I think its significance is about 0.18 |
| 00:07 | <jgraham> | masinter: I don't know how to put in on a scale. |
| 00:08 | <masinter> | i mean, 1% of the population would switch from FirefOx to Chrome if Chrome sniffed and FireFox didn't, even if Firefox was faster and implemented more other features? |
| 00:08 | <tantek> | none of that matters if the browser "breaks" from the user's perception. |
| 00:08 | <jgraham> | It is significant enough that it has to be there |
| 00:08 | <masinter> | exactly this response has to be there? |
| 00:08 | <Philip`> | It is believed by browser vendors to be significant enough that it has to be there |
| 00:08 | <masinter> | i mean, this is a major "feature" and the justification is that someone read a bug report? |
| 00:09 | <jgraham> | Philip`: Those two statements are roughly equivalent |
| 00:09 | <masinter> | which product manager would back that up? |
| 00:09 | <tantek> | "oh this browser doesn't work with my bank, I'll try another browser, or ask my friends which browser they use and try that. oh look this other browsers seems to 'work' with my bank, and is fine with other sites too, I'll stick to it." |
| 00:09 | <masinter> | which banks have misconfigured web servers? |
| 00:09 | <tantek> | which banks don't? |
| 00:09 | <jgraham> | masinter: Working with the web is a major feature. In a web browser |
| 00:09 | <masinter> | sure, some user sites, c'mon tantek |
| 00:09 | <tantek> | misconfigured HTTP, HTML you name it |
| 00:09 | <Philip`> | The theoretically quantifiable figure is probably more like: If a million happy Firefox users try out Chrome, how many abandon Chrome because one of the websites they like to visit fails to work in Chrome (due to sniffing differences) |
| 00:09 | <masinter> | you're making circular definitions |
| 00:09 | <tantek> | know any bank sites that validate? good luck. |
| 00:10 | <masinter> | name one, Tantek, that has misconfigured mime types? |
| 00:10 | <masinter> | this isn't about validation, it's about content-type sniffing |
| 00:10 | <tantek> | nope - all the same |
| 00:10 | <masinter> | my left shoe isn't configured properly either |
| 00:10 | <tantek> | it's all about compat |
| 00:10 | <masinter> | tantek, what is all the same? |
| 00:10 | <tantek> | to the user it's all the same. my browser is broken. |
| 00:10 | <masinter> | hmmm, argument by assertion? |
| 00:10 | <tantek> | doesn't matter whether the pipe or pipe-fitting is broken |
| 00:11 | <jgraham> | masinter: Since banks typically require a login it is rather hard to verify whether they have configured their server correctly |
| 00:11 | <tantek> | and experience. i've built browsers. |
| 00:11 | <masinter> | i understand the nature of the argument, tantek, and repeating it doesn't help |
| 00:11 | <tantek> | and usertested browser useres. |
| 00:11 | <tantek> | users even |
| 00:11 | <masinter> | |<tantek> "oh this browser doesn't work with my bank, I'll try another browser, |
| 00:11 | <tantek> | this is one of those "duh" things to anyone who builds browsers. |
| 00:11 | <jgraham> | tantek: indeed |
| 00:11 | <masinter> | "duh" "duh" |
| 00:12 | <masinter> | well, it's a "duh" argument indeed that if you make claims about banks and user behavior and market share that you have to have more than saying "well, duh, we're right and you're wrong nyah nyah nyah" |
| 00:12 | <Hixie> | masinter: market research data that i've seen from two different browser vendors puts compatibility with sites as the number #1 reason for switching browsers |
| 00:12 | <Hixie> | literally above all else |
| 00:13 | <Hixie> | more important than security, than having extensions/add-ons, than having features, than speed, anything |
| 00:13 | <masinter> | well, why is the citation in http://www.adambarth.com/papers/2009/barth-caballero-song.pdf to a mozilla bug report? |
| 00:13 | <jgraham> | I would say that Hixie's data matches my experience |
| 00:13 | <Hixie> | what else would you cite? browser vendors aren't going to publish the data telling their competition why they are losing customers! |
| 00:14 | <masinter> | I mean, if there were any market research data, why cite the bug report? |
| 00:14 | <Hixie> | i don't think i've seen any of these numbers publicly |
| 00:14 | <masinter> | oh, well, you could cite "John Q. Product Manager, Personal Communication" |
| 00:14 | <jgraham> | masinter: I doubt the market research data mentions content type sniffing explicitly |
| 00:14 | <masinter> | jgraham: so you have any personal experience with content-type sniffing? |
| 00:15 | <masinter> | i was just looking at the table again, and noticing content-type sniffing for application/postscript |
| 00:15 | <jgraham> | masinter: It's not something I have worked on directly. So only the amount of experience you get by osmosis doing general browser QA |
| 00:15 | <masinter> | and trying to figure out why a user would switch browsers if the browser they were using wouldn't sniff application/postscript |
| 00:16 | <masinter> | i mean, since it doesn't help you any to sniff postscript, because most people don't have a postscript interpreter installed anyway |
| 00:16 | <Philip`> | If I clicked a link to a .ps file of an academic paper and got a load of gibberish text, I'd be pretty unhappy |
| 00:16 | <tantek> | masinter, perhaps Adobe could fund a development experiment to create a "conformant" (but real-world-web-site-content-breaking) browser (e.g. fork Moz or WebKit and rm all the compat behavior) and see if anyone bothered to use it as a primary browser. |
| 00:16 | <masinter> | so how does the market share loss argument (which is unsubstantiated) even apply for postscript? |
| 00:16 | <masinter> | so you'd want it to infer application/octet-stream? |
| 00:17 | <jgraham> | masinter: Well presumably the type of people looking at postscript documents have postscript interpreters installed |
| 00:17 | <masinter> | why are you making normative requirements based on presumptions? |
| 00:17 | jgraham | isn't doing anything |
| 00:18 | <masinter> | you don't support making content-type sniffing a normative requirement? |
| 00:18 | <jgraham> | Yes, but that's not what you said |
| 00:18 | <masinter> | ok, let's go break this down |
| 00:19 | <jgraham> | Or, at least, I assumed "making normative requirements" refered specifically to the postscript sniffing |
| 00:19 | <masinter> | do you support http://tools.ietf.org/html/draft-abarth-mime-sniff-01 and the HTML specification's normative reference to that as something HTML interpreters MUST follow? |
| 00:21 | <jgraham> | In general, yes. Possibly some details could be altered, I don't know |
| 00:22 | <masinter> | and, in particular, the requirement in section 3 that the 'sniffed type' for documents labeled text/plain should follow the sniffing algorithm such that data that looks like postscript MUST be treated as application/postscript, even though it is text/plain? |
| 00:22 | <masinter> | what justification is sufficient for altering details? |
| 00:23 | <jgraham> | http://blogs.msdn.com/ie/archive/2005/02/01/364581.aspx |
| 00:25 | <jgraham> | masinter: Details can be altered if a) they don't match current practice and implementors refuse to change to match the spec or b) there is a compelling (to implementors) case made that the detail can be changed without adversly affecting marketshare |
| 00:25 | <masinter> | yes, i read that blog but it doesn't answer my question about what you think the criteria is for following exactly what IE happened to do? |
| 00:26 | <masinter> | and how do you measure "adversely affecting marketshare"? |
| 00:26 | <masinter> | i'm just wondering whether "compatibility" is taken as covering a multitude of sins where what was really asked for is much more limited |
| 00:26 | <jgraham> | masinter: That ballis in the court of those trying to change the details |
| 00:27 | <jgraham> | I don't know a-priori what arguments would be compelling to indicate that a specific change would not adversly affect compatibility |
| 00:28 | <masinter> | "ball is in the court" metaphor assumes some ownership of the court, doesn't it? |
| 00:29 | <jgraham> | (but obvious things would be studies indicating that a particular part of the sniffing did not apply to a significant number of pages) |
| 00:29 | <masinter> | after all, the internet draft doesn't match current practice, for good reason |
| 00:29 | <masinter> | well, since there's never been any evidence that anything besides text/plain => html matters, and even then, only for a limited number of sites |
| 00:30 | <masinter> | and since browser content-type sniffing isn't uniform anyway |
| 00:30 | <jgraham> | I guess you mean that you haven't come across the evidence. |
| 00:31 | <jgraham> | I would be very surprised if that was the case |
| 00:31 | <tantek> | masinter, do you have a test case URL that demonstrates non-uniform browser content-type sniffing? |
| 00:31 | <masinter> | i thought XML wasn't uniform |
| 00:31 | <tantek> | no XML is worse, it's draconian |
| 00:31 | jgraham | is going to bed now |
| 00:32 | <masinter> | looking for XML test case |
| 00:32 | <Hixie> | tantek: there are lots of areas of content-type sniffing that aren't uniform -- it leads to security bugs, it leads to an arms race increasing how much is sniffed, and it leads to a general low level of interop; that's why I, and now Adam, are trying to specify this. |
| 00:32 | <masinter> | tantek you think all browsers sniff XML from text/plain uniformly? |
| 00:32 | <Hixie> | tantek: we want to nail it does so that this kind of crap can be uniformly implemented and stop spreading like a cancer |
| 00:33 | <masinter> | yeah, i think you're looking at the wrong end of the telescope, and that every case of sniffing actually needs to be justified by "some users really care" rather than the general principle of "if IE did it, we're going to slavishly follow" |
| 00:34 | <masinter> | i think it's a bad idea to sniff PDF too, for that matter, although Adobe security just said it didn't matter to them much |
| 00:34 | <tantek> | which IE followed vaguely from "if Netscape did it, we're going to follow in order to not 'break' sites" |
| 00:34 | da3d | found a site earlier today that serves up an svg image as text/plain... |
| 00:34 | <tantek> | Hixie, I think your approach to this problem is reasonable. |
| 00:34 | <masinter> | but if something's labeled text/plain but looks like PDF it should still be treated as text/plain, because if the MIME type is broken, probably something else is too |
| 00:34 | tantek | would like to see a path forward out of the compat mess. |
| 00:35 | <masinter> | tantek: are you saying my approach is unreasonable? |
| 00:35 | <Hixie> | masinter: the doc adam is working on is so far removed from what IE does that your suggesting that it has any resemblence to it belies your ignorance of the subject |
| 00:35 | <masinter> | oh c'mon Hixie |
| 00:35 | <tantek> | masinter, no, I can see the reason behind your approach as well. but it's just less practical. |
| 00:35 | <masinter> | now you're gonna start calling me names |
| 00:35 | <masinter> | Jane, you ignorant ... etc. |
| 00:36 | <Hixie> | masinter: well, stop trying to troll us then |
| 00:36 | <masinter> | discussing a subject at your convenience is trolling? |
| 00:36 | <masinter> | everybody who disagrees with you is a troll? |
| 00:37 | <Hixie> | masinter: accusing us of following 'general principle of "if IE did it, we're going to slavishly follow"' is either ignorant or a troll. Which is it? |
| 00:37 | <masinter> | we spent quite a while at the TAG meeting talking about sniffing, and i thought it was worth just, you know, talking about it |
| 00:37 | <tantek> | How many people on the TAG have actually built and shipped a browser? |
| 00:37 | <masinter> | you don't make any provocative statements, do you? |
| 00:37 | <tantek> | (in this decade) |
| 00:37 | <tantek> | (not a rhetorical question) |
| 00:38 | <Hixie> | in #whatwg? i make provocative statements all the time :-) |
| 00:38 | <masinter> | i think it is a pretty irrelevant question, isn't it? |
| 00:39 | <tantek> | not at all, it's the difference between architectural handwaving and shipping software brutally tested by a market |
| 00:39 | <masinter> | oh, ok, 'slavishly' was wrong, how about 'without careful consideration of actual user benefit'? |
| 00:39 | <masinter> | tantek, are you saying the TAG does 'architectural handwaving'? |
| 00:39 | tantek | says this as someone who has done both (handwaving and shipping) |
| 00:39 | masinter | waves his hand to no effect |
| 00:39 | <Hixie> | masinter: seriously? you think we're ignoring the benefits of users? |
| 00:40 | <masinter> | no, i didn't say you were 'ignoring' it |
| 00:40 | <Philip`> | http://www.igmetall-eisenach.de/pressemitteilungen/pressemitteilung_29_08_05_14_07 doesn't look very good for me in Firefox |
| 00:40 | <Hixie> | masinter: what exactly do you think our motivations are? just to make the web a horrible place? |
| 00:40 | <masinter> | i'm just asking about the end user benefit of application/postscript? |
| 00:40 | <Hixie> | masinter: so you're saying we're incompetent? |
| 00:40 | <masinter> | oh c'mon |
| 00:40 | <Hixie> | we don't carefully consider stuff? |
| 00:40 | <masinter> | in this particular instance, i'm asking for the benefit of your careful consideration |
| 00:41 | <masinter> | what is, please, the end-user benefit of content-type sniffing application/postscript? |
| 00:41 | <Hixie> | no, you're just chain-accusing us of random evils |
| 00:41 | <masinter> | really, i came with a specific question about a specific use case |
| 00:41 | <Hixie> | i'm not interested in discussing technical work with people who go from insulting me to trying to act all innocent by asking technical questions |
| 00:41 | <masinter> | and i got platitudes about market share and who has shipped a browser |
| 00:42 | <masinter> | i'm not insulting you, and asking questions and criticizing the specification you wrote is not directed against you |
| 00:42 | <Hixie> | you're not insulting me? let's see. in the last |
| 00:42 | <Hixie> | 10, 20 minutes |
| 00:42 | <masinter> | no, i really am not |
| 00:42 | <Hixie> | you've said: |
| 00:42 | <Hixie> | * that's we're slavishly following a principle of "if IE did it, we're going to follow" |
| 00:43 | <Hixie> | * that we don't consider users carefully |
| 00:43 | <masinter> | well, read what the barth paper says |
| 00:43 | <Hixie> | * that we're giving you platitudes when we're giving you our actual reasoning |
| 00:43 | <masinter> | I didn't say that you didn't consider users in general, but i can't see it in the particular case |
| 00:43 | <masinter> | "Once one browser vendor implements content sniffing, |
| 00:43 | <masinter> | the other browser vendors are forced to follow suit or risk |
| 00:43 | <masinter> | losing market share" |
| 00:44 | <masinter> | how would you interpret that sentence, from http://www.adambarth.com/papers/2009/barth-caballero-song.pdf |
| 00:44 | <masinter> | once one browser vendor implements X, the other browser vendors are forced to follow suit |
| 00:44 | <masinter> | what is that ? Or do you think the paper is wrong? |
| 00:45 | <masinter> | now "one browser" doesn' mean Amaya, of course, it means the unmentionable Internet Exploder |
| 00:45 | <Hixie> | if you want to ask about something adam wrote, i recommend asking adam |
| 00:45 | <masinter> | so was this just academic hyperbole on Barth's part? |
| 00:46 | <masinter> | so you have no opinion about this logic? It isn't the justification for content-type sniffing? |
| 00:46 | <masinter> | when I asked about the content-type sniffing and research, it's the paper Adam pointed me to |
| 00:46 | <Hixie> | i've already given the justification for mime sniffing in this very conversation, let me repaste it: |
| 00:47 | <masinter> | i mean, we could go back to trading email but it's better just to talk this out, you take what i'm saying and make it personal |
| 00:47 | <Hixie> | <Hixie> there are lots of areas of content-type sniffing that aren't uniform -- it leads to security bugs, it leads to an arms race increasing how much is sniffed, and it leads to a general low level of interop; that's why I, and now Adam, are trying to specify this. |
| 00:47 | <Hixie> | i take what you're saying and make it personal when you insult my competence, yes |
| 00:49 | <masinter> | i'm not talking about you, i'm talking about specs and documents |
| 00:49 | <masinter> | and we're better off to focus on that, it was bad enough that mpilgrim wanted to tell me i was ugly |
| 00:49 | <Hixie> | saying that'we slavishly following things, saying that we write specs without "carefully considering user benefits", that's personal |
| 00:49 | <masinter> | wait, i was talking about this sentence in the barth draft |
| 00:49 | <masinter> | "forced to follow suit"? What is that? |
| 00:50 | <Hixie> | you mean his paper? |
| 00:50 | <masinter> | it wasn't about you or Adam, it was what "browser vendors" felt they were "compelled to do" |
| 00:50 | <masinter> | "slavishly follow" == "forced to follow suit" |
| 00:51 | <Hixie> | you just said slavishly follow was wrong! |
| 00:51 | <masinter> | i think that was legitimate english use that was not about you at all, it was about the presumption of what browser vendors felt they had to do |
| 00:51 | <Hixie> | now you're saying it's right? |
| 00:51 | <masinter> | no, the fact that browser vendors may believe they are forced to follow suite -- i don't dispute that they believe that |
| 00:52 | <Hixie> | but you said we were slavishly following IE |
| 00:52 | <Hixie> | which is completely wrong |
| 00:52 | <masinter> | i just think they are wrong, there are lots of things they could do besides "follow suit" |
| 00:52 | masinter | looks back |
| 00:52 | <masinter> | "yeah, i think you're looking at the wrong end of the telescope, and that every case of sniffing actually needs to be justified by "some users really care" rather than the general principle of "if IE did it, we're going to slavishly follow" |
| 00:52 | <masinter> | that's what i said |
| 00:53 | <Hixie> | you also said "oh, ok, 'slavishly' was wrong" |
| 00:53 | <masinter> | and you assumed that i was talking about you having this general principle, but certainly it's clear you odn't |
| 00:53 | <Hixie> | let's start this conversation over because you've contradicted yourself so many times i no longer know what to ignore and what not to ignore |
| 00:53 | <Hixie> | hi larry, how are you? how can i help you today? |
| 00:53 | <masinter> | well, ok |
| 00:53 | <masinter> | what's the justification for sniffing application/postscript ?> |
| 00:54 | <masinter> | i know IE does it, and maybe some other browsers too, but there doesn't actually seem to be any end-user benefit, and potentially some harm instead |
| 00:54 | <masinter> | seems like a bad idea |
| 00:54 | <masinter> | well, i don't know that IE does it, i presume that |
| 00:55 | <masinter> | I'm assuming every bit of sniffing that IS done in draf-barth is becasue someone else already does it, and probably someone else = IE |
| 00:55 | <masinter> | is there a specific end-user benefit for that? |
| 00:55 | <Hixie> | I believe the justification for having sniffing for application/postscript in the spec is that when i created that table, I copied the algorithms in Mozills's codebase that were unambiguously beneficial to users. |
| 00:55 | <masinter> | how were they "unambigiously beneficial"? |
| 00:56 | <masinter> | since in this case the benefit seems mysterious |
| 00:56 | <Hixie> | (IE really has very little bearing on what the content-sniffing draft says, in practice, because we used what the other browsers found themselves forced to implement as a guide for what was actually necessary, and what was not) |
| 00:56 | <masinter> | i mean, just because someone implemented it in Mozilla doesn't mean it is unambiguously beneficial |
| 00:56 | <Hixie> | (IE basically ignores Content-Type 99% of the time, so following IE would basically mean throwing out most of the MIME mechanisms) |
| 00:57 | <masinter> | right? You're not assuming that "since Mozilla did it, it must be right", of course |
| 00:57 | Hixie | looks at adam's draft to make sure he's talking about the right table |
| 00:58 | <masinter> | " I copied the algorithms in Mozills's codebase that were unambiguously beneficial to users." -- how did you determine "unambiguously beneficial"? |
| 00:59 | <Hixie> | this sniffing is beneficial because if a user finds a page with no MIME type, or the MIME types unknown/unknown, application/unknown, or */*, or if the user loads a text/plain page that is clearly not text/plain (since it contains raw binary), and if the page is in fact a postscript page, it's more useful to show the postscript in an interpreted fashion than expose the user to the source of the file. |
| 00:59 | <Hixie> | in practice, in particular, users prefer browsers that allow them to print the resulting files, rather than show the source |
| 01:00 | <masinter> | what postscript interpreters to people have? |
| 01:00 | <Hixie> | and market research data (not published) shows this kind of thing (though not necessarily this specific case) is the #1 reason for users to switch browsers. |
| 01:00 | <masinter> | most operating systems don't come with postscript interpreters, and when people install them, the ones i've used -- most of them over the years -- don't do the right thing anyway |
| 01:01 | <masinter> | so trying to fire up something that isn't installed, or something that is installed and does the wrong thing -- how does that help anyone? |
| 01:01 | <Hixie> | generally, users specifically opting to view postscript pages have postscript interpreters, i would imagine (though this is not based on any hard data) |
| 01:01 | <Hixie> | it doesn't do the wrong thing, actually -- it will typically offer the file to be saved to disk |
| 01:01 | <Hixie> | which is reliably more useful to users than showing the content raw on the screen |
| 01:01 | <Philip`> | (I believe most Linuxes have PS interpreters by default) |
| 01:02 | <masinter> | do they, Philip? |
| 01:02 | <Philip`> | masinter: I believe so |
| 01:03 | <masinter> | i'm just interested in the "unambiguously beneficial" bit |
| 01:04 | <masinter> | the other example where type sniffing seems harmful is interpreting text/plain as text/xml even if it's mal-formed |
| 01:04 | <Hixie> | what would the benefit be of _not_ either offering the file to download or opening the file in a PS interpreter? |
| 01:04 | <Philip`> | (e.g. okular (KDE) and evince (Gnome) both support PDF and PS and some other formats) |
| 01:04 | <Hixie> | i don't believe text/plain is _ever_ sniffed as text/xml by adam's draft |
| 01:04 | <masinter> | it would be better to assume application/octet-stream than application/postscript |
| 01:04 | <Hixie> | that would be a security risk |
| 01:04 | <Hixie> | masinter: why? |
| 01:05 | <masinter> | because just because it starts with a few bytes of the header is no indication that the rest of the file is valid |
| 01:06 | <masinter> | it's a heuristic at best, and the consequences are ugly. at least with text/html you can View Source and see the original text/plain |
| 01:06 | <masinter> | and you're not turning text into application |
| 01:06 | <Hixie> | wait, which case are you talking about? |
| 01:06 | <masinter> | no, application/octet-stream is lower capability than text/plain |
| 01:06 | <masinter> | and much lower than application/postscript. It means that *no* automatic processing should happen |
| 01:06 | <Hixie> | text/plain containing binary being interpreted as application/postscript, you think that would be better interpreted as application/octet-stream? |
| 01:07 | <masinter> | better not being interpreted |
| 01:07 | <Hixie> | or...? |
| 01:07 | <masinter> | since application/octet-stream is the explicit "type unknown" mime type |
| 01:07 | <Hixie> | i'm not sure i understand what you're saying browsers should do and in what case |
| 01:08 | <masinter> | well, if we can agree that a change is in order because there's a problem, then working out the solution is next |
| 01:08 | <Hixie> | which case are you talking about? |
| 01:08 | <masinter> | there are a lot of ways in which browsers could respond to a heuristically determined server configuration error, only one of which is to automatically assume that because the heuristic triggered |
| 01:09 | <masinter> | well, i noticed application/postscript and thought it was worth understanding the justification for that in the current draft |
| 01:10 | <masinter> | i thought it was worth at least talking this out first, don't you? would you have preferred to wait for some formal objection with a line-by-line analysis first? |
| 01:10 | <Hixie> | so you're proposing that text/plain-labeled content, containing undisplayable binary and starting with the postscript signature, instead of being interpreted as application/postscript, would be better interpreted as application/octet-stream? |
| 01:10 | <Hixie> | i'm jsut trying to understand your proposal |
| 01:11 | <masinter> | i haven't made a proposal yet, and don't want to make one offhand |
| 01:11 | <Hixie> | oh. what did you mean by "it would be better to assume application/octet-stream than application/postscript" then? |
| 01:11 | <masinter> | well, that would be better, but i don't know if it would be best |
| 01:12 | <masinter> | it's worth examining what all of the alternatives are to the current proposed behavior before making a concrete proposal, isn't it? |
| 01:12 | <Hixie> | so you're saying that in your opinion, if the UA finds text/plain-labeled content containing undisplayable binary and starting with the postscript signature, it would be better (though maybe not best) if, instead of being interpreted as application/postscript, it was interpreted as application/octet-stream? |
| 01:13 | <masinter> | well, "interpreted as application/octet-stream" is pretty misleading |
| 01:13 | <masinter> | it would be better if no automatic interpretation were offered, and the user instead prompted to save the file |
| 01:14 | <othermaciej> | that's what "interpreted as application/octet-stream" amounts to in practice |
| 01:14 | <Hixie> | that's also what "interpreted as application/postscript" amounts to in practice, unless the user has a viewer, which i understand (based on masinter's comments) is not the common case |
| 01:14 | <masinter> | well, i think i understand that, not sure everyone who reads this dialog would know that for sure, and "rather than interpreting as X, interpret as Y" where X is the best guess -- sounds like an odd proposal |
| 01:15 | <Hixie> | oh i thought you said Y in this case was the better guess |
| 01:15 | <masinter> | well, and the possibility that Linux systems often have postscript interpreters, maybe Firefox on Linux does something interesting? |
| 01:16 | <masinter> | the only harm to users in not doing sniffing is that they always are offered to save the file without invoking the displayer automatically |
| 01:16 | <Hixie> | no, not at all |
| 01:16 | <Hixie> | in this case, not doing sniffing would mean showing the undisplayable binary content to the user |
| 01:16 | <masinter> | why is it undisplayable? |
| 01:16 | <masinter> | my emacs displays binary data just fine, and so does notepad |
| 01:17 | <Hixie> | the file in this example is "text/plain-labeled content containing undisplayable binary and starting with the postscript signature", that's the case we're talking about |
| 01:17 | <masinter> | yes, exactly |
| 01:17 | <masinter> | well, you're saying "undisplayable" and I think it is "ugly" |
| 01:17 | <masinter> | but most systems display it |
| 01:18 | <masinter> | and it might be a general heuristic about text/plain data with ugly (or undisaplayable) binary |
| 01:18 | <Hixie> | this only gets invoked with files containing control characters that are by definition invalid in text/plain |
| 01:18 | <othermaciej> | Safari has an inline PostScript viewer |
| 01:18 | masinter | fires up windows safari |
| 01:19 | <othermaciej> | not the Windows version |
| 01:19 | <othermaciej> | (yet, anyway) |
| 01:19 | <othermaciej> | Mac Safari displays PostScript and PDF files natively in the browser window (with ability to download or open in external viewer provided) |
| 01:20 | masinter | switches to mac |
| 01:20 | <othermaciej> | the reason I cite this is because, for Safari at least, sniffing as "application/octet-stream" vs "application/postscript" would result in significantly different behavior |
| 01:21 | <othermaciej> | contra Hixie's earlier remark |
| 01:22 | <Hixie> | iirc, the case larry was saying that not sniffing would be better for is the case where the signature is present but the file isn't postscript -- any idea how safari handles that case? |
| 01:22 | <othermaciej> | long ago, we would often display binary files labeled as text/plain in UglyText format |
| 01:22 | <othermaciej> | that's what we would do if we had no sniffing |
| 01:22 | <othermaciej> | users really really hated that behavior back when it happened frequently |
| 01:23 | <masinter> | i'm going through www-cdf.fnal.gov/offline/PostScript/ |
| 01:23 | <othermaciej> | not only due to the ugly, but also because it was unclear to them how to actually download, and often because binary files would take forever to render as text and hog lots of memory |
| 01:23 | <Hixie> | othermaciej: yeah that matches my experience with other browsers |
| 01:24 | <othermaciej> | if we tried to view a file with the PostScript signature inline and it wasn't really PostScript, we would probably show a broken partial rendering, but would still offer the "download" and "open in external viewer" controls |
| 01:24 | <Hixie> | so a superset of treating it as larry suggested, as application/octet-stream? |
| 01:25 | <Hixie> | that seems better than just treating it as application/octet-stream |
| 01:25 | <othermaciej> | that amounts to treating it as application/postscript (though I'm not sure if we actually presently sniff for the PostScript signature) |
| 01:26 | masinter | is looking at MIME types |
| 01:27 | <othermaciej> | and yes, I think a broken attempt to render as PostScript is likely better than just downloading (a file that looks like a PostScript file but isn't, is most likely a damaged but perhaps still usable PostScript file) |
| 01:27 | <othermaciej> | and it is definitely better than a broken attempt to render as plain text |
| 01:28 | <masinter> | if a site misconfigures postscript and sends it as plain text, wouldn't they also send other binary data as plain text too? |
| 01:28 | <othermaciej> | probably |
| 01:28 | <masinter> | shar files, .double files, etc? |
| 01:28 | <masinter> | so those would show up as ugly text too? |
| 01:28 | <othermaciej> | I think the most common data types sent erroneously as plaintext are video files |
| 01:29 | <masinter> | unix binaries |
| 01:29 | <othermaciej> | I think the algorithm to detect unrenderable text would identify most of those things and treat them as "application/octet-stream" |
| 01:30 | <othermaciej> | (and thus cause them to download instead of displaying inline) |
| 01:30 | <masinter> | so not sniffing postscript wouldn't generate ugly text anyway |
| 01:31 | <Hixie> | if postscript were removed from that table, then the user would just get the "save as" dialog |
| 01:31 | <othermaciej> | that's right, it would be the difference between "download" and "attempt to display inline as PostScript, with a control available to download" |
| 01:31 | <masinter> | for mac safari users |
| 01:31 | <Hixie> | which i think is pretty unambiguously worse than having the choice between saving it or immediately viewing it |
| 01:31 | <othermaciej> | (assuming that sniffing for binary-looking stuff in text/plain was retained in general) |
| 01:32 | <masinter> | well, unless it isn't really postscript |
| 01:32 | <Hixie> | in particular, for instance, users downloading videos are usually downloading porn they want to see right away, and are not trying to save them to disk |
| 01:32 | <masinter> | i was talking about postscript, not videos. are there video types in the table? |
| 01:32 | <Hixie> | not yet, but adam and i were talking about adding them |
| 01:32 | <Hixie> | since that would be a big help to users |
| 01:33 | <othermaciej> | I haven't personally seen content that looks like PostScript but isn't, to the degree that trying to render it as PostScript is actively harmful |
| 01:33 | <masinter> | i'm still puzzled by the market share justification |
| 01:33 | <masinter> | maybe it's just Adam & etc's choice of wording |
| 01:33 | <othermaciej> | the market share justification skips a few steps in the logic |
| 01:33 | <othermaciej> | here's the bottom line: |
| 01:34 | <othermaciej> | - Not having sniffing causes some sites not to work as users expect, often enough that browsers lacking sniffing noticed. |
| 01:34 | <masinter> | i'm not arguing there isn't a 'market share justification', just the quantifiers in the logic |
| 01:34 | <othermaciej> | - Users complain to browser vendors or switch browsers when sites don't work. |
| 01:34 | <othermaciej> | - Browser vendors believe that not providing adequate real-world compatibility hurts their market share. |
| 01:35 | <masinter> | does that make sense? You might justify that "some sniffing of some times are necessary if sites that require it are widely deployed and important to users, and the consequences of sniffing are egregious enough to be noticable" |
| 01:35 | <othermaciej> | I can tell you that Web site compatibility is still a big concern for Safari, even though we have been out for 8 years and have many major companies actively looking to support us. |
| 01:35 | <masinter> | yes, of course "Web site compatibility" is a big concern and i'm not doubt it |
| 01:35 | <othermaciej> | We spent most of our engineering effort over those 8 years fixing Web compatibility bugs. |
| 01:35 | <masinter> | i'm not doubting the steps of the logic, or your efforts |
| 01:36 | <Hixie> | that's not the bottom line, the bottom line is this: we tried requiring that UAs not browser sniff for 19 years, and the result was that the requirement was ignored. |
| 01:36 | <othermaciej> | Our Product Marketing still cites it as a very important area for users. |
| 01:36 | <masinter> | no, that's hardly the bottom line of anything |
| 01:36 | <Hixie> | so now we're trying to mitigate the damage by saying how it should be done |
| 01:36 | <Hixie> | that is the only reason i'm doing this |
| 01:36 | <Hixie> | i want interop |
| 01:36 | <masinter> | for 19 years we've had "browser wars" where browser vendors went out of their way to encourage behavior differences and paid people to put up "best viewed by IE/Netscape" badges |
| 01:36 | <othermaciej> | I can stand behind those statements, but I don't think I can prove that removing sniffing specifically would have a large effect on market share. |
| 01:37 | <othermaciej> | we haven't really done heads-up A/B experiments of sniffing and not sniffing to see how many more users switch to other browsers, or how many fewer adopt Safari |
| 01:37 | <Hixie> | masinter: and is that going to change? |
| 01:37 | <othermaciej> | we are not inclined to do that level of investigation |
| 01:37 | <masinter> | i appreciate your efforts, but i don't think it's insulting you to question some of the conclusions you've come to |
| 01:38 | <Hixie> | you haven't insulted me since we restarted the conversation, indeed |
| 01:38 | <Hixie> | but do you think the browser wars are going to end? |
| 01:38 | <othermaciej> | the browser wars are currently escalating, not cooling down |
| 01:38 | <masinter> | i hope they will but i don't understand why they would |
| 01:38 | <othermaciej> | fortunately, all the major browser vendors seem to see interoperability as more in their interest than proprietary author-targeted features |
| 01:39 | <Hixie> | masinter: well, if the browser wars are the reason the requirement to not sniff was ignored, and we have no reason to think they would stop other than hope, i respectfully suggest we should go with the working assumption that for the forseeable future, the requirement not to sniff will continue to be ignored |
| 01:40 | <masinter> | oh hmm, well someone started this trend |
| 01:40 | <masinter> | I mean, someone was first in sniffing, and the other browser vendors followed suit, right? |
| 01:40 | <Hixie> | they long ago became millionaires and retired |
| 01:41 | <masinter> | well, what about sniffing video? |
| 01:41 | <masinter> | nobody would put up a site with videos labeled as text/plain if it didn't work in SOME browser |
| 01:42 | <masinter> | and the people who built the browser that sniffed video -- are they all millionaires and retired? |
| 01:42 | <Hixie> | probably, i believe that would be the IE team |
| 01:42 | <Hixie> | they sniff pretty much everything |
| 01:43 | <masinter> | well, so... are there a lot of postscript files mislabeled as text/plain? |
| 01:44 | <masinter> | maybe a list of 3-4 examples? |
| 01:44 | <Hixie> | no idea off-hand |
| 01:44 | <Hixie> | i don't really see any harm in sniffing in the case where the mime type is absent altogether |
| 01:44 | <Hixie> | in fact, iirc that's what http suggests doing |
| 01:44 | <masinter> | it says MAY not MUST |
| 01:45 | <Hixie> | sure, so does adam's draft |
| 01:45 | <masinter> | i don't think it says SHOULD, lemme check |
| 01:45 | <masinter> | well, unless it's an escallation |
| 01:45 | <masinter> | but almost everything is an escalation |
| 01:45 | <masinter> | i mean, if you have a buggy jpeg implementation, jpeg is an escalation |
| 01:46 | <Hixie> | and the text/plain-content-with-binary-data case is basically the same as there being no type -- you have something you know isn't text/plain, so the choice is between treating it as just unknown, or treating it as something known but not text/plain |
| 01:46 | <masinter> | sniffing could even be site-by-site with a table of well-known broken sites, and sniffing prompting |
| 01:46 | <Hixie> | which is the same as when you have something unknown because it has no type -- the choice then is between treating it as just unknown, or treating it as something known |
| 01:47 | <masinter> | i've started getting warnings about bad certificates |
| 01:47 | <masinter> | which i never got before |
| 01:47 | <masinter> | no, text/plain content with binary data is different from there being no type, by a long shot |
| 01:47 | <Hixie> | well, yes, in that the default behaviour is worse, sure |
| 01:48 | <masinter> | if it's mislabeled, it's a warning to be suspicious about other things |
| 01:48 | <masinter> | Hixie: you quoted something i said as if it were really wrong, about how matching reality is sometimes not the most important goal |
| 01:49 | <masinter> | but sometimes reality sucks, and trying to match it isn't nearly as good as trying to fix it |
| 01:49 | <Hixie> | surely the goal of any spec is to have the spec and reality match, however that happens |
| 01:49 | <masinter> | sometimes reality is insecure, divergent, broken, crashing, giving bad experiences, etc. |
| 01:50 | <masinter> | well, you know, there's leadership: sometimes you have to propose something that vendors jointly agree to do even if none of them would do it if the others didn't agree |
| 01:50 | <masinter> | certainly all of the new stuff is in that category -- nobody's implemented it before it was proposed |
| 01:52 | <masinter> | etc. ... insecure, not international, inconsistent with other software that you also want to interoperate with, there are performance difficulties, not accessible, .... there's a long list of ways in which the community actually needs to be led out of local minima |
| 01:53 | <masinter> | i think the difference is really how long you're willing to wait |
| 01:53 | <othermaciej> | the sites with a lot of mislabeled content tend to be in the "long tail" |
| 01:53 | <othermaciej> | so listing them is not practical, but nontheless they do have a significant user impact |
| 01:53 | <masinter> | i didn't say list them all, just give some examples |
| 01:54 | <masinter> | i read several suggestions in the history about asking users "This site seems to mislabel images, want me to try to show them anyway?" |
| 01:54 | <masinter> | and then remembering that on a site-by-site basis |
| 01:55 | <Hixie> | when would a user say "no"? |
| 01:55 | <othermaciej> | you suggested "a table of well-known broken sites", it was not clear to me that this was as an example rather than as a restriction on sniffing |
| 01:55 | <masinter> | i mean, after all, people are sending their sites to google every time they go to a new page |
| 01:55 | <masinter> | oh sorry, Maciej, you're right, i made two suggestions |
| 01:55 | <masinter> | you could seed the user's configuration |
| 01:55 | <othermaciej> | It seems to me that citing live Web content for examples of particular practices is a bad idea, since it's likely to change |
| 01:56 | <masinter> | well, this would be "site's i'm willing to let you sniff" |
| 01:56 | <masinter> | it would apply back-pressure, if the sites were maintained, to fix them |
| 01:56 | <othermaciej> | then such a seed list would not work well for my cited "long tail" reason |
| 01:57 | <Hixie> | masinter: btw, do you agree with the statement "the goal of any spec is to have the spec and reality match, however that happens"? it wasn't clear if you were agreeing or not, above. |
| 01:57 | <masinter> | there are numerous web applications that aren't browsers and don't have the 'market share' argument that would be better off if sniffing weren't a requirement |
| 01:57 | <masinter> | hixie, it's a timing issue |
| 01:57 | <othermaciej> | I don't think having users opt in to sniffing on a per-site basis would improve the user experience |
| 01:57 | <othermaciej> | I think it would harm the user experience |
| 01:58 | <masinter> | and the word "match", I think, has a wide range of interpretations |
| 01:58 | <othermaciej> | so I would not be inclined to go that way, even if not for the collective action problem |
| 01:58 | <Hixie> | masinter: how long as you willing to wait? |
| 01:58 | <masinter> | well, that depends a bit on the impact of the divergence |
| 01:58 | <othermaciej> | I think it would be silly for me as a browser developer to prioritize the needs of developers of non-browser applications over the needs of my users |
| 01:59 | <masinter> | i'm in favor of specs actually acknowledging current practice, telling people what's really going on |
| 01:59 | <Hixie> | masinter: how long as you willing to wait for the least impactful divergence? |
| 01:59 | <masinter> | "least impactful" is "no impact", no? |
| 02:00 | <masinter> | any time you have a normative requirement that can't be tested, there's no way to determine whether the spec matches reality, is there? |
| 02:00 | <Hixie> | masinter: how long as you willing to wait for implementations and the corresponding specs to be 100% in convergence? |
| 02:01 | <masinter> | need to go soon lets wrap this part up before we get onto anything else |
| 02:01 | <masinter> | specifications, standards, draft standards, are *proposals* for implementors |
| 02:02 | <masinter> | which implementors either agree or don't agree to implement |
| 02:02 | <Hixie> | 5 years? 10 years? 20 years? 100 years? |
| 02:02 | <masinter> | and in the history of standards, there are no standards that are uniformly and exactly and pricely followed |
| 02:02 | <Hixie> | this doesn't seem like a question that needs a complicated answer |
| 02:02 | <Hixie> | are you saying it's ok for standards to not be uniformly and exactly and pricely followed? |
| 02:02 | <masinter> | it does, because the thing you're asking for a time frame for is complicated |
| 02:03 | <masinter> | can you name a standard that is? |
| 02:03 | <Hixie> | HTML5 will be in 2022 |
| 02:03 | <masinter> | the width of railroad tracks? The distance between threads in a screw? |
| 02:03 | <masinter> | can you name any standard in the history of standards that has ever precisely and uniformly and exactly followed? |
| 02:03 | <masinter> | the length of a meter? |
| 02:04 | <masinter> | i think that got redefined anyway, wavelength of cesium? |
| 02:04 | <masinter> | i forget |
| 02:04 | <Hixie> | i cannot name any web standards that match reality, no, and i consider that a failing of our industry that i am trying to address in the specs i work for |
| 02:04 | <Hixie> | do you disagree? |
| 02:04 | <masinter> | disagree that you're trying to address this? |
| 02:04 | <Hixie> | disagree that it's a problem |
| 02:05 | <masinter> | it's a problem that no standard in this history of standards in computer software has ever been exactly and precisely implemented by anyone? Or more than any one implementor? |
| 02:06 | <Hixie> | right |
| 02:06 | <masinter> | well, i dunno, i have some modesty here |
| 02:07 | <masinter> | i've worked on a lot of standards, and i think it's better to have a realistic goal of interoperability |
| 02:07 | <Hixie> | ok, let me phrase it another way |
| 02:07 | <Hixie> | what goal is more important than the goal of specs matching reality within a time frame of a few years or decades? |
| 02:07 | <masinter> | that the standard helps people build things that work together, that seems like a more realistic goal, especially if the things work better than they did when the standard was written |
| 02:08 | <masinter> | that it's helpful to the industry in general, that it leads people to better solutions jointly than they would have made if they were all working alone or in private consortia |
| 02:08 | <masinter> | W3C's motto is "Leading the web to its full potential" |
| 02:08 | <Hixie> | aah, that explains a lot about our arguments |
| 02:09 | <masinter> | yes, i think so, of course, a standard isn't very helpful if nobody follows it |
| 02:09 | <Hixie> | indeed if you consider getting people to work together to be more important than getting full documented interop, then the html5 effort and the specs that it has spawned lie mimesniff are going to seem quite alien to you |
| 02:09 | <masinter> | i'm not sure, but my impression is that most people involved in this effort agree with my goal more than with yours, but i'd be interested in a poll |
| 02:09 | <masinter> | hardly alien |
| 02:10 | <masinter> | i mean, i think i understand what you want to do, i just don't think it's practical, and it's causing a lot of difficulties and alienating a lot of pepole who actually want to lead the industry to better things, rather than just describe whatever it is that a few browser vendors are willing to claim is "reality" |
| 02:10 | <masinter> | like with the character sniffing |
| 02:11 | <masinter> | you said something about all browsers implementing it or else having known bugs that they would implement it |
| 02:11 | <masinter> | i was going to joke about the cow planning commission's planned cowpath |
| 02:12 | <masinter> | and even then, there's a big range in a spec between descriging what's implemented, what MAY be done, what SHOULD be done, and what MUST be done |
| 02:13 | <masinter> | lots of ways of mandating the 'right thing' without nailing down behavior which isn't necessary in order to accomplish interoperability |
| 02:13 | <tantek> | masinter, very little of what W3C has produce over the past 10 years (e.g. http://w3.org/TR/ ) has anything to do with "Leading the web to its full potential". Mostly either useless specs, or useful only to BigCorps and behind the firewall / intranets - quite disconnected from the reality of "the web". |
| 02:13 | <Hixie> | i think your goal is a worthy goal, i just think specs are a horrible way to go about achieving that goal |
| 02:13 | <masinter> | there's no reason to believe that browser makers, if there were a spec by 2012, would continue to follow it anyway |
| 02:14 | <masinter> | seems to me that, at least in my experience in standards, that's what all standards efforts have been about |
| 02:14 | <Hixie> | if you want people working together, team building exercises, open retreats, social outings, unconferences, and the like are far more effective |
| 02:14 | <masinter> | well, no, i don't think so, because you actually need agreement on a technical spec |
| 02:15 | <Hixie> | if implementors (browser vendors or otherwise) find reason to start deviating from the spec, then the spec needs changing |
| 02:15 | <Hixie> | as i've said before, no spec is ever "finished" or "done" until it's obsolete |
| 02:15 | <masinter> | i do remember an standards subcommitee meeting where i called a meeting of the committee to convene in the hot tub |
| 02:15 | <masinter> | well, that's certainly not the case with any other standard I can think of, can you name anohter spec that has that policy? |
| 02:16 | <Hixie> | CSS has that policy |
| 02:17 | <Hixie> | but as i said, i think we as an industry have failed because of not having this policy |
| 02:17 | <masinter> | well, does anyone agree with you on that? |
| 02:17 | <Hixie> | it's pretty much the consensus of the csswg and the whatwg, as far as i can tell, though i've hardly done a formal poll on the subject |
| 02:18 | <Hixie> | aaron sent an e-mail to the whatwg list basically asking us to move to that modal formally |
| 02:18 | <Hixie> | which i imagine we'll do once html5 is done |
| 02:18 | <Hixie> | ("done" as in there are no remaining missing sections, not "done" as in interoperably implemented) |
| 02:19 | <masinter> | i think we might be able to make progress on technical issues without resolving the philosophy question |
| 02:19 | <Hixie> | possibly, but in that case you have to realise that we may come to different conclusions based on the same data, because our goals differ |
| 02:20 | <masinter> | Hixie: I don't think you're goal is *wrong* in the sense that it isn't desirable |
| 02:21 | <masinter> | well, hmmmm |
| 02:21 | <masinter> | actually, no, i guess i would still say it's secondary |
| 02:22 | <masinter> | writing specs that helps the industry build stuff that works better than it would if the spec hadn't been written is more important than making sure the spec precisely and exactly and completely describes what everyone has and will do in the future |
| 02:22 | <masinter> | put that way, your goal sounds very Orwellian: everything that isn't mandatory is forbidden |
| 02:23 | <masinter> | s/has and will do in the future/has implemented/ ? |
| 02:24 | <masinter> | it's the same reason why i think that interoperability with deployed browsers with significant deployed base and are unlikely to change quickly should be a goal |
| 02:24 | <Hixie> | i thought you said it shouldn't be a goal |
| 02:25 | <masinter> | well describing how to accomplish it |
| 02:25 | <masinter> | i mean, if you want to be useful to web site builders, giving them a clue, considering what they have to do ... those are factors |
| 02:26 | <masinter> | because otherwise we'll have a HTML5 web and a non-HTML5 web, and that doesn't help the industry build stuff than works better etc... |
| 02:26 | <Hixie> | the goal "matching reality" means that there will only be an HTML5 web |
| 02:26 | <masinter> | i really do have to go but i think this has been useful, hope you have |
| 02:27 | <Hixie> | even if it means matching browsers that won't change |
| 02:28 | <masinter> | i'm willing to continue this later if you are, but i need to go now, ok? |
| 02:29 | <Hixie> | sure |
| 02:29 | <Hixie> | later |
| 08:49 | <hsivonen> | this reminded me of some standards discussions: http://farm3.static.flickr.com/2488/3952434921_3c9b723ee8_b.jpg |
| 09:15 | hsivonen | notes that Mac OS X and most Linux distros ship with the capability to display .ps files. Only Windows is the odd one out. |
| 09:32 | <Philip`> | Windows doesn't even ship with the capability to display .pdf files |
| 10:00 | <othermaciej> | hsivonen: amusing |
| 10:54 | <Hixie> | http://damowmow.com/playground/microdata/004/ is my proposal for what we'll test monday |
| 10:54 | <Hixie> | it takes into account the stuff we've learnt so far |
| 10:58 | <Steve^> | the item attribute has gone, replaced by itemscope and itemtype? |
| 11:09 | <Steve^> | At first I assumed itemprop="fn org" labelled the string as both fn and org, just like class="foo bar" works. |
| 11:10 | <Steve^> | But I see the space is part of the name too, is this wise? |
| 11:10 | <Steve^> | In all other cases a hyphen is used instead |
| 11:11 | Philip` | attempts to use git |
| 11:11 | <Philip`> | User-friendliness point 1: you can run "git add -n" for the same as "git add --dry-run", but you have to run "git push --dry-run" and can't run "git push -n" |
| 11:13 | <Hixie> | Steve^: it actually does do what you thought in the real syntax |
| 11:13 | <Hixie> | Steve^: i just didn't want to try to explain that in the study, and it wasn't the point being tested |
| 11:13 | <Steve^> | ah, ok |
| 11:14 | <Hixie> | and yes, see http://damowmow.com/playground/microdata/NOTES for the changes and reasoning |
| 11:14 | <Steve^> | I'm the guy that notices these things and gets annoyed that the teacher won't tell me the truth :P |
| 11:15 | <Hixie> | yeah, i know the feeling! |
| 11:15 | <Steve^> | Hixie, who are the test subjects? |
| 11:16 | <Hixie> | the intro doc has to be as brief as possible to not take too much of the hour for them to read, while hitting all the points they'll need for the exercises, so i was focusing on conveying tutorial-like info, not spec-like info |
| 11:16 | <Hixie> | you mean their names? :-) |
| 11:17 | <Steve^> | are they people off the street? college students? web developers? |
| 11:17 | <Hixie> | web devs |
| 11:17 | <Hixie> | and software engineers |
| 11:17 | <Hixie> | from various walks of life |
| 11:18 | <Steve^> | then I feel good about my employability |
| 11:18 | <Hixie> | we |
| 11:18 | <Hixie> | er |
| 11:18 | <Hixie> | we've had an interesting range of people |
| 11:18 | <Hixie> | some were highly competent, and got this concept pretty quickly |
| 11:19 | <Steve^> | oh |
| 11:19 | <Hixie> | others thought they did but were stumbling around having problems with things that weren't even being studied |
| 11:19 | <Hixie> | like basic html syntax |
| 11:19 | <Steve^> | you mention a few things that were a problem for everyone |
| 11:20 | <Hixie> | yeah, containership in particular |
| 11:20 | <Hixie> | i've tried to make the intro doc introduce that concept more forcefully |
| 11:20 | <Hixie> | to see if it was just a poor intro, or if the concept itself is hard |
| 11:20 | <Hixie> | similarly i've made the intro say explicitly that you can't just make up names |
| 11:21 | <Steve^> | the intro reads very very well |
| 11:22 | <Hixie> | if it tests well i might just end up using it almost verbatim as the intro section |
| 11:22 | <Steve^> | itemref seems upside-down to me, if you took a section out of context, you may lose the itemref link and the name/value pair loses meaning or becomes part of another item |
| 11:23 | <Steve^> | itemfor at least tells you it doesn't belong there, even if you don't know the whole story |
| 11:23 | <Hixie> | seems the problems exist in both directions |
| 11:25 | <Philip`> | Require the syntax to indicate the link in both directions, then it's harder to unknowingly break |
| 11:25 | <Steve^> | I think itemref breaks more than itemfor |
| 11:26 | <Steve^> | as it could add data to an item that shouldn't be there |
| 11:26 | <Steve^> | I like the idea of articles being completely extractable, independent of their surroundings |
| 11:27 | <Hixie> | the problem with itemfor="" is that it's a performance nightmare -- given an item, you have no choice but to walk the entire DOM to find if there are any more properties |
| 11:30 | <Philip`> | If you're extracting all the items from a document, that's not a problem, because you have to walk the DOM anyway and you can keep track of itemfors while you're doing it |
| 11:30 | <Philip`> | so it only seems a problem when you're trying to extract microdata from a specific element on the page |
| 11:31 | Philip` | doesn't know how the use cases typically would be extracting data |
| 11:33 | Philip` | wonders if querySelector('*[itemfor]') would be unreasonably slow anyway |
| 11:34 | <Steve^> | there are use cases?! :) |
| 11:37 | <Hixie> | the DOM API would be a case where you're trying to extract microdata from a specific element on the page |
| 11:37 | <Hixie> | and it happens to be a case where performance is critical |
| 11:38 | <Hixie> | ok bed time |
| 11:38 | <Hixie> | nn |
| 11:38 | <Steve^> | bye |
| 12:26 | <AryehGregor> | Sigh, yet another video about HTML5 only available if you have Flash. |
| 12:28 | <Steve^> | there are videos about HTML5? |
| 12:29 | <murr5y> | gief url! |
| 12:29 | <AryehGregor> | http://vimeo.com/6691519 |
| 12:30 | <AryehGregor> | I didn't bother watching. |
| 12:30 | <murr5y> | well obv, it's on vimeo |
| 12:30 | <AryehGregor> | (Using Chrome on Linux, where enabling plugins causes the browser to freeze up every ten minutes, has given me remarkable fortitude in resisting the temptation to use Flash.) |
| 12:30 | <AryehGregor> | Maybe whatwg.org should offer to host HTML5-related videos in Theora with <video> only. |
| 12:31 | <AryehGregor> | Maybe it could allow uploads to the wiki, actually. I think OggHandler would need setup as an extension, though, off the top of my head. |
| 12:31 | <Steve^> | Why are you using Chrome then? |
| 12:32 | <AryehGregor> | Because Firefox is hideously slow by comparison, at least for me. Not so much with a fresh profile, but I can't be bothered to dig through what's wrong with my Firefox profile. |
| 12:32 | <murr5y> | flash is shabby in linux either way :p |
| 12:32 | <Steve^> | I found Opera handy with flash problems. Clearly flash was at fault, but Firefox would tend to crash too, whereas Opera would be a little more graceful |
| 12:32 | <AryehGregor> | I also like a lot of the features, like more screen real estate and such. |
| 12:33 | <murr5y> | i use opera/linux, it's relatively stable but crashes once in a while |
| 12:33 | <Steve^> | Its interesting to see how anti-accessible chrome is heading |
| 12:33 | <AryehGregor> | In what way? |
| 12:33 | <Steve^> | disabled users would benefit from more buttons on the chrome |
| 12:33 | <AryehGregor> | Really? |
| 12:33 | <Steve^> | such as text zoom buttons |
| 12:33 | <Steve^> | yes |
| 12:33 | <AryehGregor> | Do you have data to support that? |
| 12:33 | <Steve^> | Not personally, but it was heavily backed at standards.next |
| 12:34 | <Steve^> | users can be shown where the particular options are to make text bigger, but they easily forget |
| 12:34 | <Steve^> | the menus are too confusing. Having a button under the users nose may help them use these options |
| 12:34 | <othermaciej> | having lots of buttons in the default UI is bad for most people |
| 12:34 | <AryehGregor> | Frankly, I'm not disabled, so I don't really care. If you have poor vision, you should be increasing your default OS font size. |
| 12:34 | <AryehGregor> | (I don't personally care, I mean. If I were a Chromium dev I'd care.) |
| 12:35 | <Steve^> | sure |
| 12:35 | <AryehGregor> | (But not at the expense of non-disabled users, since there are way more of them.) |
| 12:35 | <Steve^> | the concensus is |
| 12:35 | <Steve^> | that you should have a javascript text soom function on your site |
| 12:35 | <Steve^> | because we can't trust the browsers and OS settings to me easy to set |
| 12:35 | <Steve^> | which is daft, but that's the way it is |
| 12:36 | <othermaciej> | in Safari on Mac, you can use Command + and Command - to zoom |
| 12:36 | <Steve^> | othermaciej, that's not helpful |
| 12:36 | <othermaciej> | which for experienced users is much more memorable than any button, since it is quick and consistent across apps |
| 12:36 | <Steve^> | the user needs to remember that |
| 12:36 | <othermaciej> | I dare say it's more helpful than having zoom buttons on the default toolbar (you can customize the toolbar to add them) |
| 12:36 | <Steve^> | memorable is a bad assumption for accessibility |
| 12:37 | <othermaciej> | putting lots of buttons in the toolbar is a bad assumption for usability by anyone |
| 12:37 | <othermaciej> | there is also an OS-wide screen zoom feature |
| 12:37 | <Steve^> | sure, don't put everything on there |
| 12:38 | <othermaciej> | I think web pages adding zoom (with different behavior than the built-in kind) is likely to be more confusing than helpful |
| 12:38 | <AryehGregor> | Has anyone presented any data indicating a real problem? |
| 12:38 | <Steve^> | I'm bringing this information from a meeting of people working with cognitive and other disabilities |
| 12:38 | <AryehGregor> | And do they have actual data? |
| 12:39 | <Steve^> | yes |
| 12:39 | <AryehGregor> | Guess they should file an issue in Chrome's issue tracker, then. |
| 12:40 | <Steve^> | one woman showed us videos of people interacting with common websites, she's done a lot of hands on work with disabled users |
| 12:40 | <Steve^> | but she doesn't seem to have a website, so I'm not sure what I can show you |
| 12:40 | <AryehGregor> | "Give our small minority of users extra space on the toolbar that's wasted for everyone else" probably isn't an adequate solution, though. |
| 12:40 | <Steve^> | But it is a fact that many users cannot remember where the browsers settings for text size is |
| 12:40 | <AryehGregor> | They shouldn't have to, they should set it once in the OS if they need to. |
| 12:40 | <AryehGregor> | And have it work for all apps. |
| 12:40 | <Steve^> | or any other setting |
| 12:41 | <Steve^> | should is another bad word |
| 12:41 | <Steve^> | unfortunately we have to work with what people actually do, rather than what they should |
| 12:41 | <othermaciej> | most users don't change any settings |
| 12:41 | <Steve^> | A good example is an internet cafe with a different browser and a computer that can't be altered |
| 12:41 | <Steve^> | how do we allow them to use our website? |
| 12:42 | <othermaciej> | however, it would be wrong to conclude from this that UI should be designed to cater to a wide variety of special needs |
| 12:42 | <Steve^> | this could be a council website, viewed from a library machine for example |
| 12:42 | <othermaciej> | (the default UI) |
| 12:42 | <Steve^> | So, a dialog should pop up at the start, please select your disabilities: |
| 12:43 | <AryehGregor> | No, dialogs are evil. |
| 12:43 | <othermaciej> | Mac OS X does let you indicate you are blind at install (or initial system configuration) time and goes straight into spoken UI |
| 12:43 | <Steve^> | bruce posted a link on twitter to a site about html5 with massive text. It was actually too big to read and I closed the site |
| 12:43 | <Steve^> | This is what users do when they have difficulties, they close the site |
| 12:44 | <Steve^> | I think Mac OS X is a bad example as not everyone can use it |
| 12:44 | <AryehGregor> | Burdening all users with things that are only really needed for a small minority is still not the answer. |
| 12:44 | <Steve^> | and I don't think Apple give cheap macs to people that need them |
| 12:45 | jgraham | wonders what OS "everyone can use" |
| 12:45 | <Steve^> | Perhaps not, but what is the answer? |
| 12:45 | <AryehGregor> | Realistically, essentially everyone can use a Windows desktop. Lots of people need to run Windows-only apps, few people need to run Mac/Linux-only apps. |
| 12:46 | <othermaciej> | the answer is to allow minorities to configure software for their needs fairly easily |
| 12:46 | <AryehGregor> | Steve^, maybe there is none. Life acts that way sometimes. |
| 12:46 | <AryehGregor> | Cure all visual disabilities, how about that? |
| 12:46 | <othermaciej> | Mac OS X ships with a screen reader included, but we don't turn it on for all users |
| 12:46 | <AryehGregor> | C'mon, we're in the middle of a biotech revolution, right? |
| 12:46 | <othermaciej> | likewise it has high-contrast mode which is also not on by default |
| 12:47 | <AryehGregor> | othermaciej, I talked to a blind user once about screen readers. IIRC, he said the major screen readers were Windows were both terrible and horrifyingly expensive; the Linux ones were about as terrible as the Windows ones, but at least they were free; and OS X's was awesome and came bundled with the OS. :) |
| 12:47 | <AryehGregor> | s/were Windows/for Windows/ |
| 12:47 | <othermaciej> | sorry to keep using Mac OS X as an example based on the fact that I think it does things well |
| 12:47 | <jgraham> | AryehGregor: Well I could, but I would have to buy windows. Just like I had to buy a Mac (my desktop was second hand and so didn't have an OS) |
| 12:48 | <Steve^> | anyway, my original point is that chrome is going the wrong way |
| 12:48 | <Steve^> | minimalist designs confuse people |
| 12:48 | <AryehGregor> | I totally disagree. And so do Google's usability studies. |
| 12:48 | <othermaciej> | I don't think that is true as a general rule |
| 12:48 | <AryehGregor> | (which, presumably, are mostly on people who aren't disabled) |
| 12:48 | <murr5y> | complex designs confuse people |
| 12:48 | <Steve^> | I think Microsofts choice to hide the menu bar from everything is very confusing |
| 12:49 | <Steve^> | I hate menus that auto-hide items |
| 12:49 | jgraham | finds the Chrome UI somewhat too minimal but that might not be typical |
| 12:49 | <othermaciej> | there is such a thing as being too minimalist, to the point that you can't find needed features |
| 12:49 | <Steve^> | I need to be able to see the options |
| 12:49 | <AryehGregor> | That I agree with, but I don't think it's comparable to Chrome's UI decisions. |
| 12:49 | <murr5y> | it's a fine line |
| 12:49 | <murr5y> | and it all depends on the users needs |
| 12:49 | <othermaciej> | but in general, user interfaces with fewer moving parts are easier to use |
| 12:50 | <Steve^> | if you are trained with the Office ribbon, it is nice to use |
| 12:50 | <Steve^> | but IE7 is dreadful for finding options |
| 12:50 | <jgraham> | It's more like UIs with the right (and only the right) moving parts are easiest to use |
| 12:50 | <othermaciej> | of course, I work for a company famous for making a device with only one button, so I may be biased |
| 12:50 | <AryehGregor> | http://www.theonion.com/content/video/apple_introduces_revolutionary |
| 12:50 | <Steve^> | doesn't it have 2 buttons? |
| 12:50 | <AryehGregor> | (another Flash-only video, of course) |
| 12:50 | <jgraham> | e.g. it turn out that the apple remote is a terrible ui for doing text input |
| 12:51 | <jgraham> | because it only has 5 buttons |
| 12:51 | <othermaciej> | that I'd believe |
| 12:52 | <othermaciej> | I certainly would not use it to write my novel, or even compose an email |
| 12:53 | <Steve^> | I must depart, be back later |
| 12:53 | <jgraham> | We were using one to find music on youtube and the gap between songs was about as long as the songs because entering the search terms was so slow |
| 12:54 | <jgraham> | Not taht this has anything to do with the chrome ui, really |
| 12:54 | <othermaciej> | not really, no |
| 13:07 | <annevk2> | why is there itemtype now? I thought types were based on elements? |
| 13:08 | <annevk2> | wow, that Web IDL discussion exploded |
| 13:12 | jgraham | doesn't know if it is worth making a case for catchalls |
| 13:13 | <annevk2> | 400 new messages during the weekend is no fun |
| 13:13 | <jgraham> | Especially since they are pretty much part of the legacy now |
| 13:13 | <jgraham> | annevk2: I sympathise |
| 13:14 | <othermaciej> | making a case for them being good? |
| 13:14 | <jgraham> | othermaciej: Making a case for them being a naural fit for localStorage |
| 13:14 | <jgraham> | *natural |
| 13:15 | <othermaciej> | they are, but the possibility for conflict with built-in methods and properties makes them hard to use safely |
| 13:16 | <jgraham> | What do you mean safely? Just "people have to avoid creating items called toString" or someething security related? |
| 13:16 | <othermaciej> | having storage items named "key", "length" or "clear" is not that unlikely |
| 13:16 | <othermaciej> | not security, just "easy to write buggy code accidentally" |
| 13:17 | <othermaciej> | for example, if you write APIs that layer on top of Storage and handle arbitrarily named storage items, you'd better use getItem() / setItem() instead of brackets |
| 13:18 | <jgraham> | There is a concern there |
| 13:19 | <jgraham> | Although it is generally true in ECMAScript that if you try to use an object as a hash table you can trip over the things in the prototype chain |
| 13:19 | <othermaciej> | yep - would be nice to have proper hashtables of some sort |
| 13:20 | <jgraham> | Indeed, and if ECMAScript had them localStorage woul be using that API instead |
| 13:21 | <jgraham> | I tend to think that if people are trying to make some natural feeling API and the language makes it hard to do that safely it is a problem with the language rather than with the desire for that API |
| 13:22 | <jgraham> | Although it is harder to fix the language than just avoid certian designs |
| 13:24 | <othermaciej> | I think if the Storage object forced you to use methods (maybe just "get" and "set" instead of getItem and setItem) it would not feel much less natural |
| 13:25 | <othermaciej> | (of course it's too late to change now, but speaking hypothetically) |
| 15:17 | <theMadness> | Ouhm, xfn seems to be conflicting with html5. |
| 15:17 | <theMadness> | http://gmpg.org/xfn/join <=point 3, that doesn't quite validate. |
| 15:30 | <gsnedders> | theMadness: Everything ignores the profile attribute anyway. |
| 15:31 | <theMadness> | Yay. :P |
| 17:29 | <hsivonen> | We should define Universal Representation Locators |
| 18:14 | <AryehGregor> | hsivonen, or define "resource" to mean "representation, since no one uses content negotiation anyway, stfu". |
| 18:26 | <hsivonen> | AryehGregor: yeah, that would be better |
| 18:27 | <Dashiva> | That would just make even more noise |
| 18:27 | <Dashiva> | Go with Representation, that way you don't change a stable and useful existing standard |
| 21:50 | <AryehGregor> | Hixie, are we still scheduled for October Last Call? |
| 21:52 | <Philip`> | If there's a delay, we can just redefine October to match the reality of the spec's status |
| 22:35 | <jgraham> | Isn't the internet in an eternal september anyway? |
| 22:59 | <AryehGregor> | jgraham, awesome catch. |
