homepage Welcome to WebmasterWorld Guest from 23.22.29.137
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderators: not2easy

CSS Forum

This 47 message thread spans 2 pages: 47 ( [1] 2 > >     
Why 'variables' in CSS are harmful
SuzyUK




msg:3741925
 12:21 pm on Sep 10, 2008 (gmt 0)

Bert Bos has written an essay on his reasoning behind Why "variables" in CSS are harmful [w3.org]

Adding any form of macros or additional scopes and indirections, including symbolic constants, is not just redundant, but changes CSS in ways that make it unsuitable for its intended audience. Given that there is currently no alternative to CSS, these things must not be added.

If developed, it should be a module that is used off the Web, though. Macros are a help for authors, not for the semantic Web. The Web's main formats, HTML, CSS, SVG, PNG, JPEG, etc., already have all the structure they need. Adding an extra, independent structure would just make them more difficult to process

 

alt131




msg:3742450
 3:01 am on Sep 11, 2008 (gmt 0)

Thanks for the link SuzyUK.

on the philosophy ...
I thought the essay interesting, but arguments that a thing is "too difficult for most people" suggest arrogance, and using that premise to justify maintenance of the status quo isn't reflected utilitarianism (IMO). It presents as a self-appointed elite (of the self-evaluated "enlightened") presuming to make decisions for the (assumed to be less enlightened) non-elite on the basis the unaware-non-elite needs the self-appointed-elite to make those decisions for them. Whew!

That argument's been used for centuries to justify quashing calls for participative governance, access to information, freedom of expression, association and many other humanitarian freedoms now taken for granted. Truth is, my stomach is feeling a bit queasy at it being unashamedly expounded as an appropriate intellectual approach to the evaluation of anything related to the development of the "internet".

... My opinion about the way Bos exercised his freedom of expression aside ;)

on the issue of constants/macros/variables

For myself, it seems that what is being proposed can already be done via a range of programming languages - if the author chooses. Much more - if the author chooses. So I am not sure what is achieved by taking a tool designed to describe style and turning it into a(nother) tool with programming capabilities given it is already possible to employ programming techniques - if you choose.

Calls for css to be able to natively script/program have always seemed to me to be akin to the age-old complaint css is "deficient", based on egs such as an inability to deal with mouseover events. Which, as an eg, seems to me to indicate the "complainer", while perhaps an adept programmer, hadn't figured "mouseover" isn't a css selector, and also expected css to have programming capabilities for no reason except the coder was used to dealing with languages that did.

Unfortunately my reasoning loses credibility when applied to the people whose knowledge and vision have husbanded the css evolution, so I'd be really interested to hear others point of view.

... SuzyUK, you're a css-wiz - what are your thoughts, for starters?

Bert36




msg:3752618
 1:29 pm on Sep 26, 2008 (gmt 0)

Ok, I'll bite ;-)

I read that essay and I totally, wholeheartedly DISagree with it.
It is full of presumptions like e.g.:

CSS style sheets are short. They are not much bigger than one editor window. Very few people (only professional designers, it seems) write style sheets longer than a hundred lines.

There is so much wrong with this one sentence I know hardly where to begin.

But I won't go into the contents of the essay apart from my own simplistic "need" for variables and constants in a style sheet:

Maintaining a site's colours, fonts, sizes etc. can be tedious. Using find and replace to change colours and fonts could be so much easier when using literals was possible.
And being able to use a simple equation for the width of elements instead of using your calculator all the time to accommodate for borders, margins etc. would be a vast improvement I would think. This would also apply for font sizes and line heights when maintaining a "vertical rhythm".

The argument that CSS is not a programming language is true, but adding variables, constants and simple equation capabilities does not make CSS less of a non-programming language. It simply adds to the flexibility of the mark-up.

swa66




msg:3752657
 2:17 pm on Sep 26, 2008 (gmt 0)

Size:

I'm not even sure size does matter all that much, but anyhow.
Most stylesheets I see are bloated with useless statements, or stuff added to keep IE from derailing (which should go in a conditional comment till Microsoft finally makes a browser capable of doing standard compliant CSS and convince their customers to actually use it).

Preprocess:

This is the neatest solution. It allows to keep your colors in sync etc. Use some sort of macro and preprocess the file on the server. Only hand out the preprocessed CSS.
I'd look at m4 (but then I'm a unix-head)

Considering the misery MSFT puts us through with their horror interpretation of CSS, let's keep it simple for them so they can finally catch up.

Font:

I'm going to go for "normal" sites (not e.g. a site talking about font faces) don't need more than 2 or 3 fonts. Any more becomes tacky.

So to stick with a simple example:

* {font-family: "Lucida Bright", "Times New Roman", times, serif}
h1, h2, h3, h4, h5, h6 {font-family: Verdana, Arial, Helvetica, sans}
.code {font-family: "Courier New", Courier}

And then the rest of your code doesn't need any more font-family.

So while I'm not as outright against variable, I don't believe we need them. Anything we don't need, is probably best not included.

And scripting in CSS is absolutely not needed, regular JavaScript is more than enough to create dynamic CSS should you need it.

Bert36




msg:3752699
 2:50 pm on Sep 26, 2008 (gmt 0)

And then the rest of your code doesn't need any more font-family.

I agree that 2 types of font is usually all you need. But, and this is a big but. Any substantial site will use these fonts in places where you cannot simply use them the way you depict them. You need things like:


#name > ul > li > p > a {
font-family: Arial, etc;
}

Besides, this is part of the strength of CSS: the cascading.
(Which makes me think that variables and constants should cascade as well...think of the possibilities!)

