Re: Deciding in public (Was: SVGWG SVG-in-HTML proposal)

On Thu, 31 Jul 2008, Sam Ruby wrote:
> Ian Hickson <ian@hixie.ch> wrote on 07/31/2008 08:41:54 PM:
> > On Thu, 31 Jul 2008, Sam Ruby wrote:
> >
> > But nothwithsanding that, it's a *good* thing that we need wide review 
> > and serious thought before we extend the language that the Web is 
> > based on. When we don't have peer review and so forth, we end up with 
> > things like <marquee> or <blink>.
> 
> And <canvas>.

Indeed, and <canvas>, another good example of why it is really bad for 
people to go and invent their own elements without working with the wider 
community. We're _still_ dealing with the problems Apple caused with 
<canvas>, for example the lack of a Path object, which we could have 
avoided if they had had wider peer review before shipping.


> This is another example of painting things as black and white.  I 
> anticipated this a year ago.  My response both then and now is as 
> follows:
> 
> Sturgeon’s law still applies.  90% of all namespaces are crap.  This 
> proposal doesn’t change that.  Put your faith in Darwin.  Something in 
> 10% of the remaining 10% will knock your socks off.

IMHO that's too high a cost. Given the reactions of utter fear when people 
even suggest that browser vendors might invent some new tag, I believe 
that I am not the only one who thinks that it is too high a cost.


> > If the request is for a mechanism for arbitrarily extending 
> > text/html's vocabulary without having to go through a standards body, 
> > then I hope we never reach that point. The Web is too valuable.
> >
> > I've said this before, for example search for "willy nilly" in:
> >
> >    http://lists.w3.org/Archives/Public/public-html/2008Apr/0205.html
> 
> "willy nilly" is another example of painting an issue in terms of black 
> and white.

When I speak in nuanced tones, people tend to misunderstand me. I find 
that exaggeration conveys my points better. Please feel free to assume 
that whenever I make a strongly worded statement, that I am aware that 
some caveats may apply, but that they aren't, IMHO, significant. (If you 
think they _are_ significant, then by all means, point them out, as you 
did above with the assertion that 10% of people inventing their own 
proprietary elements for text/html would give us something good and that 
that is worth paying the cost of the other 90% for.)


> > ...where I detailed the reasoning for this.
> >
> > (You've responded to this saying you disagree, but that you think that 
> > having XHTML5 and XML which can be used with XML namespaces to extend 
> > the language without discussion, effectively mitigates the issue.)
> 
> Mitigates?  Yes.  But not in a means that is widely accessible.  My site 
> is one of the very tiny minority of sites that can take advantage of 
> that. And at a cost of a loss of function (e.g. document.write).  I 
> forego revenue from Google AdSense because of this limitation.

Google AdSense pays my salary, so I guess we're both feeling the pain. :-)


> > Ok, I'll try to be less dismissive. Could you answer some of the 
> > questions I asked?
> >
> > e.g. in:
> >
> >    http://lists.w3.org/Archives/Public/public-html/2008Jul/0453.html
> >
> > ...the following questions:
> >
> > | So anyway, as editor, I now have a choice: either I ignore the evidence
> > | that namespace prefixes are confusing to authors, or I don't use your
> > | proposal in its entirety. What should I have done?

Could you answer this question?


> > | Given that proposals equivalent to this one had been considered long
> > | before, why should your proposal change anything?

And this one?


> >    http://lists.w3.org/Archives/Public/public-html/2008Jul/0430.html
> >
> > ...the questions "How should such accomodation happen?", "How can anyone
> > know?", "Is that unreasonable?", "How can we make it more obvious?" (I
> > would quote the context, but that would basically just be quoting the
> > entire e-mail).
> 
> I would suggest treating questions that come up again and again as a bug 
> report.

The questions above weren't asked in the context of questions that come up 
again and again. They were asked in the context of one person asking for a 
decision to be reconsidered. Could I ask you to answer those questions in 
that context?


> The bug in question in this case is the lack of supporting documentation 
> or rationale for the document.  Or more directly: the reason questions 
> come up again and again is a direct consequence of the way this work 
> group is being run.  That might be OK -- it is a tradeoff.  Spending 
> time documenting things that never end up being asked again is a waste 
> of time.  But if that is the consious choice, then accepting the 
> consequence (i.e., repeated questions) would seem to be in order.
> 
> Indirectly, this is another example of being dismissive.  It sends out 
> the clear message that "you are wasting my time", and "I don't need to 
> explain myself to you".

