5 ms·

JSON stylesheets - screw CSS frameworks, use JavaScript - JSSS

16 points by JimBastard 17y ago

lanstein 17y ago
see also http://www.featureblend.com/css-json.html http://www.featureblend.com/css-json.html
- JimBastard 17y ago
  thank you!
- ftrBlndWasFirst 17y ago
  isn't this the same stuff just 2 years later? why are we talking about this?
tptacek 17y ago
(1) CSS frameworks work whether or not client disable Javascript. (2) Many of the problems this article's thesis lays out with CSS are solveable server-side, by preprocessing CSS.
- SamAtt 17y ago
  "CSS frameworks work whether or not client disable Javascript." 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.
  - tptacek 17y ago
    Until very recently, you were either all-in with Flash or you couldn't watch most video online. Now there's ClickToFlash. Similar things are happening with JS. Either way, it's a disadvantage of doing styles in pure JS.
    - axod 17y ago
      And it's a disadvantage to using CSS if the user has disabled CSS :/ I'm not sure why that argument is relevant. Fact is, 99%+ will have CSS and JS enabled.
      - mdg 17y ago
        Sites still function without CSS. The same cant be said for poorly coded sites and javascript. I do agree this is mostly a non-issue though.
  - windsurfer 17y ago
    There's a good chunk of people using NoScript. By forcing people to use javascript, you're making the barrier of entry higher for those people. 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.
- JimBastard 17y ago
  as the article states, "CSS frameworks (haml, sass, less) are meant for server-side templating and we need client-side templating." this is intended for client-side templating and dynamically assigning CSS classes and properties at run-time. :-)
  - tptacek 17y ago
    That reasoning is kind of circular, isn't it? Why do you need client-side stylesheet dynamism?
    - axod 17y ago
      So you can allow styles to update without a page reload? For example, on Mibbit, you can skin your client how you like. You just open a prefs screen and mess with colors, fonts, backgrounds, etc. Using css for that would be ridiculous. Hence client side styling via js.
- robotron 17y ago
  The page does seem to be missing a "disadvantages of JSSS" section.
  - JimBastard 17y ago
    if used in conjunction with a traditional CSS framework and you require javascript for your page, there are really no dis-advantages. 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)
    - woid 17y ago
      one big drawback I'm seeing is binding styles directly to DOM elements (it will appear as style attribute). this definitely has memory (many non-shared styles) and performance implications (may cause many reflows because you are setting styles individually) and it may interfere with existing code I would expect this tool to generate real CSS stylesheet code and embed it into page dynamically
      - axod 17y ago
        I don't think this is an issue. You're modifying the DOM directly. Those style properties exist anyway. You're just modifying them via js. It only "appears as style attribute" if you serialize the DOM into HTML.
        woid 17y ago
        Have you ever looked at any open-source browser implementation? Because of cascading nature of style definition. Data structures describing current styling form trees (for memory efficiency and easy manipulation from script). Effective styles are evaluated during rendering. For example look at this talk and around 11:30 the guy is describing style-related data structure in Chrome/WebKit: http://www.youtube.com/watch?v=RVnARGhhs9w http://www.youtube.com/watch?v=RVnARGhhs9w Your statement "Those style properties exist anyway" is simply not true.
IgorPartola 17y ago
This will be SLOW. Also not having vars in CSS is a blessing in disguise: otherwise business logic would be built into the stylesheet by some genius and I would Auvergne to support it. No thanks.
- JimBastard 17y ago
  1. jQuery and sizzle are pretty fucking fast 2. if you cant separate your business logic from your views....you have bigger problems to deal with....
  - IgorPartola 17y ago
    1. Not as fast as C++ 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.
    - JimBastard 17y ago
      lolwut? i'll agree with you that c++ is faster then jQuery....good day
mdg 17y ago
> CSS is not a programming language - no variables, no functions, no logic 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> I guess this goes hand-in-hand with the grammar, which is also lacking. 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" } This is different / an improvement on CSS how? You are adding extra characters (double quotes and colon) compared to plain-old css for a more bloated stylesheet that must be downloaded? That might be considered nit-picky, but the benefit here of using JSSS is not obvious (Im still trying to figure it out). 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]);} } }; Comments have already been made about having javascript disabled. Perhaps a <noscript> tag that would pull down REAL CSS (again, what is the point of this? I am now maintaining CSS and JSSS?) would remedy.
- axod 17y ago
  Unless I'm mistaken, the point is that you can modify your styles on the fly as you wish. CSS is pretty static, apart from :hover etc. With js you're free to do what you please. Personally I prefer to use js rather than css for rich webapps.
