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

On Fri, 1 Aug 2008, Sam Ruby wrote:
> >
> > 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?

Apple creating the feature wasn't the problem. Apple _shipping_ the 
feature, without any peer review, was the problem.


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

Indeed. That's why we can't base this on our opinions nor on a popularity 
vote, but on must use an objective analysis.


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

The DOM, XML, and text/html all have particular things that the others 
don't. For example, XML has DTDs and entities, the DOM can have two 
adjacent hyphens in a comment, and HTML has <noscript>. We've tried to 
minimise these to a great extent, but there's a limit to what we can do.

Also, some things aren't necessarily missing features. For example, some 
people like the draconian error handling of XML, and others like the error 
handling in text/html. You can't have both at the same time.

So I don't think that a proper superset/subset relationship is actally 
achievable, nor do I agree that it is necessarily desireable.


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

So are you saying that what I should have done is rejected your request 
for an extension mechanism that uses namespace prefixes, and instead 
worked on finding another extension mechanism?


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

Your proposals aren't being dismissed without reason. What you should do 
is take stock of the objections (ideally documenting them -- please feel 
free to use one of the wikis if you like), and come up with a proposal 
that addresses all the objections and everyone else's use cases as well as 
yours.


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

That's not an answer to the above question.


> If the situation you find yourself in is "I don't have time to document 
> rationale... because I spend all of my time answering the same questions 
> over and over", then perhaps you should consider spending more time 
> documenting rationale.

I don't find myself in that situation. I find myself in the situation of 
"I don't have time to document the rationale... because I spend all of my 
time answering different questions and editing the spec".


> Or accepting that from time to time questions will be raised again and 
> again.

When questions are raised over and over again by different people, then 
they end up on the FAQ.


> > But we _do_ document questions that come up over and over:
> >
> >    http://wiki.whatwg.org/wiki/FAQ
> >
> > [...] 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.

Ok, I've added a question and answer for this topic:

   http://wiki.whatwg.org/wiki/FAQ#HTML5_should_support_a_way_for_anyone_to_invent_new_elements.21

Please, do feel free to add more questions if you think they should be on 
there. (You don't need to add an answer.)


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

Oh, I thought the prefix part was a key part of what you wanted. My 
apologies.

If you are asking for a mechanism to have containers with custom names 
without peer review, then we already have such a mechanism in text/html. 
It has several key features:

 1. You can pick any name, or even multiple names, for each container.
 2. You can, if desired, use URIs (or any other mechanism) to guarantee 
    uniqueness and to disambiguate.
 3. You can pick an existing HTML element to use as fallback for user 
    agents that don't support your extension.
 4. You don't need any sort of peer review to use it.
 5. It's compatible with existing user agents and can even be used in 
    legacy documents without changes to the rest of the content.
 6. It is supported natively by Selectors and CSS.

The mechanism is the class attribute. Say you wanted to introduce a new 
element for marking up prices in HTML. You could take an existing fragment 
of HTML like this:

   <p>The peas cost $7.99.</p>

...and then you could mark up the "price" bit with a custom container with 
the name "price":

   <p>The peas cost <span class="price">$7.99</span>.</p>

If you wanted to disambiguate your "price" from other people's, you could 
use a URI instead:

   <p>The peas cost <span class="http://ns.intertwingly.net/price">$7.99</span>.</p>

You could select this element from CSS -- if it's a simple name, for 
example, it would look like this:

   .price { color: blue; }

With HTML5, you can even have custom attributes on your element:

   <p>The peas cost <span class="price" data-currency="XCD">$7.99</span>.</p>

Does this resolve your use case? If not, why not? Could you elaborate on 
what your use case is and exactly what requirements you have that this 
doesn't already cover?


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

Do you mean the ISO standard metadata vocabulary that, when applied to 
HTML, uses the HTML metadata extension mechanism? I'm not sure I 
understand its relevance to the discussion of Microsoft's custom tags 
parsing mechanism. Could you elaborate?


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

HTML has multiple mechanisms for including metadata information, and 
similarly has had thousands of extensions invented and several widely 
used. That use case appears appropriately handled so far by HTML5.


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

Yes! Absolutely! We go there with every single element, every attribute, 
every value, every feature, every single time anything is proposed, and 
then again repeatedly thereafter to make sure that we only add the 
absolute bare minimum to the spec.

Let's look at <article> and <video> though. Both are examples of features 
that in previous versions of HTML5, and in deployed content today, used 
existing extension mechanisms successfully.

The semantic conveyed by <article> is found today in the form of 
class="content" and similar names; class names that, in studies, were 
within the top ten class names.

The semantic for <video> is found today using the <embed> extension 
mechanism, with Flash.

In both cases, we see a successful "inward migration" of extensions to the 
language into a peer reviewed part of the core language.


> The reality is that browsers aren't consistent in how they handle 
> unrecognized tags.

Indeed. This is mostly due to the lack of defined error handling in 
earlier versions of HTML. We have addressed this in HTML5.


> Which leads to the fact that XHTML (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.

I don't understand what point you are making here.


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

Here are quotes from a conversation on #microformats last night (I did 
not take part in this conversation, I just saw it in my logs):

   <bennewarde> I don't think I've _ever_ seen someone wanting custom 
   elements

   <tantek> the point of microformats was not infinite extensibility

   <tantek> and btw, we have always intended microformats to be limited, 
   in both number, and usefulness, and have pursued them knowing this. 
   it's their limitations that make them achievable, useful, implementable.

HTML5 has been working with the Microformats community to address major 
problems, and so far the only issue that's really come up has been the 
issue with how to encode time, and we handled with with <time>. Indeed, 
the Microformats community is a testament to the strong extension 
mechanisms that HTML already has. Certainly I have not heard any requests 
from that community for anything like what you have been requesting.


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

Ok, but you apparently have concluded the opposite, so what do you base 
your decision on? How is my analysis flawed?

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