But we _do_ document questions that come up over and over:

   http://wiki.whatwg.org/wiki/FAQ

For example "Does HTML5 support href on any element like XHTML 2.0?". If 
anyone wishes to contribute to this FAQ they should feel more than welcome 
to do so. Could you help us out here and contribute questions and answers 
that you have seen asked a lot? (The answers need not be comprehensive, 
other people can add to them too.)


> >    http://lists.w3.org/Archives/Public/public-html/2008Jul/0404.html
> 
> I only see one question.  Suffice it to say that as long as the answer 
> works out that there is no mechanism by which independent parties can 
> define new elements, I will never be satisfied.

This is an important point. You have been asking for reasoning (e.g. "The 
proposal I was interested in understanding the disposition of was 
Microsoft's"), but you state here that the reasoning is irrelevant, since 
you would never be satisfied with reasoning that didn't conclude in your 
favour.

If you are unable to ever conceive of changing your mind on this issue, 
then it appears we are operating under an asymmetric model, in which those 
who disagree with you have to "seriously consider" your proposals until 
such time as they agree with you, but on the other hand there is no 
expectation that you will similarly seriously consider counter-proposals.

I can't say that I am interested in participating in such a model.


> That might be OK -- you can't please everyone. But in this case, 
> creating a spec that outlaws such extensions will have the same long 
> term effect that Prohibition had in the US.

Well, we've had a spec that outlaws such extensions for 18 years so far. 
I'm not sure what effects Prohibition had in the US, so it's not clear to 
me what effects I should be looking for as signs that this has caused a 
problem. Could you elaborate?


> It is clear that Microsoft will implement something in this area.

Indeed, they've had something implemented for nine years now. (I looked it 
up, apparently custom tags were implemented in IE5.)


> To the extent that such is adopted by content producers, other browser 
> vendors will be forced to respond.  You can help to channel this.  Or 
> not.

It would appear the extent of adoption is pretty much limited to Microsoft 
Office's HTML output so far. This is actually pretty strong evidence that 
the ability to unilaterally introduce and use proprietary vocabularies is 
not a widely needed feature.


> > Or in:
> >
> >    http://lists.w3.org/Archives/Public/public-html/2008Jul/0371.html
> >
> > ...the question "Are there any proposals that show indirection syntax 
> > can be designed in a manner that doesn't have the problems that other 
> > prefix-based proposals have had?"
> 
> I would be a fool to say that indirection syntaxes don't have problems. 
> The only thing that would be a bigger mistake would be to not build in a 
> mechanism for distributed extensibility.

Deciding whether the lack of an extension mechanism for custom 
vocabularies is a greater cost or a lower cost than the confusion caused 
by having a prefix indirection mechanism is something that we should base 
on evidence.

The cost of not having an extension mechanism for custom vocabularies is 
presumably an opportunity cost -- the loss of benefits that such a 
mechanism would bring. The benefits that such a mechanism would bring can 
be seen if we look at systems that do provide custom extension mechanisms, 
and see what benefits have been drawn from this.

There are several places we can examine. We can look at output targetted 
at IE browsers. There we find features such as VML and HTML+TIME, but we 
also see that there has been virtually no use of those features in the 
past nine years. We can look at HTML itself, which has had extensions like 
<marquee>, which enjoy some extensive support in certain markets (Asia in 
particular). However, <marquee> itself probably shouldn't be chalked up in 
the "win" column for having an extension mechanism, since it was 
introduced despite not having one, and also because people have widely 
derided it anyway. We can also look at Microsoft office, which introduces 
custom tags like <st1:state>, but in practice Microformats have provided 
similar mechanisms without using an extension mechanism, so again maybe 
this isn't such a great win.

In conclusion: maybe, generously, we could say there has been some 
moderate loss to not having an extension mechanism.

Then we must look at the cost of having a prefix indirection mechanism. 
Here we find ample evidence of author confusion, starting with the figure 
that I've quoted several times regarding the response to Micah's XForms 
book, which, despite being about the relatively complex subject of XForms, 
received most of its feedback on the topic of namespaces. Anecdotally, 
prefixes have caused problems all over the place:

   http://lists.w3.org/Archives/Public/public-html/2008Jul/0363.html

