homepage Welcome to WebmasterWorld Guest from 54.237.213.31
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

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

WebmasterWorld Senior Member suzyuk us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3741923 posted 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

 

idfer

5+ Year Member



 
Msg#: 3741923 posted 4:56 pm on Oct 15, 2008 (gmt 0)

I'm a little late into this dicussion, but i thought an example of a real website i've designed might be helpful... This site has several distinct sections (e.g. one group of pages to describe different widgets, one group to describe the company behind the widgets, another for informational content related to widgets, etc). While all pages are styled and laid-out similarly, for fun i decided to give each group its own distinctive color scheme. So i have a base css file that defines all the layout and styling, then a separate css file for each section that includes the base css then overrides the colors.

Base css:

h1, h2, h3 { color: red; }
.standout-text { color: red; }
.nav-section { background-image: url(graphics/default/nav-bg.gif); }
li { list-style-image: url(graphics/default/my-bullet.gif); }

Widget css:

@import url(base.css);
h1, h2, h3 { color: blue; }
.standout-text { color: blue; }
.nav-section { background-image: url(graphics/blue/nav-bg.gif); }
li { list-style-image: url(graphics/blue/my-bullet.gif); }

Without variables, if i add a new style element to the base.css whose color changes for each section, i have to go back to each section's css file and add a new statement to override that element's default color.

