URL decomposition attributes on <a>, confusingness of references

On Aug 26, 2009, at 10:00 AM, Roy T. Fielding wrote:

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

I agree this is potentially confusing. For what it's worth, URL  
decomposition only needs to be implemented by implementations that  
support scripting, so this definition is probably not of interest to  
DOMless implementations.

I think treating DOM elements interchangeably with markup elements is  
fine - DOM elements reflect the markup in the form of an abstract  
model. However, the name collision between markup attributes and IDL  
attributes. The spec should make sure to qualify as "IDL attribute" or  
"markup attribute" wherever there is potential ambiguity. Another  
possibility is to use the term "property" to refer to IDL attributes,  
since they are reflected as JavaScript properties, and the chance of  
confusion with CSS properties is much less.

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

I've always read it in online hypertext form, and often I have to  
chase quite a few links to fully understand how something works. I  
can't imagine doing that in print, where the links don't even link.  
Perhaps there should be a version for printing that includes a section  
number after each in-spec link (I imagine this could be generated  
automatically).

Regards,
Maciej

Received on Wednesday, 26 August 2009 21:26:15 UTC