(2) Many of the problems this article's thesis lays out with CSS are solveable server-side, by preprocessing CSS.
I've been thinking about this a lot lately and I'm not sure it's that big a concern anymore.
I did a test one day and tried to get through a day with Javascript disabled and I came to the conclusion the web simply isn't usable that way. Because these days even the simple sites require Javascript because tools like dreamweaver embed javascript for menus and other basic animations.
Sometimes, when I see a page completely broken because it requires javascript, I just close the tab. If it's too much trouble to get your pages, which might only have static text or other elements that don't require anything fancy, to work without javascript, it's probably not worth my time to check out your page.
in my rich internet applications i will use traditional CSS for the initial "base" state of the application and then JSSS for all further states which are generated via JS (no page-reload)
this is intended for client-side templating and dynamically assigning CSS classes and properties at run-time.
:-)
How is that an issue and what made you think that it was a programming language?
> CSS properties are not cross-browser compatible
Neither is the DOM. Both statements are misleading because most CSS properties are cross-browser.
> CSS frameworks (haml, sass, less) are meant for server-side templating and we need client-side templating
This is a "disadvantage" of CSS frameworks, not of CSS itself.
> dynamically including .css files in the DOM does not guarantee CSS classes will be set cross-browser
Ok? Are you talking about dynamically including them client or server-side?
This site looks rather bland considering that it is promoting a stylesheet framework. Lets take a look at the stylesheet on this very site:
<style>
body {background-color:#000000; color:#FFFFFF; margin:20px;}
a { color:#FFFFFF;}
a:hover { color:#CCCCCC;}
</style>
Now lets take a look at the sample styling code:
drip.toolbar.css = {
height : "40px",
width : "89px",
position :"fixed",
right : 50,
bottom : 0,
overflow : "hidden",
cursor : "pointer",
color : "#FEFEFE",
"background-color": "#932c2c",
"text-align" : "left",
"font-family" : "Arial, Helvetica, sans-serif",
"font-size" : "12px",
"#drip-toolbar-button" : {
height : "30px",
width : "50px",
cursor : "pointer",
},
".links" : {
color : "#FEFEFE"
}
Also, the 4 line example is actually 6:
function parseCSS(id,css){
for(style in css){
if(typeof css[style] == 'object'){parseCSS(style,css[style]);
else{$(id).css(style,css[style]);}
}
};
Personally I prefer to use js rather than css for rich webapps.
you can try re-reading the comments on this thread but if you've never dealt with really rich javascript apps, i can see why this is hard to grasp.
You are right, I do not understand why I would want to place CSS inside an object literal instead of just placing the CSS in a CSS file.
>you can try re-reading the comments on this thread but if you've never dealt with really rich javascript apps, i can see why this is hard to grasp.
Ok, I see (not in any order):
1. "Here, something like this already exists, see [link]"
2. "This wont work / This will be slow / What is the point of this"
3. "Server-side preprocessing already works"
4. You refuting anyone who disagrees with you.
2. if you cant separate your business logic from your views....you have bigger problems to deal with....
2. Exactly. And this simply invites someone to put in the stylesheet.
3. Debugging CSS is already not trivial due to implementation issues. As this technique still relies on CSS you will still have some of the same issues.
4. Ability to have expressions in the stylesheets has already been tried. Once. Trust me you don't want it. Testing and debugging it is very hard.