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

Hi Justin,

I think we are indeed starting to communicate on this proposal.  
However, it is the use cases and the authoring practices that I think  
you still don't appreciate. This is to provide a mechanism much like  
you describe here below, but with much wider implications than your  
example depicts.

The most common place this would get used in providing a natural  
language description for semantically-oriented class attribute values  
(as in your example). However, its intended primarily for greater re- 
use and typically wider use than just one author (hence the potential  
for re-use). It also typically does not belong in the HTML document  
itself, since the semantics are already encoded in the class  
attribute. Instead this is a natural language (and potentially  
localizable) description of the semantics of the class attribute:  
semantics presented by the particular CSS declaration block. While an  
author of a single document may want to style the works of Jackson  
Pollock in a unique way, the legend would apply to all such works and  
shouldn't be included on any one of them.

Another thing to keep in mind is that including the legend property in  
the CSS facilitates common authoring practices where the CSS author  
will more often be in a position to describe why a particular CSS  
selector and corresponding declaration block is being conveyed. In the  
case where the declaration block is purely presentational and conveys  
no semantics in the HTML document, the legend property is omitted.  
When the declaration block is designed to convey a particular meaning  
within the document the CSS author provides that legend then. The  
ability to use a URI or other CSS syntax could also enable an author  
to get to separate HTML legend documents, or a legend embedded in a  
single document (such as a meta element with an id attribute set).

Some common use-cases for this include:

  • communities sharing (in a microformat fashion) the same semantic  
class attribute values or other attribute values (like the biblical  
example on the wiki or a juridical community like another example I  
gave)
  • A small or large corporation with a set of official corporate  
stylesheets
  • Everyone sharing HTML and its semantics (for example an author or  
community of authors using bold for emphasis rather than italics since  
the low resolution of modern screens doesn't really render it with  
enough distinction; here no class selector is involved just a element  
type selector).

The last example is a good case where there should be no reason to  
include the description of the semantics in the HTML document. Here  
the semantics are conveyed using the EM element. However, a group of  
authors may decide to deviate from convention and present emphasis  
with a bold font weight rather than an italic font style. Yes the EM  
element’s semantics are already defined, but the author can still  
provide them in the CSS declaration block legend to convey that the  
semantics of emphasis is in bold rather than italics.

The HTML5 draft is another good example where this could be used. For  
example it now has a partial legend with[1]:

> Known issues are usually marked like this. There are some spec-wide  
> issues that have not yet been addressed: case-sensitivity is a very  
> poorly handled topic right now, and the firing of events needs to be  
> unified (right now some bubble, some don't, they all use different  
> text to fire events, etc).

In this case the legend property would read: “Known issues” and the  
legend-presentation property would read ”like this”. Consider the  
problem surrounding this author provided legend. Other stylesheets may  
override the “like this” so a better description such as “in red text  
and with a red border around the paragraph” might be better, but might  
also be inaccurate with the results of the cascade.

There are accessibility and universality issues here as well. When an  
author includes a legend property in a declaration block, the author  
is signaling that the declaration block conveys important semantics  
about the document and without any distinguishing presentation of  
those semantics, the user/reader will be missing something.

This CSS legend proposal provides authors with a better way to  
describe their styling (when that styling conveys underlying document  
semantics). Also by doing this, the proposal allows users of  
unconventional UAs and media to identify missing style declarations  
and fill in the gaps.

Sorry for the long reply, but I hope this helps make it clearer.

Take care,
Rob


[1]: <http://dev.w3.org/html5/spec/Overview.html#stability0>

original message:
On Jun 3, 2008, at 5:02 PM, Justin James wrote:

