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

On Tue, Jul 7, 2009 at 4:21 AM, Ian Hickson<ian@hixie.ch> wrote:
>
> (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.)

I think the chairs assume that we use our own judgment on such
matters. They are giving us the compliment that we're all adults here.


I will attempt to answer all of your questions:

>> > 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?
>
>

I believe that Sam listed reasoned argument, and that was an excellent response.

Reasoned argument, and a commitment of people to support the decision,
should be considered as highly as, if not more, than a random sampling
of data. Interpreting the results of the data queries has been a
purely subjective process, and therefore the efforts of the research
has no guarantee of improvement.

Less, likely, because you'll have removed one of the few tools that
those who support accessibility can use.

[snip]

>
> 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?
>

As I just wrote above, reasoned argument, and commitment of support
for a specific action.

Remember that though markup such as the summary attribute have been
around for some time, it's only in the last few years that
organizations dedicated to the advancement of accessibility have
really started making web page developers and designers aware of the
problems. The folks need time to do their job.

[snip]

>
>> 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?
>

I freely admit to being biased for RDFa, not because I'm enamored with
its capability, but because I can use it now, it is being used now,
and it will be used much more frequently in the future, thanks to
efforts by Yahoo, Google, and Drupal (and others). More importantly, I
am aware of the importance of supporting one specific data model for
semantic data, which is RDF, and RDFa has tool support I can use,
right now, for work I'm interested in doing, right now.

I don't support the microdata section because you put less than a
week's thought into it, if that, and there is no support for it
anywhere, and only a few people have come along and said they actually
liked it. And as far as I can see, none of these people originally
submitted a use case for a section on semantic metadata, so one has to
assume they're really not all that interested.

I've also been following the discussions with Bruce d'Arcus [1] in the
WhatWG group, and there are specific problems with the hard defined
vocabularies, too.

All of these should be sufficient. However, there is another
additional argument against the microdata section, in that the charter
for this group specifically states about the importance of this group
working with other standards groups, including RDFa group. Your
unilateral decision to disregard this group's efforts and interests is
counter to the very charter of this group.

> 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...?
>

The trickery is telling yourself that you're following an unbiased
course because you remove names from issues submitted to the issues
database. But you have had multiple discussions about these issues in
mailing lists. You do remember who is interested, or not, in most
topics.

You're basically tricking yourself into thinking that you're operating
in an unbiased manner, by telling yourself, and us, that no, you don't
consider who is interested or why in any one issue.

My point is I would rather people own up to their biases, and work
with others to ensure that they don't adversely impact the
specification.

[snip]

>
>> 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
>

Ian, I believe you took that comment out of context. And we've also
had a discussion about what is truly hidden data and what is not, so
I'll refer you to that thread for further discussion.


> 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
>

ditto

> If I was biased against RDFa people and Microformats people, wouldn't I
> also disagree with them on this?
>

I'll again refer you to the thread on hidden data for further
discussion on this topic.

>
> 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.
>

This isn't a question, but I will respond:

I see you as a person who is very capable and hard working, but not
particularly empathetic, and somewhat overly focused on one's self.
When you talk about HTML 5, I notice you never use "we", you always
use "I".

Beyond this brief sentence, we'll either need to take this discussion
off line, or move it to www-archives, because this is not about
technology.


[snip]

>>
>> 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?
>

After a quick glance through this month's and last month's email
archives for this list, I would say one can find examples sprinkled
liberally among the recent discussions on summary. It also appears in
the principles document discussion [1].

>
>> 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?
>

Ah, there's a difference between hearing and listening Ian. And I
don't think people would be so frustrated as they are if they felt you
really listened.

Again, though, we're getting out of technical and so if you want to
continue this, we'll do so in www-archives.

>> >>
>> >> 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?
>
>

The use of bolt-on in the abstract you mention is focused on there not
being support for accessibility built into the specification, as
summary is currently built into HTML. Tricks and algorithms are used,
instead, which are as the document states, fragile, and vulnerable to
failure.

If we're talking about summary, as far as I know that is built-in
accessibility.

So I support built-in and not bolted on.


>> 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?
>

Thanks to the link you provided, I better understand the differences
between the two.

>
>> 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.   `._.-(,_..'--(,_..'`-.;.'
>

I believe I answered all of your questions. Hopefully the answers are
sufficient. If not, you may want to separate each question into a new
email, as this thread has veered from the original topic.

Shelley

Received on Tuesday, 7 July 2009 13:06:14 UTC