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: Justin James <j_james@mindspring.com>
Date: Thu, 5 Jun 2008 04:22:27 -0400
To: "'Robert J Burns'" <rob@robburns.com>
Cc: "'HTML Issue Tracking WG'" <public-html@w3.org>
Message-ID: <04ae01c8c6e5$4a6df630$df49e290$@com>

Robert -

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)
* I believe that allowing user created "semantics" is a mistake; we keep
trending away from pre-enumerated values in favor of this ultimate
flexibility. 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. When we mandate a predefined enumeration, we
allow developers to leverage that and write applications that can truly
understand the semantics of a document.
* 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.
* 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. 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".

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

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.


-----Original Message-----
From: Robert J Burns [mailto:rob@robburns.com] 
Sent: Wednesday, June 04, 2008 5:08 PM
To: Justin James
Cc: 'HTML Issue Tracking WG'
Subject: Re: Liaison with CSS WG to provide a mechanism for expressing the
style of document semantics

Hi Justin,

On Jun 4, 2008, at 2:12 AM, Justin James wrote:

> I think I "get" it now. There are two items which are throwing me  
> for a
> loop; the word "legend", and the way I *thought* you were using the  
> concept
> of semantics.

Indeed I think you understand the proposal. Let me see if I understand  
the changes you're suggesting. As far as I can tell, you're simply  
suggesting the name of the property should be "purpose" rather than  
"legend". Is that correct? Are there other differences in your  
rendition, that I'm missing?

> OK, here is my revised understanding:
> "Legend" tries to provide a mechanism so that the semantic value of  
> a tag
> can be derived from the CSS definitions applied to the tag (with the  
> usual
> hierarchies, inheritance, etc.). It is similar in *concept* to "aria- 
> role",
> but instead of defining a function role at the element level, it  
> specifies a
> semantic purpose at the CSS definition level.
> I think (if my new understanding is correct) that the problem here  
> is that
> the semantics are not pre-enumerated. In the examples listed, the only
> applications that can "get" the semantics are ones written by the  
> author, or
> in collusion with the author.
> If, instead, we rename "legend" to be "purpose" (or something along  
> those
> lines), and pre-define a list of semantic purposes ("emphasis",  
> "strong
> emphasis", "blockquote", "header", etc.), then we make the following
> possible:
> .footnote {
>   purpose: "citation";
>   font-size: smaller;
>   color: grey;
> }
> So now the author can use <div class="footnote"> and achieve  
> styling, while
> retaining the same semantic meaning as a <citation> tag.

Well that is possible even without this legend proposal. What legend  
makes possible is a way to give users and consumers of the content a  
natural language (and localized) description of the meaning conveyed  
through some CSS style declarations (and by extension the the element  
type names and attribute values that constitute the semantics encoded  
in the HTML/XML document).

> This type of mechanism maintains my historic aim of separation of  
> semantics,
> presentation, and content, while also pushing towards the semantic  
> Web in a
> way that anonymous applications can understand the meaning of a  
> document. It
> also provides an alternative mechanism so that less specific tags  
> (such as
> div, span, img, etc.) can have more accurate semantic meanings,  
> without
> having to radically re-style existing semantic tags. In this  
> example, using
> <img class="footnote" ... /> for an image that represents a footnote  
> is a
> heck of a lot better than using a <citation> tag with a  huge amount  
> of
> styling to transform it into a tag able to display the needed image.

Yes, I think that's a nice way of putting it. Certainly part of my  
goal here was to capture that "self-describing web" idea.

> So, Robert, if my understanding of your proposal is now accurate, I  
> would
> suggest the changes that I have here. Otherwise, I will gladly  
> propose these
> items separately, and hopefully we can figure out how to talk about  
> "legend"
> in a way that we can all understand it.
> Thanks for your patience with me on this!

No, problem. There are many great ideas that have been floated among  
the WG members. It takes some measure of patience from all of us to  
fully understand them.

Take care,
Received on Thursday, 5 June 2008 08:23:37 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:32 UTC