W3C home > Mailing lists > Public > public-html@w3.org > June 2008

Re: Liaison with CSS WG to provide a mechanism for expressing the style of document semantics

From: Robert J Burns <rob@robburns.com>
Date: Thu, 5 Jun 2008 12:30:40 +0200
Cc: "'HTML Issue Tracking WG'" <public-html@w3.org>
Message-Id: <36B877F3-4FBD-4CDC-8285-0C3FA11C33FE@robburns.com>
To: Justin James <j_james@mindspring.com>

Hi Justin,

Let me reply to your bullet points here:

On Jun 5, 2008, at 10:22 AM, Justin James wrote:
>
> Whew! It's nice to finally "get" this! Now that I understand it the  
> way you
> intended it, I like it a lot better. Some comments though (I know,  
> I'm a
> tough crowd):
>
> * I am proposing a touch more than just a rename (although the  
> rename would
> make it more clear, IMHO)

Perhaps, but to me a legend in the sense of: “wording provided by  
authors explaining the meaning of the presentational properties” is a  
more apt description.

> * I believe that allowing user created "semantics" is a mistake; we  
> keep
> trending away from pre-enumerated values in favor of this ultimate
> flexibility.

Well I'm not proposing user created "semantic", but instead  
facilitating the extension of authoring semantics that's already  
taking place on the web. Whenever an author coins a new class name or  
even attaching the id value of footer or header to a DIV they are  
authoring semantics whether they themselves think of it that way or  
not. Typically when a CSS author adds a class selector or other  
intricate selectors they are often doing so to provide a unique  
presentation mechanism to expose the semantics of the HTML document.

> I believe that an insanely small fraction of developers ever
> extend these systems, and when they do, consumers are never able to
> understand the extensions.

Quite the contrary authors regularly extend the system whenever  
coining class names or attaching those class names to a particular  
element. And by providing a CSS legend mechanism we give consumers of  
content the ability to understand those semantics.

> When we mandate a predefined enumeration, we
> allow developers to leverage that and write applications that can  
> truly
> understand the semantics of a document.

Certainly.

> * The human user figures out semantics easily, regardless of markup.  
> When I
> see "USS Nimitz", I know that it is a ship's name regardless of the
> formatting, thanks to the "USS" prefix. But when a human HTML author  
> marks
> that string with <em> to provide the grammatically correct italics  
> to it,
> any machine semantic parser with think that the string is important,  
> which
> is not its semantic meaning at all.

Not always imagine the semantics of big issues in the current HTML5  
draft. If the authored legend of “big issues are marked like this”  
were not included in the document, the user would not necessarily  
comprehend the semantics conveyed by the red text and red border  
styling. Obviously the user can draw on context and other clues, but  
it is better to provide an explicit mechanism for authors. For a user  
of unconventional media, the author may have failed entirely to  
provide legend information or even distinctive styling declarations.  
For that user, the semantics remain completely inaccessible.

> * I think that an awful lot of our problems come from trying to  
> import XML's
> concept of extensibility into HTML. I posit that HTML, when it is
> extensible, does not need to be consistent. After all, HTML *is* an  
> end-use
> standard. XML is a metastandard used to define other standards.  
> That's a big
> difference. As it applies here, I don't see why authors need the  
> ability to
> create their own semantic roles for things.

Authors already do create and use their own semantics by using class  
names, id values and even combinations of various attribute values  
(apparent in compound CSS selectors). Keep in mind that most times a  
CSS author makes a CSS declaration it is typically associated with a  
semantic in the document and often times associated with extended  
semantics not provided by HTML<5.

> Indeed, if we just take the
> existing list of semantic tags, and strip off "<" and ">", that  
> right there
> is a great start for an enumeration of all of the semantic concepts  
> that we
> want to expose to "legend/purpose".

Well the element type names contain semantic information yes. However,  
authors do add other semantic information through the other mechanisms  
available in HTML.

> I hope I am making sense here; to be frank, I haven't had real sleep  
> in a
> while, and I know that my grammar and logic have been suffering a  
> bit as a
> result.

I understand. I do think we're starting to understand each other, but  
there are clearly still some gaps.

> Thanks again for your patience! I think that we have a great start  
> to an
> idea that will really improve things for Web browser implementers, Web
> developers, and the authors of applications that consume HTML.

Thanks for your feedback, confidence and enthusiasm. I do think this  
can be a valuable addition to the semantic and self-describing web.

Take care,
Rob
Received on Thursday, 5 June 2008 10:31:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:55 UTC