CSS 2.1 Becomes W3C Recommendation

yuhong writes "After about a decade of development, CSS 2.1 has become a W3C recommendation. From the announcement: 'The current interoperability makes it easier than ever for developers and designers to enrich the toolkit. W3C expects future additions to CSS to be organized as independent modules, allowing smaller, more focused feature sets to progress and stabilize at their own pace. Some of these new features are already supported in browsers and other software in draft form (using the built-in CSS prefix mechanism designed for experimentation). As interoperability improves for each one, developers can transition to the standard to simplify their code. The CSS Working Group also publishes snapshots of which CSS features are supported interoperably in browsers; see, for instance, the most recent CSS Snapshot.'"

Comments

CSS *2.1*?

[tchernobog]

And while they are so slow finalizing the CSS standard, I use SASS and CSS 3.0. SASS is not about adding new features, just some basic common sense in the grammar, allowing for nesting, variable substitution, and another couple of sugary things.

Next step they'll finalize a standard on BASIC from the 80s. :-p

Re:CSS *2.1*?

[Anonymous Coward]

Next step they'll finalize a standard on BASIC from the 80s.

Says the guy using ruby to generate a declarative stylesheet?

Re:CSS *2.1*?

[kikito]

Your point?

Re:CSS *2.1*?

[tchernobog]

And there is nothing bad about it; I also like CoffeeScript over Javascript, when possible. Not to mention the Vala language, that "compiles" in C.

If browsers do not support the syntax you like directly, there is nothing bad to ease your developer's work server-side, go with a DSL, and make it work in a browser as a standard-compliant code.

You sure do not expect that these changes first get voted on by the W3C, before they make road into browsers! That is my whole point, NOT to wait for them, but use a intermediate mechanism that benefit both the user and the developer, while respecting the outdated standard.

Re:CSS *2.1*?

[Migala77]

I agree that avoiding duplication is too difficult in CSS, but fixing that and having graceful degradation to support non-supporting browsers would be a nightmare. SASS looks pretty interesting there. Would be great if there was something like this as a language-independent Apache module.

Re:CSS *2.1*?

[mikael_j]

Yes, I've been hoping for way too long that someone at the W3C would just suggest something "radical" like simply adding simple reference variables in a useful way.

Even a very limited syntax like the below example would be useful:

$bluebg = { background:#00f; } div#foo { $bluebg; }

Now, something like this could easily be implemented as a server-side module, but I would rather see it implemented into CSS proper. And I know there are various tricks and workarounds, it would just be a neat and powerful tool.

Re:CSS *2.1*?

[Anonymous Coward]

There's also LESS (http://lesscss.org/) if you're looking for dynamic style sheet method.

Re:CSS *2.1*?

[StripedCow]

Yes, but why don't browsers offer us a simple binary platform? The open-source community could then develop compilers for any domain-specific language we want. We could then even implement our own version of HTML and CSS.

I think W3C has done a good job, but they are unintentionally keeping us, (open-source) developers, hostage.

Re:CSS *2.1*?

[Anonymous Coward]

The question is, what's the cost for rendering such pages? If it can be server side generated, then why is more complex parsing and interpretation needed which might (not certainty) slow down every page render?

Re:CSS *2.1*?

[Anonymous Coward]

And there is nothing bad about it

You suggest the W3C standardise on "Basic from the '80s" and don't see the irony in your using a smalltalk inspired language to generate CSS?

I also like CoffeeScript [github.com] over Javascript, when possible. Not to mention the Vala language, that "compiles" in C.

Sure, I've played with Vala and C compilers in-turn generate assembly. Do javascript or css need the language advancements made from asm to C to Vala (yes I ommited C++)? I do sometimes generate CSS on the server where, I regret to inform you; lack of variables and difficulty of optimising CSS rules have not been a cause of a single sleepless night over the last decade ;) I had M4, sed and a C pre-processor before I was even doing CGI's and not once did I ever need to add variables to CSS for a production site.

Re:CSS *2.1*?

[Anonymous Coward]

And while they are so slow finalizing the CSS standard

That's not a bug, it's a feature. The W3C, despite what some people think, is not a kind of "web government" that sits above browser makers, website designers etc. and tells them what to do. Rather, its purpose is to make the standards that the community has agreed on official.

This does mean that the W3C will have working groups staffed with industry officials and experts to work on those standards, yes; but it also means that a standard will only be finalized when it is, well, a standard: before that, the specification is there for everyone to adhere to, but it's still a draft - a proposal.

It helps when you think of draft standards as RFCs. In fact, that comparison is particularly apt insofar as that the IETF also published STDs, which are the ACTUAL standards (e.g. STD 5, also known as RFC0791, which describes IPv4).

Think about it.

Re:CSS *2.1*?

[mwvdlee]

There is: http://code.google.com/p/ecss/

The thing I dislike about these CSS extensions is that they all have different syntax and require a specific language/method
It would be great if one of these would run as an apache module, php/perl/python/ruby script, javascript, java/C# library, etc.

W3C does a great job, but they seem to go for semantical perfection instead of practical use.

Pet peeve: http://www.w3.org/TR/css3-color/#css2-system was deprecated in favour of http://www.w3.org/TR/css3-ui/#appearance. Nothing wrong with "appearance", but neither can do what the other can. If I want a HTML element to have the appearance of a button, I'll make it a button element. If I want to make a tri-state checkbox with the look and feel of the OS, I can't. Why not have both?

Re:CSS *2.1*?

[icebraining]

Why? You can compile to HTML, JS or CSS just as you would compile to a binary format. I mean, many tools export to HTML already and projects like Pyjamas show that you're not forced to use Javascript.

Re:CSS *2.1*?

[mwvdlee]

p.s. I know most browsers support CSS2 system colors, and most likely won't stop supporting it any time soon, but the fact that W3C has deprecated it in CSS3 tells me where their priorities are.

Re:CSS *2.1*?

[dmgxmichael]

No. God forbids designers from programming...

(That's sarcasm btw)

Re:CSS *2.1*?

[mikael_j]

Well, without doing any calculations I suspect that the cost to the user in terms of CPU cycles in negligible compared to some of the Javascript and massive (X)HTML documents sent these days.

Not to mention that it should with some optimization be possible to cut down on the parsing required (since the browser only has to parse the '$bluebg' block once as opposed to parsing say, 300 different 'background:#00f;' statements).

And the maintenance wins are potentially enormous (with a custom server-side setup you are using a custom non-standard solution which can be a maintenance nightmare).

Re:CSS *2.1*?

[i_ate_god]

you do realize that html elements can take multiple classes right? Variables are pointless

Re:CSS *2.1*?

[TheRaven64]

A javascript bytecode format would be much easier to target than JavaScript itself. I've written a C / Objective-C to JavaScript compiler, and it's quite messy trying to make sure that you don't hit any of the weirdness of the JavaScript syntax. It would also be easier for browsers. They could interpret the bytecode directly and JIT compile segments of it, rather than having to parse the JS code.

Re:CSS *2.1*?

[drinkypoo]

I don't get it and the SASS page doesn't explain, if it contains stuff that's not in CSS (which it implies) how will users view the content (receive the styles, whatever)?

Re:CSS *2.1*?

[Anonymous Coward]

I guess they compile the fancy SASS into standard CSS. Like compiling C++ into C if you haven't got a native C++ compiler.

Re:CSS *2.1*?

[telekon]

Sass only contains things that aren't in CSS in terms of syntax and semantics. What's seen by the browser is valid CSS, but with Sass you get variables, functions, etc. for free. It makes it much easier to keep your templates and your presentation code DRY, and allows you to do things like compute colors or column-widths on the fly. But ultimately, you're producing CSS.

Re:CSS *2.1*?

[drinkypoo]

So it's precompiled, then? Or, there's a Javascript component? Or...?

Re:CSS *2.1*?

[Anonymous Coward]

It includes a precompiler and a module which somehow hooks into Ruby websites and compiles on-the-fly.

Re:CSS *2.1*?

[mikael_j]

Of course I know that but it does not mean that variables in CSS would be pointless.

If anything variables would mean that you wouldn't be forced to say, use the same color value in multiple locations (or have a bunch of classes named "lightOrangeBackground", "darkOrangeBackground", "grayText", "lightGrayText" which makes for some annoyingly long lines in the HTML in the form of <div class="defaultLightBackground defaultDarkBackground blueLinks fooBorders barMargins">).

With variables/constants in the CSS you can have much clearer class names and rather than put "defaultLightBackground" on every element that is supposed to have that background you can define this directly in the CSS, which would actually make sense and which is why you don't really see people use multiple classes all that much, it is much more common to instead repeat the same boilerplate bits and pieces all over the place (oh, and here is where someone replies to me telling me that search-and-replace is enough to make global changes without considering the classic "int a = 20; int b = 20;" problem. Imagine that your global search and replace is for "20" but you only want to change the value of the variable a, when you have a 2k+ line CSS file you don't exactly want to have to step through every occurrence of a short string that appears a hundred times).

Re:CSS *2.1*?

[drinkypoo]

It includes a precompiler and a module which somehow hooks into Ruby websites and compiles on-the-fly.

Now THAT makes sense. Oddly I didn't see the "only for Ruby" note anywhere. Another case where the software engineer needs to form a relationship with a web designer. Or maybe, a smarter one. Or maybe, a less smart one. Hard to say.

Re:CSS *2.1*?

[SanityInAnarchy]

Chrome does, though it's still experimental.

However, unless you're going to have your own version of HTML and CSS compile to real HTML and CSS, you lose a lot of the benefits of a web app in the first place. As it is, I don't see the problem with using tools like Haml and Sass. I've generally preferred actual JavaScript to preprocessors, but CoffeeScript looks awesome, I don't think I ever took a good look at it before.

The biggest annoyances of the current Web are all things we can deal with.

JavaScript is almost exactly the sort of language I'd want to work with, and CoffeeScript addresses my biggest annoyance -- the syntax is ugly. Other than that, Chrome's V8 has better boot time and execution speed than other languages I'd want to work with, and I don't need to force the users to download an entire interpreter, all of which makes my pages load faster than if I forced some nativeclient interpreter on them, though it's nice to have that option.

Haml addresses my biggest complaint about HTML, which is also mostly skin-deep -- I really don't like the XML syntax. The fact that I can mix in Ruby to generate more HTML is also useful. I used to think XSLT with a custom XML schema was the answer, but I find Haml is much more pleasant to work with.

CSS does most of what I want. Sass makes it prettier, but I'm never really going to love it. But I'm also not a designer. While it's clear there's room for improvement in CSS, this is mostly just me. On the other hand, CSS is also where you find the most differences between browsers, which is why on any significant project which needs to support open standards and IE, there's an ie.css file somewhere.

And that's the last major annoyance -- differences between browsers. Yet CSS is the only place I still deal with that directly on a regular basis. The HTML is reasonably standard, and the differences in JavaScript are hidden by libraries like jQuery. Putting preprocessors in front of the actual HTML/CSS/JavaScript also makes it possible to fix the portability issues once and then not have to deal with them -- which is great, because aside from IE, I already barely have to deal with them.

I still think Chrome's nativeclient is a good thing, but mostly for performance -- for the same reason that in a language like Python or Ruby, I'd write C extensions to make stuff fast. So, in a web app, if I find one thing that's really costing me in performance, I'd write a nativeclient version.

Re:CSS *2.1*?

[SanityInAnarchy]

You suggest the W3C standardise on "Basic from the '80s" and don't see the irony in your using a smalltalk inspired language to generate CSS?

Web standards have moved on since then. So has Ruby.

Web standards are inspired by stuff like SGML, which is older than dirt. That's entirely beside the point. The point is that the W3C is standardizing stuff that we've been using for years, almost a decade. This is more like if C only became an official standard today.

Re:CSS *2.1*?

[aztracker1]

I've been using .less a bit myself, which is similar. what I use is pre-compiled, but there are supporting modules for on-the-fly delivery. I believe there are js interpreters as well.

Re:CSS *2.1*?

[fortyonejb]

The W3C, despite what some people think, is not a kind of "web government" that sits above browser makers, website designers etc. and tells them what to do. Rather, its purpose is to make the standards that the community has agreed on official.

Interesting. So basically they come a long and say, "hey you're all using that? Ok, it's a standard now". Well, thanks captain obvious. So really they are nothing more than glorified technical writers.

Re:CSS *2.1*?

[telekon]

It's not only for Ruby. For on-the-fly compilation, there's a Rails plugin, but compilation can also be invoked manually from the command line. It is written in Ruby, but there's no reason you can't use Sass to generate CSS for PHP, Python, plain-old-HTML, etc. driven sites.

Re:CSS *2.1*?

[BZ]

Have you ever tried writing a standard?

It took so long to finalize CSS 2.1 for two reasons:

1) There's a lot of complicated behavior the standard had to describe.

