Re: Variables, Heritage, CSS!, .... : old proposals but compared with new requests

Francois Remy wrote:

> * I've also putted in green sections of samples that have no more sense : *

Usability: you should not rely on colour as the only distinguishing 
feature.  I see no green, probably because FireFox is set for limited 
HTML support.


>     * * My first idea is to generalise @font-face into an @res rule. * 

What is "res" short for?

> 
> *Why ? *
> Because when you're developper, you use several times the same color, 
> and it would be great to "give a constant name" to the color
> - It's easier to retain names than color values ("bgColor" vs "#e4cedd")

This really is the variables/constants issue, but note that CSS already 
provides a method of grouping colour, which corresponds to one of the 
techniques that is used in plain language style sheets, namely listing 
all the contexts for the colour (as selectors) then giving the colour once.

A plain language style sheet would be very heavy reading if it 
continually said "corporate colour number 2".

(I would suggest that the other common way in plain language would be to 
  say "the same as for ....".  I haven't thought about whether that 
could be translated to CSS without causing problems with performance, 
the cascade, or partial load failures.)

Note that CSS colours are not restricted to use for text.

> - You can swicth themes keeping the main CSS file, just updating your 
> constants.
>     * * My second idea is to give more decisional power to CSS. * 
> 
> *Why ?*
> Currently, we can't check browser name nor version in CSS, we must use 
> hacks or IE conditionnals comments in HTML.

Historically, CSS was supposed to provide only hints, so style sheets 
were supposed to work even though many properties were ignored.  I still 
believe that if you want absolute control, you should use a page 
description language, not HTML/CSS, however a lot of people seem to want 
to build absolute control on top of CSS.

You worded this as though you are talking about browser sniffing. 
Browser sniffing has a long history of discrimination against minority 
browsers and older versions (the browser gets enhanced but style sheets 
continue to assume that it has the limitations of the ancient version), 
with the result that all minority browsers provide a means to fake their 
identity, and even IE actually puts its identity in a comment, so that 
it can get round early discrimination against non-Mozilla (i.e. early 
Netscape) browsers.

(Historically, the browser sniffing that has resulted in faked 
identities tends to be at the HTML level, and all too often resulted in 
a please upgrade message, often actually requesting a downgrade from, 
say, Mozilla (current Mozillas) to IE4.)

The other approach is feature detection.  This gets discussed on a 
regular basis.  The big problem is with partially implemented 
properties.  Marketing departments will always take a liberal view as to 
whether a feature has been implemented completely, and even developers 
won't, initially, know that they have mis-implem

> Based on this, I think CSS should be able to give more "programatic" 
> responses to the browser with functions like "IIF", "firstOf", ...


-- 
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

Received on Thursday, 10 July 2008 07:31:46 UTC