It would be so much easier if i could do something like (using swa66's syntax):

Base css:

@variables {
schemeColor : red;
schemeGraphicsDir : default;
}
h1, h2, h3 { color: var(schemeColor); }
.standout-text { color: var(schemeColor); }
.nav-section { background-image: url(graphics/var(schemeGraphicsDir)/nav-bg.gif); }
li { list-style-image: url(graphics/var(schemeGraphicsDir)/my-bullet.gif); }

Widget css:

@variables {
schemeColor : blue;
schemeGraphicsDir : blue;
}
@import url(base.css);

Then i can add/remove style elements to base.css as needed without going back and changing all the section-specific css files. Right now, the website is totally accessible, it works well with or without styling, Javascript, or images.

swa66

WebmasterWorld Senior Member swa66 us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3741923 posted 10:42 pm on Oct 15, 2008 (gmt 0)

@idfer

I'll play with it if I find the time to do so, but e.g using a simple php script you could have the variable as php variable and generate a CSS file as you need.

The syntax there is something I borrowed from an earlier post of SuzyUK. And for all clarity I'm not trying to promote it.

The scoping of variables into other files is going to be a nightmare I didn't even think about. Such files are cached by the browser individually. But if you scope the variables to be active outside the file they are defined in, it's going to quickly turn very complex.

And next there will be a call for global variables, local variables etc. While I'm still not convinced we need them at all.

Just an example of what you posted:

@variables {
schemeColor : red;
...
}
h1, h2, h3 { color: var(schemeColor); }
.standout-text { color: var(schemeColor); }

Why not write it as

h1, h2, h3, .standout-text { color: red; }
?

The same goes for your files: do all in black&white in the base file
only add colors over it in the specific file and load both as you need them (no need for the @import, you can easily load both with a link in the header)

SuzyUK

WebmasterWorld Senior Member suzyuk us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3741923 posted 10:52 pm on Oct 15, 2008 (gmt 0)

nice example idfer..

apart from the fact you've possibly/likely inadvertently hit on the next "expected" thing this proposal should have (i.e. be able to @import @imports - I think this is where it goes to technical talk like macros and processing.. i.e. hit time)

In what you're showing us are you going to or already have? scripted the decision how/if to call a particular "widget.css"?

if so why not just script in the unique html or body ID and use CSS specificity, that way no need to change add variables anywhere, no need to change base.css, widget CSS can be called once and be particularly specific to not only the variables, but also the area of the site you've designated.. 2 sheets only (no variables required)

edit: sorry, my speeling is soo bad!

[edited by: SuzyUK at 10:57 pm (utc) on Oct. 15, 2008]

swa66

WebmasterWorld Senior Member swa66 us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3741923 posted 12:40 am on Oct 16, 2008 (gmt 0)

I made a simple example of how to use php to generate a css file and add variables to it server side.

The html I played with:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Example</title>
<link rel="stylesheet" type="text/css" href="css.php" />
</head>
<body>
<h1>test</h1>
</body>
</html>

And the css.php :

<?php
//set the type to text/css
header("Content-type: text/css");
//variables
$background="yellow";
$color="red";
?>
body {
background-color: <?php echo $background ?>;
}
h1, h2 , h3, h4 , h5 , h6 {
color: <?php echo $color ?>;
}

This is very basic, php is a much more elaborate programming language and adding parameter in the call to it, if/then/else, even loops, calculations and all you cold imagine is possible.
Variables also have scopes, you have includes and all you might ever imagine.

The only somewhat unusual portion is to set the content-type to text/css (css must be served as such).

For the rest you have all php can do ...

vincevincevince

WebmasterWorld Senior Member vincevincevince us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3741923 posted 1:07 am on Oct 16, 2008 (gmt 0)


Why not write it as

h1, h2, h3, .standout-text { color: red; }

or:

<h1 class="themea">; <div class="standout-text themea">; <h3 class="themea">; etc.
With:
.themea {color:red}

In this way where you would like to use a variable you instead use a class. An element can have many classes.

An advantage of this is that you can add multiple things to that class:
.themea {color:red;background-color:blue}

A single variable would not be able to cater for adding additional properties to all locations using that variable.

swa66

WebmasterWorld Senior Member swa66 us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3741923 posted 1:21 am on Oct 16, 2008 (gmt 0)

Another way to do theme-ing based on where you are in a site could be to add an ID on the body and then use that to select the theme in the css

#about h1 { color: red; }
#links h1 { color: blue; }
#products h1 {color: green; }
...

Bert36

5+ Year Member



 
Msg#: 3741923 posted 11:02 am on Oct 16, 2008 (gmt 0)

I am with SuzuUK on this one. This is a textbook example of how NOT to use constants in CSS.

@swa66: just google "css variables" and you will find a multitude of php scripts that already exists. Some of them very advanced.

@vincevincevince: You suffer from divitis, classitis and iditis. Do as swa66 and SuzyUK suggest, go as high up in the document tree as you can to specify.


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

What I mean is exactly this:


This is very basic, php is a much more elaborate programming language and adding parameter in the call to it, if/then/else, even loops, calculations and all you cold imagine is possible.
Variables also have scopes, you have includes and all you might ever imagine.

Put this into perspective when SuzyUK says:

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.

My question then is, what is the difference between adding constants to CSS and using preprocessing? I would say: adding constants is just one little thing while preprocessing is an immediate addition of a complete programming language. So what happens if "the masses" discover the flexibility of PHP? In time it will probably mean that CSS is no longer used "stand-alone" but as an integrated part of a php-file. Opening the very box of Pandora we are trying to prevent.

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

lavazza

5+ Year Member



 
Msg#: 3741923 posted 5:21 pm on Oct 16, 2008 (gmt 0)

=Bert36 (POST#3) [webmasterworld.com]
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.

I thought you were right (about Bert Bos being wrong)

Now, thanks to mattur's thread (MAMA: What is the Web made of? Opera's new analysis of web page structure [webmasterworld.com] I know how wrong

dev.opera.com/articles/view/mama-key-findings/#css [dev.opera.com]

MAMA: Key findings
CSS

CSS is clearly a dominant Web technology, found in 2,821,141 MAMA URLs (80.39%). Several methods are available to authors for using style sheets, and MAMA detected all of them. Let us look at some quick results:

  • Embedded and Inline CSS (via the STYLE element and Style attributes respectively) each had an average length of about 1,000 characters.
  • The average length of external CSS (referenced via the LINK element) is about 8,500 characters.
  • External and Inline CSS were both used in approximately 65% of all CSS cases, while Embedded CSS is found in ~45% of all CSS ... there is obviously some significant overlap between these CSS inclusion methods.


By my reckoning, 8,500 chars equates to around 500 lines (with one attribute per line)...

Either Bert Bos had a very tall editor window or a very short grasp on reality

vincevincevince

WebmasterWorld Senior Member vincevincevince us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3741923 posted 5:50 am on Oct 17, 2008 (gmt 0)

@vincevincevince: You suffer from divitis, classitis and iditis. Do as swa66 and SuzyUK suggest, go as high up in the document tree as you can to specify.

If I go high up the tree and declare colour:red; that affects everything downstream as per usual rules. My theme is a two-colour theme - I need to set two colours (red, blue). Upstream CSS entries do not achieve this. I would end up having to change the colour code in more than one location in the CSS file.

By having a second class on the elements which are in the first colour and a different second class on the elements which are in the second colour I am certain to only need to change the colour code in one place.

Class entries in CSS are semantic-neutral. I have no objection to their use.

SuzyUK

WebmasterWorld Senior Member suzyuk us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3741923 posted 2:53 pm on Oct 17, 2008 (gmt 0)

Upstream CSS entries do not achieve this.

@vvv, Yes they do, you just might not understand how perhaps - if you have a two color theme then you only need something which will give you or toggle that high level ID, 1 x single if/else argument, usually built into most CMS templates these days anyway! - once it's set CSS Specificty will take care of the rest, and grouping the selectors for the affected elements will likely mean only one change to the actual color..

I'm sorry if I'm outta line, but IMHO this is a prime example of folks not really understanding CSS properly and using the other side (the programming side which they understand better perhaps?) to say CSS itself is deficient.

CSS Frameworks are useful as an INTRODUCTION to learning CSS, or just getting a job done by the numbers - much like FP was to HTML. But they are not a true representation of how CSS actually works, they encourage bad practice, code bloat, both HTML and CSS, divitis, classitis etc. The performance hit time of a bloated sheet is now considered so minimal that it has gotten out of hand, leading to maintainability issues which now require yet another supposed solution.. I despair - are the JS libraries the same?

Bos is half-right, wrong with the size of the average sheet perhaps, but absolutely right that they probably do not need to be as big as they are, frameworks are doing nothing to disillusion that fact, but frameworks are an outer module so all is well use them or don't.. it's your choice, but don't bring the "solution" for bad coding practice into CSS itself

Yes, I do often feel like saying resistance is futile ;)

My question then is, what is the difference between adding constants to CSS and using preprocessing? I would say: adding constants is just one little thing while preprocessing is an immediate addition of a complete programming language.

I don't know any more than what I said earlier, except that it's probably not just another little addition.. I'm not that technically minded, that's half the reason I like CSS so much .. it and I just go with flow, and we programme enhancements /modules/widgets using the right tool

However I think the recent CSS Working group resolutions might just offer that first clue?

from the W3C Css Blog [w3.org] - Minutes and Resolutions from August:
CSS Variables

  • Daniel presented some changes to the CSS Variables proposal and Hyatt's experimental implementation in WebKit.
  • Several people felt that parse-time macros would be preferable, and would indeed be required for handling multi-declaration substitution.

So if I'm reading that right even the "simple" addition would start to cause problems straight off, and this is where the browsers would have to get more complex from the get go, or am I way out, and just what is a "parse-time" macro in english?

alt131

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 3741923 posted 7:42 pm on Oct 17, 2008 (gmt 0)

My question then is, what is the difference between adding constants to CSS and using pre-processing? I would say: adding constants is just one little thing while pre-processing is an immediate addition of a complete programming language. So what happens if "the masses" discover the flexibility of PHP? In time it will probably mean that CSS is no longer used "stand-alone" but as an integrated part of a php-file. Opening the very box of Pandora we are trying to prevent.

(Emphasis mine) Thanks for the clarification Bert - but I disagree with your premise.

Using php to "pre-process" css programmatically is not the same as adding "programming" capabilities to css itself. Nor does using a programming language to manipulate css mean css has been "integrated" into that programming language.

Nor do I view using a programming language such as php to manipulate css as a "Pandora's Box" that should be kept closed. Unless php (and other programming languages are somehow "banned" that box is well and truly open and long may it stay that way. I see nothing wrong with coders learning and employing languages as they were designed to be employed.

Using php (or other programming language) to manipulate css is about coders selecting from a range of available options to suit relevant needs/skill levels/preferences, etc. Embedding "programming" or "programming-like" capabilities into css is just that. Per my opening post - and as illustrated by later examples, I still think that calls for this to overcome perceived deficiencies would disappear if some coders allocated a little of their complaining and "wish list" time to learning css enough to grasp that much of what they want to be able to do is already possible. Or not. Because css wasn't designed to perform that function.

css is supposed to provide a simple mechanism for applying style to documents in way that separates style from content. Per my opening post, what I am still looking for is material that directly addresses the single and simple issue: How changing the fundamental nature of css will improve the ability of css to achieve what is designed to achieve.

That's not about protecting anyone from the apparently destructive masses, nor about making css emulate this or that programming language, nor about coders choice of class/variable names, nor about arguing the granular detail of code snippets.

Its about how these modifications are going to improve the liklihoood coders will learn css well enough so the modifications will be used well enough to improve the application of style while keeping content and style separate - and by that means improve delivery to the user.

suzyUK - jusy saw your post. Looks like we're batting from a similar box

Bert36

5+ Year Member



 
Msg#: 3741923 posted 8:10 am on Oct 18, 2008 (gmt 0)

Obviously our arguments are the same, we only come to different conclusions. I guess only time will tell. I just fear that CSS will go the same way as CMS (even though it is a completely different concept). Back in the early days of "dynamic pages" PHP and MySQL were an extension of "normal design", theses days the designing part has become secondary to the actual CMS-program. Templating and making a Joomla/Drupal/Wordpress/etc. site requires you to have some insight into PHP programming and has very little to do with HTML/CSS any more. Sure they are still there but have taken a back-seat in regard to the mechanisms already in place.
Perhaps you are right and I am just getting old. Afraid of the web taking a direction away from its positive potential.

Sorry, forgot:

parse-time macros are...well it is difficult to say in that context. It depends on what they are talking about. It could mean they want PHP or even JavaSScript to handle it, like we are talking about here, but it may also mean they are thinking about things like Ruby. I guess the problem they are facing has to do with how to anticipate what value is to be substituted. The obvious way around this is to first "parse" the script to find all the values and then to parse it for real to create the page. (Like an interpreting language e.g. Visual Basic) But I could be way off here. Again, I don't understand the context in which they wrote it.

Oh [yet another edit] Yes SuzyUK, JS frameworks are the same I fear. It started out as a good and simple idea. It filled the hole many felt was left by the sluggish constructs of JavaScript. these days I see more and more people unable to program JavaScript but having no problem to alter ready-made Prototype/MooTools/jQuery scripts.
So all in all, when I look at the past and consider CMS and JS frameworks, I fear for CSS if it does not evolve by itself.

[edited by: Bert36 at 8:32 am (utc) on Oct. 18, 2008]

Bert36

5+ Year Member



 
Msg#: 3741923 posted 5:22 pm on Oct 22, 2008 (gmt 0)

Well, I thought I would try and see if I could actually think of an example other than the "color=red" type of thing. Just to make it more interesting ;-)

So I did some php script (mind you I am bad at php so excuse my ugly code) to aid me in calculating a vertical rhythm. As it turned out, I thought it was rather handy, but seeing as I am not very versed in php I posted it in the appropriate forum; here: [webmasterworld.com...]

Anyway, even though I hope this script will evolve somehow and become usable. I still think it could be done much more elegantly and more efficiently if we had direct access to the parsed CSS computed values.

If I could refer to the font-size value of another element inside my stylesheet I would not need another scripting language to do that like jQuery or phpQuery. And don't tell me it would bloat the UA because it must be implemented. It already IS implemented. How else can the browser calculate computed values and refer the parents font-size to determine em-values? It is not a matter of creating a new type of parser, it is a matter of making the parser accessible from within CSS directly.

Back to the example. Imagine you could just write in your CSS:


h1, h2, h3, h4, h5 {
margin-top: eval(2 * this.line-height);
}

Beats the hell out of:


h1 {
margin-top: 1.76538765em;
}
h2 {
margin-top: 1.166666667em;
}
h3 {
margin-top: 1em;
}
h4 {
margin-top: 0.9866666em;
}

etc. (you get the idea)

swa66

WebmasterWorld Senior Member swa66 us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3741923 posted 7:02 pm on Oct 22, 2008 (gmt 0)

Even Microsoft who introduced a non-standard CSS expression (javascript alike thing) since IE5 is starting to stop [webmasterworld.com] it in IE8. The days of expressions in CSS seem to be counted in favor of either server side or javascript solutions.

SuzyUK

WebmasterWorld Senior Member suzyuk us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3741923 posted 10:09 pm on Oct 24, 2008 (gmt 0)

Back to the example. Imagine you could just write in your CSS:

h1, h2, h3, h4, h5 {
margin-top: eval(2 * this.line-height);
}

imagining... how many passes through the stylesheet(s) a browser would have to make before it gets to that final computed line-height - it will be at least twice as it must get to the end, of all sheets, imported or otherwise, to allow for the "cascade" - before it can go back and render the "computed" margins?.. imagining also that this is a perfect world and folks have used the cascade properly

sorry but IMHO, that means we'll be back to table style rendering in no time (note: lessons learned means CSS offers a choice for that now too) . i.e. the important content cannot render until the browser gets the counting right, hmm I so don't want to go back there CSS or otherwise

alt131

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 3741923 posted 7:07 am on Oct 25, 2008 (gmt 0)

Bert, you're doing a great job of making me think about this ;)

And don't tell me it would bloat the UA because it must be implemented. It already IS implemented. How else can the browser calculate computed values and refer the parents font-size to determine em-values?

And my ear-drums ring from complaints about the calculation model. It seems counter-intuitive to base an argument on a characteristic that supposedly needs fixing because it is irreparably broken.

Aside from that, calculations for such things as ems are relative to the parent of the relevant element. That works with the cascade, inheritance and is intuitive for "top-down" ua loading. Maximising a computers ability to process information very quickly (as referred by another poster)

The example given has the potential to step outside that. Rather than maximising processing speed, it depends on processing speed to deliver to the user within a reasonable time. And that, to me, for at least the reasons identified by SuzyUk, is very troubling.


...
h4 {
margin-top: 0.9866666em;
}
etc. (you get the idea)

Yup. The web is not print - and that's why css doesn't provide the granular control available if it were.
... and a formulae one race car handles badly off-road - "deficient" is a matter of perspective ;)