2) One of the criteria for a W3C REC nowadays is that there are two independent correct implementations of every part of the standard.

BASIC from the 80s is dead-simple in comparison, and probably still fails the criterion above. ;)

Re:CSS *2.1*?

[BZ]

Think of them more as arbitrators whose job is to get the community to agree on something even when different parts of it want different things to happen.

Re:CSS *2.1*?

[Anonymous Coward]

The first paragraph on the page.

"Sass makes CSS fun again. Sass is an extension of CSS3, adding nested rules, variables, mixins, selector inheritance, and more. It’s translated to well-formatted, standard CSS using the command line tool or a web-framework plugin."

You write a sass dsl stylesheet which is translated into straight css the resulting css stylesheet is what goes on your live site.

Re:CSS *2.1*?

[yuhong]

Yea, W3C tried this with CSS 2.0 in 1998, and the fact that no browsers fully implements it is exactly why CSS 2.1 was created in the first place.

Re:CSS *2.1*?

[shutdown -p now]

Next step they'll finalize a standard on BASIC from the 80s.

ISO/IEC 6373:1984 "Data Processing — Programming Languages — Minimal BASIC" was published in 1984.

ISO/IEC 10279:1991 "Information Technology - Programming Languages - Full BASIC" was published in 1991.

(the corresponding ANSI standards were published 4-5 years earlier).

Re:CSS *2.1*?

[shutdown -p now]

Javascript is too high-level to serve as a convenient - and, more, importantly, efficient - backend for many statically-typed languages. It's also quite a waste to have all that type information at compile time, then ditch it all in translation to JS, and then have the runtime do very complex flow analysis trying to figure out the types to JIT-compile to efficient code.

In some cases, it simply doesn't offer the required facilities - e.g. there's no way to guarantee tail call optimization.

Re:CSS *2.1*?

[shutdown -p now]

NaCl major flaw is its platform dependence. Sure, it covers the most popular platforms today, but it's not future-proof.

Now they also have PNaCl, where the browser downloads LLVM intermediate language (binary-serialized), compiles that to native, and then runs it in a NaCl sandbox. That is precisely the kind of thing needed - a low-level but nonetheless portable target platform that permits efficient implementation of various things. The only problem is that I'm not aware of any actual implementation so far, only the whitepaper.

Re:CSS *2.1*?

[SanityInAnarchy]

NaCl major flaw is its platform dependence. Sure, it covers the most popular platforms today, but it's not future-proof.

I suppose it technically is in the sense that there's always emulation...

Now they also have PNaCl, where the browser downloads LLVM intermediate language (binary-serialized), compiles that to native, and then runs it in a NaCl sandbox. That is precisely the kind of thing needed - a low-level but nonetheless portable target platform that permits efficient implementation of various things.

What I would wonder here is how efficient it is. How much are you giving up by not using pure native code? It looks like PNaCl is included with NaCl, otherwise it's pointless -- if I have to include an LLVM interpreter anyway, and I'm using low-level languages like C anyway, I may as well compile to native.

But if it is included, having this as an option makes sense in another way: Multiple fallbacks. If NaCl is available, but I don't have a binary for the user's platform, I can try PNaCl. If that doesn't work, I can fall back to a JavaScript implementation.

Re:CSS *2.1*?

[shutdown -p now]

What I would wonder here is how efficient it is. How much are you giving up by not using pure native code?

Nothing. LLVM is not an interpreter - it's a compiler. LLVM intermediate code is compiled to pure native code on browser side, and then the appropriate, architecture-dependent NaCl sandbox is used to run that. The benefit here is that when a new architecture becomes popular (consider how meteoric the recent ARM rise has been), the burden is on Google to provide a new NaCl sandbox, and on Apple (and Google) to provide an LLVM backend - your compiled binary remains the same and keeps working.

Re:CSS *2.1*?

[spauldo]

The W3C, despite what some people think, is not a kind of "web government" that sits above browser makers, website designers etc. and tells them what to do.

Since when? Remember XHTML? Or XForms? They were so far ahead of the curve that they took years to notice the rest of the community had turned off somewhere way back. Of course, that's back when Microsoft believed that packaging IE with Windows meant they didn't need to fix bugs or add features to it anymore.

Sure, some of their more out there stuff sparked some ideas, but a good chunk of it went unimplemented. That's why the WHATWG got started - the W3C was going its own route, and the industry finally got tired of dealing with them.

CSS *2.1.*!

[Hermanas]

This is a quote from wikipedia, which might explain why CSS 2.1. is only *now* part of the recommendation:

The CSS Working Group began tackling issues that had not been addressed with CSS level 1, resulting in the creation of CSS level 2 on November 4, 1997. It was published as a W3C Recommendation on May 12, 1998. CSS level 3, which was started in 1998, is still under development as of 2009. In 2005 the CSS Working Groups decided to enforce the requirements for standards more strictly. This meant that already published standards like CSS 2.1, CSS 3 Selectors and CSS 3 Text were pulled back from Candidate Recommendation to Working Draft level.

Even so, what has the W3C been doing the last 6 years!?

Re:CSS *2.1.*!

[Anonymous Coward]

Nothing.

Re:CSS *2.1.*!

[Carewolf]

Even so, what has the W3C been doing the last 6 years!?

