W3C home > Mailing lists > Public > public-html@w3.org > August 2009

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

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 26 Aug 2009 10:00:57 -0700
Message-Id: <2340DEAD-32E1-4B64-AA3E-FD456060BB40@gbiv.com>
Cc: Ian Hickson <ian@hixie.ch>, "public-html@w3.org WG" <public-html@w3.org>
To: Maciej Stachowiak <mjs@apple.com>
On Aug 25, 2009, at 10:41 PM, Maciej Stachowiak wrote:
> On Aug 25, 2009, at 8:11 PM, Roy T. Fielding wrote:
>> The DOM state as an infoset, yes.  HTML5 is not defined in terms of
>> the DOM state.  It is defined in terms of operations on that state
>> (i.e., behavior), including attributes of the DOM that are a side- 
>> effect
>> of processing operations.  The difference is quite huge.
>
> As far as I know, the only times HTML5 performs an observable side  
> effect on the DOM is when doing fixup for certain unusual syntax  
> error conditions, and when performing operations that are in fact  
> intended to mutate the document. The parse-time fixup - the  
> adoption agency algorithm -  is needed to get compatible behavior  
> for some cases of misnested tags, but HTML processors have license  
> to give a fatal error on encountering a syntax error if they do not  
> wish to do the prescribed fixup. The other cases are, I believe,  
> fully intended as part of mutating operations, and shouldn't occur  
> in read-only operations.
>
> If you know of any cases where an HTML5 algorithm expressed in  
> terms of the DOM modifies the DOM, and the operation is needed for   
> purely read-only processing, please report it, because I think that  
> would be a serious bug.

Perhaps you would prefer secondary-effect?  What I was referring to
in this case are the URL decomposition attributes of the DOM.

For example, in <a>:

    The DOM attribute relList must reflect the rel content attribute.

    The a element also supports the complement of URL decomposition
    attributes, protocol, host, port, hostname, pathname, search, and
    hash. These must follow the rules given for URL decomposition
    attributes, with the input being the result of resolving the
    element's href attribute relative to the element, if there is
    such an attribute and resolving it is successful, or the empty
    string otherwise; and the common setter action being the same as
    setting the element's href attribute to the new output value.

This is a good idea, though I would specify such attributes as null
if the entire component is missing, empty string if the component is
present-but-empty, and a filled string if it is present and filled.
This is explained in RFC 3968 section on parsing references.

However, the above is also specified in a way that is hopeless
to understand unless you already know that we are talking exclusively
about the "a" node in a DOM and its artificial children that are
instance variables for that node.  Instead, the spec refers to both
DOM nodes and mark-up as "elements" and both instance variables and
real mark-up attributes as "attributes".  That's confusing and very
annoying to folks who have no interest in non-content attributes.

The reader also has to follow the links to section 6.12.1 in order
to find the attribute definitions.  Has anyone tried to read
this document in printed form?

....Roy
Received on Wednesday, 26 August 2009 17:01:35 UTC

This archive was generated by hypermail 2.3.1 : Friday, 10 October 2014 16:24:51 UTC