- From: Henrik Dvergsdal <henrik.dvergsdal@hibo.no>
- Date: Mon, 11 Jun 2007 14:56:27 +0200
- To: HTML WG <public-html@w3.org>
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. 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" IMO this is a very tidy and precise way of specifying the behaviour of attributes (although I have some trouble with treating unset as a state). 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. So my question is: What should be the conceptual model of element attributes? -- Henrik Dvergsdal
Received on Monday, 11 June 2007 12:57:08 UTC