Waiting for the browsers to implement the full specification...

One of the new requirements made to ensure the specifications are actually sane and useful is that it has to have two full independent implementations. But for that you first need a test-suite and you need browser-developers to make complete and correct implementations, unlike the usual practice of just implement some parts and call it supported (*cough* html5 *cough*)

Re:CSS *2.1.*!

[LordLucless]

So you don't actually define a standard until it's already implemented. Wish I could get away with writing my specs like that.

Re:CSS *2.1.*!

[Hermanas]

Ah ok, that makes sense. You told me something I didn't know, thanks! Still... CSS3 must be close to having two independent implementations by now...? Or have the W3C constructed the necessary tests, but the browsers are failing it on some parts?

Re:CSS *2.1.*!

[donatzsky]

The big difference with CSS3 is that instead of one huge all-encompassing standard it's broken up into modules. Each module goes through the process independently of the others.
Two modules (colors and selectors) are currently Proposed Recommendations, with eight more being Candidate Recommendations.
http://www.css3.info/modules/

Re:CSS *2.1.*!

[TheRaven64]

You define the standard before it's implemented, but you don't finalise it. A standard with no implementations is a draft or a proposal. You can't tell if it's sane until you try to implement it. It may accidentally (or maliciously) impose some constraints that are difficult to implement in some situations.

You also seem to be confusing a standard with a specification. A specification tells you how to build something. A standard tells you how to interface with something. Defining a specification after the implementation would be pointless, but defining a standard with no implementations is equally pointless. There's no point building something on top of something that doesn't exist. Standards should always begin with implementations: the first draft defines how the experimental implementation works, and it's then refined based on lessons learned from that implementation. Eventually you end up with something that's sensible to use and not too hard to implement. This is why standardisation takes a long time, and why rushing standardisation was a mistake for both ODF and OOXML.

Re:CSS *2.1.*!

[Anonymous Coward]

"Even so, what has the W3C been doing the last 6 years!?"

Getting it right.

Which is more than can be said for the rushed, poorly developed, inconsistent, hacked together shitefest that is HTML5.

Honestly, specs are something that take time, they need to be done right, and done properly, with input from all the different web players where that input is not just simply thrown in the bin, but is taken onboard and examined in the context of the spec to see whether changes are needed or what can be done.

I much prefer the W3C to take it's time and get it right, than WHATWGs practice of sticking whatever the fuck they want in, randomly giving up on features it can't be arsed to resolve issues over, and not paying the blindest bit of attention to major criticism and instead coming up with retarded irrational and nonsensical excuses for not sorting problems out. Further, I DEFINITELY prefer the W3C's approach to WHATWG's last idea of a "living spec".

Re:CSS *2.1.*!

[Anonymous Coward]

two full independent implementations

Which ones would that be? According to quirksmode no mainstream browser has 100% CSS 2.1 support. According to the W3C test suite results, the most complete implementation is Mozilla Gecko with 99.84% coverage and 97.07% tests passed.

Re:CSS *2.1.*!

[Anonymous Coward]

CSS3 must be close to having two independent implementations by now...?

Dream on. There's not even one complete implementation of CSS 2.1, much less of CSS 3. And CSS 3 is a moving target and large parts are still underspecified, so it's currently impossible to implement completely.

Re:CSS *2.1.*!

[yuhong]

And BTW most of them depends on CSS 2.1 to be at least Proposed Recommendation in order for them to become Recommendation (look in the Normative References section). For example, CSS3 Color was also made Recommendation today.

Re:CSS *2.1.*!

[Carewolf]

Nothing is ever bug-free. I do not know the specifics, but I guess they don't have to be bug-free as long as everyone agrees those are bugs.

Re:CSS *2.1.*!

[yuhong]

unlike the usual practice of just implement some parts and call it supported (*cough* html5 *cough*)

And over time the browsers implement more parts. There is a reason why the WHATWG decided to call HTML a living standard.

Re:CSS *2.1.*!

[yuhong]

You define the standard before it's implemented, but you don't finalise it. A standard with no implementations is a draft or a proposal. You can't tell if it's sane until you try to implement it.

Yep, that is what W3C's Candidate Recommendation phase is for.

Glad to see it finally achieve recommendation stat

[tallship]

Kewl,

But it's not like it wasn't a defacto standard anyway, for quite some time.

Let's see what mACROsFOT tries to embrace and extend on this one eh?

web development used to be for anyone

[Anonymous Coward]

Back in the old days (aka 1990s) Web development was fun, it was something anyone could learn in next to no time.
HTML 3.2 was fairly straightforward.
Tables were the layout order of the day and whilst being frustrating as hell at time for interoperability, was fairly easy to get work around, learn and use.

The problem with today's web it's overly complex, excluding the "anyone can do it". HTMl 4/XHTML whilst not much more complex than 3.2 is harder to learn, CSS, and inheritance whilst a great idea to remove style from content, adds another level of complexity. CSS2, CSS3 all just add to the complexity.

and I won't even go down the cgi/php/asp/jsp n-tier approach as that's just beyond most "regular" people and consigned to us geeks.

What we don't want to do is make web development so "elegant" that we preclude the "anyone can make a website". If we do that we'll all lose some of the freedom the web has given us.

Re:web development used to be for anyone

[LighterShadeOfBlack]

Nobody is required to use these new technologies. HTML 3.2 and tables will still work as well as it ever did, so anyone can still do it All that's changed is that there are more advanced capabilities (out of necessity/efficiency requiring more stringent adherence) for those who want or need more. This is inevitable and essential to allow the Internet to grow beyond a collection of multi-coloured fonts on garish backgrounds with a couple of animated GIFs for decoration.

Even then, for those who want the capabilities and elegance of modern technologies without the complexity we have all manner of CMS systems lowering the knowledge bar to allow non-technical users to create visually and technically stunning websites.

I disagree very much with your assertion. The progress of Internet (pseudo-)standards hasn't prevented anyone from creating from creating a website, in the same way that watercolours don't prevent a child playing with finger-paints. Just don't expect your kid's painting to look like a Van Gogh.

Re:Glad to see it finally achieve recommendation s

