Re: Why I don't attend the weekly teleconference (Was: Input on the agenda) (fwd)

(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