Re: Conceptual modelling of attributes (and Note on terminology: Attribute types)

On Mon, 11 Jun 2007, Henrik Dvergsdal wrote:
> 
> I Have just started reviewing the editing section and need to clarify 
> one question before I proceed.
> 
> The contenteditable attribute is specified as follows:
> 
> ------------------
> The contenteditable attribute is an enumerated attribute whose keywords 
> are the empty string, true, and false. The empty string and the true 
> keyword map to the true state. The false keyword maps to the false 
> state, which is also the invalid value default. There is no missing 
> value default.
> 
> If an HTML element has a contenteditable attribute set to the true 
> state, or if its nearest ancestor with the contenteditable attribute set 
> has its attribute set to the true state, or if it has no ancestors with 
> the contenteditable attribute set but the Document has designMode 
> enabled, then the UA must treat the element as editable (as described 
> below).
> 
> Otherwise, either the HTML element has a contenteditable attribute set 
> to the false state, or its nearest ancestor with the contenteditable 
> attribute set is not editable, or it has no ancestor with the 
> contenteditable attribute set and the Document itself has designMode 
> disabled, and the element is thus not editable.
> 
> The contentEditable DOM attribute, on getting, must return the string 
> "inherit" if the content attribute isn't set, "true" if the attribute is 
> set and has the true state, and "false" otherwise. On setting, if the 
> new value is case-insensitively equal to the string "inherit" then the 
> content attribute must be removed, if the new value is 
> case-insensitively equal to the string "true then the content attribute 
> must be set to the string "true, if the new value is case-insensitively 
> equal to the string "false then the content attribute must be set to the 
> string "false, and otherwise the attribute setter must raise a 
> SYNTAX_ERR exception.
> ------------------
> 
> According to this text, the attribute seems to have states with 
> associated get and set mappings.

Follow the links for definitions of terms. Specifically, "enumerated 
attribute" is a defined term which introduces the concept of states that 
you mention.


> The contenteditable attribute seems to be modelled as follows:
> 
> States: true, false, unset
> Default state: unset (?)
> Set mappings: "true"=>true, ""=>true, other values=>false  (case independent)
> Get mappings: true=>"true", false=>"false", unset=>"inherit"

This seems a bit confused. There are two attributes, contenteditable (the 
content attribute) and contentEditable (the DOM attribute). The content 
attribute has a value (whatever was in the markup or whatever is passed to 
setAttribute) and a state (as defined above). The DOM attribute returns a 
string based on the state, and on setting parses the set string and sets 
the content attribute appropriately.


> However, although I haven't done any kind of comprehensive testing, it 
> seems to me that this is not compatible with the way current browsers 
> treat attributes. They don't seem to use this type of mapping at all, 
> and simply return the text that was specified on setting.

Content attributes have a value, the state of the attribute doesn't affect 
the value of the attribute.


On Mon, 11 Jun 2007, Henrik Dvergsdal wrote:
> 
> Two more questions:
> 
> The spec says: "The contenteditable attribute is a common attribute. 
> User agents must support this attribute on all HTML elements."
> 
> Does this mean that it is an ordinary element attribute or may it an 
> attribute reflected by a HTML-specific DOM property?

The statement above is orthogonal to this question. It does not say one 
way or the other.

In the spec, content attributes and DOM attributes are always explicitly 
defined separately.


> Does anyone have examples of HTML specific DOM properties that reflect 
> attributes?

Search for "reflect" in the HTML5 spec for many, many examples.


On Mon, 11 Jun 2007, Boris Zbarsky wrote:
> 
> Henrik Dvergsdal wrote:
> > getAttribute must the same value that has ben set with setAttribute.
> 
> Modulo normalization.  For example, some UAs perform case normalization 
> on the "type" attribute of <input>.

This is not allowed per HTML5. (Part of the effort to harmonise HTML and 
XML processing models for HTML5.)


On Tue, 12 Jun 2007, Henrik Dvergsdal wrote:
> 
> I think we will gain precision by using consistent, spec-wide 
> terminology to distinguish between DOM attributes and attributes defined 
> on elements (reflected by the DOM Attr interface). The spec uses (at 
> least) three different terms for the latter:
> 
> "attribute"
> "content attribute"
> "element attribute"
> 
> IMO "element attribute" is the most unambiguous and descriptive 
> alternative. At least, simply using "attribute" should be avoided.

The spec uses "content attribute" for attributes in markup, and "DOM 
attributes" for what ends up as JS properties. The term "attribute" 
unqualified is only used when it is unambiguous in the context. The term 
"element attribute" is not supposed to ever be used. (There is also "event 
handler attribute", which is a separate concept.)

Let me know if there are any times where I've used the terminology in a 
confusing manner here.


On Tue, 12 Jun 2007, Henrik Dvergsdal wrote:
> 
> Section 3.14.9 refers to "media element attributes". I guess this should 
> be understood as "content attributes pertaining to media elements", but 
> it can also be taken as a special class of element attributes.

Given that the section is called "media elements", and that the previous 
sentence defines the term "media elements", it seems logical to me to 
understand "media element attributes" as being attributes that pertain to 
media elements.

I could change it to "media element content attributes" if that would be 
clearer, though.


> Relying too much on context makes the text harder to read, increases the 
> risk of misunderstanding and makes communication more difficult (because 
> you cannot allways bring the entire context into a conversation).

On ther other hand, being explicit each times makes the text harder to 
read (because it becomes significantly more verbose), and increases the 
risk of errors in the text (because each time, the editor has to check 
which type of attribute is being discussed, even when it might not really 
matter).


> So why not put in an "element" and "DOM" here and there just to 
> explicate the difference?

The spec _does_ but "content" and "DOM" here and there to prevent 
ambiguity. They're only omitted once the context has been made clear.

Also, you can always tell which attribute is being discussed by following 
the link to its definition. The attribute definitions always explicitly 
say if it is a DOM or content attribute that is being defined.


On Tue, 12 Jun 2007, Boris Zbarsky wrote:
> 
> Henrik Dvergsdal wrote:
> > I think we will gain precision by using consistent, spec-wide terminology to
> > distinguish between DOM attributes
> 
> I've usually seen these called "properties", precisely to distinguish 
> them from element attributes...  Of course they're "attributes" in the 
> IDL... :(

Sadly there is a difference between DOM attribute and JS properties -- and 
the term "properties" isn't unambiguous either, since we have CSS 
properties. I think it would be more confusing to use the same term for 
DOM attributes and JS properties, since they are almost always the same 
thing and so when you _do_ want to distinguish them, you need to be 
extremely clear about it.

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

Received on Tuesday, 12 June 2007 20:45:26 UTC