[Carewolf]

There is a difference between which standards has 'Recommendation' level, and which ones are recommended to use. CSS 2.1 has been recommended for a long time, it is just not a 'Recommendation'. Just like RFC standards doesn't actually want your comments.

For which CSS specifications that are recommended. Check out CSS Snapshot 2007 , and don't worry about the 2007 name, the latest version is from May 2011.

Re:Glad to see it finally achieve recommendation s

[Ant P.]

I've seen some people (foaming-at-the-mouth microsoft nutcases) claiming that nothing needs to be done right in the browser *until* the W3C finalises it. Watch MS try to spin this as a publicity stunt, despite their working group plants usually being the ones holding the process up.

CoffeeScript is a bandage over a horrible wound.

[Anonymous Coward]

CoffeeScript isn't "good" in any way. It's merely a bandage over the horrible wound that is JavaScript.

Every aspect of JavaScript is a failure. Every single one. They managed to fuck up the syntax. They managed to fuck up the semantics. They managed to fuck up prototype-based OO. They managed to fuck up the equality and inequality operators. The fact that you need to hide it as much as possible, whether using something like jQuery or CoffeeScript, further goes to show how anally fucked it is.

JavaScript has no redeeming value. There's nothing good about it. Frankly, it should have been destroyed years ago. But browser developers haven't exactly shown themselves to be the brightest people around. I mean, just look at Firefox. Who the fuck thinks it's a "good idea" to write huge portions of a desktop app using JavaScript and XML? It's no wonder it is so fucking bloated, slow, and prone to memory leaks, and it's supposedly a "lightweight" browser.

It's time for a real programming language in the browser. It doesn't matter if it's Lua, or Scheme, or Python, or Ruby, or Erlang, or even Haskell. We just need to get rid of JavaScript. We need to get rid of what is actually the biggest mistake ever made in the field of computing.

Re:Glad to see it finally achieve recommendation s

[Anonymous Coward]

Replace "finalize" with "recommends" and you're a little closer to correct. The problem being that a lot of other browsers are implementing very early and quite immature drafts which are in flux, and doing so without consulting W3C or even each other on implementation details which invariably leads to different behaviors.

What everyone should be doing, apart from implementing experimental support in their browsers, is submitting test cases to the test case suites at W3C so that these details can be hammered out in an agreed upon fashion while simultaneously providing other implementers with working examples.

We need to move forward

[lazy_arabica]

Ok, I know I'm gonna be modded as "Troll", but I need to say it: CSS is an horrible, backward, overly-complex standard. And yet, for philosophical / ideological reasons, it has been branded by the semantic folks as one of the most exciting innovation of the 20st century.

CSS has been invented in the days when most web pages consisted of simple blocks of text, with an occasional image floating left or right of it. All that was needed back then was changing the color of text, adding margins / paddings and that's about it. It was NOT designed to handle complex layouts: for that, you used tables.

And then the semantic folks arrived and told everyone using tables was baaaadddd for their main purpose was to present tabular data, not to layout things. And they were right, of course. But they made the wrong choice, deciding to extend CSS rather than crafting a new standard, specifically designed for the task. And here is the result: more than fifteen (15) years later, we still can't do simple things like "aligning this block to the bottom of this one" without using dirty - not semantic at all - hacks, or even falling back to JavaScript.

Even CSS 2 isn't supported properly by some browsers. Let alone CSS 3. And while you may think it isn't W3C's fault, I think perhaps, if some of the richest companies in the world haven't been able to implement this standard properly in, say, 10 years of continued effort, and that standard doesn't even reproduce all of the basic features that have been used in print for decades, it *might* be overly complex to get right. Look at these stupid cascading rules, for example: who seriously wants that ?

We need to move forward and develop new standards, focusing on /features/ rather than on pseudo-philosophical crap. We want to design websites that look great. Period.

Re:We need to move forward

[Anonymous Coward]

Actually I think you'll find the problem is *old* browsers don't support those cool features.

CSS was the right thing to extend - it shouldn't be thrown out just because it doesn't do what you want (*cough* don't know how to do it) - just like we've extended HTML instead of throwing that out to create something new.

Aligning to the bottom is an easy task. All any program (or css) needs to align to the bottom is top + height of box - height of thing. Its all the design programs do too.

The difference with a print program is that you are laying out your content to a *fixed* size like paper (Letter / A4 / whatever). So all your measurements are relative to this fixed size. On the web you have to layout to *any* size if you're a good designer or create an "fixed" width if you can't cope .... and a "fixed" width only suits a small percentage of your audience.

And no it isn't the W3C's fault - the W3C take recommendations from anywhere, and you can always participate in the standards and help steer the future. The fact that you're whining that it doesn't do what you want says to me:
(a) you don't participate / provide feedback on future standards
(b) you don't know how to use the standards to create a great looking website
(c) you don't have a better idea on what a new standard should contain
(d) you should learn more about the standard / good design / css / html programming

Re:We need to move forward

[Anonymous Coward]

I want two boxes next to each other, each containing variable length text, consuming just enough vertical space for the larger box (whichever one it is) and with the bottoms of the two boxes aligned. How do I do this in HTML+CSS without using tables or javascript?

Re:We need to move forward

[Bogtha]

foo { display: table-cell; }

It's been around since 1998, the only thing stopping people from using it was Internet Explorer 7 and below.

Re:We need to move forward

[Bogtha]

It was NOT designed to handle complex layouts: for that, you used tables.

Tables weren't designed to handle complex layouts either.

And then the semantic folks arrived and told everyone using tables was baaaadddd for their main purpose was to present tabular data, not to layout things. And they were right, of course. But they made the wrong choice, deciding to extend CSS rather than crafting a new standard, specifically designed for the task.

The concept of separating semantics and presentation was around well before CSS. CSS was designed for this. They weren't "extending" CSS, that's what it's for.

Even CSS 2 isn't supported properly by some browsers.

Neither are tables. The question is, which browsers? The only mainstream browser that doesn't support CSS 2 is Internet Explorer 7, which people are already dropping support for.

I think perhaps, if some of the richest companies in the world haven't been able to implement this standard properly in, say, 10 years of continued effort

"Some of" isn't true. One of is. And that one has a vested interest in incompatibility, that they have explicitly stated in internal memos.

Here's another data point - iCab, before it switched to WebKit, supported CSS 2. It was built by a single developer. If a single developer can do it, it's not "overly complex".

Re:We need to move forward

[Anonymous Coward]

So use a table then :-)

