Slashdot Mirror
10 Best Resources for CSS
victorialever writes "Since one could have noticed an increasing number of websites that are employing CSS and an increasing number of resources talking about how great CSS is, it seems to become impossible not to jump on the CSS bandwagon as well. The 10 Best Resources for CSS provides an impressive list of the CSS resources which have recently become essential for web-developers. Among them - CSSZenGarden, The Web Developer's Handbook, Stylegala, PositionIsEverything etc."
It's still easier to do certain things with table-based layouts than it is with CSS alone. Control of vertical positioning/height being the obvious one. That and fluid layouts.
If you're a busy designer, sometimes you just have to take the pragmatic route rather that waste hours or days trying to make a pure CSS layout work across all the common browsers (none of which implement CSS 100% correctly anyway).
Either that or (worse) you compromise the design to make it fit the limitations of a pure CSS layout.
I think the latter approach accounts for the huge number of 'identikit', bloggish-looking sites out there (all proudly displaying their little W3c validation logos of course).
It's still perfectly possible to create valid, semantic XHTML/CSS markup that uses the odd table for layout (no, I don't mean a heap of nested ones with spacer gifs!).
While I'm all for standards and separating content from presentation, at this stage of the game, we just need to choose the solution that works best.
I know it's probably heresy to say this, but IMO tables work in an intuitive way that you can easily visualize whereas a mass of floated DIVs often do not!
A lot of other CSS sources are already being quoted now, better start bookmarking this /. article then.
My wife's sketchblog Blob[p]: Gastrono-me
Structural markup is the essential differentiating factor, not just that you have found out how to replace tables with divs ...
</rant> over.
Rich.
libguestfs - tools for accessing and modifying virtual machine disk images
HTML is not a semantic markup language, hijackers in the W3C not withstanding. It's a rich text markup format. It always has been. XML is (well, can be) semantic markup, and if you really want to store your pages semantically, use XML (with no styling at all), and transform them with XSLT. Dispense with the ridiculous concept of "semantic HTML", which is useless in practice and almost useless in theory, and try using the correct tools for the right job - XML for storing your content, and HTML for presenting it.
Those of us who have been dealing with CSS for several years have no problem at all visualizing the layout. The big question here is, how do you visualize YOUR layout when you can't have images loading? How do you visualize your table layout on a cellphone? How do you visualize your layout when you cant visualize anything at all... for example if you have low vision or no vision?
Maybe instead of thinking about getting the job done fast you should consider getting the job done right when you're doing your estimates.
Have a good one!
This post brought to you in semantic XHTML.
"The need to build the internet comes from something inside us, something programmed... something we can't resist."
there's some serious advantages - like the fact that all major and most minor browsers will render them identically, that they're far more intuitive, and that they allow re-flowing in a way that you can only do with CSS attributes that are explicitly designed to mimic the layout algorithms of "traditional" tables
If you really believe all of this, then I don't think theres hope for you... unless you define "major and minor" browsers as "IE". Tables get rendered differently by different browsers, just like CSS gets rendered differently.. the only thing is that it's easier to work around CSS bugs
CSS is *WAY* more intuitive than tables ever were (and there's a reason - because it's designed that way.) You use DIVs to define blocks of code, then use CSS to say how you want them positioned. With tables, you have to screw around with row and column spans *in the HTML itself*.
It's pretty obvious that you prefer tables because you've spent a lot of time learning their quirks - don't slam CSS just because you don't know how to use it properly.
try using the correct tools for the right job
If you really believed this, you'd be using CSS.
I've been using CSS for many years. I've been using tables for many years, too, but don't mistake the fact that I'm aware of deficencies both in the CSS stndard and in it's imlpementations for a lack of knowledge. And the fact that you're telling me I need to use blocks of DIVs to layout my stuff is telling me that you're just another blind herd following CSS monkey, rather than anyone who can actually evaluate the usefullness and appropriateness of claims like "semantic markup". There's no excuse for telling someone to replace thier tables with divs "just because".
And just because you managed to find some stylesheet on a CSS site that you use blindly to work around certain CSS bugs (no doubt without realizing that the stylesheet itself relies on other bugs to work correctly, and the widespread reliance on these bugs is a major obstacle to the uptake of correct CSS implemetations in IE), doesn't mean that CSS incompatibilities are easier to work around than the practically non-existant table ones.
Yes, there is. You can do it with CSS tables. Internet Explorer doesn't understand them, but we're talking about the capabilities of CSS, not the capabilities of Internet Explorer, right?
In any case, there's very few instances where a parent-child relationship isn't available to be used in this way. That's just the nature of web pages - things that are visually related tend to be structurally related too.
That's not a very good example; in both cases it usually requires drastic alterations to the page structure.
Come off it. Typical table layouts would need way more changes than that. I've made this change quite a few times to various websites of both kinds. The CSS websites, I've had to rearrange a couple of <div> elements and change a single stylesheet. The table websites, I've had to completely rework dozens or hundreds of pages, depending on whether they were dynamically generated or static.
Rubbish. Float the first column over to the side, set percentage widths on each column, and clear the footer. That's not "a huge amount of CSS hackery", and it's even easier if you don't have to support Internet Explorer.
That's what min-width is for. I don't think table behaviour at extreme sizes is very intuitive at all, and I think it's just a convenient distraction - how many people actually need to resize their window to extremely small sizes and keep the layout intact?
You are being ambiguous. Did you mean fixed width?
Unless you are an Internet Explorer developer, you'd better back off on that point, because they have posted on their weblog that they are going ahead and fixing CSS 2 selectors anyway. So it's not an obstacle and it looks very much like you've just made that up.
Bogtha Bogtha Bogtha
Well you don't start out with a complicated example when you learn other stuff, do you? Back off on the corporate intranet pages and do a few simple layouts to begin with. Once you're familiar with the basic concepts, it'll be easier to move on and do more complicated things.
Experience with tables doesn't translate to experience with CSS. You aren't experienced, you are a newbie as far as CSS layouts are concerned.
What are you talking about? "Semantics" means "meaning". If you are using element types that mean something (as opposed to element types that just give a particular visual effect), then you are using semantic HTML. HTML has had semantic element types since the very first version.
People keep saying tables are intuitive. They aren't. You've just been using them a long time. Lots of rowspans and colspans aren't intuitive. Spacer gifs aren't intuitive. Superfluous closing tags aren't intuitive. It's all just stuff you've memorised. Of course something new is going to be at a disadvantage if you are assuming that you are going to be just as good with the new stuff even though you haven't built up this experience first.
Bogtha Bogtha Bogtha
There are exception like Patrick Griffith's "Elastic Lawn" http://www.csszengarden.com/?cssfile=/063/063.css& page=0.
Scales rather nicely when you adjust the font-size.
Presentation is not *more* important than content, but it certainly *is* important.
I expect you'd prefer all websites to present raw information in an unbroken screeds of text, without paragraphs or columns, in 14pt black Times New Roman.
Whether you care or not, for the vast majority of people good, attractive design matters (if only subconciously) and is as much a part of communicating an idea as text is.
The majority of the CSS Zen Garden designs have cross-browser support.
Table layouts have no support for user-defined styles.
Whether a layout works with overridden text size or has a fluid layout is not something that is different between table layouts and CSS layouts. Both can break, both can work. It's whether you assume a certain text size or canvas size when laying things out that makes the difference, not whether you use CSS or tables.
I missed your point there. Can you restate it?
Huh? Maybe you could get it to look similar under default settings, but it wouldn't work the same - and I thought you just said user-defined styles, overridden text size, different window size and cross-browser support were success criteria? Image maps and Flash presentations can't acheive all that.
Bogtha Bogtha Bogtha
Just write a plain HTML page, something that would look ok and be readable without CSS. Then add div:s and CSS.
The result is a page that separates content from layout and works well both with and without CSS. It will also be easy to replace the CSS when you need to. This is also useful when you have different style sheets for different media. Have a "print" style sheet that excludes the sidebar and uses different colours.
He was also complaining about designs that did not handle resizing of text very vell. And very common "webdesigners" tries to lock the users to one font-size and the layout breaks horrible if one tries to resize the text. So yes, the layout I linked to is an exception to that rule. Even a layout that uses the whole width can break when the text is resized.
So for me a design that doesn't break in diffrent font-sizes is more important than one that uses the whole width.
You don't code a site in CSS. The content still uses HTML.
The CSS styles that content.
Instead of div hell you should code the content using semantic blocks: headings (to introduce sections of the page), lists (for lists of items), forms, paragraphs (for most of the normal content), and tables (for your tabular data)
I scanned the article quickly, and did not find a CSS validator on the list. This is a useful tool for CSS novices such as myself.