- From: Robert J Burns <rob@robburns.com>
- Date: Tue, 3 Jun 2008 21:52:39 +0200
- To: "Justin James" <j_james@mindspring.com>
- Cc: "'HTML Issue Tracking WG'" <public-html@w3.org>
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