As far as preprocessing is concerned: I partially agree with you. But the essay also states that macro's and programming in general is too difficult for the average user. (load of rubbish, but that is what the writer suggests and this is what we are discussing here). The essay writer suggests that including variable and equation capabilities to CSS would make creating websites difficult for the majority of website builders. Logic therefore dictates that preprocessing should get the same argument.
Besides. When you start using preprocessing you must test your site on a (test)server. Is that not too difficult for the majority of users?

I would argue that of everything related to programming, variables and constants are the easiest to understand and to be grasped, especially compared to some of the more ambiguous things the CSS standard itself coughs up.

Bert36




msg:3752719
 3:12 pm on Sep 26, 2008 (gmt 0)

(can't seem to find the edit button, so making this an extra reply, sorry)

Regarding preprocessing I would also like to point out that the essay writer refers to using PHP as an alternative, but at the same time he argues:

For many people, style sheets with constants will thus simply not be usable. It is too difficult to look in two places at once, the place where a value is used and the place where it is defined

Well, 2 places at the same time? What does he mean? Using constants in stylesheets means they are in the same place, namely the same stylesheet. But using php you actually take part of the style and place it inside another file (php-file in this case). Not only does this mean you have two places to look, but also that your html or css looks confusing because it has a <?php tag followed by a lot of -what looks like too most people- garbage.

He also talks about "re-using" code from others. (I will leave the fact that this borders on copyright infringement aside). Downloading or opening php files is a major difficulty. You can only get the final processed file, and that does not include any of the unprocessed statements. SO how does that make learning easier? As the writer tries to make us believe.

[edited by: Bert36 at 3:18 pm (utc) on Sep. 26, 2008]

SuzyUK




msg:3756922
 7:00 pm on Oct 1, 2008 (gmt 0)

At last! I've had this flagged since seeing there were some replies and have been meaning to add my thoughts for days..

Anyway alt131, thanks for the compliment. On the surface I'm on the side of CSS should not have them, CSS is not and should never be a scripting language. And yes why add an extra layer to CSS when there are already ways of achieving this if your company so desires.

The introduction of variables would make debugging a nightmare, it would make validators and web developer tools useless unless they too became parsers. Imagine how it would work trying to teach your team what the variable/constant is for each color.. why not just use the color, a place a text color palette somewhere in your file so the codes can be found quickly, then a simple text search will find every instance in a sheet. Also with specificity and advanced selectors it might very well take more time to match a selector with a variable than it would be to find it by it's actual value?

It really is adding in a unnecessary layer for the majority.. the larger considerations are probably already generating their stylesheets dynamically

If the capability were to be built into CSS instead of using an outside scripting language as is possible today it's also possible that standards would fly out of the window, e.g. how could a color be validated (i.e. make sure there is hash before it if it's numeric) The UA's/validators/software parse engines would have to become able parse the whole stylesheet and have access to the variables in order to find out how to render the variables, let alone validate them! (I know which would suffer;)) - more especially image px, em, % in a variable .. far better that the constants are is modularised and dealt with by whatever outside source your site uses - so the UA's etc are simply having to deal with the rendered source..same as PHP/ASP etc. produces valid HTML.

there's likely more but I've gotta go play Ker-Plunk! :)

Bert36




msg:3757018
 9:22 pm on Oct 1, 2008 (gmt 0)

It is funny how everybody who seems to be against variables in CSS still say it is ok to use pre-processing. And all the arguments against variables in CSS also apply to using pre-processing (even more so in fact), can someone explain?
Just because we include variables in CSS doesn't mean we must use them. Just like now we can use pre-processing, but you don't have to.

As for things like hashes...well, that is just coding practice, but one that variables would actually make simpler, just include the hash in the variable standard by means of a function. That way it is done automatically and we never have to worry about it again.

I would however be willing to make a compromise. I would be happy enough if variables and simple equations could just be included in a development area. This IDE would then just output "normal" css at the end. It would serve the same purpose. That way we all get what we want.

swa66




msg:3757056
 10:16 pm on Oct 1, 2008 (gmt 0)

... all the arguments against variables in CSS also apply to using pre-processing

I don't agree with that at all: e.g. with preprocessing, nothing has to change in the UA (the browsers), we don;t need to rely on the AUs all doing the same thing (we all experience every day how bad e.g. MSFT is at following standards).

pre-processing and storing the CSS (or regenerating it on the fly) is a server-side thing. Don't care how it's done as long as it's not done in the browser.

Just because we include variables in CSS doesn't mean we must use them.

But it means the browser MUST implement it. Browsers are very complex already (just look at the lack of fixes for outright bugs in IE6), let's make them simpler and more coherent, not more bloated.

Use macro's or other processing as you like/need. It's fine. but generate standard CSS out of it before handing it to a browser. If it needs run-time dynamism: consider javascript, it can change things if you really have to. I've never had the need so far.

To make it work in your development environment: use e.g. php, it can be just one file you'll end up with, no need for two. And once you move to production, retrieve the generated CSS and put it in a static file and be done with it. (or leave it in php if you feel the need, it's your server that will feel a slight bit of additional load and a slight bit of additional delay to hand the file to the user)

alt131




msg:3757076
 10:55 pm on Oct 1, 2008 (gmt 0)

Just because we include variables in CSS doesn't mean we must use them.

But it means the browser MUST implement it. Browsers are very complex already ... let's make them simpler and more coherent, not more bloated.

Jolly good point.
And one of the reasons browser programming/design is so difficult is because of the need to be fault tolerant given the large quantity of appalling code in circulation.

I am simply not going to ruin my day by trying to imagine how huge and complicated browsers would have to become to cope with mangled constants/variables/call them what you will - as well.

Bert36




msg:3757281
 9:11 am on Oct 2, 2008 (gmt 0)