My own experience is that even people who are supposedly experts 
misunderstand namespaces on a regular basis, witness the threads in this 
very mailing list over the past few months that indicate a lack of 
understanding of namespaces, or the several teleconferences that I have 
attended where significant portions of the time were spent explaining 
namespaces to other participants.

In conclusion: conservatively, prefixes cause at least a moderate level of 
confusion.

So, to go back to what you said:

> I would be a fool to say that indirection syntaxes don't have problems. 
> The only thing that would be a bigger mistake would be to not build in a 
> mechanism for distributed extensibility.

Why would it be a bigger mistake? As far as I can tell, from the analysis 
above, it would be at most an equally big mistake, and likely a lesser 
mistake.


> This email was fine.  I did not have an interest in responding to the 
> other portions of the other emails when it seemed likely that I would 
> simply be blown off.

I assure you that if I ask a question I will not blow off the answer.


> I will, however, note that any mention of mechanism of distributed 
> extensibility or improved namespace support in my email was elided from 
> your response.

For completeness here is everything you wrote that I didn't include in my 
reply:

| Hmm.  You seem to have rearranged my email.

I didn't want to lead with the paragraph that I wrote in reply to your 
first paragraph.


| Was this sarcasm really necessary?  Particularly as it contradicts the
| impression you left just a few paragraphs above that suggests that the 
| post in question contained a "great wealth of information"?

I didn't mean to convey that impression. Obviously my sarcasm wasn't 
necessary.


| Just to prove that I can do sarcasm too: perhaps a few of them were 
| reading the mailing list.
|
|   http://lists.w3.org/Archives/Public/public-html/2007Aug/0134.html
|
| Note the times on both the blog post and the mailing list post.

My apologies.


| The reason why I posted that on my blog is that your attitude then had 
| me convinced that the key aspect of the post - namely distributed 
| extensibility - would not be seriously considered.

I omitted this paragraph because I have not found a polite and 
constructive way to reply to it.


| Ignoring every other detail of Microsoft's "Improved Namespace Support"
| proposal, it does capture that one essential ingredient.

I omitted this paragraph because I had responded to this "essential 
ingredient" in another part of the e-mail already.


| Now lets restore the question that you originally asked, but chose to 
| elide from my respose.

I had elided the question because it did not seem to be required to give 
context for your text. I try to keep my quoting to a minimum.


Anyway. You said:

> I will, however, note that any mention of mechanism of distributed 
> extensibility or improved namespace support in my email was elided from 
> your response.

What was it that I omitted that I should have kept in? I don't understand 
what my mistake was here.


> I was convinced a year ago, and remain convinced now, that you are 
> entirely unwilling to entertain a civil discussion of providing a 
> limited mechanism by which third parties can define vocabularies 
> involving new elements.

On the contrary, I have discussed this topic with many people in great 
detail, but have concluded, on the whole, that the existing mechanisms for 
marking up information and behaviour that HTML5 can't represent natively 
(mechanisms such as data-*="", class="", title="", namespaces in XHTML, 
<script type="text/xml">, <meta name>, <link rel> and <a rel>, <embed> and 
the NPAPI, <span>, and <div>) are more than enough to support all likely 
extension mechanisms, and that a mechanism for introducing new elements 
does not provide sufficiently new and useful capabilities to be worth the 
hassle that it inevitably would introduce.

All the participants partaking in a discussion have to allow for the 
possibility of multiple outcomes, for example here both the outcome of 
introducing an extension mechanism and the outcome of _not_ introducing an 
extension mechanism must be possible outcomes, if it is to be considered 
civil. Yet you have stated that you will never be satisfied if you don't 
get your way here ("as long as the answer works out that there is no 
mechanism by which independent parties can define new elements, I will 
never be satisfied").


> And that you will go to extreme lengths to preventing such a discussion 
> -- be it omitting the point from your replies

What point did I omit? As far as I can tell, I have replied to all your 
points and have not attempted to hide anything.

On the other hand, you have failed to reply to a number of the questions 
that I have asked, even going so far as to suggest that you aren't 
replying because you think I would ignore your answers.


> or painting the issue in stark black and white terms like "willy nilly",
> or being either sarcastic or downright dismissive (or both!) of anybody 
> who might have the temerity to ask such questions.

If I was being dismissive, I would have stopped replying long ago.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'