But seriously, thanks for the answer.

Re:We need to move forward

[lazy_arabica]

It was NOT designed to handle complex layouts: for that, you used tables.

Tables weren't designed to handle complex layouts either.

Never said that it was, nor that table are a great tool for that. My point is: CSS wasn't born as a layout tool, but as a /styling/ tool. Hence the name.

And then the semantic folks arrived and told everyone using tables was baaaadddd for their main purpose was to present tabular data, not to layout things. And they were right, of course. But they made the wrong choice, deciding to extend CSS rather than crafting a new standard, specifically designed for the task.

The concept of separating semantics and presentation was around well before CSS. CSS was designed for this. They weren't "extending" CSS, that's what it's for.

My point (which you seem to miss entirely) was that CSS hasn't been designed as a layout tool. It was, of course, designed to separate semantics and presentation. But back then, presentation mostly meant: "which color should I use for this title ?" or "would this yellow text look better on a black or on a blue background ?". CSS was a great tool for such decisions. It simply wasn't adapted to the growing complexity of layouts, and still isn't.

I'm not saying that separating semantics and presentation is a bad goal. It isn't. I just feel that the emphasis should be put more on design features, and less on semantic-web-2.0-blah-blah.

Even CSS 2 isn't supported properly by some browsers.

Neither are tables. The question is, which browsers? The only mainstream browser that doesn't support CSS 2 is Internet Explorer 7, which people are already dropping support for.

I think perhaps, if some of the richest companies in the world haven't been able to implement this standard properly in, say, 10 years of continued effort

"Some of" isn't true. One of is. And that one has a vested interest in incompatibility, that they have explicitly stated in internal memos.

Here's another data point - iCab, before it switched to WebKit, supported CSS 2. It was built by a single developer. If a single developer can do it, it's not "overly complex".

Well, we obviously don't have the same definition of "mainstream". I still see quite a lot of IE7 and even IE6 requests in my logs.

And while most non-Microsoft browsers now have a decent support for CSS3, we musn't forget how much time it took for them to get it right. I didn't try iCab, so I can't say how great it CSS 2 was, but even the W3C hasn't been able to implement all of CSS2 into its own browser.

Re:We need to move forward

[Anonymous Coward]

Agreed. Tables weren't designed for layout but neither was CSS and, bluntly, tables are vastly easier to use for that purpose. My mother has never used a computer and she could do table layout with pencil and paper after 10 minutes instruction; try that with CSS. Instead of investing vast amounts of energy, resources, and angst in trying to make CSS do what tables already do it would be better to have either modded tables to fix the problems related to using them for layout, or to have come up with a third alternative entirely dedicated to controlling web page layout. Note: I said "fix the problems related to using them {tables] for layout" above so please don't go on about how tables do/don't do this or that.

Re:We need to move forward

[Anonymous Coward]

And here is the result: more than fifteen (15) years later, we still can't do simple things like "aligning this block to the bottom of this one" without using dirty - not semantic at all - hacks, or even falling back to JavaScript.

hacks?

display:inline-block; vertical-align:bottom;

position:relative; position:absolute; bottom:0;

I'm sure there's more. I suppose, technically, you could consider nesting blocks in a container specifically for positioning a hack. Then again, you could make the semantic argument that you want to group like things together similar to how grouped form elements go in fieldsets. In any case, aligning the bottoms of blocks is a simple thing to do.

Though in most cases, blocks are top-aligned and heights are often stretched to align bottoms. I don't recall ever having to align bottoms so I'd like to see a real-world example.

Re:We need to move forward

[Anonymous Coward]

doesn't do what you want (*cough* don't know how to do it)

Create a layout that has an element wide enough for your users' usernames, whether they registered as "A" or "MMMMMMMMMMMMMMMMMMMMMMMM" or "iiiiiiiiiiiiiiiiiiiiiiiiiiii". In the font and fontsize of the users' choosing, of course.

This is not a theoretical problem. The slashdot redesign originally put the username in the left navigation column which caused it to expand over the content if your name was "too wide".

Re:We need to move forward

[itsdapead]

Tables weren't designed to handle complex layouts either.

But they do a far better job of it than CSS - even properly implemented CSS.

The concept of separating semantics and presentation was around well before CSS. CSS was designed for this.

Except it does a bloody lousy job because, to achieve particular effects with CSS (e.g. the sort of multi-column layout that is ubiquitous on websites) your "semantic" mark-up has to be written with precisely the right hierarchy of properly-named "div" elements in the correct order.

Unfortunately, CSS gives the impression of being "designed" by a committee who had never visited a late-1990s-era webpage, used a DTP package, or used a GUI layout manager API.

"Some of" isn't true.

Care to name any MS or non-MS browsers that support "page-break: avoid" in any useful fashion? (Hint: if HTML/CSS had better facilities for controlling printed output then maybe more online journals would put stuff online in nice, semantically-marked-up HTML form rather than as PDFs).

Re:We need to move forward

[BZ]

The reason that CSS is so complex and such a pain to implement is the combinatorial explosion when you have multiple interacting features. The standard has to define how they interact, and UAs have to implement the interactions. Any standard that focuses on features but not their interactions with each other will simply mean that browsers handle interaction of the features differently.... and any standard that actually tries to standardize behavior will be just as complicated as CSS by the time it reaches feature parity.

Note that print layout is much simpler than web layout because you don't have to deal with size changes and because some features are missing in print but present on the web. Something as simple as the interaction of :first-line with a in the first line that changes font size on hover is not an issue print has to deal with, but _is_ an issue that CSS and implementations have to deal with.

