Re: 'style' attribute

Regarding the style attribute there seem to be some fundamental issues with 
it's use.  I think the problem is that content authors feel they don't have 
a way to transclude information without losing styling information.  Also 
from previous posts that content authors are sometimes prevented from adding 
styling information because they do not have access to the site-wide style 
sheets.

As to the last issue.  The (X)HTML spec I feel cannot be a source of policy 
change.  There is a reason that the corperations restrict access to these 
stylesheets and it is not the responsibility of the W3C to allow content 
authors to shirk their bosses restrictions.

As to the transclusion issue, due to the nature of cascading style sheets, 
specifically the cascading part, it is impossible to retreive the styles 
associated for an object (text, images, etc.) simply by grabbing the style 
attribute alone.  At best you might get some styling information, but in no 
way are you garunteed to be getting the entire set of styling key/value 
pairs.  On a second note, using only style attributes and not central 
styling information located in the style element or remote style sheets is 
not an option.

Additionally because of the inheritence ability of CSS, it becomes 
impossible to directly apply a 3rd party's remote styling information with 
their 3rd party content.  Id's won't match, decendants selectors won't match 
because their ancestors aren't there, etc.

So what we are left with is needing a mechanism that will build style sheets 
for a particular sub-tree.  Essentially starting with the element I want to 
transclude or the immediate parent of the element I want to transclude if I 
am retrieving content inside a node, but not the node itself, I create a CSS 
that includes all of the rules that affect that node and that node's 
children.

To assist in this perhaps it is time to introduce local style sheets; 
essentially allowing style sheets to be specified at the element level in 
addition to the document level.  This would allow greater context for 
elements without the need for id's.  For example when a content author was 
creating a navigation bar or a content section rather than using id's, the 
content author could just specify the stylesheet that would be applied to 
that particular element's content.  This could also be tied into a generic 
xml styling - something that currently doesn't exist.

One of the forseeable problem with this is that positioning information 
doesn't play nice when you transclude it, nor do positioning tricks (e.g. 
margin and padding tricks) when you want to do the same.  This I think has 
more to do with the concept of an element determining it's own location when 
it is contained in another element.  There are certain properties that 
simply cannot be transferred to another context.  These will need to be 
addressed.

Which brings me to my last point, the elimination of context-dependant id's 
as an in-document context system in CSS.  Context-dependant id's do not 
transfer by definition because these particular type of id's cannot be 
garunteed to be unique once they leave their context.  The solutions that I 
have found, which by no means is an exhaustive list, is to create 
context-independant id's (which have their own problems), not using them in 
CSS and instead applying styling information directly to the element 
allowing for the possibility of remoting or allowing elements to have their 
own style element or style link and not relying on the document-level style 
element or style links.

Orion Adrian

_________________________________________________________________
Store more e-mails with MSN Hotmail Extra Storage – 4 plans to choose from! 
http://click.atdmt.com/AVE/go/onm00200362ave/direct/01/

Received on Saturday, 21 February 2004 13:20:15 UTC