- From: Robert Burns <rob@robburns.com>
- Date: Sun, 5 Aug 2007 00:57:51 -0500
- To: Ben Boyle <benjamins.boyle@gmail.com>
- Cc: public-html@w3.org
On Aug 5, 2007, at 12:33 AM, Ben Boyle wrote: > > HTML attribute isn't bad. "Content attribute" is a bit vague. > > Knowing where the spec is referring to the serialisation and when the > DOM is quite tricky; which has not been a problem in the past when the > HTML and DOM specs have been kept separate. > > I don't mind merging the specs (especially if it helps implementors) > but clarity of language will be a challenge. "HTML attribute" and "DOM > attribute" seem simple choices to me. I like the idea of using HTML attribute. In some ways I think it would make sense for a recommendation such as HTML5 to use "HTML" in the broadest possible way. Then use 'DOM' to refer to the HTML DOM, 'XML' or 'XHTML' to refer to the XML serialization of HTML and "text/ html" (or something like that) to refer to the legacy HTML serialization of HTML. Applying those principles to this situation HTML attribute makes a lot of sense. However, since this is the HTML DOM, if the value of this attribute were to differ (and this case it shouldn't) it would make sense to differentiate the HTML attribute from the DOM attribute (even though this is an HTML DOM attribute). This also raises another issue that has concerned me. I really do not like the cases where a DOM attribute with the same name (or differing only by case) is not a direct reflection of the contents of the corresponding HTML attribute. I haven't really explored the backwards compatibility issues on this, but in general I think we should avoid that situation. It's only going to lead to a sore source of confusion for authors/developers. Finding a different name that varies from the HTML attribute name does not seem like it should be that difficult. The dateTime DOM attribute on the TIME element [1] is a case in point. If we could avoid this we could say for every DOM attribute that has a corresponding HTML attribute the DOM attribute's value must always reflect the state of the HTML attribute. This helps unify the HTML concept too, in that every time a DOM attribute has a corresponding serializable HTML attribute they're mirror images of one another: they're all HTML attributes. The DOM would then have its own uniquely named attributes in some cases that would be properly called "DOM attributes" or "DOM only attributes". Take care, Rob [1]: <http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html? rev=1.78#the-time>
Received on Sunday, 5 August 2007 05:57:59 UTC