Re: 'style' attribute

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

http://lists.w3.org/Archives/Public/www-html/2003Mar/0030.html

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

Wingnut

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