Well, I cannot disagree with the browser argument. But it is not an argument used by the essay writer (unless I missed that one). The only arguments so far were about making css more difficult and coding more tedious. And those arguments do apply the same to PHP or ASP.

As far as UA's are cencerned, like I said, I agree. That is a major problem. I sometimes wonder if it would prove "profitable" (I don't mean in a financial sense) to develop a pre-processing mechanism that renders HTML and CSS and simply delivers the output to the browser in a format they all handle the same. But that is another discussion.

Using PHP (or whatever) in an IDE is not really an option because none of the IDE's I know are capable of processing on the fly (so they can't e.g. show class-names in code-hints etc.)

SuzyUK




msg:3757374
 12:57 pm on Oct 2, 2008 (gmt 0)

I'm not against preprocessing, but it can already be handled by languages suited to the purpose, defintions/scope etc. I just don't see why we need to add that layer into CSS itself.

<rant>
The biggest arguments for this feature that I can see is theming, now to me that means these arguments are coming from utilitarian CSS users/programmers, the ones that just want to write a stylesheet once and believe that changing a color scheme is theming. It isn't that's templating with a choice of skin. Templating can be taken care of via other means, probably preprocessed or dynamically generated sheets and if you're going to template your pages you may as well put the presentation back in with content (add classes to everything!) and pull your constants/variables that way?

Theming is different and where CSS comes into its own, take out the utilitarianism and inject some creativity, design etc. and see how the constants would work then. Look at CSS ZenGarden and tell me that style of theming would've benefited from constants, I think the range of THEMES would not have been nearly so vast if the designers had been in "constant" mode

Cascading STYLE Sheets, just where would the style be in a series of constants? The stylesheet writers would be too busy concentrating on which elements could use constants instead of just grouping together their already given or classified selectors, a function already provided by CSS - The design and creativity (the purpose of stylesheets) of the designers would be stifled as they get pushed and prodded into a programmers 'box'
</rant>

To me that's what this feels like, it feels like the "automate everything to make life easier" crowd want to stifle the design creativity freedom that CSS has brought to the web... They don't understand CSS and want to package it up into a way they do understand

anyway personal feelings aside,
IMHO CSS, when used properly, can pretty much constant things for you, if that's what you want. As swa66 stated above just group the selectors that you want to have a constant color, font, background etc.

@Bert
I agree that 2 types of font is usually all you need. But, and this is a big but. Any substantial site will use these fonts in places where you cannot simply use them the way you depict them. You need things like:

#name > ul > li > p > a {
font-family: Arial, etc;
}

with that I completely disagree, substantial site or not, you do not *need* things like that, and even say you do whichever way you do it you are simply looking to match that very specific selector to a font-family you've already used (made into a constant). Perhaps that's why programmer types (not saying that's you btw Bert.. just the feeling from reading some of the other articles out there too) feel the need for constants, it's what they understand, they maybe don't get CSS quite as good as they should - in my experience "regular" CSS inheritance would likely take care of something like that, but if it is indeed an anomaly to your regular "body" font that you only want anchors that are inside paragraphs that are inside a list inside that div#name then firstly there is very possibly no need for the child selectors (it would have to be a very extreme one-off case for something like that and if you think about it there's hardly a need to constant an anomaly?)

But for arguments sake lets say it was a real scenario, take a look at the comparison of how it can be now and how it might be under a constant scenario.

How it could be now, to use swa's example with your example added in:

h1, h2, h3, h4, h5, h6,
#name ul p a
{font-family: Verdana, Arial, Helvetica, sans}

as opposed to the "proposed" note: this syntax is only a theoretical sample and is lifted from another site with HeadingFont, and some h2, h3 constants added in by me

@variables {
HeadingFont : Verdana, Arial, Helvetica, sans-serif;
CorporateLogoColor : red;
TitleColor : blue;
TitleFontSize : 16px;
SubTitleFontSize : 14px;
SubSubTitleFontSize : 14px;
LinkColor : green;
}

h1 {
font-family: var(HeadingFont);
font-size: var(TitleFontSize);
color: var(TitleColor);
}

h2 {
font-family: var(HeadingFont);
font-size: var(SubTitleFontSize);
}

h3 {
font-family: var(HeadingFont);
font-size: var(SubSubTitleFontSize);
}

/*
I'm missing out h4 to h6 but you get the idea..
*/

#name > ul > li > p > a {
font-family: var(HeadingFont);
}

that is not easier, indeed because (and it was only as I was typing it I realised this) you have to name the constants so they make sense. I added an extra sub for each heading level down in order to follow the naming conventions the example (or my employer) laid down.

So tell me just what is the point in replacing the already semantic elements we already have.. and then when it comes to actually applying the constant to your nested link scenario var(HeadingFont) for a nested link :o - does that name now make sense? - is anyone seeing a naming convention problem yet ;)

and just for fun, the first and second method combined (just with font family again):

@variables {
HeadingFont : Verdana, Arial, Helvetica, sans;
CorporateLogoColor : red;
TitleColor : blue;
TitleFontSize : 16px;
SubTitleFontSize : 14px;
SubSubTitleFontSize : 14px;
LinkColor : green;
}

h1, h2, h3, h4, h5, h6,
#name > ul > li > p > a {
font-family: var(HeadingFont);
}

and as you can see if the grouping selectors were used in the second example it would be doubling up for very little gain

Yes you can go in and change the HeadingFont in one place, but what happens if you then don't want that nested link to change, only the headings? you have to make a new variable for the link and still go to stylesheet to ungroup it from the heading selectors to replace it's value.. that's all we have to do right now, except we use the properties existing value as the constant instead of adding in a new variable name