- 17y ago
docyes 17y ago
See also http://www.cssugar.com/ http://www.cssugar.com/

16 points by JimBastard 17y ago

lanstein 17y ago

see also http://www.featureblend.com/css-json.html http://www.featureblend.com/css-json.html

JimBastard 17y ago
thank you!
ftrBlndWasFirst 17y ago
isn't this the same stuff just 2 years later? why are we talking about this?

tptacek 17y ago

(1) CSS frameworks work whether or not client disable Javascript. (2) Many of the problems this article's thesis lays out with CSS are solveable server-side, by preprocessing CSS.

SamAtt 17y ago
"CSS frameworks work whether or not client disable Javascript." 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.
- tptacek 17y ago
  Until very recently, you were either all-in with Flash or you couldn't watch most video online. Now there's ClickToFlash. Similar things are happening with JS. Either way, it's a disadvantage of doing styles in pure JS.
  - axod 17y ago
    And it's a disadvantage to using CSS if the user has disabled CSS :/ I'm not sure why that argument is relevant. Fact is, 99%+ will have CSS and JS enabled.
    - mdg 17y ago
      Sites still function without CSS. The same cant be said for poorly coded sites and javascript. I do agree this is mostly a non-issue though.
- windsurfer 17y ago
  There's a good chunk of people using NoScript. By forcing people to use javascript, you're making the barrier of entry higher for those people. 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.
JimBastard 17y ago
as the article states, "CSS frameworks (haml, sass, less) are meant for server-side templating and we need client-side templating." this is intended for client-side templating and dynamically assigning CSS classes and properties at run-time. :-)
- tptacek 17y ago
  That reasoning is kind of circular, isn't it? Why do you need client-side stylesheet dynamism?
  - axod 17y ago
    So you can allow styles to update without a page reload? For example, on Mibbit, you can skin your client how you like. You just open a prefs screen and mess with colors, fonts, backgrounds, etc. Using css for that would be ridiculous. Hence client side styling via js.
robotron 17y ago
The page does seem to be missing a "disadvantages of JSSS" section.
- JimBastard 17y ago
  if used in conjunction with a traditional CSS framework and you require javascript for your page, there are really no dis-advantages. 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)
  - woid 17y ago
    one big drawback I'm seeing is binding styles directly to DOM elements (it will appear as style attribute). this definitely has memory (many non-shared styles) and performance implications (may cause many reflows because you are setting styles individually) and it may interfere with existing code I would expect this tool to generate real CSS stylesheet code and embed it into page dynamically
    - axod 17y ago
      I don't think this is an issue. You're modifying the DOM directly. Those style properties exist anyway. You're just modifying them via js. It only "appears as style attribute" if you serialize the DOM into HTML.
      - woid 17y ago
        Have you ever looked at any open-source browser implementation? Because of cascading nature of style definition. Data structures describing current styling form trees (for memory efficiency and easy manipulation from script). Effective styles are evaluated during rendering. For example look at this talk and around 11:30 the guy is describing style-related data structure in Chrome/WebKit: http://www.youtube.com/watch?v=RVnARGhhs9w http://www.youtube.com/watch?v=RVnARGhhs9w Your statement "Those style properties exist anyway" is simply not true.

IgorPartola 17y ago

This will be SLOW. Also not having vars in CSS is a blessing in disguise: otherwise business logic would be built into the stylesheet by some genius and I would Auvergne to support it. No thanks.

JimBastard 17y ago
1. jQuery and sizzle are pretty fucking fast 2. if you cant separate your business logic from your views....you have bigger problems to deal with....
- IgorPartola 17y ago
  1. Not as fast as C++ 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.
  - JimBastard 17y ago
    lolwut? i'll agree with you that c++ is faster then jQuery....good day

mdg 17y ago

> CSS is not a programming language - no variables, no functions, no logic 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> I guess this goes hand-in-hand with the grammar, which is also lacking. 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" } This is different / an improvement on CSS how? You are adding extra characters (double quotes and colon) compared to plain-old css for a more bloated stylesheet that must be downloaded? That might be considered nit-picky, but the benefit here of using JSSS is not obvious (Im still trying to figure it out). 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]);} } }; Comments have already been made about having javascript disabled. Perhaps a <noscript> tag that would pull down REAL CSS (again, what is the point of this? I am now maintaining CSS and JSSS?) would remedy.

axod 17y ago
Unless I'm mistaken, the point is that you can modify your styles on the fly as you wish. CSS is pretty static, apart from :hover etc. With js you're free to do what you please. Personally I prefer to use js rather than css for rich webapps.
17y ago

docyes 17y ago

See also http://www.cssugar.com/ http://www.cssugar.com/