sorry but IMHO, that means we'll be back to table style rendering in no time (note: lessons learned means CSS offers a choice for that now too)

I'm not so sure SuzyUk. What I do think is that we would be back to the web being the prerogative of programmers. Who, <shudder> don't strike me as the van-guard for accessibility or usability.

Bert, I don't think you are too "old" (I am, anyhow), or afraid of the web taking its positive potential. What I can't figure is why you support introducing an unnecessary complication to a mechanism that is supposed to aid access to information.

But if we are going to hark back in time, who here cannot remember browser sniffing for all known browsers (when there were so few they could be known), then using javascript to serve the relevant proprietary html to each browser (after making sure the sniffer javascript also accommodated the proprietary differences as well)?

It was that mess that provided the impetus for w3, caused many of us to embrace the concepts of style/content separation, server-side over browser-side programming, device/platform/ua independence, design with regard for accessibility and usability, begin to use terms like "valid" and "conforming" - and of course, css.

To me, the idea of serving and styling content as a function of scripting has already been tested and rejected. To bang the old drum ;) - still waiting for an answer as to how these whiz-bang really super programmer thingies will achieve superior delivery to the user.

Bert36

5+ Year Member



 
Msg#: 3741923 posted 10:00 am on Oct 25, 2008 (gmt 0)


