W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: definitions [was: closing on 2009-09-03]

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 27 Aug 2009 14:38:57 -0700
Cc: Ian Hickson <ian@hixie.ch>, Julian Reschke <julian.reschke@gmx.de>, "public-html@w3.org WG" <public-html@w3.org>
Message-id: <194893CC-B342-4819-8F60-A9AAAA31D44D@apple.com>
To: Sam Ruby <rubys@intertwingly.net>

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

This archive was generated by hypermail 2.3.1 : Friday, 10 October 2014 16:24:51 UTC