CSS Options


One thing I have been thinking a lot about lately has been the multitude of ways that CSS can be applied to a document. You can have inline styles, you can have style elements in your page, you can have external style sheets, you can have styles applied by ID, styles applied by classname, styles applied by tag. Every web developer I talk to has a different preference for how to do things. Some will use different techniques depending on the situation, and some will always follow a rule based on standards or personal preference.


This is all well and good. CSS allows a lot of flexibility. I respect that. But how do you have an interface that allows people to efficiently direct a designer to generate CSS like this? This is the next challenge for web development tools to handle.


In my comments to my first post I asked a respondent what he thought of a feature that would move inline styles off of tags and it sounds like for that person it would be something he wanted. But would this be something everybody would want? When I think about what I would like to have for managing styles it seems like a good idea.


Whidbey generates a lot of CSS when you use the designer. This is a good thing, and an improvement over VS.NET 2003. No more font tags! It will be interesting to hear about how people will arrange all this CSS that the tool will generate for them.


Comments (10)

  1. Anonymous says:

    After reading the comments of F1R57 P057 regarding CSS management and removing inline styles – I couldn’t agree more! This is something which really needs to be addressed. Here in the UK us web developer Brits are very much into seperating all CSS from code. Basically if you use inline styles you don’t get the job! The idea about moving all CSS to Script tags in the head of the HTML document is very good and sounds very promising. I especially like the idea of it being updated if you drag something to another position or to extend from this maybe apply changes from the properties tab and this updates corresponding CSS style.

    One idea which I have had though which I think would be better than placing all CSS in the head of the HTML document is to go one step further and add all styles to an <em>external<em> *.css file and link the document into the page using <link rel="stylesheet" type="text/css" media="screen" href="/css/main.css" /> declaration. That would not only be sooo cool – its also the right thing to do, especially when you guys have been working so hard on getting Whidbey to generate valid XHTML. In fact want to repeat that :

    ‘add all styles to an <em>external<em> *.css file and link the document into the page using <link rel="stylesheet" type="text/css" media="screen" href="/css/main.css" /> ‘

    I tell you – if you could do this you would have the UK web development industry licked! Seriously.

    I’m sure there are hurdles in achieving this but I also know the Microsoft team are a clever bunch!

  2. Anonymous says:

    Sorry in my excitement I wrote Script tags – what I meant was Style tags. Oh the excitment of being listened to!

  3. Anonymous says:

    I agree too. It’s frustrating when you want to change a style for something that is set in an inline style attribute from a Web Control.

    My preference is to have multiple external stylesheets. Have one for generic style stuff (fonts, colors, general layout of the site). Then, have one tailored for the controls on a specific page.

    I understand this would be a big challenge though. Dreamweaver MX 2004 tries to put your styles in classes, but it doesn’t work out all that well.

  4. Anonymous says:

    Joe90 has it bang on. External style sheets are the only way to go. The main beauty of CSS is site wide maintenance, one file update and the whole site updates. Inline styles although, technically compliant, still leaves us with the same problem of nightmare site wide updates. Also, an external CSS file is read once and cached making for a lighter, more responsive pages (to make up for the hit we get from the viewstate ;)).

  5. Anonymous says:

    External stylesheets all the way. I think ASP.NET has done a great disservice by teaching new web developers to use inline styles out of ignorance. I get so many questions on how I make my site’s colors change on the fly — and its just basic stylesheets!

  6. Anonymous says:

    It is interesting to hear this feedback. Back when HTML was brand new large websites did not exist (obviously, because nobody had time to create them yet 🙂 but as the websites got bigger, they turned into large code-like projects. I think that some people still treated them like documentation instead of code, but the design patterns I see with complex sites now resemble code way more than documentation.

    CSS is basically code reuse for websites. And when I look at people’s Longhorn demos I can see that the idea of separating content and appearance will be the future of client side apps too.

    What is it about current tools that is not quite there? I think that the difficulty in designing a tool for these scenarios is when people want to mix and cascade styles. Personally I don’t do it much (it makes it hard to debug the appearance of things) but people sometimes want to or have to do it.

    What I am curious about is the order that people do things. Do you find yourself making everything inline at first, to get a handle on things, and later on making a stylesheet? Or do you make a stylesheet first and then create content around it? I have seen people do both, but I wonder what is more common, or if what people do is because of how the tools work rather than what they want to do.

  7. Anonymous says:

    The order of play for building web UI’s is basically (at least to my mind) as follows.

    In trying to develop a site as XHTML the first thing I will do is get the conceptial structure the design onto the page i.e. at its most simplist – header, left (right) column navigation and footer I use <div> tags a lot to do this so I might do something like :

    <html>

    <div id="header">

    </div>

    <div id="navigation">

    </div>

    <div id="maincontent">

    </div>

    <div id="footer">

    </div>

    </html>

    (Whidbey is on the right track with Masterpages because web site pages do tend to be templates of maybe 3 or 4 variations of the concept design)

    Then you can start to write CSS in your external file to ‘manipulate’ the defined container (<div>) blocks i.e. use display: float to change whether the <div id="navigation"> block is on the left or right of the page of change the <div id="header">

    </div> contents to show a different background image/logo.

    The beauty of doing this way is that if a user views the site without a CSS enabled browser such as a speech/braille reader the elements to the site will still be interpretated as it were meant to be i.e. header, navigation, content. This improves implied accesibility and semantics.

    To be honest I think the only people who use inline styles first are the types of programmers who have never had to deal with UI stuff (thats not a dig at anyone! just my experience of the web industry and working with talented people at all levels).

    Your comment – <quote>or if what people do is because of how the tools work rather than what they want to do.<quote> …

    believe me – we need tools that allow us to work how we should be working! If we have tools that try to change our way of working to a way that we feel is ‘wrong’ then there are I think quite a lot of users who won’t use the tools and then basically the game is lost.

    I think the DreamweaverMX CSS support is pretty good – in the UK its uptake has been good (although I still prefer handcoding) and so its seen as certainly being on the write track. It has influential support of web standrads bodies such as http://www.webstandards.org as they worked with Macromedia in improving the tool.

    In terms of Whidbey I think a good way of improving CSS support would as follows:

    In the designer you would be able to view the webform showing elements which are able to have CSS applied. You would then click the element you want to change and have a choice of either selecting properties and values (like the properties panel now) or a window would open to allow hand coding CSS for that elements’ ID. The changes made would be reflected in the desgner immediatly so you could correct, change and refine the design.

    You could also have another panel which would show the CSS cascade – like a tree view similar to view XML nodes or Page.Control tree. You could then insert new styles into the tree to act as overiding styles (sorry if that sounds a bit abstract!) and change how the cascade is interpretated.

    I would also like to see the Build process to take the CSS styles property ‘metadata’ and dynamically generate the style sheet which is then used throughout the site. Due to the use of IContainer interface in server controls generating unique IDs I think it would be possible to generate a style sheet cascade that works for the whole site and if this was possible it would mean that you wouldn’t have to generate individual style sheets for each page.

    I think I’ve started to babble now so I’m going to stop right there.

  8. Anonymous says:

    Actually while we’re on the subject of dynamically generated external files – another peev I have is the way that Javascript is placed in between <body></body> tags. If it has to be in the page it should be in the <head></head> of the document but would be infintely better would be to place all javascript into an external file and linked in like this:

    <script language="JavaScript" type="text/javascript" src="/main.js"></script>

    this is the right way of doing things!

    Maybe I’m just crazy but again I would like to see the Build process take care of this on a site wide basis.

  9. Anonymous says:

    All very good comments up to this point. Here’s one concern I have (or maybe I’m mistaken). Recently I was asked to CSS a calendar control for a client of mine. They wanted the ability to change the "look & feel" of the calendar without having to mess with the .aspx page. So I set about doing that… here’s the methodology I used.

    I went into the .aspx page, where I declared the calendar control. I proceeded to add CssClass properties to every aspect of the control. Then I went into the .css file, and added classes for each of those calendar parts. But there was a problem. For some reason, several parts of the calendar control weren’t accepting the styles from the CssClass I had defined for it. I won’t name them here, but it made it very frustrating to work with. Even though I had set the CssClass property, the calendar control was still outputting inline styles! Needless to say, it was very, very frustrating… and I had to train my client how to make some changes in the .aspx page (never a good thing to do) and the .css page.

    Moral of the story, let’s hope Whidbey provides us the opportunity to better style of web pages with CSS.

    C

    PS

    Oh, if I was simply mistaken and this is a common problem, please give me a hand. I asked on the asp.net forums and nobody could help. Thanks!

  10. Anonymous says:

    The order I usually do things with CSS now is externally (after the structural XHTML is setup). Very similiar to Joe’s approach. When I first started with CSS, I would code inline at times to get a feel for what it would do to my page. But, now that I understand exactly what the CSS is going to do to my page, I just code it straight into an external sheet. I always use external stylesheets now, to keep the css separate from the XHTML, and to allow stylesheet switching (which is very, very cool. Check out http://www.csszengarden.com for some great examples).

Skip to main content