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?
Are you on acid?
Apples Safari has been able to render Acid 2 for more than a year now.
- - -
http://mil.int.gov.edu.org
Slashdot's advertisers STILL CAN'T GET IT RIGHT. I just saw a CSS error, in Firefox 1.5, that disappeared with a reload. Obviously a top of screen banner ad went bad.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
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.
Is like technology growing old all around me. 2002 is like the year I started with Wiki, and now looks almost like the good old days. ....
Dont let me start with 1995 and my commodore 64 computer
-Woof woof woof!
http://www.w3.org/Style/CSS10/ first link points to the press release and the CSS Hall of Fame is worth visiting, too!
It was about ten years ago that I saw Hakon present CSS to some of the engineers and product managers at Netscape, where I was a technology evangelist. That was a great moment in my career, where I knew how much trouble we had with the rendering engine as well as how much responsibility we had to fight the good fight for standards.
Thanks to Hakon and Bert, congrats to the w3c, and keep on on styling your designs!
My opinions are my own, but you may share them!
Yay, yet another bunch of web pages with light grey text on white background! Just what the world needed.
Come on guys, it might be valid CSS, but it is not easy on the eyes.
Uh oh
#navigation li Invalid number : text-shadow Property text-shadow doesn't exist : 0 2px 4px #000
Zing!
Håkon Wium Lie
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.
Ok, guys, the "Age of the Tables" is officially over. Let's start using divs! (Correctly, please).
-- The TekWiz
Before CSS, we had formatting with nested tables. After CSS, we had formatting with nested DIVs. Big deal. Plus absolute positioning, the big mistake. And layers, which are 10% useful and 90% annoying ads.
Of course, now we have more "abstraction". Yeah, we have a macro system. Big deal.
The real effect of CSS was to make web layout more complicated, so as to keep a role for programmers in web design. Otherwise, the artists would be in full control by now.
I'm sorry, but I can't wait until my options for web type are more then the font tag, a crappy style sheet, a picture that looks like type, Flash, or some sort of odd embeded media option that a only fraction of people can view. I hope by the time Slashdot posts "CSS turns 20" we've finally embraced our SVG overlords, or some sort of superior vector graphic solution.
Even if browsers were to finally properly support tracking, x-height controls, etc., CSS is still obnoxiously rudimentary in comparison to the typesetting tools that exist for static type. Hell, it's been over a decade and there is still no widespread adoption of a way to embed an f'n typeface in cross platform / cross browser way that does not annoy everyone. ugh.
"Things are more moderner than before- bigger, and yet smaller- it's computers-- San Dimas High School football RULES!"
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)
Do any browsers really do CSS right? Firefox is missing drop shadows and IE7, Safari, and Opera still don't center content correctly all the time. Still things are a lot better than with older browsers such as IE6.
I wish the standards would be realistic and just realize that no browser is ever going to be 100% perfect in how it renders a page and that in some cases the standard isn't going to be perfect either. I hate to praise IE but IE has a way to only load certains stylesheets for IE or even certain versions of IE. It'd be nice to see that built into the standard so it'd be easier to make minor tweaks for individual cases. If you can specify the stylesheet's media then why not browser? Heck, I like to switch stylesheets based on window size even so why not make that possible also without resorting to Javascript (which results in a minor jump as the page loads and changes stylesheet). Like print stylesheets, few developers might use such browser or size optional stylesheets but for those of us who do it'd make things easier for us and nicer for our users.
Overall, I love CSS though. It allows me to vary the look of my sites a lot and to do things that look good without requiring plug-ins like Flash and without making pages unusable for the disabled. I can't wait for the additional features of CSS3.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Is that some kind of server room safety equipment? And what's NFL? Is that some new kind of filesystem? Don't just tease us with these mysterious new IT related products, give us the details!
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
And here I thought that CSS meant Content Scrambling System(This is the 10th anniversary of CSS btw) which isn't a great thing to celebrate since it was cracked in a three years.
Perhaps it's not as obvious as it should be, but the point of the CSS Zen Garden isn't the default stylesheet (the grey-on-white colour scheme you mention).
It's actually a gallery of very different styles, including quill pens on parchment, urban tagging, and even one that looks like an old-time movie theatre with scrolling credits.
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?
Some browsers may pass the acid2 test, but does acid2 pass the Slashdot test?
Please correct me if I got my facts wrong.
Wow! CSS has been son incredibly inconsequential, that I have gone 10 years, running income-producing web sites, with no CSS, whatsoever. That's pretty amazing, when you think about it, that CSS has made such a lack of impact.
Trying slashdot.org on article's link http://www.w3.org/Style/CSS10/
.yui-ac-content Invalid number : border darkgray is not a color value : 1px solid darkgray3 8
3 8 .details .details .details .details ...etc
18 December 2006 - Fuji CSS Validator released (more) http://jigsaw.w3.org/css-validator/
--
W3C CSS Validator Results for http://www.slashdot.org/
Sorry! We found the following errors
URI : http://images.slashdot.org/base.css?T_2_5_0_138
16 h1, h2, h3, h4, h5, h6 Invalid number : text-shadow Property text-shadow doesn't exist : #000 0 0 0
176 Invalid number : min-width Property min-width doesn't exist : 0
178 Combinator ~ between selectors is not allowed in this profile or version
345 div.storylinks ul li.comments Invalid number : text-shadow Property text-shadow doesn't exist : #000 0 0 0
638 div.storylinks ul li.bin Invalid number : text-shadow Property text-shadow doesn't exist : #000 0 0 0
659 a.ac-source Invalid number : background-color darkgray is not a color value : darkgray
668 #ac-select-widget Invalid number : background-color lightgray is not a color value : lightgray
674 #ac-select-widget input Invalid number : border lightgray is not a color value : 2px solid lightgray
688 #ac-choices
URI : http://images.slashdot.org/slashdot.css?T_2_5_0_1
15 a#newuser Invalid number : text-shadow Property text-shadow doesn't exist : #000 0 0 0
Warnings (224)
URI : http://images.slashdot.org/handheld.css?T_2_5_0_1
17 Same colors for color and background-color in two contexts #logo h1 a and #slogan h2
26 Same colors for color and background-color in two contexts div#links div.block div#links-sections-title and
26 Same colors for color and background-color in two contexts div.block div.title and
26 Same colors for color and background-color in two contexts div#links div.block div#links-sections-title and
26 Same colors for color and background-color in two contexts div#links div.block div.title and
No, if you are thinking of the <div> element type as a replacement for the <table> element type, you're still doing it wrong. Moving to CSS isn't about replacing <table> with <div>, it's about using the most appropriate element type for the job. You only use <div> when there isn't anything more appropriate (there usually is).
Bogtha Bogtha Bogtha
Safari could not open the page "http://www.webstandards.org/action/acid2/" because the server stopped responding."
Thanks, slashdot!
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...
Here I am with mod points and I am frittering away my time to use them by replying to this.
CSS... Ah yes the grand attempt to make HTML more usefull. It has been somewhat successful, but thats the problem then isn't it, its only somewhat successful, and all of the finer points that would make web sites really functional are left to chance.
My basic problem with CSS is that in its laudable attempt to make something from a thing that was never meant to be what it has been twisted and shoe-horned into, is that no one will call a rather well polished turd, well, a turd.
CSS at best is marginaly comprehensable. The Documentation is horrible. The grammer for the various incarnations of weak hacks is totaly unrelated to itself. I have made a solid attempt at using CSS. Some of it is pretty straight up, yet the finer points of it are black alchemy. Now I am not saying I am the sharpest tool in the box, but neither am I the dullest.
Sadly CSS is help together contextualy. For example, Position Relative. Well relative to what? The preceeding DIV? The immediately preceeding line of HTML? It needs to be glued together better, objectified if you will. In my opinion if something is declared relative, it should be a requirement that it be declared what it is relative to, instead realying on simply the preceeding line, ie: position relative(object). This glues it firmly to another object and therefor cements the relationship and each object knows what it should be relative to and can behave accordingly.
Ok and then there is the whole EM -v- PX debate, and the CSS people can't even make up their own minds about the best usage of it. Now this is not quite the same as a discussion about using i++ -v- i = i + 1. This is about fundamental behavior of the user agent in its interaction with the content! Should padding around an object be some relative to the size of the font as in this example which shows a padding: 1.5em?? I was under the impression that pixels are used to deal with the placement of an object within the browser window, relative to its upper left hand corner being 0,0 and its lower right hand extreme ( even if it is beyond the viewport and must be scrolled to ) being the x,y limit of the virtual screen space.
CSS extends standard HTML tags, yet one can create completely new things with CS. Then as I aluded to previously there are the grammer conventions. .content which is shorthand for document.content ( once again everthing being relative ) and the statements that beging with pound symbols (#) or not as the case may be, again non intuitive useage.
Then there are the various browser work arounds. Now clearly this is not the problem of CSS or its designers, this is the problem of user agent implimentations and their programemrs, or really is it... Lets ponder this for a moment with the PX - EM debate, or the position absolute debate. it would seem that CSS designers and the actual spec authors want to use everyhting with everthing else except where they don;t want it and then only if condition X exists. Now from a programers point of view, this is what we call, out worst nightmare. We like to write code that is straight forward and follows a given set of rules. We handle exceptions when the input violates those rules and handle them accordingly, usualy by showing some sort of message that is minimly explanitory and at least somehwat polite. I for one would really like to see a CSS rule matrix, developed by the CSS people that is coprehensive to the layout process. It would an interesting exercise and programemrs who try to write code to interpret this hodge-podge would probably be eternaly greatfull, well as greatfull as a programmer can get when people screw up their well ordered world.
All in all I think the goals of both HTML and CSS are laudable, but they are fundementaly broken. No
Hey KID! Yeah you, get the fuck off my lawn!
Nice to know that not even W3C can afford to spell check everything: teached CSS. It's not just /. editors! :)
HTML, from it's inception, was designed to be layout indepedent. The size and placement of objects is determined from inside out, expanding to fit.
CSS follows this model, to keep things from horribly breaking when a browser decides to turn off some CSS feature or substitute a stylesheet for print preview or what have you.
Saying that some container should expand to an arbitrary size that hasn't been determined yet breaks the model. That becomes especially problematic when you nest a series of parent-relative-sized elements within each other. You'd have to use a two pass model... where you establish minimum sizes for elements, and then potentially increase the size of some of them working back outwards for vertical alignment (without introducing reflow; if you do then you have to go back and recalculate the widths of everything).
I think it's a fundamentally hard problem unless you introduce a layout language that is properly seperated from the content so it can be more clearly expressed. Sort of like "framesets", for positional layout, and then CSS+HTML for document-flow content within each piece.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
I've been playing Counter-Strike : Source for ten years already?!
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
Why couldn't style sheets be based on HTML? Why Yet Another Language/Syntax? If HTML is not good enough to express styles, then lets fix it. Didn't anybody challenge that idea? Didn't anybody stand up and ask, "Why do we need yet another language/syntax?" Where is Bones when you need him to ask the hard questions?
Table-ized A.I.
It was supposed to be over 10 years ago.
Need a color? Try 100 random colors
My biggest beef with Safari is that it does not style form elements such as , , , etc.
Agreed, passing one test is silly. We need some suite of tests.
... and still overly messy.
I just had some experience with the CSS validator (http://jigsaw.w3.org/css-validator/validator.html .en) since I tried to make my new pages CSS compliant. First even if I choose "English" on the front page the results are in "German". My dear, before making pages conform to standards they should first be functional correct. How could W3C put up such a silly beginners mistake.
Yet whenever an error is spotted the resulting error message is more or less useless.
td,th,tr{
align:left;
vertical-align:baseline;
}
=> td, th, tr Die Eigenschaft align existiert nicht : left
Now each browser I tried interprets this correct even if it might be wrong formulated. Why can't the validator detect it as well and give a better error message?
Another case is the "size=1" argument in a "select" statement.
select.mini {
width:10em;
size:1;
}
=> select.mini Ungültige Nummer : size Die Eigenschaft size existiert nicht : 1
Again any browser is able to interpret this correct only the validator isn't.
The question arises why have the W3C validator such silly beginners syntax detection while any browser is far better? How can standardization been taken serious if W3C can't provide better tools?
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
From: http://www.squarefree.com/burningedge/
2006-12-13 Trunk builds:
* Fixed: 300030 - Refactor intrinsic width computation out of nsIFrame::Reflow (land dbaron's reflow branch).
This is a huge change that David Baron has been working on for about two years. It involved changing 201 files, simplifying many of them: a diff showed 8726 insertions but 18253 deletions, for a net removal of 9000 lines of code. It improved speed on page load tests by 3-5% and fixed over hundred bugs, including:
* Fixed: 69745 - Auto-width left float containing only nested right float is too wide.
* Fixed: 129346 - Fieldset renders incorrectly with style="float: left;" or any other shrink-wrap situation.
* Fixed: 269643 - When clicking link, page redraws with different layout, click is ignored.
* Fixed: 291126 - Intrinsically sized (shrink-wrap, auto-width) absolutely positioned element containing right float is too wide.
The reflow branch landing fixed the last remaining issues with the Acid 2 test, so Firefox trunk now passes the test.
Good idea, how about the CSS Test Suite?
I don't get what all this hype about the Acid2 test is about - its not even a standards test! By their own admission it's a "means of exposing the ability of user agents to handle invalid CSS properly" (source).
I'd rather browser makers worked on fixing bugs (may take a while to load) and more rich features.
From reading the comments, I'm guessing I'm the only one who doesn't really think CSS is that hard to understand. Yeah, the implementations are clumsy, and it lacks in some important areas, but holy mother of balls is it preferable to me over editing 4000 font tags in a website. The syntax is kinda ugly, but compared a lot of the other syntaxes in the web world (javascript, I'm looking at you) it's clean and sleek. Sheesh.
I think a huge problem is that a lot of people use CSS like they use font tags - instead of reusing tags and classes, and allowing for cascades, they create a new class for every block that they want to style.
----
"I used to listen to Null Device before they sold out."
...because your idea of what a layout is seems quite rudimentary to me:
Check the CSS3 Layout module proposal: it has rows and columns. Because this is what layouts are.
A layout is NOT a table! A table is a specific KIND of layout in a sense (it is a way to structure content as well, as in a spreadsheet or database, which is why XHTML still has a TABLE construct). You might as well say "Check out this square--it has four sides. Because this is what parallelograms are".
Layouts can be free-form (flowing) or consist of elements in fixed positions described by cartesian coordinates, or be columnar, or, yes, be tabular. CSS3 advanced layout standard as *proposed* (it is NOT yet standard--it is a working draft) contains a "row and column" mode of operation--as well as "template" and "stacked" modes of operation...and look what has been said about the rows-and-columns mode:
This is an alternative to the layout policy above. Probably we don't need both. Maybe the best parts can be combined: layout that is independent from the document structure in one case and arbitrary levels of stretchability in the other.
"Alternative" policy? "Don't need both"? Looks like it isn't seen as essential to keep in the recommendation doesn't it? I certainly wouldn't use them if I didn't have to. As I said, CSS layout is far from perfect and there are challenged in doing things like multi-column, newspaper-like layouts that make less sophisticated web designers give up and use tables, and CSS3 advanced layout was set up to address such shortcomings so that it is easier to avoid the mis-use of layout tables in the content (html code). It "has" rows-and-columns as currently proposed but it DEFINITELY doesn't rely on them, and in fact does not even consider them the layout policy of choice!
The Cascading Style Sheet remover
If one posts a reply that mentions a Mac outside of apple.slashdot.org, one should expect to be immediately be modded down to (-1, flamebait). This is true even if said post is true, relevant, on topic, and links to a previous discussion on /. itself.
--
And my biggest beed with Firefox on OS X is that it allows styling of form elements, which look like some Windows/KDE crap from the start anyway.
Form elements are supposed to be drawn by the OS. If you start to mess with them (apart from background/text color, and maybe font/font size at best), you may end with users not recognizing your form elements.
Yes- that is exactly what I want to do, change the background color, change the foreground color, change the font and font size, and apply borders and padding.
Not allowing styling of form/input elements to protect the user from bad design is silly. There are plenty of bad designs out there that don't style forms.
From elements should NOT be overridden by the OS. Does 'aqua' override flash-based forms? No. Does it override image-based input elements? No. It allows styling of A/Links. If I make my A look like a 'button', I should expect my INPUT to look the same -- borders, colors, everything.
Has it really been ten years? It feels like just yesterday my brother introduced me to it. I've spent countless hours figuring out its little foibles and trying to get better at it. It looks really simple but it's just not the kind of thing that you can just pick up.
There's certainly still room for improvement, and from what I read we can expect big things for it in 2007.
I still think de_dust is the best though.
"You can justify anything by putting it in quotes, adding a famous name and making it a sig" - Albert Einstein