W3C home > Mailing lists > Public > www-html@w3.org > February 2004

Re: 'style' attribute

From: Wingnut <wingnut@winternet.com>
Date: Sat, 21 Feb 2004 07:15:18 -0600
Message-ID: <403759E6.8050406@winternet.com>
To: www-html@w3.org

Jens Meiert wrote:

> First of all, why was the 'style' attribute declared deprecated in XHTML 1.1
> [1] and will be introduced again in XHTML 2.0 [2]? Did I miss something, or,
> for example, is only the Style Attribute Module deprecated (in XHTML 1.1),
> but not its attribute...?
> Nevertheless, I absolutely agree that it shouldn't be used [...] and is
> therefore deprecated in the recent XHTML specification, but coming across the
> 'new' CSS profiles for the 'style' attribute [3] I think it's a good idea to
> keep it (due to e.g. the possibility to import stylesheets via this attribute,
> which significantly changes the situation, I guess).
> Consequently and due to the publication date of both CSS 3 profiles (May
> 2002) and XHTML 1.1 specification (May 2001), I wouldn't wonder that XHTML 1.1
> declared it deprecated while XHTML 2.0 offers it again (if the non-existence
> of these profiles was the reason), which could answer my initial question.
> Since I'm just spinning around now, I propose to change at least the following
> part of the current XHTML 2.0 draft:
>     'Note: use of the style attribute is strongly discouraged in favor
>     of the style element and external style sheets.'
> ...since the situation really changes as mentioned before -- above all,
> being allowed to use imported stylesheets here (which use the referring element
> as the 'document' root) might be a really useful complement to format
> documents, and it doesn't represent formatting in the document, either. (This doesn't
> imply that this action is recommended.)
> -- Well, I'll keep this short for now, and excuse my horrible language use
> once again ;)
> All the best,
>  Jens.

Hi gang!  Just a general reply... not really "countering" any comments. 
  I just want to remind that I still have a need for the style attribute 
to remain... in order to carry author-preferred styles WITH a node when 
that node is transcluded. (node serving)

I'm still waiting for getStyleRuleById which, as best I can tell, will 
return a string of name/value pairs used on a given class of stylerule 
(Yes, all 132+ name/values that aren't null or 0).  The style attribute 
is how I-will/one-can ship-around that stylestring... if I ever get 
peekStyle methods like these, in dom.  The style attribute's ability to 
carry a node's stylerule... insures that the correct style rule stays 
with the correct node during transclusion.  Node viewer apps will need 
that embedded (and retrievable) style... when a node has been gleaned 
from afar... and when the node viewee wants to honor the node author's 
original styling preferences.  See more at...


Too bad this has to keep being brought up... but I'm not going to sit 
back and allow the subtle trivialization of the style attribute, when I 
THINK it needs fleshing-out, not deprecation.  People seem to forget 
about transclusion (node gleaning from afar), and thus they forget about 
considering how to carry the node's (and node-author's) style WITH the 
node when its "pulled".  There must be a "pocket" to carry that 
stylestring-in, and the style attribute is it, so far.  As it currently 
stands, I would not call a node "transcludable" unless its entire style 
rule is within its style attribute. Otherwise, author-preferred style on 
that transcluded node... is being ignored after transport. Right now its 
a contorted two part operation which requires a "content management 
system" (cms) behind the web server.  First, 
manager:getNodeById(namespace, id) to get the node... and then 
manager:getStyleByNode(namespace, nodeId)... and then we can hook the 
two together at server or requester end.

The second step could be skipped if manager:getNodeById(namespace, id) 
returned a node (in cms-like string form, whatever THAT is) with a style 
attribute already INSIDE it... containing the proper goods.

(Understand that these cms method calls return strings, not references 
to nodes like dom methods of like-name do. These strings will be made 
into webpages for delivery, for a webserver is currently not equipped to 
be asked-for a single node or single style, or deliver such without a 
document wrapping it... as far as I know.)

Unfortunately though, a style sometimes needs to be cascaded into a 
certain 'inheritence state' when it is referenced by a node.  So, a 
stylerule-extracting content management system (cms) will almost need to 
sim-grow the document into a dom tree (cascading the style), then 
manually peek all 132 css properties FOR the outbound node (if its been 
styled at all).  Then, the cms must build a style string of 132 
name/values and put it in the node's style attribute, probably 
overwriting any style attribute already found there.  Lastly, the cms 
wraps the nodestring (with 132-prop style attribute) into a document so 
the webserver can deliver it to the requester.  This all sounds 
complicated because I'm not overly bright... but in short, we WILL have 
a need to transclude styles WITH nodes under certain circumstances. 
Let's stay prepared for that future tech... by adding "also used as a 
style-carrying suitcase when the node goes traveling" to the "uses for 
the style attribute".  If the style attribute leaves the scene, I 
gaurantee I will be back to talk about this subject yet again.

Potential thread-hijacking averted!  Continue-on safely. :)

Received on Saturday, 21 February 2004 08:18:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:07 UTC