Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03

On Aug 26, 2009, at 2:49 AM, Sam Ruby wrote:
> I'm going to try to recap my understanding; which may very well be  
> significantly imperfect, but perhaps if you both can point out  
> where I veer off into the weeds, it might be useful in furthering  
> discussion.
>
> First premise: there exist elements in the language that are widely  
> discouraged (whether that is deprecated, obsolete, non-conforming,  
> or whatever is immaterial to this particular discussion).  An  
> example of such is the <plaintext> element.  However, even for such  
> elements, it is important that the spec completely describes their  
> behavior, and that conforming user agents have no observable  
> behavior that differs from the behavior specified.

No.  It is important that the spec defines the language, because
that is what the title of the spec claims to do and that is what
the issue topic claims to supplant.  If it also described the
behavior of conforming user agents (which, again, are only a very
small percentage of the total applications of HTML), that's gravy.

> Second premise: there exists (in the past, present, and foreseeable  
> future) HTML implementations that not only do not possess a DOM,  
> they positively have no interest in possessing a DOM.  Within the  
> scope of the functions that they perform, all that is important is  
> that they do not differ in observable behavior from other  
> implementations that may possess a DOM.  If they do that, such  
> implementations can fully interoperate and participate in the  
> ecosystem that we call the web.

They don't just exist.  They outnumber browsers 1000:1.

> I don't believe that either of these premises are in dispute, but I  
> welcome anybody to indicate otherwise.
>
> Now, let's try to anchor (no pun intended) the discussion with a  
> concrete example expressed in terms of a HTML fragment:
>
>   <table>
>     <tr><td>foo</tr>
>     <a name='bar'>x
>     <plaintext>
>     <a name='baz'>z
>
> In that fragment, the behavior that HTML5 describes is that there  
> exists exactly one anchor, and for any implementation for which it  
> is important to define the precise location of that anchor, the  
> correct placement is before the <table>.  Any implementation that  
> can be observed to behave differently (e.g., ones that identify two  
> anchors, or ones that identify the anchor as being placed within or  
> after the table) may be of some utility, but can't be described as  
> fully interoperable or conforming.
>
> And I will note that all of the statements in the above paragraph  
> are independent of the fact that the above fragment is itself non- 
> conforming in a number of ways.
>
> Now, expressing the full interoperable behavior desired in this  
> case is a daunting task.  As a matter of editorial style, Ian has  
> often chosen to define such behaviors in terms of the info-set that  
> a DOM-possessing implementation would produce.  On matters of  
> editorial style, people can and do differ, but as long as the  
> document produced does not run afoul of the second premise above,  
> the document may not be considered ideal by all, but it is acceptable.

I don't care about that use case.  I care about knowing what each
of those elements is intended to represent and knowing that those
elements are not being used as they should.  I couldn't care less
if every single browser had its own unique presentation of that
brokenness and entirely different internal DOM structures.
None of that is relevant to *my* implementations of HTML.

I can live with additional stuff being published in the HTML spec
that will only be of interest to browsers, even though the spec
is now 628 pages long, because browser use cases are important to
someone else's implementations.  What I don't agree with is the
theory that HTML can be *defined* in terms of browser behavior.

And my comments have only been on the definition of <a>.  At this
rate, we won't even make it through a read of the entire draft
by the end of this year.

....Roy

Received on Wednesday, 26 August 2009 17:23:26 UTC