1

The only reasons I see on the internet to not to use inline-css is because of the separation of html and css & management, but if this is not a problem in my case I don't care I will use.

Another pro I can say is this: imagine you want to load a widget made by another user, you will only need to load 1 file, the javascript and not the css.

But it might have other problems? thanks

Totty.js
  • 15,563
  • 31
  • 103
  • 175
  • There will eventually come a time when you'll want to change the look of some elements, or change some styles for cross browser stuff. Always keep it separated. – Kyle Aug 30 '11 at 09:43
  • I will change my javascript, and will be changed all over the page, as css will be generated and not hand-write. So no problem too.. – Totty.js Aug 30 '11 at 09:46
  • What about the reason of saving bandwidth? I'm currently using an UMTS-connection, which sometimes is really slow. – feeela Aug 30 '11 at 10:57
  • What does this have to do with JavaScript? – BoltClock Aug 30 '11 at 11:02
  • I think @feeela and other missunderstood my question. Of course is saving bandwidth at cost of the time of runtime-initialization. All you will download is an empty-html-page + ~100kb of min scripts instead of html+css+js! So all the html+css will be generated at the runtime and is abstracted to the developer. – Totty.js Aug 30 '11 at 11:09
  • @BoltClock: javascript generates the code at runtime, simply that. – Totty.js Aug 30 '11 at 11:10
  • @Totty Well, then it should make no difference, except inline-stylesheets are easier to handle in JS. – feeela Aug 30 '11 at 11:43
  • If you are generating html+css by javascript, that means that probably you are coupling presentation with logic, if this is the case, you have a great disadvantage in code maintainability, presentation and logic can't evolve independently, but if you are decoupling this layers in another way (using an MVVM like knockoutjs or angularJs for example), then it's ok, because the generated inline css code is not your source code. – Miguel A. Carrasco Aug 09 '13 at 22:35
  • The logic and presentation is separated but not like classical (html+css for presentation, javascript for logic). Is just a view and a model javascript (Model-View). – Totty.js Aug 27 '13 at 20:55

3 Answers3

6

If you read your question again, you have answered it yourself. There is a reason for the "separation" of html and CSS. Because at some point in time, you will eventually want to change the look of what you have coded up. These are the times when having a separate CSS file would be very helpful so you are only ever making changes in one place and not throughout your application.

EDIT

Another usefulness of having the CSS separate is the caching. Most of the modern browsers cache the CSS files. This means there are less round-trips to the server and quicker response times. I'm not sure if same is the case for JavaScript, because JavaScript files would be cached, but the client browser will have to execute the code every time it loads.

Hiral Desai
  • 1,062
  • 1
  • 9
  • 24
  • I think I didn't explain well. All the css is done in a different way: you create a new UI Object and will have a look based on it's properties. If object.backgroundColor = 'black', then when will generate the html will create
    ; Then if I want to change in all object that color I just set that on the main "class" of the UI Object or a javascript theme will be provided. I will never have to cache CSS or HTML as they dont really exists in my code. My code only knows that "backgroundColor" will convert in "background-color" for css, and a new UI object will     – Totty.js Aug 30 '11 at 10:08
  • 1
    be created in a new
    tag. So if I need to change the look I will make a javascript theme (that is app specific) and then my javascript will generate all the html+css based on the new properties. If I want to have css only on a specific element, it will be set at the instance level. ps.: I haven't answered myself because I already said that separation is not a concern as is abstracted by javascript.
     – Totty.js Aug 30 '11 at 10:11
  • Hmm, I see what you mean. Although I have never done it before, I suspect there will be a significant difference in page load times in both methodologies. Have you done any load time calculations using both these options using firebug/yslow or any other tools you might be using. Not saying what you are doing is incorrect but there must be a reason there is an emphasis put on having separate CSS files. Also, the approach you are taking could also be changed so that all your CSS rules are produced in a separate file and the generated HTML only had
    . Your call! :-)     – Hiral Desai Aug 30 '11 at 10:22
  • In my case the page load time will be defined by the time to "download the code" + "code execution" + "dom generation" vs "html download" + "css download" + "javascript download" + "code execution". In my option, the "dom generation" will be heavier than the other approach. But I have no "css & html download" time. Now the time difference is based on internet-speed & browser & ui-objects-number. Javascript can't generate a separate css file but can generate a separate style tag with all css rules (at runtime, as all I speak here is generated at runtime). But will be a pain to remove and change – Totty.js Aug 30 '11 at 10:46
  • Not to speak about setting a different id on every tag. I think would be slower – Totty.js Aug 30 '11 at 10:47
  • Hmm, still you will never know until you test it. Many times we humans think differently than the computers. :-) Also, you are not taking into consideration the rendering difficulties for the browser. Many times you would see the sites appearing to render quicker than other sites just because the elements are displayed before the styles are loaded. In the approach you are taking both these will happen simultaneously, making it appear to load slower. **EDIT** This is just a guess based on what I know, I have no proofs to support it. :-) – Hiral Desai Aug 30 '11 at 10:51
  • in my case I'm not interested in seeing the object sooner but with no style. Seeing directly, without seeing the un-styled elements, is a little pro in my opinion as they are not "usable" and makes apps look buggy, even if not. Take a look at the source of this dojo app: http://demos.dojotoolkit.org/demos/mail/ – Totty.js Aug 30 '11 at 11:06
1

I think this is a good question that is worth exploring. I don't think there is a performance or standards-based argument for not using inline CSS - it works perfectly well - the only (though considerable) argument for separated CSS is for maintainability / readability. And so if you are generating CSS from JavaScript, generating it inline is just as sound as any other way.

In fact, DOM APIs in general expose much simpler methods for assigning styles directly to elements ( https://developer.mozilla.org/en/DOM/element.style ) than for creating new stylesheets. Therefore almost all JavaScript libraries, like jQuery, when they have to manipulate styles they do it by adding inline styles to an element.

Having said that, I have never before seen a situation where the mark-up and styling for a whole page was generated with JavaScript. I would expect this to be rather inefficient. I can see that if you have a web application where all content is pulled in through Ajax (a perfectly good solution) then you might write a fair bit of the mark-up with JavaScript, but still it would be better/more efficient to load most of the surrounding mark-up for your content in the initial page load, and then use JavaScript to swap out content within existing elements.

In any case, I would recommend that you keep most of your CSS in an external stylesheet with relevant classes already defined, so that all your JavaScript does is create elements with the correct class. This would have a performance advantage and would also mean that all your style information was located in one place, and is separate from your JavaScript, which would make your code easier to maintain.

Robin Winslow
  • 10,908
  • 8
  • 62
  • 91
  • ps.: if you look at how gmail works you understand that html is all generated, and only takes a little bit to do it. But the css is not inline most of the time – Totty.js Aug 30 '11 at 13:00
-3

It's OK to use inline css. (in this specifice case)

Totty.js
  • 15,563
  • 31
  • 103
  • 175