Now you're right that CSS was initially designed for document layout and that its facilities for laying out a user interface are pretty much nonexistent. That's being worked on with various CSS3 proposals; we'll see how that goes. And document layout is still needed on the web, of course; not every web page all user interface (many are user interface wrapped around a document).

Re:We need to move forward

[lazy_arabica]

Huh... right. So, since I don't know HTML/CSS, please enlighten me ?

- How do I achieve the the sticky footer effect without an ugly hack and without using additional markup ?
- How do I place a box to the bottom of another variable height box ?
- How do I vertically center a fixed-height box within another fixed-height box ?

If you come up with an easy, no-hack solution that truly achieves separation of style and semantics - that is, that doesn't force you to change your markup to layout things the way you want -, I'm ready to admit I'm wrong.

Now, to reply point by point to your "conclusions" about my particular case:

(a) You might not believe it, but I have a job.
(b) I sure do, and that also happens to be my job. I'm just constantly limited in my creativity by the poor standards that are pushed on us.
(c) Well, I just gave you 3 examples of things that should be easy to do in a good standard.
(d) Frankly laughable.

Re:We need to move forward

[yuhong]

AFAIK the reason CSS 2.1 was created in the first place was that no browser actually fully implemented CSS 2.0 to the letter due to the many problems with the spec. And remember CSS 2.1 did not exist when IE6 was released.

Re:We need to move forward

[s31523]

Even CSS 2 isn't supported properly by some browsers.

And when is page-break-inside finally going to be supported? Man, that would be helpful.

What good is a standard if no browser fully supports it and when some browsers (*cough* IE *cough*) flat-out ignore them.

Re:We need to move forward

[Anonymous Coward]

Thanks for your statements about tables. Couldn't agree more.

A few years back, I tried looking into the so-called "clean" way of doing layout with css. The truth is, there is no clean way of doing it with css.

Hijacking the table element for layout was rightly criticized. However, rather than the browsers providing a new syntax for grid-based layout, it seems there was a reactionary demonization of grid-based layout, ignoring that grids are the most natural way to specify layout. You create several different boxes with content, and you then specify where those boxes should appear within the document for the medium in question.

IMO, the lack of a decent grid-layout interface is the biggest failing of both web browsers and latex.

Re:Glad to see it finally achieve recommendation s

[Billly Gates]

Yep. Microsoft has a very cranky enterprise oriented customer base. They do not want to upgrade IE only to find out a bug screwed up an intranet app because the w3c changed a detail about a css property that the new IE follows. It seems there approach is to simply ignore the standards unless recommended as to prevent adoption. This causes everyone to wait as IE is the most popular browser in the world

The problem with CSS goes back to its creator

[telekon]

Adding any form of macros or additional scopes and indirections, including symbolic constants, is not just redundant, but changes CSS in ways that make it unsuitable for its intended audience. Given that there is currently no alternative to CSS, these things must not be added.
- Bert Bos, W3C/ERCIM

That's not only idiotic, it's also kind of douchey. Macros and variables make it unsuitable for web designers? PLEASE. Learning to use Dreamweaver efficiently is harder than learning Sass to do styles with all the nice features CSS lacks by design.

Just remember that CSS is HORRIBLE BY DESIGN, and you'll be OK.

Re:The problem with CSS goes back to its creator

[Anonymous Coward]

Macros and variables make it unsuitable for web designers?

No: unsuitable for its intended audience of someone who either (a) had dreamed up a rigid theoretical model of how markup should work which they were not prepared to change to reflect real world demands, or (b) someone who had already written a CSS parser that didn't allow for macros and didn't fancy re-writing it, or (c) a committee made up of types (a), (b) and other academics used to writing for journals who hadn't changed their layouts since the invention of moveable type.

Re:CoffeeScript is a bandage over a horrible wound

[Anonymous Coward]

We need to get rid of what is actually the biggest mistake ever made in the field of computing.

Hey, mysql has nothing to do with client side development.

CSS 2 finally a Recommendation, in other news...

[Carcass666]

Duke Nukem Forever hits stores on June 14, 2011. 2K Games, now the patron saint of lost causes, has agreed to spearhead the shepherding of CSS 3 through the W3C standards process. They have committed to the publishing of CSS 3 as a formal standard by the time Duke Nukem Infinity hits store shelves in 2020.

Re:CoffeeScript is a bandage over a horrible wound

[SanityInAnarchy]

Every aspect of your post is flamebait...

They managed to fuck up the syntax. They managed to fuck up the semantics.

In a few important ways, sure -- things which are fixable, and things which pale in comparison to other mainstream languages. I'd much prefer JavaScript to C++.

They managed to fuck up prototype-based OO.

In what way? It seems to work well in modern browsers.

They managed to fuck up the equality and inequality operators.

No worse than Perl, and from what I can tell, CoffeeScript deals with that problem.

The fact that you need to hide it as much as possible, whether using something like jQuery or CoffeeScript...

Sorry, what?

jQuery isn't even in the same category. It doesn't change the syntax. It doesn't "hide" anything. It provides a useful library abstracting over the DOM, which is not part of the core JavaScript language, and which has similar problems and solutions in other languages -- the obvious example is Hpricot in Ruby (though the cool kids seem to be using Nokogiri these days), and Ruby has none of the issues you just mentioned with JavaScript.

CoffeeScript deals with the syntax, and makes it easy to generate the good parts of JavaScript -- by, for example, replacing '==' with '===', which does what you'd expect '==' to do. I really can't see anything wrong with this. It's exactly like having a preprocessor for C which makes it hard for you to accidentally do unsafe pointer arithmetic.

JavaScript has no redeeming value. There's nothing good about it.

Bullshit. Here's a list of advantages it has over Java, as a language:

1. Actual closures.
2. Functions as first-class variables.
3. Much easier metaprogramming. (It has 'eval' if all else fails.)
4. REPL/commandline, so I can try code out a line at a time.
5. Trivial to implement your own OO inheritance semantics -- just put functions in a hash.
6. Native syntax for hashes (maps), and much better array syntax.
7. Setters and getters that look semantically identical to properties.
8. I'd prefer strongly typed, but I can still pretend it's strongly, dynamically typed. Java forces its anal static type system on me.
9. Equality is a === b. Sucks, but at least it's not (a != null && a.equals(b) for objects, and a == b for primitives. WTF, Java?
10. Embeddable. Ok, Java is too, but the JVM is pretty heavyweight to provide scripting for a non-JVM app.