nah, I think I'd rather stick to the grouping of selectors we already have, if people would concentrate on using the proper markup, and then learn CSS properly instead of trying to make things unnecessarily complicated I think maintainability (as this is what this is all about isn't it?) would ease itself

Bert36




msg:3758687
 3:45 pm on Oct 4, 2008 (gmt 0)

Argument 1)


with that I completely disagree, substantial site or not, you do not *need* things like that, ... in my experience "regular" CSS inheritance would likely take care of something like that, but if it is indeed an anomaly to your regular "body" font that you only want anchors that are inside paragraphs that are inside a list inside that div#name then firstly there is very possibly no need for the child selectors ...

I used a child selector here, but it could also have been a descendant selector (which would have made more sense in the context of the argument, I agree. I was probably just lazy).But I still say we do need things like that:

The power of CSS is for a large part in it's inheritance. What most designers (I know) do is:
1) They override the inheritance with an ID or class directly assigned to the element.
2) They assign an ID or class to the "nearest" ancestor (or create one).
Both these constructs have some disadvantages in common. They lead to Divitis (and ID-itis/class-itis), and they create the circumstance that the description of layout (CSS) is placed inside the content (HTML).

When designing a website it is very important to study the flow of the markup-structure. It is best to place layout as high as possible in the tree so it can cascade down into the descendants without the need of superfluous code. Then, whenever you need an override on the default layout within that container you create a CSS selector with descendant/child selectors (and make sure you do not go down the line more than you need to). No need to create wrong class names like .WarningColour or "#FloatLeft". This way you keep your HTML free of silly classes, id's and div's, and when time comes to redesign the site or make alterations, you only have to alter the selectors, not the names, not the mark-up etc.

This does however provide us with the need to comment our css extensively.


.redtext {
color: #FF0000;
}

is wrong, but much more descriptive than:


#header > ul {
color: #FF0000;

It is a simple and silly example, but you get my point.
Now just suppose we could use symbolic constants. Then we would get something like:


#header > ul {
color: var(InactiveMenuItemColour);

No more need for a comment, since the code becomes self-descriptive. As a bonus we have excluded silly naming and superfluous classes/div's from our html. in other words, we can both alter the actual values *as well* as the element they refer to inside our CSS!
(just as a side note, choose a website, print out the code and try to rewrite as many classes and id into basic selectors, it is fun...well, I think so)

So my first argument for symbolic constants would be: better code structure and readability which leads to better (maintainable) code.

Argument 2)


:o - does that name now make sense? - is anyone seeing a naming convention problem yet ;)

Yes, but no more so than for ID's and classes. We all know we must use well-thought-out names for those. And the same rules apply for symbolic constants.
What most people do is give a class/id/variable (etc.) a name based on either the designed value (which is strange since class/id's/variables etc. can change value) or based on the designed location (which defies the purpose of them).
The way one should name id's/classes/symbolic constants/ etc. is it should be based on categorising it's meaning.

Some examples for symbolic constants:
CorporateColour, BaseFontType, PageWidth, etc.
Better still, reverse the order and make them stand out by means of there first part: ColourCorporate, ColourContrast, etc.
This same rule applies also for classes and div's.

So naming conventions is not a big problem, as long as you overthink it and use the proper selectors. Remember argument 1 above? Why should the upper-most level of divs all have an id?
I can also call some of them by means of:

body > div { } (all at once)
body + div { } (the first one)
body > div + div { } (any that immediately follow another)

If I do this I no longer need names like "Wrapper".
I say naming conventions will not be a problem.

Argument 3)

It has not been mentioned in this thread (yet) so let me be the first. Those who are opposed to symbolic constants in CSS are also opposed to symbolic constants in HTML...yes?
Well, surprise: you are already using symbolic constants in html! They are just called differently.
What is a symbolic constant: The definition is: "A word that represents a value or range of values used in a program" The UA (or rather it's rendering agent) is the program. So guess what words in html represent a value or range of values?
Answer: class- and id-names.

In short:

.thumbnail {
width: 12px;
height: 12px;
}
<img class="thumbnail" .../>

is the same as as:

<img width="12" height="12" .../>

So why would browsers become more complex when they have to parse symbolic constants when they are already doing it?
So if HTML has the ability to access the CSS layer below it, why can't CSS have access to the lowest level below it? There are no more levels beyond exact values placed in symbolics. I want to be able to determine that exact value from within CSS itself, not by means of external programming languages.

And one of the reasons browser programming/design is so difficult is because of the need to be fault tolerant given the large quantity of appalling code in circulation.
I am simply not going to ruin my day by trying to imagine how huge and complicated browsers would have to become to cope with mangled constants/variables/call them what you will - as well.

I am not going to refute this, but I don't think programs are designed as debuggers in principle.

Argument 4)

Theming. I agree with SuzyUK on that one. It is a stupid argument I think. Whenever I am visiting a website that flaunts it's ability to change themes I cannot help but think the owner must have some sort of identity crisis.
The only possible (and I am using this term carefully here) argument for symbolic constants in relation to theming would be accessibility, which is sort of, kind of a theme as well.
For me theming is not an issue.

Argument 5)


To me that's what this feels like, it feels like the "automate everything to make life easier" crowd want to stifle the design creativity freedom that CSS has brought to the web... They don't understand CSS and want to package it up into a way they do understand