Even Microsoft who introduced a non-standard CSS expression (javascript alike thing) since IE5 is starting to stop it in IE8. The days of expressions in CSS seem to be counted in favor of either server side or javascript solutions.

Actually, the css expression in IE IS javascript (try using it with javascript disabled in IE; it won't work.)
One of the arguments to remove it is because it is a security risk. Which is true, Javascript is a security risk. But most users have it enabled anyway, and (client-side) AJAX is very popular these days. (more and more websites are relying on jQuery, mootools prototype etc. etc.)
A few weeks ago I came across phpQuery, which is a port of jQuery that runs server-side. And then I came across Jaxer. The last I do not quite grasp, but as I understand it, it renders everything server-side and then delivers it to the UA.
These kind of technologies would give us -as designers- the benefit of knowing for sure that users will all get the same picture, on the other hand, it would pose a higher security threat to the servers and put a much higher (CPU) load on them. So in the end, wouldn't it be the same difference?
Anyway, I am getting slightly off-topic here.

CSS files are sort of "parsed" multiple times already. Consider this example:


#content {
font-size: 10px;
}
h1 {
font-size: 1.2em;
}
#sidebar {
font-size: 14px;
}

When the parser gets at h1, it can immediately calculate that font-size needs to be 12px inside the #content box. But it doesn't know yet how much it must calculate for the #sidebar box. Because that one comes later in the cascade.
I am no expert on css-parsers, but I *think* UAs simply store values as-they-are inside the DOM, replacing them as they go down the cascade, and then start calculating at the end. If so, I don't see anything wrong with (2*line-height). it can be stored as-is like any other value and be calculated afterwards when the entire cascade is known. The only difference would be that the parser would have to have an extra repository for storing constants. (this is also the reason I think why we are talking constants and not variables, as only the last declared value in the cascade can be used).

