W3C home > Mailing lists > Public > www-style@w3.org > May 2004

Re: @media in style attribute

From: Mikko Rantalainen <mira@cc.jyu.fi>
Date: Fri, 21 May 2004 14:51:51 +0300
Message-ID: <40ADED57.4020500@cc.jyu.fi>
To: www-style@w3.org

Ernest Cline wrote:
>>From: Justin Wood <jw6057@bacon.qcc.mass.edu>
>>just add a simple thing.
> <example snipped using <link> and classes>
>>This all will allow you to style the display correctly for those 
>>elements (block etc;) in normal stylesheets/style attribs, and the 
>>print.css and screen.css will over-ride them on a normal use.
>>just add the class in there, along with any other classes you
>>need, will save alot of UA download.
>>As well as prevent UA's from /needing/ to impliment a pseudo
>>class for something that we allready support via an @ rule.
> I will have to disagree with you.  Setting style on an element
> by using an attribute of an element (or a descendant of an
> element, altho that is not the mechanism that is used at present)
> of an element on an element instead of by a separate <style>
> or <link> element that is not either an ancestor or descended
> greatly eases the job of transcluding an element from another
> document.

I think that the style should be separated from content even for the 
transcluded part. IMO, the transcluded part should by default use 
the same style as the rest of the document - I really cannot see any 
benefit for mixing different styles from different documents just 
because some part of the document were "quoted".

However, I can understand that some people expect functionality for 
this so I propose following:

Allow a stylesheet attribute that can be used to link to different 
stylesheets and those stylesheets get additional specificity for the 
element selectors that match any child selector.

For example:

<html> ...
<body> ...
<div id="ext" stylesheet="urn:source-of-this-transclusion-style">
transcluded part

The linked resource may then proceed to suggest behavior for 
printing the transcluded part and anything else that it needs to 
set. It may use the @media at-rule for this. The additional 
specificity could be implemented as if the "inline linked 
stylesheet" had "html>body>div>div>div " in front of every selector 
or as if the "a" in CSS specificity calculation[1] was 1 (or more).

This still needlessly attaches style information to document 
structure (markup) and I'd rather have some mechanism to attach such 
  external stylesheet, that only applies to part of the document, 
via CSS. So instead of above "stylesheet" attribute, I'd rather 
write style like

#ext {
   subtree-stylesheet: url(urn:source-of-this-transclusion-style);

Or, I could use any other selector to select the subtree that needs 
to have this different style.

In this case, the "a" value would be current "a" value plus one so 
nested "subtree-stylesheet"s would get higher specificity 
automatically. Still, a selector "p" in such a "subtree-stylesheet" 
should match only "p" elements inside that subtree, not every "p" 
element in the document. The implementation could prefix every 
selector with the selector that was used with the 
"subtree-stylesheet" rule -- in the above example that would be 
"#ext". If the above rule had selector "html>body>div>div>div", then 
it would be the prefix.

> I will agree that outside of the domain of transclusion, there
> is nothing that a style attribute offers that cannot as easily
> be done with a centralized stylesheet and using either
> id or class as appropriate.  However, I already said earlier
> in this thread that 

Yes, the style attribute is easier to understand for the current 
user base[2] but the question is, do we want to continue on our 
quest for separating style from content? If we do, then we must not 
allow any way to include style inline.

[1] http://www.w3.org/TR/CSS21/cascade.html#specificity

[2] because the current user base is familiar with the WYSIWYG 
feature of some application and they (for some reason) expect the 
same feature from (X)HTML and CSS even though the end user medium 
may be something really different from what they use or expect.

Received on Friday, 21 May 2004 07:52:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:13 UTC