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

Ian Hickson <ian@hixie.ch> wrote on 07/31/2008 11:42:57 PM:

[first, overall kudos for keeping civil; and being very thorough]

> 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 a glass is half-empty point of view, perhaps?

Would HTML5 have canvas at all if Apple hadn't created it?

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

And, undoubtedly, I am not the only one who thinks that a closed vocabulary
that does not plan for extensions is a too draconian solution.

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

To be clear, the real issue is that there should be a proper
superset/subset relationship between XHTML5 and HTML5.  It doesn't matter
which is "on top", but as long as the state is that in order to get THIS
you need to give up THAT there is an issue.  So from my point of view, one
of the two serializations needs to have both a decentralized extensibility
mechanism and a functional document.write.

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

Yes, you can point to anecdotal evidence of issues.  And I can point to
vocabularies in related standards that have thrived.  But beyond this, the
issue is a lack of distributed extensibility.  Namespace prefixes are
merely one means towards that end.>

When every proposal that attempts to address this issue is quickly
dismissed, and the process is getting something considered is to make
proposals, what should I have done?

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

Repeating for emphasis: when every proposal that attempts to address this
issue is quickly dismissed, and the process is getting something considered
is to make proposals, what should I have done?

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

Perhaps I was unclear.  I was not commenting on your questions.  I was
attempting to address your questions.

If the situation you find yourself in is "I don't have time to document
rationalle... because I spend all of my time answering the same questions
over and over", then perhaps you should consider spending more time
documenting rationalle.  Or accepting that from time to time questions will
be raised again and again.

Based on observation, the latter is the path that you have taken, just
without the "accepting" part.  And given the sheer volume of comments that
you address, and the relatively small number of ones with issue, this would
seem to be a valid tradeoff.

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

The original context of this was "You've since brought it up at least half
a dozen times, both here and on your blog, and gotten a response each
time", and has since evolved in quite a different direction.

The FAQ does not address these types of questions.  And genererally I have
been successful in getting past the initial "but that was already decided"
responses.  This horse is now sufficiently dead and no longer in need of
further flogging.

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

The point that I brought up "at least haf a dozen times" was broader than
Microsoft's proposal, or rather, Microsoft's proposal is merely but one
possible solution.

I'd like issue 41 to be addressed.  As near as I can tell, the defined
process is to make proposals, though it seems that every proposal from any
source gets quickly dismissed.  A point of frustration for me.

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

The reality is the reverse.  Many proposals have been made.  Most were
merely intended to be starting points for discussion, and each was
completely and thoroughly shot down.  Asymmetricly.

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

Prohibition didn't stop drinking, and new HTML elements continue to be
invented.

But I will conceed that the 18 years and...

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

... 9 years are good points.  As far as they go...

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

... Is dublin core a proprietary vocabulary?

There may be other factors in the cause and effect here.  Feeds have proven
to be an effective carrier wave for metadata; hundreds if not thousands of
such extensions have been defined, a few dozen are widely used.

The difference in browser implementations (i.e., lack of standardization)
has made this considerably more difficult in the context of HTML.

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

I could use that same reasoning to say that all of the new tags introduced
in HTML5 (from article to video) are something we can live without, and
that we should stick with HTML4.  Do you really want to go there?

The reality is that browsers aren't consistent in how they handle
unrecognized tags.  Speaking from experience, the only way to effectively
implement HTML5 today across the four major browsers involves both XHTML
and Javascript.

Which leads to the fact that XHML (by virtue of being built on XML) is the
only vocabulary that has given much thought to how to detect the difference
between tags that enclose other data and tags that are void or empty.
However, not much can be learned from that vocabulary in the context of
browsers because (1) the dominant browser has never implemented it, and (2)
the defined error recovery is a cost that few content producers are willing
to pay.

The one exception to this that I am aware of is microformats.  If one looks
at microformats, one can see that there is a strong desire for
decentralized extensibility, one that will not wait for this workgroup, and
one that is greatly hobbled by the limitations I have cited.

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

What is clear that you have decided this.  And base this decision on a
number of anecdotes that you regularly pull out.

The bulk of the remainder of this email deals with you being thorough,
explaining, and appologizing.  All very much appreciated.

[snip]

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

Previously, when you were responding with sarcasm, I chose to address the
sarcasm first.  With that out of the way, I believe that we have both gone
back and been thorough.

- Sam Ruby,