- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 7 Jul 2009 09:21:58 +0000 (UTC)
- To: Shelley Powers <shelley.just@gmail.com>
- Cc: public-html@w3.org
(I thought the chairs' advice was that this e-mail belonged off public-html, but now I've received advice from the chairs that it is ok to send it to the list, so, here goes. I wish the rules on what we should send to public-html could be outlined somewhere clearly so that this kind of confusion didn't arise.) On Mon, 29 Jun 2009, Shelley Powers wrote: > > > > What studies do _you_ plan to take to demonstrate that summary="" is > > the superior solution? > > Actually, I don't believe we need to, not unless there's a plan to do > the same with every last bit of the HTML 5 spec. Ok. So if we shouldn't base decisions on research and data, what _should_ we base our decisions on? > >> But it could be worse than doing nothing. > > > > Using what data we have is not worse than doing nothing. > > Using data incorrectly, in order to support a bias is not a better > choice. I agree, but I don't think we're doing that. I understand that you think we are. However, if you think we shouldn't be working from data, as you seem to suggest above, then this point is moot, and we can ignore the data for the purposes of this discussion. > >> You have stated that summary is harmful. You have provided no proof > >> of harm. No, the so-called "studies" are not a conclusive proof. > > > > They are convincing enough to me. You are certainly welcome to > > disagree. > > Yes, but disagreement here means some form of action. We'll most likely > take a vote, but that defeats the point I'm trying to make, in that you > don't seem to be aware of how your own biases are influencing how you > interpret data, and how you're editing the HTML 5 specification. Ok. Let us take the data out of the equation for this discussion, then, so that I am not interpreting it at all. > >> I ask in return: where are the studies you plan to take to > >> demonstrate that collapsing summary into caption will be the superior > >> solution? > > > > I am not planning any such studies currently, though I would be happy > > to entertain any ideas you may have. I could offer to use Google's > > usability lab to perform studies; would you accept the results of such > > a study? > > No, Google is a now a browser company, and with some recent statements, > the company is showing a particular bias about how it believes the next > version of HTML 5 should be. Ok. Then there isn't much I can do. > I would rather have IBM's usability labs, which I studied when I was > getting my degree in IO psychology. The company had some of the best > usability studies ever, though I imagine these have had to be cut > because of the times. Probably cut years ago. If you could get IBM to contribute some data here, I would be very happy. The more data the better. However, let's assume that we don't succeed in doing that, and move on to not using data, as you suggest. What should we use instead? > There are few studies, if any, about what is included in the HTML 5 > specification, and what is pulled. I'm not sure why you're demanding an > exceptional level of rigor for accessibility markup that you're not > requiring for other markup. Actually we've done studies and based things on research for almost every part of the spec, but that's another story. > Unless you suffer a disease that means you forget everything every > single day, you know who is either interested in an issue, or if you are > entering issues people bring up in comments, you "know" who the > submitter is. Actually I really don't pay much attention to the From: line. My mail client (pine) doesn't show the From: line when I'm responding to e-mails past the first page, and I've configured my mail client to not show names in the index of messages. So I really don't know who I'm responding to a lot of the time. Also, since I reply to literally dozens if not hundreds of e-mails a day (I read over 300 individual e-mails yesterday on one topic, responding to a representative sample -- that's over 13000 lines of text), and since I have a very poor memory for names (I once lived with a dozen other people for a year and still didn't know all their names by the end of the year), I really don't know who has what opinions a lot of the time. Whether this is a disease or not, I don't know. > Why would you believe otherwise? Do you consider yourself some kind of > superman, who can leap human fallibility at a single bound? It's more that I am using my human fallibilities (inability to really remember names) as an advantage (to try to avoid bias). > So your suggestion of lack of bias is, frankly, silly. And I'm very > concerned that you seem to believe that you are operating without bias. > I would rather a person own up to their biases, and ensure others' input > whenever issues related to that bias arise, then someone who pretends > that they've eliminated all bias, and continues making isolated > decisions. It's quite possible that I have biases for or against individual contributors, but I have structured my work around ignoring the source of feedback precisely so that such biases don't affect my work. If I have any biases that _do_ affect my work, which I'm sure I do, it's more likely to be biases of a technical nature. For example, favouring simple solutions, favouring deployed implementations over proposals, favouring the behaviour of whatever browser I happen to be using at a particular time as my default browser (though it changes regularly, so hopefully over the years I've spread that bias out amongst multiple browsers such that it doesn't really matter). > You mentioned the semantic metadata use cases. Well your bias in that > regard caused you to misread several of the use cases. And then you used > this misreading to form some new microdata section, which we've just > seen has very little support. All because you have a basic bias against > RDFa, or namespaces, or whatever, and you make the ultimate decisions. I don't know that I would describe my aversion to namespace prefixes as a "bias"; it's a reasoned position based on the experiences of many people. If we're counting that as a bias, then yes, I have many biases. BTW, I don't have an inherent "bias" against RDFa specifically, only against a number of its component parts, like prefixes, using URIs for identifiers, having multiple triples declared per element, its use of "rev", and various other things like that. Still, if those are "biases" then I don't think a bias is a bad thing. Are you "biased" against microdata or in favour of RDFa? Or is that just a fair opinion you have derived based on reason and careful examination? The word "bias" implies a lack of fairness, an opinion based on an emotional attachment or aversion that is independent of reality. I really don't think I care enough about RDFa, Microformats, and microdata to have any kind of true bias on that topic. > >> However, perhaps if there were more people involved in both the > >> effort and the decision process, you wouldn't have to resort to such > >> trickery. Because this form of trickery will not succeed. > > > > I'm sorry, you've lost me. What trickery? > > See above. I still don't follow. Do you mean the biases you accuse me of having? I don't understand how one can "resort to bias". If I do have biases, surely the whole point of having a bias is that one is affected by them regardless. If I am picking and chosing when to use my biases, surely they're not actually biases...? > >> One is known by both our words and our interests. If there is an > >> issue related to, say, RDFa, one can assume you remember those people > >> interested in RDFa. Same with summary and so on. > > > > My point is that it doesn't matter who is interested or who is not, > > since all I look at is the arguments and data that is presented. > > Oh good lord, Ian, wake up and smell the reality. I am astonished that > you think you have somehow eliminated bias because you remove names > from issues you yourself record. I don't record them, I have a script that automatically does that for me based on e-mails sent to the lists. It's the one that strips the names off the record. > > In the discussion of data annotation, for instance, I only looked at > > the use cases and so forth _after_ stripping all information about who > > wrote them. If you look at the e-mails I sent on the subject you can > > see the text that I used to derive the solutions. It doesn't mention > > who asked for what. The "who" is irrelevant to the technical goals. > > But unless you suffer that aforementioned disease, you do know who is > interested. Of course you do. Well, sure, but so what? I have nothing personally against, say, Mark Birbeck (sorry Mark, you're the only person whose name I could remember as bein involved in the RDFa work). I don't know precisely what use cases he listed anyway, so I couldn't possibly set out to only address his use cases, or explicitly set out to not address his use cases. I really don't understand how you think my "biases" are affecting my work. > You just sent me and a small group of other people questions about > Canvas, because we've all expressed interest in accessibility issues. So > you know who is interested in these topics. I just took the list of e-mail addresses from Laura's recent e-mail without looking at them, actually, except for stripping mailing lists (and I stripped one too many, just to further demonstrate how little attention I was really paying...). > More than that, it doesn't eliminate your biases about "hidden" data, Is the RDFa community also biased against hidden data? | Hiding any sort of meta-data from a human is generally considered | harmful because hidden meta-data easily gets out of sync with the | displayable page data. If you can't see your meta-data when you look at | the web page with a browser, there is a good chance that you won't catch | errors and neither will your site visitors. -- http://rdfa.info/wiki/Common-arguments-against-rdfa Is the Microformats community also biased against hidden data? | It is advisable not to hide information in your site, regardless of | whether it is microformatted or not. [...] Avoid invisible (meta)data. | Publish visible data. -- http://microformats.org/wiki/faq If I was biased against RDFa people and Microformats people, wouldn't I also disagree with them on this? I have to say that the person you paint me as being -- biased against RDFa except when I'm biased against the blind, so biased against individual people that I subconsciously decide which use cases to address and which to not address based on nothing more than who proposed them, so biased in my interpretations of data collected that I can actually change the results of independent studies to support my case -- is someone capable of such amazing feats of doublethink, with such a complicated set of constraints to prioritise his biases, that I'm actually rather jealous of him. I wish I was that competent. Though he does sound like someone who needs a lot of psychological help. It sounds like a heck of a lot more work than just basing decisions on technical arguments, though. > which you don't really back up with any empirical research. > Other than looking at data at Google, or elsewhere. Other than the data that I've looked at with Google's index of billions of pages, the data Philip` independently collected, the data that Opera independently collected, the new data Philip` collected based on a totally different corpus, and based on the experience of both the RDFa and Microformats communities, I indeed do not back up my "bias" against hidden metadata with any empirical research. However, since as you said we don't need to demonstrate that our proposals are superior than the other proposals, that doesn't seem to matter. > The only way to help lessen bias is involve others in the decision > making process, but you effectively bar entire groups of people from > such. The working group has the authority and responsibility to override me. So even if I did ignore all feedback, or some feedback as you suggest, everyone in the working group would still be involved in the decision making process. Allowing peple to take part in the decision making process, as literally hundreds of people have during HTML5's development, does not mean that they get to have their way when they are not proposing the best technical solution. In the many cases where I've proposed something that is inferior to somethinge else, I haven't gotten my way. The same applies here. The summary="" and longdesc="" attributes are inferior to almost all the other proposals that have been put forward, according to the data collected (which I understand you think we should ignore, but I don't know what else to look at). Having people take part in the decision making process, contributing proposals, and so forth, does not mean that we decide on whatever is proposed first, or that any one group or another gets some sort of free pass on their ideas being accepted. It means that their ideas should be listened to, critically examined, and that the best ideas should be taken forward. > But you make the call as to what is reason, you make the call as to what > is a good argument, Yes, insofar as what I edit is based on feedback, I do make the call on what is a reasoned argument. > you make a call as to who you listen, No. I listen to everyone, even when others have told me that I should stop doing so and should ignore certain people. > you make the call, as to the people who you respect enough to actually > change your mind. No. I don't look at who said what. I base my decisions on the arguments presented. > And you do so based less on argument, and more on how similar they are > to you. Not in the least. I do it based on the research and arguments that are presented, in the context of the goals of the HTML5 project and the design principles (that have been documented several times over the years; originally at [1], most recently at [2], with more comments at [3]). [1] http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html [2] http://www.w3.org/TR/html-design-principles/ [3] http://wiki.whatwg.org/wiki/FAQ > Twenty something able bodied men, with varying computer science > background, and sharing an astonishingly significant geographical > similarity, most of whom are either in school, or who work for companies > building browsers. This is completely inaccurate. Even the most active participants of the HTML5 effort come from a hugely varied background. (It is true that several of them have been hired by Opera in the past few years, but they were independent participants with much the same viewpoints long before.) > They are more interested in new toys and web applications, and building > the web OS than providing a good, overall specification that serves the > needs of all people. I think it is a bit presumptuous to tell people what they're interested in, I think. However, yes, HTML5 is targetted specifically at Web applications and building a Web platform (indeed the spec used to be called "Web Applications 1.0"; it was renamed at the W3C WG's request). That isn't incompatible with providing a good, overall specification that serves the needs of all people. In fact, it is a necessary part of doing that. > It's the same people who are bloating the browsers to the point that the > things fail all too often. The vast majority of people who have contributed to HTML5 have no relationship with any of the browser vendors. > This is who HTML 5 is designed for. HTML5 is designed for a number of different groups of people, primarily Web authors and user agent implementors (search engines, data mining tools, ATs, web browser vendors, authoring tools, etc). > Because you are biased towards people who think like you. I think you are confusing cause and effect. If someone proposed that HTML should have draconian error handling, and that Web browsers should therefore show an error message for 97% of Web pages, they would likely not get so far _with that specific proposal_. This isn't because I'm biased against them personally, but because their proposal isn't in line with the goals of the HTML5 work (backwards compatibility). Similarly, if someone suggested that we shouldn't bother actually improving the state of the Web for blind users, or that it would be acceptable for users of ATs to be limited to just a few sites that they happen to know are well-designed, instead of being able to access the whole Web, then again, they would likely not get so far _with that specific proposal_. This, again, isn't because I'm biased against them personally, but because their proposal isn't in line with the goals of the HTML5 work (universal access). So sure, if soneone has goals that are incompatible with HTML5's goals, they will find that their proposals don't get as much traction. This is not a bias against them personally. This is a perfectly rational situation for a project to be in. If someone suggested to Debian that they should ship a commercial product, they wouldn't get much traction. That's not because Debian people are biased against them, it's because that would be counter to the goals of the Debian project. We can't simply please everyone. Fundamentally, if two people propose conflicting proposals, they can't both be satisfied. That doesn't mean there is any bias in favour or against any specific people. Someone could have a totally different set of goals than the stated goals of the HTML5 project, however, and still get their proposals and feedback accepted, so long as they were compatible with the goals of the project. > > The difference between an expert and a non-expert is that the expert > > can be expected to be more competent at explaining his reasoning, at > > showing his research, at documenting his work. Experts are better than > > amateurs. That's the only difference. We must still treat them the > > same. > > Again, though, you act as filter to the experts, demanding that the > expert use your assessment of what is reason and rationality, your > biases, even your terminology. People keep suggesting solutions, and you > keep responding with questions about asking their feedback, because you > need solutions. I don't understand what you mean. Do you have any examples? > You can't "see" their viewpoint, you don't hear what they say, you show > little but veiled disdain for most of the arguments What are the viewpoints I don't see? What are people saying that I don't hear? > >> >> If anything, I see a decreased interest in providing any > >> >> specialized help. > >> > > >> > If by that you mean that there is a tendency to prefer built-in > >> > accessibility (like <input type=date> rather than bolt-on > >> > accessibility (like <img alt>) then yes, that is intentional [...]. > >> > >> Now, we're seeing a new criteria being introduced into the > >> discussion. > > > > This isn't new, this kind of design has been part of HTML5's > > development since the very beginning. It's how most of Web Forms 2.0 > > was written back in 2003/2004. Heck, even then it's not new -- it > > underlies how HTML was designed all the way back to the first version, > > as far as I can tell. It's the whole reason for arguing for separation > > of presentation and semantics. > > Then provide links to relevant discussions. I've noticed that most > people in this mailing list provide links to the relevant arguments. I have no idea. This was prehistory even before I became involved. The idea that things should be accessible by default is so fundamental that I don't even know if it's been discussed in decent years. A quick search on Google pops up the following interesting link: http://books.google.com/books?id=rmLaD4l3_vwC&pg=PA683&lpg=PA683&dq=accessibility+bolt-on&source=bl&ots=5nSNuFPbO8&sig=l1syDD5MAH14plb40LuRhStvVq8&hl=en&ei=oLZKSqOQJJTUMvSb0aIB&sa=X&oi=book_result&ct=result&resnum=1 Steven refers to the bolt-on accessibility of <canvas> as "big dirty" in this talk (it's the reason we are looking into alternatives): http://www.slideshare.net/stevefaulkner/html-5-accessibility What is your opinion? Do you think bolt-on accessibility is better than built-in accessibility? > What forms the basis for your criteria of "built in" versus "bolt on"? I don't understand what you mean. Do you mean how do we distinguish one from the other? > What are the studies you've conducted that support this particular > preference? Off the top of my head I can't think of any public research that demonstrates this particular principle quantitatively. But since you said we don't need to demonstrate the superiority of one solution over another, I haven't looked into it any further. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 7 July 2009 09:22:38 UTC