views:

601

answers:

10

I tend to take the academic approach all too often and adhere to strict principles in my development when the reality is that I could have finished the project sooner had I been a little less cautious. I'm looking to find the right amount of practicality.

I want to take the "Zen" approach to designing a site which (in my words) says "Use HTML strictly for content structure, and let the CSS magic do the rest". How practical is this in reality? One of the issues I run into is that I want to develop (make functional) the site first, then come back in and design it later. I know structure-wise how I want the site to flow, but I haven't even begun playing with the CSS layout, graphics, or any of the other designy stuff. What is the right approach here?

A: 

In theoria yes, in practice, browser differences may force you to add a bit of javascript to deal with the differences.

Keltia
this is terrible! what if the user has JS turned off? layout should be entirely CSS driven (and I have not yet encountered a situation where this could not be achieved)
annakata
I know that it should be possible. My experience on the field is that theoria rarely wins...
Keltia
Then I think you should be posting the problems as questions here and letting SO solve them. there's a lot of smart CSS guys here.
annakata
Example for annkata: make a div 50% of the parent div width and 10 px border. People who do entirely CSS driven layouts simply prohibit everything that CSS cannot express. This mental restriction works well for programmers, not so well for designers.
buti-oxa
"prohibit everything that CSS cannot express" meaning what? Many people seem to think that some layouts can only be done with tables, not CSS. This simply isn't true.
roryf
careful what you ask for :P - div {width: 50%; border: 10px solid black; } I know what you mean to say though (alluding to mixed percentages and fixed units) and even that can be achieved with margins or paddings or approximation or in the worst case scenario more markup than desired.
annakata
If you know know what I mean, why do you give me incorrect answer? Try our div in narrow window and see how it takes more than half the space. I am not aware of a solution w/o additional markup.
buti-oxa
+21  A: 

It's absolutely practical, and provides infinite benefit. In fact it's exactly what CSS and the separation of content and layout is designed for.

The right approach given the above, is to let different teams get on with the different tasks at hand. That requires (perhaps) an initial graphic design which can be quite rough, and a documented and collaboratively agreed set of naming conventions for things like "#viewport", ".user" etc..

The markup team will usually be backend driven and will usually lead the design team slightly, but they should and must remain flexible enough to change markup where required, or put that in the control of the designers.

This last is just my $.02, but where one person is both roles, again I think you lead yourself with the markup/backend first and then iteratively go to a design stage, then markup, then design, as required.

annakata
Good answer - but I'd take issue with "infinite benefit"
Sam Meldrum
"boundless"? My read is it's divide by zero of benefit/pain which is pretty much the inverse of inline styling
annakata
"I don't want to know what something is *designed* to do, I want to know what it *can* do" - Gene Kranz (Apollo 13)... There is always one browser to screw you up. And you know what it is.
Senthil
+2  A: 

Sure, you can do that, but be prepared that it WILL NOT render under IE. On a recent web project, the majority of our front-end defects were fixing stuff in IE that already worked fine in Firefox. Maybe this will change in IE8, but I doubt it. In some cases we even had to write some javascript that would be executed on IE only to work around things that couldn't be done with just CSS.

Ed Griebel
It will render, with knowledge and patience.
Nick Sergeant
Agree with Nick, the more you work at it the less effort will be required to fix the issues. And IE8 WILL fix a lot of them.
roryf
This is just a matter of experience and/or hiring better front-end devs - it *is* possible
annakata
@annakata - There are some corner cases, where things are very difficult do with just XHTML/CSS that will work in all browsers without redesigning the UI, especially in IE6. Just like using tables for layout, at some point you need to be pragmatic, especially in business.
Ed Griebel
+3  A: 

It can be very practical and you will be suprised how clean your HTML looks. I like using a CSS reset file to help get started, I personally like the YUI reset. Another Zen item to consider is the use of unobtrusive JavaScript. This further separates the different layers of your code. JavaScript libraries, like jquery, prototype and dojo can help with this.

Brian Fisher
nice links - google "Erik Meyer reset" for an alternative CSS reset
annakata
+3  A: 

It can be done, and I think your site (and your web design skills, not least) will be much better for it. But it also has a certain learning curve. It requires a more thorough understanding of the XHTML/CSS specs than many people have.

Making sure your HTML can be validated is just the beginning. Oh, and make sure all browsers run in strict mode when rendering the page.

