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: Sun, 1 Jun 2008 15:09:19 -0400
To: "'Robert J Burns'" <rob@robburns.com>
Cc: "'HTML Issue Tracking WG'" <public-html@w3.org>
Message-ID: <01c101c8c41a$fe70fab0$fb52f010$@com>

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 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.

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).


-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
Behalf Of Robert J Burns
Sent: Sunday, June 01, 2008 8:08 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,

I fail to see what this email has to do with anything proposed on that  
wiki page. Your logically equivalent but (bogus) example is unclear. I  
think if you don't understand something about the proposal, then  
please ask questions. I do not recognize anything in this email as  
relating  to that proposal.

I will admit that this is largely an issue for the CSS WGs. However,  
it is also a bridge issue in that it is trying to provide authors a  
mechanism to express the semantics their presentation represents. It  
also has some important accessibility implications in that it provides  
UAs a way to discover legends or alternate media and allow the user to  
round-out the missing portions of presentation with user style  

Keep in mind that the legend referred to in this proposal is not the  
same legend as the element for form controls. Perhaps a better name  
for this property could be used. Aside from that I can't think of how  
anything you say here relates to the proposal.

Take care,

On Jun 1, 2008, at 6:30 AM, Justin James wrote:

> Robert -
> Looking over this again, I still do not see how this fits in with  
> any of our
> goals for HTML 5. Since I am a relative newcomer to this group, I  
> may not
> understand those goals, but from my perspective, this proposal  
> creates a
> mechanism to put content into a style document.
> Regarding the concern of legend reuse, I put forth that anyone using  
> the
> same legend that often may want to reconsider their usage; they most
> certainly will want to not use plain, static HTML for such repetitive
> content. I believe that while it may be a valid use case, it is not  
> one that
> we should work hard to *discourage* by making it more difficult, not
> encourage by not only making it easier, but codifying it in the HTML 5
> specification.
> Take the following example of a logically equivalent (but bogus)  
> proposal:
> 	Add a "value" property to CSS. Any HTML tag with the "value"
> property set will be 	assumed to have either its "value" attribute  
> set to
> that value, or its CDATA value. 	An actual @value or CDATA content of
> the tag itself will override any value property 	from the CSS.
> I truly hope that this example illustrates the horror that I have at  
> the
> prospect of this proposal going anywhere. If we want authors to start
> putting legend *text* in the style sheet, why not the contents of,  
> say, the
> menu bar? After all, it is pretty repetitive to type in those menus.  
> Why not
> the footer? There is another boring piece of text, ripe for  
> inclusion in the
> style sheet.
> * And I am "positive" (sarcasm) that the "bad guys" out there would  
> not use
> this mechanism to cloak content or otherwise abuse the mechanism.*  
> Right off
> of the top of my head, I can think of a few deceptive practices  
> which would
> easily be modified to use this mechanism.
> I still think this one should be shelved, it does not have any of  
> our goals
> in mind, and causes nothing but problems. The problems it *does*  
> address
> seem to be problems that are not the concern of HTML as a document  
> format.
> J.Ja
> -----Original Message-----
> From: Robert J Burns [mailto:rob@robburns.com]
> Sent: Thursday, May 29, 2008 5:06 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,
> One more thing I meant to add to this reply. The use of CSS for the
> legend also permits reuse of legend information. Imagine the site-wide
> or community-wide use of a class selector.  For example a community of
> juridical authors might use the class "parties" to markup documents. A
> a set of alternate reusable stylesheets might be used to style all of
> the documents in this authoring community. There should be no reason
> to place the legend description within thousands upon thousand of
> document when a few stylesheets can simply have the declaration:
> .parties {
> 	legend: "parties to the suit whether: plaintiff, defendant,
> petitioner or respondent";  /* or
>         */ legend: uri(http:www.example.com/legend#parties)
> 	font-weight: bold;
>         text-transform: uppercase;
> }
> To require the placement of the legend in the document itself would
> require it be repeated in every document. This does not prevent
> authors from referencing the same legend from their documents as well.
> <link rel='legend' href='http:www.example.com/legend' >
> or perhaps more precisely through RDF.
> Take care,
> Rob
>> On May 29, 2008, at 4:33 AM, Justin James wrote:
>>> I can't figure out this wiki thing enough to put my comments on
>>> there, so I
>>> will have to do it on the list instead (I suspect that the wiki is
>>> the
>>> "right" place for it, but without a way of using it...).
>> No, discussion here is certainly appropriate. I will try to add
>> links to the email discussion as it happens.
>>> Looking at this, I am curious as to why in the world, after 10
>>> years of
>>> begging people to separate their styling from their semantics, we
>>> would then
>>> turn around and make a mechanism that allows people to embed
>>> content and
>>> semantics (in this case, putting a string with a legend text is
>>> certainly a
>>> form of content) into the style sheet. This really looks like a
>>> massive step
>>> backwards. In this case, people should be using a tag in HTML with
>>> a *role*
>>> of "legend" (and another attribute indicating the ID of the tag
>>> that it is
>>> the legend of), with a stylesheet to style the legend itself. The
>>> legend
>>> text does not belong in a *style* definition.
>> I understand your point here. The URI value for the property does
>> permit the author to separate concerns in just the way you suggest.
>> That is the legend text can reside in the document itself, while the
>> presentation description gets automatically generated or handled
>> through the legend-presentation property. Perhaps I should include
>> just such an example with the legend in the original document.
>> One of the reasons I turned to CSS for this is that I wanted it to
>> participate in the cascade. UAs might also assist users in
>> identifying duplicate presentation idioms resulting from the cascade
>> and correcting those. Imagine for example, the UAs default
>> stylesheet.  It might include:
>> em {    legend: "emphasis"
>>            font-style: italic;}
>> Yes this legend is redundant with the specification of HTML.
>> However, it places the legend in the UA stylesheet where it can be
>> handled in the same manner with other legends. If the legend had to
>> reside in the HTML document, then the UA stylesheet could not also
>> provide the information. Likewise a user could not provide any
>> legend information, though they might also be interested in
>> selecting and styling a particular semantic. I'm a big advocate of
>> the separation of concerns, but there are times when CSS with its
>> cascade provides valuable abstraction and flexibility that cannot be
>> matched otherwise. Also it is important to provide authors multiple
>> ways to achieve the results they seek. For example, a stylesheet
>> author may identify particular semantics she wants to style with a
>> stylesheet, but not have write access to the original document so
>> this separate of concerns provides the needed flexibility to place
>> the legend in either place.
>> Take care,
>> Rob
>>> Here is another issue that needs to be introduced here for
>>> discussion,
>>> as it will be added to the issue-tracker in time. This idea has been
>>> discussed briefly within the WG and more off-list. I welcome
>>> additional feedback now. As this involves nearly entirely only CSS,
>>> it
>>> would merely be a rough draft proposed to the CSS WG from the HTML  
>>> WG
>>> if the WG decides to do so.
>>> Liaison with CSS WG to provide a mechanism for expressing the
>>> semantics of styling.[1]
>>> [1]: <http://esw.w3.org/topic/HTML/SemanticPresentationLegendCSS>
Received on Sunday, 1 June 2008 19:10:08 UTC

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