RE: title (editorial) to scope (technical)

> It more comes down to the majority of HTML  
> processors have far more relevance to what is needed for compat. than  
> other implementations (and the fact that the four biggest are all  
> browsers is coincidental). 

One question is how you count "HTML processors":
installed base, number of bytes processed, economic value of
the HTML processing being done, etc. I think different
individuals and participants in the process may have
different ideas on that.

The second question is around the threshold for "major":
if the four largest HTML processors represent 90% of 
all processors, then satisfying their requirements
seems like it would give a useful result. But if the
four largest HTML processors represent only 20% of
all processors (by some metric), then satisfying the
needs of those processors isn't adequate for insuring
that the standard has broad applicability.

I think the latter is closer to the case. For every page
served and rendered by a browser, there is some process
or program or effort to create, author or produce, 
post, back up, date, provide metadata for, and otherwise
manage the page or data used to create it.

"if the major processors don't implement a feature it
shouldn't stay in the spec., as for the vast majority of
users the feature may as well not be in the spec"

Even if you were only considering the four major
browsers and their users as the only source of
requirements, some caution would be needed, because
of indirect dependencies:

Users may not think they care about how the web page
they're looking at got there, and so they might think
of the other components necessary to give them what
they want. The stages of processing are independent. 

Lack of utility of a feature for the "majority" still
doesn't support leaving the feature out, if the
scope of the document being produced is to be useful
for categories of processors that are not represented
in the "majority".

To make this more concrete (so that we're not talking
in the abstract):

For example, an authoring tool might have good use for
a "version indicator" (which version of this spec is this
page intended to be valid under), even if a browser has
no use for such an indicator (because it the browser has
to be robust when receiving content with incorrect 
version indicators.)  

A version indicator might have no impact on browsers --
they can likely ignore it -- but if it has utility in
other parts of the value chain, and isn't harmful
to other processors, it may still be useful and belong
in the specification.

Larry
-- 
http://larry.masinter.net

Received on Thursday, 28 May 2009 22:19:27 UTC