>
> Robert -
>
> I am formally admitting that I do not understand this now. :)
>
> I think maybe I should explain what I think this proposal is saying.  
> Please
> let me know if I have this all wrong, in which case it is safe to  
> ignore
> most of my comments here!
>
> * Many elements, most notably images, but possibly video or audio as  
> other
> obvious cases, have a need for explanatory text.
> * This explanatory text is a form of "meta data" to the element, and  
> however
> it is marked up needs to let the UA know to handle it as explanatory  
> text.
> For example, a screen reader might use a different voice pitch and/ 
> or volume
> to indicate that the text is an "aside".
> * This text is supposed to be used for... I have no idea, to be  
> honest, what
> this text is used for that @alt doesn't address. But assuming that  
> it has a
> purpose other than what we specify @alt for...
> * This text gets defined in CSS, and well as rules for how the browser
> should handle its display.
>
> For example (I am totally guessing on the property usage here, this  
> is for
> demonstration purposes only):
>
> .pollack {
>   legend: "The works of Jackson Pollack";
>   legend-presentation: "deep voice, red text";
> }
>
> This would cause an element with a class of "pollack" to be  
> displayed (on a
> screen-based UA) with the text "The works of Jackson Pollack"  
> somewhere, and
> that text should be red; a screen reader would use a "deep voice" when
> speaking the words, "The works of Jackson Pollack".
>
> I actually like this proposal to an extent (assuming that it works  
> the way I
> think it does). What I like about it is the ability to give hints to  
> the UA
> as to the presentation of this additional "helper text". My  
> objection is in
> the inclusion of the "help text" in the CSS definition. If you moved  
> the
> "legend" property to be an HTML attribute, we would be golden in my  
> book.
> For example, if you remove the "legend" property from my previous fake
> definition, and used this tag:
>
> <img src="/images/jpollack1.jpg" height="100" width="100"  
> id="pollack1"
> class="pollack" alt="Jackson Pollack's most famous painting"  
> legend="The
> works of Jackson Pollack" />
>
> What you would get is the usual @alt text, some sort of display of the
> legend text "The works of Jackson Pollack" presented in red text and/ 
> or a
> "deep voice", and the image itself.
>
> And this to me makes sense. Not everything properly has @alt, but  
> @legend
> could/should be applied to all elements (data tables spring to mind,  
> for
> example). But the major hang up I have here is the inclusion of the  
> legend
> text in the CSS. I know that it may save someone some time in the  
> edge case
> of someone writing static HTML by hand and using things with the  
> same legend
> text more than a few times. Tough for them, they probably need to  
> use a
> dynamic app anyways. And it may save some bytes on the wire, to  
> which I say,
> "turn on HTTP compression." But in terms of the static semantic  
> goals of
> HTML/CSS, putting legend text in CSS is not a good idea from where I  
> sit.
>
> Assuming, of course, that I am thinking of this correctly. :)
>
> J.Ja
>
> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org]  
> On
> Behalf Of Robert J Burns
> Sent: Monday, June 02, 2008 7:56 AM
> 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 1, 2008, at 7:09 PM, Justin James wrote:
>
>>
>> Robert -
>>
>> I do not currently have any questions about the proposal, but I am
>> beginning
>> to suspect that I do not understand its purpose. If I have an unclear
>> understanding of it, then I have either read it so wrong that I
>> think I
>> understand it, or it does not convey its purpose properly.
>
> I'm pretty sure you don't understand it. But I'd like to work on it
> through email and the wiki page to see what I can do so others don't
> have the same misreading.
>
>> I will say this, the more I read this proposal, the more it looks
>> like an
>> attempt to compensate for the lack of granularity of @alt, or
>> provide an
>> alternative to @alt.
>
> No, it has nothing to do with @alt.
>
>>
>>
>> Let me rephrase my thoughts, sans examples which are clearly making
>> my point
>> not clear.
>>
>> Content does not belong in a stylesheet (or any kind of style
>> definition).
>> "Legend" is content. It does not belong in a style definition. The
>> use case
>> provided on the wiki does not make a strong argument for this
>> solution to
>> the problem, and the example you cite below (repetitive items
>> require the
>> same legend) is not realistic; anyone generating that much repetitive
>> content is not writing static HTML by hand, and making new ways of
>> cutting
>> down the document size of HTML is not one of our goals as far as I
>> know
>> (that's why there is HTTP level compression).
>
> Part of the confusion here is over what is content? Yes, this proposal
> can be thought of as involving content in a sense (after all it uses
> the CSS content property). However, I don't think it is content in the
> sense you're reading it. I think that is contributing to us talking
> past one another.
>
> Keep in mind this is about bridging the semantics of the HTML document
> with the presentation of the CSS document. So the proposed "legend"
> property might be construed as semantic content (in some sense, but
> not in the sense I think you're thinking of it). While on the other
> hand, the "legend-presentation" property involves non-semantic
> content: instead it describes the visual aural or tactile presentation
> declarations.
>
> The use of such presentations legends is necessarily repetitive.
> Consider the extreme example of a default UA stylesheet.
>
> @media screen {
> strong {
>                 legend: "strong emphasis";
>                 legend-presentation: "italic";
>                	font-style: italic;
> }
> }
>
> @media speech {
> strong {
>                 legend: "strong emphasis";
>                 legend-presentation: "increased stress and richness";
> 	        pitch: medium;
>                 pitch-range: 60;
>                 stress: 90;
>                 richness: 90
> }
>
> }
>
> This legend would be used millions or billions of times across pages
> around the World. This legend would be used on pages, many of which
> are hand-coded. Authors of HTML documents could also add their own CSS
> content property usage to include the print media legend in a printed
> document. Or fine-tune this in other ways. The point is that this is
> the type of content that is ripe for reuse, and is already widely
> reused (at least the CSS declarations are reused without legends).
>
> Also to contrast things a bit, the following CSS declaration would
> certainly not include a legend:
>
> body {
> 	font-family: Georgia, "Times New Roman", Times, serif;
> }
>
> In this case the CSS is purely presentations. It conveys no meaning to
> the user that the body uses a serif font.
>
> I hope this helps clarify things. Perhaps this dialog will help make
> it clearer for others.
>
> Take care,
> Rob
>
>

Received on Tuesday, 3 June 2008 19:53:22 UTC