- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 27 Aug 2009 14:38:57 -0700
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: Ian Hickson <ian@hixie.ch>, Julian Reschke <julian.reschke@gmx.de>, "public-html@w3.org WG" <public-html@w3.org>
On Aug 27, 2009, at 2:26 PM, Sam Ruby wrote: > Ian Hickson wrote: >> On Thu, 27 Aug 2009, Julian Reschke wrote: >>> Ian Hickson wrote: >>>> On Fri, 28 Aug 2009, Michael(tm) Smith wrote: >>>>> Ian Hickson <ian@hixie.ch>, 2009-08-26 02:28 +0000: >>>>>> On Tue, 25 Aug 2009, Roy T. Fielding wrote: >>>>>>> If we actually defined each element and each attribute in the >>>>>>> way that >>>>>>> HTML4 does *and* define its operational behavior for the DOM >>>>>>> then the >>>>>>> specification would satisfy all implementations. >>>>>> I don't know what it means to "define" an element if that is >>>>>> not to >>>>>> define its operational behaviour. >>>>> It means defining what the element represents. >>>> "represents" in the HTML5 spec when used about elements and >>>> attributes is a term that just refers to the media-independent >>>> rendering of those features, which as far as I can tell doesn't >>>> apply to <a name>. Did you have something else in mind? >>> With all due respect, Ian: I think it's obvious that Mike has in >>> mind, and it's not what you said. >> If you think it's obvious, maybe you would be willing to explain it >> to me? >> The only interpretation that I can see is that Mike means non- >> normative text giving an introduction to the feature to help >> authors use it. That, however, is not a definition, and would in >> any case be inappropriate for obsolete features such as those being >> discussed here. > > I might be wrong, and if so, I'll blow what little credibility I > have and derail this discussion, but given that the discussion > doesn't seem to be moving forward very fast, I guess it is worth the > risk. > > It seems to me that in HTMLT5 there is a difference between <b> and > <strong> that is both normative and can not be described in terms of > browser implementations. That is a good point. Furthermore, HTML5 says elements and attributes have semantics: "Elements, attributes, and attribute values in HTML are defined (by this specification) to have certain meanings (semantics)."[1] HTML5 also requires that elements and attributes must be used consistent with their semantics: "Authors must not use elements, attributes, and attribute values for purposes other than their appropriate intended semantic purpose."[1] It seems to me that semantics need to be defined at least for obsolete but conforming elements and attributes. They SHOULD not be used, but they also MUST NOT be used inconsistent with their semantics. If they have no semantic meaning at all, then the MUST NOT requirement doesn't apply, which seems silly. For obsolete and nonconforming features, it may be a tenable position to say they have no semantics at all, since they can't be used at all. But I don't see how that works for anything conforming, even if it is obsolete. Now, I'm not sure how much this applies to the things in the "obsolete but conforming" section. Many of them are purely presentational and therefore have no defined semantics in particular, so it's not wrong to use them for one purpose or another. But it seems that a semantic could be assigned for <a name>, and arguably should, because it's inappropriate for authors to put random values in there that are unrelated to its purpose, just as much as is the case for id. Regards, Maciej [1] http://dev.w3.org/html5/spec/Overview.html#semantics-0
Received on Thursday, 27 August 2009 21:39:42 UTC