I am not saying there aren't people out there who actually "think" like that. But just because they have the biggest mouth does not mean we should base our own opinions on their arguments to form a counterpoint.
First of all, computers are in essence computing machines. In other words, their primairy function is to take computations of our hands. And I fail to see why being able to have the computer make some very simple computations for me would limit my creativity. In fact, I welcome it. Whenever I want to displace something by 1px I must change at least 3 values, possibly more. Because CSS does not include borders, margins and padding into the total width. Hopefully that will change in version 3.
Another thing is line-height. Nice that it is based on the font-size, but a bit awkward when determining margins if you want to maintain that hyped vertical rhythm. And then when you finally have all your em-values straight, some containing-block needs another value and there go all the values for it's descendants. I for one would welcome the idea of being able to have that calculated for me thank you very much.
I am not preaching a full-fledged scripting language here, but just the ability to basically add, subtract, multiply and divide. (IE already has this eval() thingy in css). I think symbolic constants are the step before this.

Addendum Argument 1)

I missed this one before.

Yes you can go in and change the HeadingFont in one place, but what happens if you then don't want that nested link to change, only the headings? you have to make a new variable for the link and still go to stylesheet to ungroup it from the heading selectors to replace it's value.. that's all we have to do right now, except we use the properties existing value as the constant instead of adding in a new variable name

The ungrouping would have to be done whether you use constants or not.
As for the extra variable, no because we would have defined all the colors as variables already. I just change form CorporateColour to ShadeColour (or something). So there is neither loss nor gain here.

<RantMode>
I am not actually lobbying for this symbolic constant thing. I mean, by the time it could be implemented I most probably will have kicked the bucket already. My motive for this argument is simply my own feelings towards so-called web designers who couldn't design a website without a class if his/her life depended upon it. The whole point of CSS is that we separate, separate, separate...I can't say it enough.
Using symbolic constants is a possible aid in doing so.
</RantMode>

Bert36




msg:3758689
 3:54 pm on Oct 4, 2008 (gmt 0)

oh, by that last remark I didn't mean anything personal towards anyone here.

swa66




msg:3758755
 7:34 pm on Oct 4, 2008 (gmt 0)

Bert36,

I'm not sure I understand where you try to go, I agree when I first read the article it sounded like it was written from an ivory tower. Still...

Take a look at a set of definition and use of variables:

@variables {
HeadingFont : Verdana, Arial, Helvetica, sans;
CorporateLogoColor : red;
TitleColor : blue;
TitleFontSize : 16px;
SubTitleFontSize : 14px;
SubSubTitleFontSize : 14px;
LinkColor : green;
}
h1 {
font-size: var(TitleFontSize);
font-family: var(HeadingFont);
color: var(TitleColor);
...
}
h2 {
font-size: var(SubTitleFontSize);
font-family: var(HeadingFont);
color: var(TitleColor);
...
}
h3 {
font-size: var(SubSubTitleFontSize);
font-family: var(HeadingFont);
color: var(TitleColor);
...
}
#name > ul > li > p > a {
font-family: var(HeadingFont);
...
}
b, strong {
color: var(CorporateLogoColor);
}
a {
color: var(LinkColor);
}

vs.

h1, h2, h3, h4, h5, h6, #name > ul > li > p > a {
font-family: Verdana, Arial, Helvetica, sans;
}
h1, h2, h3, h4, h5, h6, b, strong, {
color : red;
}
h1 {
font-size: 16px;
}
h2, h3 {
font-size: 14px;
}
a {
color : green;
}

My choice is clear, which is yours ?

If I need to find what's applied to an element, all I need is something like the webmaster toolbar for firefox and a click of the mouse will tell me where in which file which CSS is applied to what I clicked on.

Just don't be afraid to use the same selector more than once!

BTW: using selectors like "body > div", "p+p" etc. rules out those still using IE6 (unless you provide a lot more in the conditional comment to rectify it all)

Bert36




msg:3759080
 11:52 am on Oct 5, 2008 (gmt 0)

On the IE6 issue: I usually run a JavaScript to make IE6 understand these selectors (much like IE7.js), If it still doesn't work I let the entire page degrade for IE6. Personally I think IE6 is so old by now I just let it fall in the same category as e.g. Netscape. (But I know this choice is controversial).

As for your example. Re-read my first argument. Good CSS does not automatically mean less code or better readable code (this is an old pitfall, a lot of people think that when you achieve something using less code that this automatically mean the code is better designed. You cannot compare human perception with computer processing). Symbolic constants would (and this is my main point) make CSS more readable and help making this separate structure from content.

Let me put is another way. If you write style sheets in such a way that it acts in all the positive ways as it can act (meaning that after you design a web site you never ever have to be in the HTML again to change anything style related, and that when you change a style in the CSS file you never ever alter the meaning of the class/id-names inside the html), then you end up with a lot of code which is also confusing to read. By using constants you can at least make the code readable again.

[edited by: Bert36 at 11:59 am (utc) on Oct. 5, 2008]

vincevincevince




msg:3762651
 5:40 am on Oct 10, 2008 (gmt 0)

Something which is frequently missed is the fact that Javascript is more than capable of manipulating CSS. You already have the ability to script and add variables into your CSS.

It is true that libraries to simplify manipulating CSS stylesheets via Javascript are not well distributed; but that doesn't mean the power is not there.

httpwebwitch




msg:3763036
 4:08 pm on Oct 10, 2008 (gmt 0)

vvv is right; all the things you could do with CSS variables are already possible using other methods. Preprocessing will let you rewrite your CSS with variables injected - you may just end up with all your CSS files being handled by a parser, maybe your CSS files will have querystrings.

Javascript has complete control over the styling of DOM elements, and if you're adept with Javascript there isn't much you can't accomplish. I have yet to find a CSS limitation that couldn't be fixed with JS, however complex or annoying.

