Slashdot Mirror
CSS Turns 10 Years Old
An anonymous reader writes "Cascading Style Sheets celebrate their tenth anniversary this week. The W3C put together the CSS10 site in recognition of this milestone with a Hall of Fame, essays from the past decade, a gallery, and more." I was glad to see the CSS Zen Garden selected for the Hall of Fame, and disappointed (but not surprised) that no browser on my computer correctly renders the Acid2 test.
Time to get a new computer.
Here's a list of ACID2 compliant browsers. It's longer than one might think.
Javascript + Nintendo DSi = DSiCade
...and we're still waiting for a complete CSS2 implementation. Though to be fair, CSS2 is only 8.5 years old, and has been undergone a couple of minor revisions. I've seen good comparisons of browser support for CSS2 and CSS3. Anyone know of a good summary of current browsers' CSS1 support?
Is it just me, or is it a little ironic that the page that celebrates 10 years of CSS is so bland looking?
I was ... disappointed (but not surprised) that no browser on my computer correctly renders the Acid2 test.
You're clearly not using a mac.
--
PNG was almost 10 years old when IE finally supported it! Maybe this means that IE8* will have CSS! Hurray!
*IE8 is expected to debut sometime in late 2018.
I'm not up on the finer points out the definitions for "nerd" and "geek" but it would seem to me that if your first thought about a core web technology like CSS was about Counter Strike your more likely to be a loser then a nerd... maybe a nerdy loser.
Uh oh
#navigation li Invalid number : text-shadow Property text-shadow doesn't exist : 0 2px 4px #000
Zing!
CSS10? But IE still doesn't have CSS2... aha! It's a binary joke! I get it now! There are 10 kinds of browsers in the world: those that implement CSS properly and those that don't.
The sad part is, Safari can pass Acid 2, but last I checked, it didn't handle onload image event contexts properly. Sad.
Hey, and maybe in another ten years we'll have a position system that works reliably across browsers and can survive the window being resized, the dpi being changed, or the font being enlarged. Other than tables I mean.
I did the CSS -showcase thing a few months ago and about 10% of the layouts by the CSS Masters of the Universe fit the above criteria. It may not be impossible, but the bar's too high.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
In case you didn't, here are a few examples.
The point of the site is to illustrate how the exact same HTML file can be displayed in an infinite number of ways by simply changing the CSS. The site is essentially an argument for a semantic Web.
Schwab
Editor, A1-AAA AmeriCaptions
I can't wait either.
They have yet to convince me just how they are going to make the table obsolete, every time you turn a corner you are hearing from CSS users (including myself) the end of the table is near, don't use the table, I think the real question ought to be why not use the table, besides the lag, the complications with non css table layouts actually tend to go down in my experience. Yes I could spend 2 days figuring out why the div layout is being difficult and use CSS hacks to make it cross browser, but in the long run the div/css layout has a lot to work on before you see it being adopted as anything more than a side note for those who want to show off their skills. Right now CSS because of its major lack of vertical control is far less stable than the table structure, yes we are told you should burn in hell for even thinking of using tables, but on the end note it works, and quite frankly If I am going to get more stable results at the the price of not promoting the great CSS, than I can get over it. I am glad CSS has had 10 years and a congratulations are in order for them, but please if you are going to promise the end of an era or style try to make sure you can back it up with proof like the decline of nearly every major dynamic web software relying on tables to ensure stability (with CMS's trying to move to the div, the BBS stuck in a rut because css/divs just don't seem to help do them well
Did someone say cake?
Believe it or not, some graphic designers / typographers actually know what they hell they're doing; and they've been schooled to use typesetting to as a communication tool that can actually increase comprehension, legibility, reading speed, etc. Yet I can't necessarily say thats all, or the majority, of "graphic designers."
That said, yes, properly styled and typeset text needs to live and accessible. It's currently not (at least in any practical form), and that's the problem.
"Things are more moderner than before- bigger, and yet smaller- it's computers-- San Dimas High School football RULES!"
The artists DID have control for a dark time in the mid-to-late 1990s, when the Internet bubble was in the earliest stages of inflation. I like to call it the "JPEG Jigsaw Puzzle Age" of the WWW.
While I think that CSS is far from perfect (it WAS, ironically enough, inspired by a concept from Microsoft after all) I do in fact find a properly-written CSS-formatted HTML page much EASIER to follow. Back in the dark JPEG Jigsaw Puzzle age, when trying to view or parse HTML source, it was cluttered with FONT-this and IMG SRC="spacer.gif"-that and TABLEs inside TABLEs inside TABLEs containing image maps. It was absolutely DREADFUL. And no, nested DIVs are NOT the same as nested tables, because tables have rows and columns and are meant for TABULAR DATA--NOT for general structuring of content. DIVs get no more complicated (from a content perspective) than simple nesting, whereas TABLEs have specialised TR collections within them, which in turn have TDs...and COLSPAN and ROWSPAN even further complicate and confuse when used for layout purposes.
CSS is more than a formatting tool--it enables content and presentation separation as well as semantic web design. The web would be beautiful but completely unusable GARBAGE if artists were in "full control". Similarly, the web would be efficient and powereful, but ugly and arcane if programmers were in "full control" (that is, we'd probably still be messing with Gopher, Archie, WAIS or similar powerful but ugly and/or user-unfriendly systems). If the artists and programmers could cooperate properly (and development tools that make use of CSS and HTML standards more effectively enabled such cooperation perhaps) then we get balance between effective presentation and functionality.
I suppose the biggest problem with CSS, beyond inconsistent interpretation of CSS by various browsers (which isn't CSS' fault) is that it is far too easy to mis-use it, and most CSS isn't properly or effectively used (probably because artists are trying to control it
A properly designed XHTML-and-CSS page is absolutely beautiful to behold: It is attractive yet simple to navigate. It is accessible (it degrades gracefully in audio and text-only browsers, and there is no need for "printer-friendly" links--ever--so get rid of them--NOW). It is easy to manage (don't like the way it looks just change the CSS, and if you need to update the content you can do so in the XHTML with virtually no effect on presentation). It is easy to parse and very human-readable (if you properly name your elements that is--use id="navigationMenu" instead of "toprightblock" and class="articleName" instead of "bigboldblue"). Without all that TABLE/TD/TR/IMG SRC="spacer.gif"/FONT/blah blah clutter in the HTML you can easily see the document structure, links, etc...and without all the
blahblahblah
Sorry...had to get this out...sometimes I can't resist a troll...
Nice to know that not even W3C can afford to spell check everything: teached CSS. It's not just /. editors! :)
No.
No.
No it doesn't, it's clear already.
"Relying on the preceding line"? It does no such thing.
"Well relative to what" - simple answer - the closest parent element / DOM node with absolute position.
If no elements have had position:absolute explictly declared, the overall canvas (body element) is assumed instead.
The fact you see both doesnt (necessarily) mean they "can't make up their own minds", it means they (we) know there is a time when either might be best, and use them accordingly.
It depends. Is the padding on the element something which should grow and shrink with user text resizing, or is the element something which is of a fixed pixel size, (eg) something designed as 'chrome' like a rounded corner or combination of background images which have to line up pixel accurately to maintain the illusion of the overall interface.
Something like line-height is better specified in ems, since you want it to remain proportionate to text size. Arguably, something like column width is too. Although this a grey area of compromise between demands of the client, purism of the designer, legal requirements of accessibility, practical requirements of browser support, etc. Hence, using both depending on where the compromise line is made.
See above; your impression is simplistic, sometimes pixels are used, other times ems are a more appropriate unit (to create liquid layouts which can adapt to user text resizing - which people may set to remain comfortable reading on small/huge monitors, if they have vision impairment, etc. Still other times percentages of parent elements are appropriate.
You seem to be talking about .classes and #ids. Albeit you get it a bit mixed up: document.whatever looks like javascript DOM speak, but there is no document element in CSS; you use elementname.classname hence div.newsitem or a.external or ul.shaded li.odd. Non-intuitive? All you've got to remember is "." means class and "#" means ID. How hard is that? Of course it's not intuitive but what is? The dozens of reserved symbols and tokens in any markup or programming language from HTML to C far outstrip the "confusion" of .class vs #id.
If I had any remaining suspicions that you worked in the professional web design field (which I didn't), you'd have just shattered them for good. Even forgetting any co