Re: ECMAScript in CSS aka "Expressions"

Forgive me for resurrecting an old thread. Recent work has brought up a 
situation that should be considered alongside these thoughts.


On Mar 15, 2005, at 5:10 AM, Bert Bos wrote:
> On Monday 07 March 2005 21:32, David R wrote:
>> what is the current state of "ECMAScript in CSS" aka
>> "Expressions" (as a recommendation put forward to the W3C by
>> Microsoft)
>
> Not quite sure if this is what you mean, but the working group recently
> decided to investigate the implications of allowing simple, linear
> expressions as values. For example:
>
>     width: expr(50% + 5px);
>     font-size: expr(2em / 3 + 2px);
>     padding-right: expr(1px + 1ex - 5%);


One should also consider some of the possibilities if a means were 
available to adjust values rather than only specifically define them. 
For example:

div.secondaryContent {
	width:150px;
	padding:5px;
	border-width:0;
}
div.subNav {
	padding:2px;
	border-width:2px;
}
div.subNav.secondaryContent {
	width:142px;
	padding:7px;
}


If we know that there will be some secondaryContent that is also a 
subNav, we can plan for it as per the third rule. But it might be 
easier, more forward-flexible, and better for team development if the 
subNav rule could merely adjust the calculated values that would have 
been applied had the subNav rule not existed.

div.secondaryContent {
	width:150px;
	padding:5px;
	border-width:0;
}
div.subNav {
	width: expr( asis - 148px);
	padding: expr( asis + 2px);
	border-width: expr( asis + 2px);
}


Someone more creative than me can likely come up with a better 
reference keyword or a syntax without a keyword, but I believe this 
illustrates my case. In this version of the subNav style rule, any div 
of any style can have the subNav class applied and combined with any 
other class to achieve a layout that is easily observed by the viewer 
as consistent, even when each such div has different values.

One awkward bit is that it creates chains of rules that do not override 
each other, requiring more work from the agent. However, this extra 
work seems minor if the order of items in that chain is well defined 
(as per cascade and specificity rules), so I think it's fine. I think 
the benefits outweigh this extra effort.


Moreover, and as a complete side note, it lends scriptors a means to 
remove a script-set style and allow it to revert to what the value 
would be before scripting took place. Right now, for example, there is 
no means (AFAIK) for ECMAScript to assign a style value and then remove 
it and have the CSS take over again; reading the value prior to the 
change and storing it for restoration works in most cases, but is not 
the same if conditions change after the value is stored. Consider this:

1. ".foo" and ".foo:target" both define a display value, so that a 
block is displayed if the browser is linked to that target, but 
display:none otherwise.
2. A script to aid accessibility allows people to toggle the visibility 
of blocks based on keypresses.
3. A visitor views a page, toggles the visibility on (script sets var 
PrevDisplay = foo.style.display;), then off (script sets 
foo.style.display = PrevDisplay; -- that is, "none")
4. the visitor then clicks the link that sends him to that target; 
since the script value is more specific and lower in the in the cascade 
than the .foo:target rule, the block remains display:none.

If instead the scriptor were able to set foo.style.display = "block"; 
to make it visible, and then foo.style.display = "asis"; to return it 
to it's non-scripted state, then these types of problems go away.

-- 

	Ben Curtis : webwright
	bivia : a personal web studio
	http://www.bivia.com
	v: (818) 507-6613

Received on Friday, 13 May 2005 19:39:04 UTC