But one could argue that preprocessing CSS is a "workaround" to a deficiency in the language.
Parable:
You can create a dynamic web application using nothing but flat-files and HTML. Millions of flat files saved to show every possible permutation of screen content... theoretically possible, and in my early days building for the web (the early 90s), that's how I did it. In my first few web applications, output wasn't generated by run-time scripts or relational databases; user interaction was passed with POST to a CGI that rewrote a flat file stored on the server. Just because something can be done using primitive tools doesn't mean newer gadgets like PHP, SQL, etc are silly enhancements.

I feel the same way about variables declared in a CSS file. They *would* be useful. Use them or don't use them - that's the developer's choice.

I take offense, as alt131 did, with the elitist tone of the essay. Arguing that it would make CSS "too complex" or "too difficult" is a condescending position. It's already possible to create horrible CSS, just as it's possible to create spaghetti code. People who use the feature properly well will benefit. People who use it stupidly will suffer. Every programming (or markup) language is a power tool - making it easier to make pixels dance on your screen in interesting and meaningful ways. A power tool. Like a chainsaw, it can be used well, or badly. Don't presume to remove tools from my belt to protect me from myself - I want my chainsaw, dammit!

The argument that search-and-replace is preferable to single-definition and variable reuse is not convicing. Do a search-and-replace through your CSS to replace "5px" with "7px" and you'll end up replacing things you didn't intend to. If I had declared a variable "column_padding", I could change that without suffering the pain of seeing all my margins and font sizes and positioning values quantized to the new value.

I vote on the side of implementing variables and scripting functionality in CSS. I'm used to declaring "parameters" in XSLT, and it's such a handy feature... you declare a variable in one place, or externally, or have it passed into the script, and it changes the output. Why is that so bad?

A little scripting in CSS would go a long, long, way.
For eg, it would be handy to be able to define the style of one element based on properties of another. For instance, let the height of one <div> always be the same as the height of another <div>. On pages where user interaction changes dimension properties, this ability would be a boon. One relatively simple rule in the CSS would replace significantly more complex scripting required in Javascript.

Doesn't the ":hover" pseudoclass already encroach on Javascript's territory? That's "mouseover", isn't it! Now imagine doing all your hover styling using onmouseover events in Javascript. Aaaaugh! See, ":hover" is a taste of how good CSS *could* be. Why stop there?

Another point: So, you won't be able to snoop into my CSS with Firebug to see what my font-size variable is, or (eek) you may have to scroll. Oh, boo hoo. Cry me another river.

I'll give credit to Bert Bos for creating a careful, thoughtful, well-argued essay. It was a good read. I just don't agree.

alias




msg:3763059
 4:26 pm on Oct 10, 2008 (gmt 0)

I could never agree with someone who thinks text-align: justify is readable.

yes, it was a good read, but some simple math in CSS would definitely not harm it.

swa66




msg:3763176
 6:48 pm on Oct 10, 2008 (gmt 0)

While I don't remember simple math being discussed in the paper, I do agree *simple* math might be something that would tempt me to use it.
IF it were available in today's CSS2.1. But it will never be for CSS2.1, leaving CSS3 as the earliest possible, and then there are better alternatives in the mix I guess.

Something like "width: 100% -20px;" but typically there are ways to avoid needing it and I guess those of us into the philosophical part of CSS will rightfully argue it's better they are not there.

But when you look at all CSS3 is in the progress of having for us to play with when it's available in browsers I doubt I'll miss math.

Clark




msg:3763233
 8:21 pm on Oct 10, 2008 (gmt 0)

I couldn't read that link. The colors were very hard to read. And lately, WW threads seem to have a sideways scroll on my screen resolution which is 1024 x 768. So even this thread is hard to read because I made the font smaller. I hope at least here that issue will be fixed. There are still some people with 800 width resolutions to make the letters bigger. I think what's causing this is the move of the preview and submit button to the right side of the quick reply feature.

But anyway, I just wanted to point out that Steve Souders in "High Performance Web Sites" wrote a whole chapter called "Avoid CSS Expressions". I would think he'd feel the same way about css variable.

swa66




msg:3763243
 8:43 pm on Oct 10, 2008 (gmt 0)

I couldn't read that link. The colors were very hard to read.

Now the beauty of CSS is that you can turn it off and that document behaves very well without CSS.
E.g. in Firefox: View/Page style/No style . You'll need to turn it on afterward again as far not all sites work so nice without CSS.

Clark




msg:3763272
 9:17 pm on Oct 10, 2008 (gmt 0)

True...was too lazy :)

SuzyUK




msg:3763606
 12:26 pm on Oct 11, 2008 (gmt 0)

Vince, http, that is one of the things that Bos is saying, and it's good to repeat it perhaps.. this is the main part of the against argument, imho, if it is something that would be useful to your team's site/application development then there are ways to implement it already, JS, PHP all scripting languages really!

It is for this reason too that I strongly believe that CSS Constants if implemented should be left as a separate layer/module/macro, whatever the right term is, perhaps usable by more languages than CSS even. So that those that do want or need to use or learn them can be free to choose whichever one suits them/their teams programming application/abilities best.

It should not be a uniquely applicable job of CSS - whose job is simply to suggest/apply a style to the page using the already predefined selectors/attributes

While I too think Bos' essay reads as somewhat ivory towered/condescending too, it simply struck me that he doesn't often write about CSS things, and when he does it's not quite so strongly, and that's someone does know his CSS! IMHO he must have a reason for doing so in this case, perhaps the proposal is about to be seriously considered and he's trying to make us think forward as to where something like that would take CSS - he obviously doesn't like what he sees ;) I know I don't, it's not about their obvious usefulness, but it's likely that it will extend from constants into variables and classes and that to me it takes the "Keep it Simple" away from it, and I think it is not that it will make CSS, as we know it, any more difficult to learn but it will possibly be harder for new users to separate the could from the should.

