Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I would like to know why they created the property style for all properties instead of create a new property for each one?
Let me explain better, today we use this:
<p style="color:blue; background-color:red"></p>
I would like to know why they didn't do like that:
<p color="blue" background_color="red"></p>
Is there something in any w3c document telling it?
My theory, based on logic... Something like color="blue" is not CSS, it would inherently be part of the HTML language.
With CSS in the picture, there is no reason to expand on HTML to handle something that HTML was never designed to handle. And so they made a way for HTML to read and understand CSS. Hence the style="" property.
Why create something that is redundant when you can simply adapt to read what already exists?
That said, you used to be able to use things such as the <font> tag to recolor or resize text, such as <font color="blue">
As CSS becomes more and more powerful and expansive, there is no need to implement this type of styling, thus why the tag is now deprecated in HTML5.
Beyond all reasoning there is a clear logical point, which is for each type of code to serve its particular purpose. While they allow you to insert CSS into HTML inline by using the style="" property, it is not best practice and should be used in extreme and unique cases.
Thanks to the style attribute, the development of new CSS properties doesn’t require an update to the HTML specifications.
If we’d have a separate HTML attribute for each CSS property, all these attributes would have to be defined in the HTML spec. So whenever a new CSS property is defined, all HTML specs would have to be updated. Otherwise this new CSS couldn’t be used in older HTML versions (validly).
In the same sense HTML doesn’t define graphic formats (like PNG) or codecs for audio/video, or the content of math or svg.
So CSS and HTML developers can work separately from one another, as long as they respect the interface they agreed on: the style attribute (and the other ways to add CSS for HTML).
Another reason: It would be possible that other styling methods come up in the future, not compatible to CSS. Now when everyone would get their own attributes, that would become a total mess.
I'm unable to point to where in the spec this is detailed, but I'll include my understanding.
I believe the intent was to promote separation of style from content. The style attribute was introduce to allow for inline element styling, but the intended approach to styling was to do so using classes and external CSS. This allows for reduced document size, as well as a generic content-only approach which allows for, among other things, a simple approach to theming.
style may also have been included to address situations where referencing an external stylesheet is either impractical or impossible.
Because as much as possible, the w3c is trying to abstract presentation (CSS) from structure (HTML) .. and if there are new properties created (attributes really) it would obscure the mark-up as well as making it more confusing (and harder to debug)
Its always best practice to use an external stylesheet whenever possible.
Related
I'd like to get opinions if this plan is worthwhile or not.
I have an existing site, and some elements have a CSS class defined.
I thought I would append each element that has a class with a new class:
<div class="existingClass">
would turn into:
<div class="existingClass newClass">
Then, if I want to override any attributes in "existingClass", I would do so in "newClass" (because the last class attributes are taken?).
I figure this way, nothing would break, so I do not risk anything because I am not removing "existingClass".
Any problems with this plan?
First know what is in the existingClass. Write newClass in such a manner that it won't break the layout. For knowing what is in the existingClass use tools like firebug to save time.
Indeed this seems to be a good approach, if you don't want to mess editing the already written CSS.
What you must master are CSS precedence rules, also known as CSS specificity.
Some good articles about it:
Specifics on CSS Specificity.
CSS Specificity: Things You Should Know
This is important because when you want to change a style, that chance will be visible only if you follow appropriately those guidelines. If you don't, then you'll face some troubles when rendering your page.
I am using SEO analyzer, and it tries to make me crazy.
It says that the page has inline css. I have external css, which lists reused styles, but I do not see value to put once-used "style" stuff into this sheet so I leave them in html. I particularly curious about width and height css properties, which I define for images. Why this SEO analyzer does not check for uniqueness of styles?
The value in using groups of styles that you only use once is that you may find later on that you may have to use it more than once. If you already have the appropriate set of rules, it's a simple matter of using the stylesheet selector. It also makes it easier to update later on since the styles are in a canonical place in the CSS rather than a random place in the html.
As for width/height on <img>, these should be done via the attributes rather than style, and the analyzer should not complain about that -- in fact it should encourage you to use those attributes.
There is probably a lot of subjectivity in the SEO analyzer, but one of the key points of SEO is minimizing download size. Removing style attributes does this. It does increase the size of the CSS file, though, but probably not by as much. I'm not sure what effect that has.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I read an interesting post on using a css classname instead of the id attribute for identifying modules or widgets. The css classname could be prefixed with a hash or underscore, to indicate that the classname is used as an id. The reason for this being, that ids can only be used once per webpage whereas a module or widget could appear multiple times.
Simple Example
Instead of using ids such as
<div id="currencyConverter1" class="foo">EUR/USD</div>
<div id="currencyConverter2" class="foo">GB/USD</div>
prefixed classnames are used
<div class="#currencyConverter foo">EUR/USD</div>
<div class="#currencyConverter foo">GB/USD</div>
In the article it suggests, that an underscore could be used instead of a hash, because hashes need to be escaped.
I quite like this idea, but I'm not sure if this is good practice or has any drawbacks. What is the general opinion on this?
It doesn't get simpler than this: does it uniquely identify an element within a document tree now and forever? Use an ID. If not, use a class name.
Remember that IDs and classes are properties pertaining to each element, not a group of elements collectively. Using "identifier" to mean "identifying a group of elements" is futile; that's why you have class names instead, to classify those elements as being related in some manner.
If you're "identifying" elements that are members of a specific widget or module, you have free reign to add a class name to each element representing that widget or module, and select it in addition to the element's class:
<div class="my-module foo">.my-module.foo</div>
<div class="my-module bar">.my-module.bar</div>
Or, if specificity is such a huge issue that you can't even afford to stack another class selector to your rules, prefix the element's class name with the name of that module and select it.
<div class="my-module-foo">.my-module-foo</div>
<div class="my-module-bar">.my-module-bar</div>
If that's the question, then yes, it's perfectly legitimate — as I've mentioned, that's the whole point of class names and selectors.
But there are no legitimate benefits to making a class selector "look like" an ID selector without functioning like one. What it does cause, on the other hand, is needless confusion, especially for other authors who may not know better. If you want to avoid ID selectors like the plague, fine, leave them alone; nobody's forcing you to use them. But if you want to uniquely identify singular elements, then you may want to remember that CSS already provides a feature for that to complement the id attribute in HTML, known as the ID selector. There's no need to hack other parts of the selector syntax to emulate some other feature that's already readily available to you and has been since the very beginning.
Incidentally, if you're running into specificity issues with your CSS rules, then it's your CSS rules that need refactoring, not your markup. Hacking your markup to accommodate your style rules only leads to further trouble, at least in my experience. (I understand the irony in saying this given that hashes are allowed in identifiers starting with HTML5.)
Its mostly driven by your own, personal taste. there are a lot of opinions and articles on this topic, even complete books were written.
I suggest the following:
SMACSS
OOCSS
MVCSS
All of them are mentioning a more-or-less similiar naming convention for CSS, while also saying that these are just rules of thumb, not dogmas.
personally, i follow that approach:
.modName // module
.modName__sub // an object or sub-module
.modName__sub--modifier // a modifier
A similiar structure is used for example by InuitCSS
If you want to use classnames as unique identifiers, than just do it, there is nothing wrong about that. Further, it is future proof in case that you wish to use it as a "standard" class. However, i would shirk that hash for obvious reasons.
Not sure what your modules or widgets are for (wordpress?) but the methodology I choose to use when coding is this:
1: If it is DOM element that has a specific function that I know will only appear once on the page, then I use an ID (things like #main_navigation, #global_header).
2: The DOM element is used for styling purposes (CSS) then I use class names. I keep class names as descriptive of what the DOM element is doing as I can. I don't use vauge names like .blue_text (explained below).
3: I need to attach some sort of information to the DOM element that is kind of awkward and doesn't fit this scheme, then I use custom HTML data attributes. For example, if I create a backend for a site and a user can pick a background color for a div, instead of putting .user_selected_background_color_class as a class in the div I will instead write data="user_selected_color". This is a kind of lame example, but I just built something where a user can select a bunch of images to be in gallery mode or slideshow mode and I used data attributes to determine how the container div should be styled.
When I see website starter code and examples, the CSS is always in a separate file, named something like "main.css", "default.css", or "Site.css". However, when I'm coding up a page, I'm often tempted to throw the CSS in-line with a DOM element, such as by setting "float: right" on an image. I get the feeling that this is "bad coding", since it's so rarely done in examples.
I understand that if the style will be applied to multiple objects, it's wise to follow "Don't Repeat Yourself" (DRY) and assign it to a CSS class to be referenced by each element. However, if I won't be repeating the CSS on another element, why not in-line the CSS as I write the HTML?
The question: Is using in-line CSS considered bad, even if it will only be used on that element? If so, why?
Example (is this bad?):
<img src="myimage.gif" style="float:right" />
Having to change 100 lines of code when you want to make the site look different. That may not apply in your example, but if you're using inline css for things like
<div style ="font-size:larger; text-align:center; font-weight:bold">
on each page to denote a page header, it would be a lot easier to maintain as
<div class="pageheader">
if the pageheader is defined in a single stylesheet so that if you want to change how a page header looks across the entire site, you change the css in one place.
However, I'll be a heretic and say that in your example, I see no problem. You're targeting the behavior of a single image, which probably has to look right on a single page, so putting the actual css in a stylesheet would probably be overkill.
The advantage for having a different css file are
Easy to maintain your html page
Change to the Look and feel will be easy and you can have support for many themes on your pages.
Your css file will be cached on the browser side. So you will contribute a little on internet traffic by not loading some kbs of data every time a the page is refreshed or user navigates your site.
The html5 approach to fast css prototyping
or: <style> tags are no longer just for the head any more!
Hacking CSS
Let's say you're debugging, and want to modify your page-css, make a certain section only look better. Instead of creating your styles inline the quick and dirty and un-maintainable way, you can do what I do these days and take a staged approach.
No inline style attribute
Never create your css inline, by which I mean: <element style='color:red'> or even <img style='float:right'> It's very convenient, but doesn't reflect actual selector specificity in a real css file later, and if you keep it, you'll regret the maintenance load later.
Prototype with <style> instead
Where you would have used inline css, instead use in-page <style> elements. Try that out! It works fine in all browsers, so is great for testing, yet allows you to gracefully move such css out to your global css files whenever you want/need to! ( *just be aware that the selectors will only have page-level specificity, instead of site-level specificity, so be wary of being too general) Just as clean as in your css files:
<style>
.avatar-image{
float:right
}
.faq .warning{
color:crimson;
}
p{
border-left:thin medium blue;
// this general of a selector would be very bad, though.
// so be aware of what'll happen to general selectors if they go
// global
}
</style>
Refactoring other people's inline css
Sometimes you're not even the problem, and you're dealing with someone else's inline css, and you have to refactor it. This is another great use for the <style> in page, so that you can directly strip the inline css and immediate place it right on the page in classes or ids or selectors while you're refactoring. If you are careful enough with your selectors as you go, you can then move the final result to the global css file at the end with just a copy & paste.
It's a little hard to transfer every bit of css immediately to the global css file, but with in-page <style> elements, we now have alternatives.
In addition to other answers.... Internationalization.
Depending of the language of the content - you often need to adapt the styling of an element.
One obvious example would be right-to-left languages.
Let's say you used your code:
<img src="myimage.gif" style="float:right" />
Now say you want your website to support rtl languages - you would need:
<img src="myimage.gif" style="float:left" />
So now, if you want to support both languages, there's no way to assign a value to float using inline styling.
With CSS this is easily taken care of with the lang attribute
So you could do something like this:
img {
float:right;
}
html[lang="he"] img { /* Hebrew. or.. lang="ar" for Arabic etc */
float:left;
}
Demo
Inline CSS will always, always win in precedence over any linked-stylesheet CSS. This can cause enormous headache for you if and when you go and write a proper cascading stylesheet, and your properties aren't applying correctly.
It also hurts your application semantically: CSS is about separating presentation from markup. When you tangle the two together, things get much more difficult to understand and maintain. It's a similar principle as separating database code from your controller code on the server side of things.
Finally, imagine that you have 20 of those image tags. What happens when you decide that they should be floated left?
This only applies to handwritten code. If you generate code, I think that it's okay to use inline styles here and then, especially in cases where elements and controls need special treatment.
DRY is a good concept for handwritten code, but in machine-generated code, I opt for "Law of Demeter": "What belongs together, must stay together". It's easier to manipulate code that generates Style tags than to edit a global style a second time in a different and "remote" CSS file.
The answer to your question: it depends...
Using inline CSS is much harder to maintain.
For every property you want to change, using inline CSS requires you to look for the corresponding HTML code, instead of just looking inside clearly-defined and hopefully well-structured CSS files.
The whole point of CSS is to separate content from its presentation. So in your example you are mixing content with presentation and this may be "considered harmful".
In addition to the other answers, another concern is that it violates the recommended Content Security Policy from MDN, https://infosec.mozilla.org/guidelines/web_security#content-security-policy
The justification they use is that inline javascript is harmful, XSS, etc., but it doesn't justify why inline styles should also be disabled. Maybe someone can comment as to why, but until then, I'll just rely on appeal-to-authority and claim: it's a security best practice to avoid inline styles.
Code how you like to code, but if you are passing it on to someone else it is best to use what everyone else does. There are reasons for CSS, then there are reasons for inline. I use both, because it is just easier for me. Using CSS is wonderful when you have a lot of the same repetition. However, when you have a bunch of different elements with different properties then that becomes a problem. One instance for me is when I am positioning elements on a page. Each element as a different top and left property. If I put that all in a CSS that would really annoy the mess out of me going between the html and css page. So CSS is great when you want everything to have the same font, color, hover effect, etc. But when everything has a different position adding a CSS instance for each element can really be a pain. That is just my opinion though. CSS really has great relevance in larger applications when your having to dig through code. Use Mozilla web developer plugin and it will help you find the elements IDs and Classes.
I think that even if you want to have a certain style for one element, you have to consider the possibility that you may want to apply the same style on the same element on different pages.
One day somebody may ask to change or add more stylistic changes to the same element on every page. If you had the styles defined in an external CSS file, you would only have to make changes there, and it would be reflected in the same element in all of the pages, thus saving you a headache. :-)
Even if you only use the style once as in this example you've still mixed CONTENT and DESIGN. Lookup "Separation of concerns".
Using inline styles violates the Separation of Concerns principle, as you are effectively mixing markup and style in the same source file. It also, in most cases, violates the DRY (Don't Repeat Yourself) principle since they are only applicable to a single element, whereas a class can be applied to several of them (and even be extended through the magic of CSS rules!).
Furthermore, judicious use of classes is beneficial if your site contains scripting. For example, several popular JavaScript libs such as JQuery depend heavily on classes as selectors.
Finally, using classes adds additional clarity to your DOM, since you effectively have descriptors telling you what kind of element a given node in it is. For example:
<div class="header-row">It's a row!</div>
Is a lot more expressive than:
<div style="height: 80px; width: 100%;">It's...something?</div>
Inline CSS is good for machine-generated code, and can be fine when most visitors only browse one page on a site, but one thing it can't do is handle media queries to allow different looks for screens of different sizes. For that, you need to include the CSS either in an external style sheet or in an internal style tag.
In-page css is the in-thing at the moment because Google rates it as giving a better user experience than css loaded from a separate file. A possible solution is to put the css in a text file, load it on the fly with php, and output it into the document head. In the <head> section include this:
<head> ...
<?php
$codestring = file_get_contents("styles/style1.txt");
echo "<style>" . $codestring . "</style>";
?>
... </head>
Put the required css in styles/style1.txt and it'll get spat out in the <head> section of your document. This way, you'll have in-page css with the benefit of using a style template, style1.txt, which can be shared by any and all pages, allowing site-wide style changes to be made via only that one file. Furthermore, this method doesn't require the browser to request separate css files from the server (thus minimising retrieval / rendering time), since everything is delivered at once by php.
Having implemented this, individual one-time-only styles can be manually coded where needed.
According to the AMP HTML Specification it is necessary to put CSS in your HTML file (vs an external stylesheet) for performance purposes. This does not mean inline CSS but they do specify no external stylesheets.
An incomplete list of optimizations such a serving system might do is:
Replace image references with images sized to the viewer’s viewport.
Inline images that are visible above the fold.
Inline CSS variables.
Preload extended components.
Minify HTML and CSS.
Personally, I think the hatred of inline css is just ridiculous. Hardcore cult behaviour, people just sheepishly repeat "Separation of concerns!". Yes, there are times where if there is a repeating element and you will need repeated styling to use a class targeted from a CSS file, but most of the time it improves speed of development and CLARITY OF CODE to put the style inline, it's great if I can look at the code and see that there is a custom margin height, it helps me picture the HTML document as a whole, instead of some named class that gives me little insight into which styles will be applied.
So I will be the contrarian here and say that inline css is great and that people who scream at you for using it are just following what they have been told without actually giving it any original unbiased consideration.
Even though I totally agree with all the answers given above that writing CSS in a separate file is always better from code reusability, maintainability, better separation of concerns there are many scenarios where people prefer inline CSS in their production code -
The external CSS file causes one extra HTTP call to browser and thus additional latency. Instead if the CSS is inserted inline then browser can start parsing it right away. Especially over SSL HTTP calls are more costly and adds up additional latency to the page. There are many tools available that helps to generate static HTML pages (or page snippet) by inserting external CSS files as inline code. These tools are used at the Build and Release phase where the production binary is generated. This way we get all the advantages of external CSS and also the page becomes faster.
In addition to other answers, you cant target the pseudo-classes or pseudo-elements in inline CSS
We have created a template-driven artifact generator that provides an include file capability for any kind of text artifact -- HTML, XML, computer languages, unstructured text, DSV, etc. (E.g., it's great for handling common Web or manual page headers and footers without scripting.)
Once you have that and use it to provide "style" tags inside your "head" tag, the "separation of concerns" argument goes away, to be replaced by "we have to regenerate after every change to the template" and "we have to debug the template from what it generates". Those gripes have been around since the first computer language to get a preprocessor (or someone started using M4).
On balance, we think the meta-izing capability of either a CSS file or "style" tags is cleaner and less error-prone than element-level styling. But it does require some professional judgment, so newbies and scatterbrains don't bother.
What should be written first while making CSS layouts XHTML code or CSS code?
Write Whole HTML first then write
CSS according to HTML
Write HTML for an design element and
CSS simultaneously
Write whole CSS first then write
HTML according to HTML
I read on this article's point # 7 "Create Your HTML First" is this advice best to follow?
Edit:
and in this tutorial author also write HTML First then write css using Edit CSS option of web developer toolbar i think this is best way.
In practice, you generally wind up needing to intermingle the two. Start out with HTML to rough out the basic areas of your design, then work in CSS around that rough idea. Typically you'll find yourself needing to add some more markup to allow for additional flexibility (perhaps you need a couple of nested containers to properly align something, et cetera).
I used to ponder about this long ago, when designing websites.
My conclusion was, and I believe it still stands today, that even though XHTML and CSS are meant to be isolated from each other as content and presentation respectively, the reality of the matter still makes the look of the website pretty much depend on the document structure - i.e. markup, XHTML - and thus CSS alone will not give you the magic wand to make your website change its look completely based on a stylesheet. I wish it were so however - certainly, that is the main purpose of CSS. And certainly, that would be the beauty of it - since each is completely isolated from the other, website developers can in peace of mind program the structure of the website documents, almost while the CSS authors can work in parallel and write the stylesheets. Then both are combined, and with the knowledge that the markup does not need to be changed ever again. That is the theory anyway.
In practice this often fails to work - because a document has a top-to-bottom left-to-right (usually) bound semantics, it becomes difficult to for instance, make an element appearing at the bottom of the document structure, appear at the top of the browser page to the user. The limitations work against the theory.
Because of the above implications, and some other real-world limitations of the CSS and markup technologies, I have decided to simply consider markup as something in between the content and the style. I.e. some of the markup will unfortunately dictate style, no matter stylesheet - the sequence of elements being one (see above), pagination limitations, etc - and so, while most of the structure may be isolated from its appearance, some of this appearance will be dictated by it. For this reason, if we don't regard client side scripting (which may aid styling by re-arranging elements of a document) - one way to do it is use XML as content, XHTML as content-style hybrid layer, and CSS to finally dictate the appearance.
Where does XML come into this? Well, you transform (either in browser or server-side) it with XSLT into a XHTML document, which you consider as relevant in the styling process. I.e. if you have an artist list of 1000 entries, and you want to customize how the page looks like, you use the following content XML:
<artists>
<artist name="Moby" />
<artist name="Cocorosie" />
<!-- and so on -->
</artists>
This is considered as an unchanging content, no matter the final style - part of the point of separating content from presentation, something you could not have done fully with XHTML because CSS cannot do certain things. With XSLT however, you can further transform the above into a desired markup ( you can then apply CSS to):
<xsl:transform>
<!-- XSLT is beyond the scope of this... -->
</xsl:transform>
will transform the XML into something like:
<h1>Artists</h1>
<h2>Page 1 of 10</h1>
<ul>
<li><a>Moby</a></li>
<!-- Only 100 artists per page -->
</ul>
And then you style it.
Bottomline is, you get to control each point of the transformation of your raw database content into final end-user application.
Much of what XSLT does with XML, can be instead done with JavaScript on XHTML, but I consider client-side scripting an addition, not replacement to things like XSLT. Then again, Firefox and most other modern browsers can do XSLT client-side, which blurs the distinction between scripting and document serving.
I think it's a mistake to do one before the other. Programming is an iterative process. Write them both until you have something small that works, then do it again. Build on it. Iterate.
If you write just HTML without writing any CSS, you'll find out later that you'll have a bunch of technical debt that needs to be paid off.
It really depends how big is your site... If it's a small website the order doesn't matter. If it's a big website i generally design basic structure in HTML then basic CSS and then move to details in HTML and then CSS.
Few advices.
re-use already made CSS and HTML.
ie. if you already have template
with basic HTML wrappers save it
for the next project or page or
if you set all images to
border:none in your CSS you can
easily save some CSS file with
basic settings
see an object in your head before
designing it
check in 5 major browsers (ie6 ie7
ie8 chrome and firefox)
I usually go with the second option:
Write HTML for an design element and
CSS simultaneously
This really helps, for example, when I am writing html, i write the CSS along the way too which helps me quickly spot any possible layout or cross-browser compatibility issues. If i wrote whole html first and then css, then things become little complicated and you have hard time correcting/styling the entire html which you already created.
As for the link you provided, i would simply say author has his own view and personal way of working. In other words, this also depends which way you are most comfortable with or rather fast.
You can't write CSS before writing the HTML (except for the body tag!), or you'll be working like a blind.
For me, I make a mock-up of the website layout, write down the whole HTML and then write CSS that just makes the layout.
I use Expression design to slice images and add/modify HTML/CSS until I get the final template.
I don't like the idea of going back and forth with code. If I'm at #header in html, it seems pretty logical to me to stylize the header right now. Is good for my mental sanity :D
So I go with the second option: I wrote code simultaneously.
You have to write HTML before CSS.
Your question is like, Is it better to design a car Interior, before having a car ?
Is it possible ? or Is it a intelligent work ?
Given that most designs are not simple, and following basic semantical rules, you will always need to adjust the html code when trying to get the layout looking as you have in mind. So doing both simultaneously is probably the most pratical way, although the other two options work as well; You just need to made adjustments then later.
Sorry , I am not choosing anyone of these..
In first you can't able to write the whole css for your page. although it's better you should write the common css classes and page layouts in the first.ie, after creating the page layout , you just design the page using table or div tags. after , while adding controls to the pages , you just identify the common styles u are using. These styles you can use like css classes. or seperate id. I am following this method for my designing.
i think its better.
By creating the HTML first, you can guarantee what the page will look like on the most basic browsers - it'll be legible on an old phone, everything's in logical order, and you aren't forcing screen readers to recite your site navigation first thing on every single page. That's design #1.
Design #2 is the CSS part, where you actually make things look visibly decent without limiting your user base.
Not that they can't be done simultaneously, mind. Just that's most likely what the author of that article was trying to get at.
See also: Progressive Enhancement.
I personally write much of the CSS first, then HTML, then tweak the two together - one page at a time (apart from common elements). At first it sounds counter-intuitive, but when you think of the CSS as not only styles but as elements that either have a style or have a style of nothing, it's actually very fast and produces lean code.
Once I've got some core styles in place, the HTML is just a question of...
<wrapper>
<div header>
<div this>
<div that>
<form>
<div footer>
... and it all slots roughly into the styles and layout that I've already defined. For elements that needed no styling, I just mentally skipped over when writing the CSS.
My 3 cents:
What's the goal of the webpage? Most of the time that goal is strongly related to it's content.
Thus, the first thing is content. HTML gives content gets it's semantics. CSS gives the semantics a context.
So the order:
content
html
css
But of course, it's an iterative process.
I write them at the same time, iteratively, in modules.
I will build out the general template (or base template) in html/css, do a full cross-browser test, then move on to the additional templates.
This fits in well with .net where I'm using master pages and nested master pages.
I may change this behaviour once IE6 is off the books, as you often have to completely restructure your markup to accommodate it.
I'd go with the second option. HTML in todays web dev is seen as a template to hold content. CSS should be used to format the layout and content within the web page.
Because of this, HTML and CSS should be used parallel in creating web-pages and individual elements.