I could go on. Some of that is opinion, I suppose, but a lot of them are big gaping holes in Java, and really nice features that I wish other languages had. And if JavaScript is still the "biggest mistake ever made in the field of computing," what does that make Java?

I mean, just look at Firefox. Who the fuck thinks it's a "good idea" to write huge portions of a desktop app using JavaScript and XML?

A desktop app that spends its entire day showing you web apps, so that's not going to be as much of a performance difference as you suggest. It also makes it a lot easier for web developers to hack on their own browser, which is very useful. Chrome is written mostly in C++, but extensions are still JavaScript+HTML, so you can go from web developer to extension developer in an afternoon.

Oh, and writing in a higher-level language -- I don't know that I like the XML idea, but JavaScript makes sense here. It's that much less of the browser that can possibly have a buffer overflow.

it's supposedly a "lightweight" browser.

I agree with you here. It started out as the "lightweight" alternative. But hey, the fact that it actually pulled that off for a year or two suggests that it's not the JavaScript or the XML that made it bloated. No, it's the feature bloat.

For years we have been working on DeCSS...

[Anonymous Coward]

For years we have been working on DeCSS, and now they give us a new and improved CSS! Oh wait. One is a Content Scrambling System, and another is a Cascading Style Sheet. Dammit! Where are the acronym police when you need them!

Re:CoffeeScript is a bandage over a horrible wound

[leptons]

is that you HIBOU? fucking troll.

Re:Glad to see it finally achieve recommendation s

[Carewolf]

Forget the CSS Snapshot 2007 link, the article summary has a link to CSS Snapshot 2010. Same thing with the year though, also last updated May 2011.

Re:CoffeeScript is a bandage over a horrible wound

[Anonymous Coward]

Every aspect of your post is flamebait...

Yet you responded and fed the troll anyway... good job.

It's in Ruby

[tepples]

Not all web hosts offer Ruby, and not all web sites are in a position to switch from one host to another based solely on Ruby support. I guess one could just compile .scss to .css before uploading the web site.

Re:It's in Ruby

[kikito]

What a shame.

Two out of three solutions

[tepples]

sticky footer

I'm not familiar with this term "sticky footer", and the page you linked doesn't appear to give a precise definition

How do I place a box to the bottom of another variable height box ?

Outer box is position: relative. Inner box is position: absolute; bottom: 0.

How do I vertically center a fixed-height box within another fixed-height box ?

Google css vertical center gives this page.

no-hack

I'd like to know what you mean by a "hack". Otherwise, I run the risk of every solution I suggest being called a "hack".

Re:Two out of three solutions

[lazy_arabica]

sticky footer

I'm not familiar with this term "sticky footer", and the page you linked doesn't appear to give a precise definition

OK. A sticky footer is a footer (...) that remains at the bottom of a page when there isn't enough content to fill the whole space, but that get pushed below when there is. In short, it's a footer that doesn't move to the middle of the page when it's almost empty.

How do I place a box to the bottom of another variable height box ?

Outer box is position: relative. Inner box is position: absolute; bottom: 0.

This "solution" pulls the positioned box out of the flow, so content may be hidden. Oh yes, of course, we might add some padding to fix this, but what happens when we don't know the height of the box ? Tricky, isn't it ?

How do I vertically center a fixed-height box within another fixed-height box ?

Google css vertical center gives this page.

Your example doesn't work in Chrome. Rejected.

no-hack

I'd like to know what you mean by a "hack". Otherwise, I run the risk of every solution I suggest being called a "hack".

A hack is a solution that feels unnatural. Any way of achieving a goal by abusing a tool that wasn't made for this is a hack. Any brittle solution (ie. local, reasonable changes might totally break it) is a hack. Any solution that violates the spirit of the language / framework it is implemented in is a hack (example: adding additional markup violates the "semantics / content separation" principle).

Re:Two out of three solutions

[tepples]

A sticky footer is a footer (...) that remains at the bottom of a page when there isn't enough content to fill the whole space, but that get pushed below when there is.

Oh, you mean giving an element min-height: 100% of the viewport height, as this page describes.

Your example doesn't work in Chrome. Rejected.

I don't have Chrome installed on this computer. In which web browsers must examples work?

example: adding additional markup violates the "semantics / content separation" principle

Even if an XSLT (EXtensible Stylesheet Language Transformation) style sheet adds this markup?

Re:Two out of three solutions

[Anonymous Coward]

Oh, you mean giving an element min-height: 100% of the viewport height, as this page describes.

Adding any padding to the container totally breaks the layout in Firefox 3.X / Chrome / Safari.

- Horrible scrollbars appear, which is absolutely "correct" according to CSS's buggy box model.
- The footer now overflows to the right of the container.

Here is what I call a brittle solution. Try again :)

I don't have Chrome installed on this computer. In which web browsers must examples work?

Well, it should certainly work on a browser that has over 10% market share and whose rendering engine is seen as state-of-the-art.

Even if an XSLT (EXtensible Stylesheet Language Transformation) style sheet adds this markup?

Yes, that's a solution, but XHTML becoming a second-class citizen with HTML 5, it won't remain applicable in many work environments.

Re:Two out of three solutions

[tepples]

Adding any padding to the container totally breaks the layout in Firefox 3.X / Chrome / Safari.

Then put html,body { padding: 0 } and put padding on the inner elements instead.

Yes, that's a solution, but XHTML becoming a second-class citizen with HTML 5, it won't remain applicable in many work environments.

I was under the impression that the XML serialization of HTML5 was still coequal with the custom kinda-sorta-SGML serialization. When did this change?

The great thing...

[CondeZer0]

...about [web] standards is that there are so many crappy ones to choose from.

That said, I thank all deities ever dreamed up that CSS is not an an XML dialect, the semantics are a mess, but at least its got a minimally sane syntax, which is quite a rarity this days (JSON is another rare exception).