btw, I think the 'confusion' of which name to use for these is a clue that there might be further confusion for some. That is not meant condescendingly as I know many here already understand one or more scripting languages, but we are not the majority in this plug'n'play world. I did wonder if this is possibly why Bos uses the word "variables" in his essay title, to point out that essentially whatever you call them, these constants are the same as variables in already existing scripting languages.

W3 Schools defines JS variables:
Variables are "containers" for storing information:

you could similarly say that a CSS Selector {} is a "container" for storing style information.. that's what CSS does!

and as for XSLT..
XSLT is designed for use as part of XSL, which is a stylesheet language for XML.

my bold ;)

XSL is the style sheet language, XSLT is the transformation of it

if they want to add something like this as part of CSS copy the above format, keep it separate call it CSST (t for transformation) if you like, because that it was something like this is doing.. it's transforming the already existing CSS language into something that makes it easier for the stylesheet authors to maintain, it does not actually serve any purpose in the outward style of the document therefore it's not CSS



as for firebug, well I highly doubt it's simply used for 'snooping', more likely it's used by professionals as a tool in their box, the variables/constants won't stop any "snooping" anyway as I presume that no matter how you use "constants" by the time the stylesheet gets the length of the screen/DOM the 'constants' will show up correctly as a "computed style"

:hover is a special case but again, it is not really encroaching on JS, CSS :hovers do not effect a change in the DOM, in CSS :hover simply toggles a *style* the source does not change, and again if CSS is turned off the content is always accessible, unlike the JS versions of the same, unless of course the JS is simply toggling a style in which case who is encroaching on whom ;)

>>simple maths
There is a proposed calc() property [w3.org], which seems to fit the simple maths request nicely

Bert36




msg:3763630
 1:14 pm on Oct 11, 2008 (gmt 0)

If you are going to use a scripting language I would opt for serverside and not clientside. First off all, clientside can be disabled by the end-user and if any major styles depend on it, your page will break. So you must circumvent that meaning more work again.
As for serverside, You need to be prepared to learn at least two languages, PHP and ASP (the two most used) and just to be safe have them both integrated just in case the site switches server-types.

The problem with this is actually the problem most of you have with Constants in CSS, namely that it makes it too complicated and bloated. Constants in CSS would only work so-far. It is a very tiny, minor addition, whereas scripting is an enormous, huge box filled with endless possibilities. So if we take the "ivory-tower argument" seriously then scripting solutions are actually worse than integrating constants into CSS. Or am I missing the point here?

You must consider the fact that once a critical amount of designers start using PHP/ASP/JavaScript then soon there is no way back from it. (We can already see this happening with JavaScript Frameworks like Prototype, jQuery, MooTools, etc.) It adds an extra, "complicated" layer on top of the "simple" (X)HTML and CSS. Given the choiche between Scripting or just constants I would opt for the latter. If only because it is less bug-#*$!e and less likely to break a page.

SuzyUK




msg:3763807
 8:41 pm on Oct 11, 2008 (gmt 0)

I don't think anyone including Bos is saying that they (constants) are not useful - he does after all recommend a right/wrong way to use them ;). and hopefully, we all know it can be done using your language of choice already. ..but as is often the case it's around the houses and to come back again.. when I posted this originally I had no opinion I hadn't even had time to read the essay, it was the simply the title that got me

The question I've been asking myself since - in between my rants/thought process - is what he's getting at when he says they are Harmful *IN* CSS - the fact that he is a little more forthright/condescending/ivory towerish about it make it hard to see past the overall tone of the essay to his point. However, we should give him leeway that yes he very likely isn't an 'everyday' CSS user, but he innately understands it, he was there at the start wasn't he? He doesn't have an ulterior motive, i.e. he's not, as far as I know, attached to any particular Browser or other software application.. thus making him able to see past the "everyday" (OT sidenote: I imagine if it were microsofts name at the top of this proposal the naysayer count would be larger, or at least merit a little thought ;))

I honestly think he's talking about CSS as a Language, i.e back to basics, what is the purpose of CSS kind of thing, and if I've interpreted that right - What would be *harmful* to CSS?

..adding in something that has nothing to do with its primary objective perhaps..
Cascading Style Sheets (CSS) is a simple mechanism for adding style (e.g. fonts, colors, spacing) to Web documents.
Source [w3.org]

or & thanks to this great discussion I think I'm beginning to see..

Constants in CSS would only work so-far. It is a very tiny, minor addition, whereas scripting is an enormous, huge box filled with endless possibilities.

My AHA! moment (Bert are you *that* Bert in disguise? :o), That is precisely the possible HARM, the wolf in sheep's clothing if you like; one "tiny" addition ushered in today under the heading of a something useful, but what next? I've already read some other discussions on the Glazman/Hyatt proposal [disruptive-innovations.com] and within one or two replies most were talking about how it could be extended,

If it were extended, where do you think the next step would take it.. "based on" type conditional variables? if/else variables?, that sounds pretty much like it's one step closer to programming/scripting capability to me. At the very least it's taking a "simple mechanism" and adding layer upon layer of something which is not necessary to its original function.

Not saying that this would necessarily happen but it could certainly open the doors to some of the other requests on the Web Designers wishlists.

Anyway, I took myself off back to re-read the essay again, because I felt I was going in circles and I do like a challenge to an opinion, and right there at the top of the essay when I re-read the introduction there it was, in plain speak - the point (for me anyway) in all it's simplicity.. my bold again!

There are certain kinds of extensions to CSS that people have regularly asked for over its (now 14 years) history but that nevertheless don't belong in CSS. They are extensions to bring CSS closer to a programming language (as opposed to extensions to support more of typography). They would at first sight be useful for advanced users, but in reality they are not, and are in fact harmful for the 'semantic Web,' i.e., for the idea that information should be re-usable.