Of course, you will require workarounds for IE support, but that can be done with several methods. First, IE supports conditional comments, allowing you to include special CSS stylesheets just to fix IE bugs, which should get you most of the way, without affecting your compliant standard-version of the page.

For some things, you may need a bit of javascript as well, but it shouldn't be necessary for most common functionality.

jalf
+1  A: 

One approach that works for me is to structure the HTML first, then add some minimal CSS in a tag in the same file (just enough to create the right layout etc). Then once you're happy with the structure, you can pull the CSS out into separate files and / or completely rework the CSS. This strikes the right balance for me - it's still a lightweight process, but it avoids the potential headache of finding and replacing inline CSS.

+4  A: 

The approach you want to follow is the right one. Just two things:

  1. If you use a validator for css or html, don't pretend that all your html or css pass the test. Obviously the ideal goal is that everything validates, but at a first stage I think is better not spend a lot of time in validation issues. And remember that no one validator is perfect, and the good way to use it at the beginning is to guide you in the right direction and avoid big mistakes (i.e. put the same id twice in one page, or put block elements inside inline ones...). Then, when the application is at a good stage, you can make your css and html perfect and valid.
  2. Don't design the interface at the end. I think that the interface of the application can give you good directions in how develop your back-end too. So, at your place, I would design the interface first, with html and css, and then I'd start to add functionality to it.

(Sorry for my english, spelling corrections are welcome.)

alexmeia
+1 for point #2, not enough programmers are driven by the "user-story" and how the product is actually going to be used
annakata
you are right. I started working as web designer before becoming a developer, but a lot of my coworkers see the interface just like the annoying part of the application.
alexmeia
+1 for the first point. But I don't quite agree with the second one. There *are* people who start with a simple layout and improvise AND come up with awesome websites (it includes yours truly and co. :D) And for annakata - think startups. Your observation may be true for web dev shops the size of EA or something.
Senthil
When I say "don't design the interface at the end" I mean that is better to start by thinking about the functionalities and actions of the interface, so that you can think about the interactions of the user with your software. A very simple layout - or a mockup - is perfect for this. You don't need to create an awesome interface - may be a good graphic designer can do this.
alexmeia
+2  A: 

while it sounds good in theory you cant create the layout for a site 100% with css. You still need to use some markup so that you have something to apply the css to. That said, you can come fairly close to ideal using this method. I'm constantly amazed at how little markup a true css guru actually requires.

closer the "zen" approach that you are really looking for is xslt. it works by your app generating xml data and then the xslt transforms that xml into html/css. this requires learning xslt and adds another layer of complication to the process of generating a page, but adds the separation you are looking for. In an ideal world the theory is that a programmer only has to worry about generating xml data and then a designer can generate the visuals using that data, however it rarely works that way as xslt is more technical than most designers can handle. Most of the time the programmer ends up generating the xslt which somewhat defeats the purpose.

mike
+3  A: 

There are reasons explained in http://www.webdevout.net/articles/beware-of-xhtml against using XHTML today. To summarize, XHTML is not supported unless you serve it as such and if you target older browsers (any IE version is old considering most of its features are implemented when they were still immature and not changed substantially for a while) you have no choice but serve it as HTML.

Unless you don't require features that being XML provides (like SVG, MathML), stick with HTML. You won't have any serious advantage over HTML, be any more semantic, have better CSS support (even less). But you get wider compatibility and your layout will be more predictable (for example table cells can inherit from first cell in the row in HTML, no such thing in XML, not even sure XHTML has any exceptions somewhere).

Validators won't help writing XHTML any more than HTML. Even annoy, if you use a strict one, leaving you wondering what is all the fuss about / in the br tag if you lie and say it is HTML. (Firefox view source shows it bright red if you serve XHTML as HTML). I am sure you can find more examples.

artificialidiot
A: 

Now... Benefits of something is different from practicality of doing it. Are you guys forgetting IE or even the pain-in-the-whatever client who wants the impossible done?

I am tempted to say you have to make some exception to the strict DTD that you are using to make it work in a reasonable set of browsers and please your stakeholder for the website/web-app.

I am a standards freak and no one would be more happy than me if it was possible to build a website that doesn't violate even 1 DTD rule. But after 4 years, I just haven't been able to do it for practical purposes.

Sure if I am the one coming up with the requirements for the website I am going to develop, it might be possible, but I have to bend the business rules to accommodate that. Believe me, that's the only way it is possible.

Senthil