Doing it like this would not pose any kind of security threat, it would put no load on the server and we would not have to worry about users having something disabled so it won't work.
Will it increase rendering time? Probably, but I am sure we are talking seconds here, not minutes. And if a user is willing to wait for photo's and flash loading taking more than 30 sec. I don't think they mind 2 or 3 seconds for the rendering to take place.
Besides, when we use Javascript or server-side solutions, it will take the same extra time anyway (probably even more so as I tried to demonstrate with my rhythm-script), so this argument is arbitrary.

I am not advocating scripting/programming capabilities in CSS which are *like* javascript/php, I am merely advocating the possibility to be more flexible when it comes to assigning values to properties in CSS. (why can I absolutely position containers based on the last relative ancestor and not on the first, and why can I set the font-size based on the parent and not on the sibling? It makes no sense to me.)

Having said all this, I also agree with everything you say. These kind of capabilities in CSS could be misused, misunderstood and could be the beginning of the end as well (just to dramatise it a bit ;-)).
But this is true for everything.
Just on a related side-note. Recently I had to teach on a local school here, and I wanted to have some examples of good CSS usage. So I started looking at real-life source codes. I thought I would find the good stuff from the big web design companies........The horror. One table layout after the other.
Despite all "our" efforts and all this time, the big companies that churn out the big company websites still abuse tables.
My (I am a pessimist at heart) view with any kind of technology, discovery and invention is: Most people will abuse it because it is easier then not to. The road to hell truly is paved with good intentions(/inventions).

The major advantage of (X)HTML/CSS is that there are published standards/best-practices/guidelines of usage associated with them. php/javascript and all the derived frameworks of them, do not!

Addendum:
In theory it is already possible to style a page completely with jQuery (or another framework) without any css-file associated with it. In fact, jQuery does a better job of complying to CSS standards then any/most browsers do. I predict a time when all styling will be done client- or server-side by scripting and not by css-like constructs. Simply because of the flexibility advantages. Maybe this can be avoided when CSS itself gives us more flexibility?

[edited by: Bert36 at 10:17 am (utc) on Oct. 25, 2008]

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