The proposed extensions include such things as conditional expressions (if-then-else), macros, expressions over properties, delegation (i.e., define an element's style by reference to another element), mark-up injection, mark-up transformation, and symbolic constants (a limited form of macros). This essay only deals with the last of these, constants, but the arguments apply in large part to the other proposed extensions as well.

great discussion btw.. I honestly did not really get why I was likely against it, the "harmful" bit, myself until after your last post Bert, (and don't worry no offence is being taken and hopefully you know that none is meant too!)

So it comes down to whether CSS should retain it's part in this "semantic" web thing or whether it move closer to a programming language, HTML have already been through this haven't they.. with calls for additions all over the place?

So I can now say that no longer am I "on the surface against" regarding this issue, it's not the actual constants themselves I'm averse to nor ever have been, I'm not scared of sorting out a stylesheet that has a little extra thinking involved in it - I'm sure I'll cope whichever way they're implemented.

I'm averse to CSS becoming a programming language, and not because I can't, trust me I can! but because I care about the semantic web and standards (and obviously CSS ;)), IMHO both HTML and CSS should remain simple, even basic, with ANY extension that is simply for the benefit of authors, as opposed to users, added via an external application/module

swa66




msg:3763853
 10:46 pm on Oct 11, 2008 (gmt 0)

When I typed up the examples in #3758755 above, I wasn't as much trying to show it was shorter to do so (I actually didn't expect that much of a difference), I was mainly trying to show a reordering of the CSS could achieve the same "only one place to change".
I was mostly trying to show the "language" of CSS already allows us to group those things together in a manner not to have such a huge need for macros.

I find the reluctance we have to use the abilities of CSS often a bit discouraging. When I post code out here I hardly ever use another grouping than a nice sequential order where all is set in one go on each selector in order. It reads simpler and helps to understand things (most of us are in it to learn things out here, myself included). But once you grasp the concept there really is no need not to go more complex if it suits your needs.

Recently I saw out here a member seeking to alphabetize CSS. We regularly see naming convention topics, I'm dealing with the "joy" of simplifying a generated CSS file of 35K long, ...
CSS can be much simpler than what most of us write, and variables is going to go the wrong direction.

What I also found while typing up the example with variables is that one makes a tremendous amount of errors in typing it up: I forgot variable names, mixed them up etc. very easily.

With what people like Bert Bos have/are making in CSS3, the progress will come from them being able to convince browser makers to fully support it all. And for the browser makers (perhaps with a bit of help from us) to convince their users to finally upgrade to a current browser.

alt131




msg:3763962
 5:09 am on Oct 12, 2008 (gmt 0)

quote by suzyUk

..... They are extensions to bring CSS closer to a programming language (as opposed to extensions to support more of typography). They would at first sight be useful for advanced users, but in reality they are not, and are in fact harmful for the 'semantic Web,' .....

That was the bit that appealed to me too.

I'm averse to CSS becoming a programming language, and not because I can't, trust me I can! but because I care about the semantic web and standards (and obviously CSS ;)), IMHO ... ANY extension that is simply for the benefit of authors, as opposed to users, added via an external application/module

Yup.
Except - as I said in my first post, many of the same souls who have been seemingly lone voices reminding us HTML is a mark-up language, css is for style, and facing down the "anti-semantic / couldn't care about accessibility " (for some reasons those arguments get locked together) are now calling for constant/macros/variables/programming.

I can't figure the reason for what seems like a contradictory move. (I think the lack of a consistent name about the new position also informs.)
And this is not about better/worse. It is about why the stalwarts changed position - which I had hoped might lead to understanding why it is a good/bad idea.

But it means the browser MUST implement it.
... is still a critical issue to my mind, and, for me, this too:
Don't presume to remove tools from my belt to protect me from myself - I want my chainsaw, dammit!
Yup, and don't sneakily try to turn my chainsaw into a reciprocating saw either!

Bert36




msg:3764003
 8:25 am on Oct 12, 2008 (gmt 0)

Primarily @SuzyUK:

No, I am *not* the same Bert. I was afraid that question would pop up sooner or later. Perhaps that is why I tried to circumvent the main point.
I agree that the fear of CSS becoming a full fledged programming language is realistic. Introduce constants today, the rest tomorrow and before you know it we have a language of which the core function (styling) becomes secondary to it's possibilities.
BUT, and this is a big BUT; If W3C would see this (and judging from mr. Bos's essay they do) they would guard against such "progression" and still introduce some things that would actually HELP the semantic web. (b.t.w. I would love a discussion such as this on that topic since I feel semantics is the last thing on peoples mind when they design websites).
Constants and equations can actually help CSS become more separate from content/markup. But indeed, it should stop there. As long as W3C keeps things like that they keep control. And here comes the but: When they refuse to give people what they yell for (no matter how idiotic) those people will look for it elsewhere. e.g. in PHP. And before you know it CSS is no longer used as seperate "language" but as an integrated part of PHP. Is that what we want?
If you accept the fact that implementing constants in CSS will bring about a cascade of events that end in chaos, you should also be able to accept that using PHP with CSS will do the same thing.
So I would much rather have a bit of "simple" addition than a "huge" assimilation.

alt131




msg:3764006
 8:35 am on Oct 12, 2008 (gmt 0)

When they refuse to give people what they yell for (no matter how idiotic) those people will look for it elsewhere. e.g. in PHP. And before you know it CSS is no longer used as seperate "language" but as an integrated part of PHP. Is that what we want?

Not following exactly what you mean by this, especially "nolonger used as a seperate language but as integrated part of php".

This 47 message thread spans 2 pages: 47 ( [1] 2 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved