CSS Proposed 20 Years Ago Today

An anonymous reader writes: On 10 October 1994, Opera CTO Hakon Lie posted a proposal for Cascading HTML style sheets. Now, two decades on, CSS has become one of the modern web's most important building blocks. The Opera dev blog just posted an interview with Lie about how CSS came to be, and what he thinks of it now. He says that if these standards were not made, "the web would have become a giant fax machine where pictures of text would be passed along." He also talks about competing proposals around the same time period, and mentions his biggest mistake: not producing a test suite along with the CSS1 spec. He thinks this would have gotten the early browsers to support it more quickly and more accurately. Lie also thinks CSS has a strong future: "New ideas will come along, but they will extend CSS rather than replace it. I believe that the CSS code we write today will be readable by computers 500 years from now."

Comments

They _Should_ Replace It

[Anonymous Coward]

I’m sure this won’t be the only "css" sucks comment. I didn't like css when it first came out, I didn't like it when it became supported enough to use, and I still don't like it.

For styling and formatting it’s ok, but for layout it is a convoluted mess. Grid based layout is a standard of just about every UI engine for a reason we like stuff to line up, we like stuff to scale gracefully, and grid based systems work very well for both. "But.. but.. in html tables were made for text" I can hear some web dev whine. That doesn’t mean the whole concept of grid based layout should be tossed out and replaced by the clusterfuck that is CSS layout.

Simple things like a complex form, which would be trivial with a grid (and are trivial with tables) are an epic pain with CSS layouts. And what great benefit has it given us? Panels that float around the screen (and break if something is resized, zoomed in, or a block of text is larger than expected).

And detaching content from style epic failure. The oft referenced CSS Zen Garden is to me an illustration of exactly how CSS failed at this goal. The layout is still being largely defined by the HTML. You can only _somewhat_ adjust how things are positioned in relation to each other with CSS, which requires you to have multiple layers of nested <div id="random_section_that_you_might_use_for_something_or_not"> to give the kind of flexibility that CSS Zen Garden does. Actually take a look at the HTML for those pages. This is not an example of how things should be done.

Re: They _Should_ Replace It

[Anonymous Coward]

Yes. Just so much yes. 20+ years of dev experience here and I couldn't have said it better myself.

Re:They _Should_ Replace It

[Anrego]

You can only _somewhat_ adjust how things are positioned in relation to each other with CSS, which requires you to have multiple layers of nested <div id="random_section_that_you_might_use_for_something_or_not"> to give the kind of flexibility that CSS Zen Garden does.

That's actually no longer totally the case. There is even a comment in the code:

<!--

        These superfluous divs/spans were originally provided as catch-alls to add extra imagery.
        These days we have full ::before and ::after support, favour using those instead.
        These only remain for historical design compatibility. They might go away one day.

-->

That said, I totally agree with everything else you said. CSS is an example of fixing a barely existent problem by introducing a bunch of major ones. Tables worked fine, and could have been cleaned up or replaced/augmented by something made for layout.

I'm not a web developer, so maybe you grow to like it, but I always found div based layout unintuitive as hell ("oh, I need to float left this div to make it centered and set the block to inline"). I still just use tables any time I dabble with that stuff. They still work!

Re:They _Should_ Replace It

[ndato]

Cascading HTML style *sheets*... it sounds like sh.t to me

Re:They _Should_ Replace It

[Anonymous Coward]

There should have been some ellipsis in there. Damn unicode.

Re:They _Should_ Replace It

[wiredlogic]

That's because web pages aren't supposed to give fine grained control of layout. Switch to PDF or campaign for browser support of XSL-FO if you want to control layout.

Re:They _Should_ Replace It

[MobyDisk]

So why not just use tables for layout then?

Re:They _Should_ Replace It

[FictionPimp]

Using a fluid grid based css layout is faster, easier to write/understand/support, and a hell of a lot cleaner than tables. Having done web development for the last decade I have to say that tables for layout was a pain in the ass and a bad hack at best.

With html5/css3 almost all of your concerns are gone. In fact you can download a nice fluid grid based template in a second that can cut your table based layout development time into a 5th.

Check out http://www.getskeleton.com/ or even the often overused http://getbootstrap.com/

Re:They _Should_ Replace It

[Anonymous Coward]

Yup!

I like to use csszengarden as a counter example (it kinda pisses off the css fanboys too, so added bonus!).

Go to the site, pick 5 random designs. Then try resizing your browser window and seem how many of them are still usable (hint: not many). Breakage ranges from information not displayed with no scrollbar to outright failure where all the elements are pushed off the page.

I randomly picked one: http://csszengarden.com/219/

I'll admit, this is impressive visually (although major form over function, as a way of conveying actual information it's pretty bad). They've even done some resize handling, such that it adjusts itself and provides scroll bars if you make the browser narrow horizontally or small but still mostly rectangular. This is better than most! But then we try keeping the browser wide and making it narrow vertically (I actually do this quite often if I'm monitoring something in the background while reading something), and we have content cut off with no scrollbars!

Three things can be taken from this:
1) In CSS, scaling is not at all automatic as it would be with tables, it's something you specifically have to design for
2) Even when you do design with scaling in mind, it's still easy to miss something
3) You didn't get this shit with tables.

Now I'll grant you that complex designs like 219 probably wouldn't be feasible with tables, but I still hold that CSS introduced a lot more problems then it solved, and they still plague us.

I say keep the formatting parts of CSS, ditch the layout and replace it with something sane, preferably detached from the content (actually detached, not just "kinda").

Re:They _Should_ Replace It

[Anonymous Coward]

Grid based layout is a standard of just about every UI engine for a reason we like stuff to line up, we like stuff to scale gracefully, and grid based systems work very well for both. "But.. but.. in html tables were made for text" I can hear some web dev whine. That doesn’t mean the whole concept of grid based layout should be tossed out and replaced by the clusterfuck that is CSS layout.

The problem with tables is that they generally were very inflexible. Trying to resize your browser (back in the day) often caused strange layout issues (and lets not forget the 1px transparent GIFs). Nowadays you have mobile devices of various sizes and resolutions and orientations in addition to browser to worry about.

I think part of the problem is some designers that want the control of Adobe Illustrator or InDesign, with PDF output, and having everything "pixel perfect", when the web should be treated in a much more flexible way.

Re:They _Should_ Replace It

[itsdapead]

I’m sure this won’t be the only "css" sucks comment.

You missed the absence of any sort of variables/constants to let you (e.g.) assign a logical name to a frequently used colour or a standard indent width. Preprocessors like "less" are a great help, of course, but I can't believe a simple macro substitution facility or simple expression evaluation would have over-taxed even 20 year-old hardware.

Then there's the bizarre box model where the size of the contents, border, inner and outer margin are all conflated - even Microsoft's mis-implementation made more sense. Or the simple, but completely non-obvious incantations to make a div act as a container, or auto-clear floats. I still can't get my head around list formatting.

Basically, you're left with the feeling that the designers of CSS had never used a DTP package, never used styles in a wordprocessor package, never used a UI layout manager or, for that matter, ever seen a website.

TFS was also right on the money in one respect: a standard with neither a test suite or a reference implementation is no standard at all. The whole set of web standards suffers from the delusion that (maybe outside of pure mathematics) you can reliably specify a complex system without non-trivial exemplification.

Re:They _Should_ Replace It

[Animats]

Agreed. The float/clear approach to layout is 1-dimensional, and just stupid. Someone suggested using some boilerplate library for grid-based layout. That's a horrible hack; it gets vertical alignment with code like .container .two.columns { width: 76px; }. "Fluid layout", hah! Some libraries have a layout engine written in Javascript. There's far too much fixed-width stuff like that since CSS came in. With tables, you can express width as a percentage of the page, or let cells self-adjust to content width. Tables have come back for layout purposes. They're now called "layout tables", to avoid humiliating the CSS fanboys. They're just tables.

Then there's absolute positioning, or "now the layout can be screwed up so bad that some text is off the page and can't be reached by scrolling".

Re:They _Should_ Replace It

[Anonymous Coward]

I still do, no matter how much CSS asslickers complain about it.

Re:They _Should_ Replace It

[AC-x]

Simple things like a complex form, which would be trivial with a grid (and are trivial with tables) are an epic pain with CSS layouts.

Sure in the pre-IE8 days it was a pain, but now it's trivial to do .form { display:table; }

Re:They _Should_ Replace It

[TechyImmigrant]

>I’m sure this won’t be the only "css" sucks comment.
You're not wrong. Can I mention inheritance, or the lack thereof?
FFS, I want to say - "This is like that but with this thing changed"
This is probably why every CSS preprocessor adds inheritance. Because it's missing from CSS.

My analysis is that the authors who drafted it were browser writers, not web content developers, who wanted something that slotted right into their data model.

Re:They _Should_ Replace It

[BarbaraHudson]

I believe that the CSS code we write today will be readable by computers 500 years from now."

If we're still using CSS 500 years from now, we're screwed. Heck, we better have something a whole lot better than web pages 500 years from now.

500 years? Look at what's come and gone in the last 50, and get back to me.

Re:They _Should_ Replace It

[Anonymous Coward]

I’m sure this won’t be the only "css" sucks comment.

You missed the absence of any sort of variables/constants to let you (e.g.) assign a logical name to a frequently used colour or a standard indent width. Preprocessors like "less" are a great help, of course, but I can't believe a simple macro substitution facility or simple expression evaluation would have over-taxed even 20 year-old hardware.

Firefox implemented CSS variables back in version 31. Your claim is false.

Re:They _Should_ Replace It

[Anonymous Coward]

None of those actually use CSS Grid Layout because no browsers fully support the current spec by default yet.

Re:They _Should_ Replace It

[Anonymous Coward]

You've just demonstrated your own stupidity for all to see. Those are javascript solutions to css's inability to make a table or grid layout that works well. Please eat a node.js reference and stab your self with a shiv made from your php or (g)rails book cover. You are the problem.

Re:They _Should_ Replace It

[FictionPimp]

Right,

But it still a fluid grid based layout that is all CSS and works in all modern browsers. It's easy to use, flexible, and looks great on a mobile device or a 27 inch display (if you have good artistic sense).

While it would be nice to more support for css grid, this does the job today and works wonderfully with dozens of prebuilt css files out there to start from (some even using tools like less to make modification that much easier).

Re:They _Should_ Replace It

[Anonymous Coward]

You're not wrong. Can I mention inheritance, or the lack thereof?

What part of 'cascading styles' leads you to believe there's a lack of inheritance?

FFS, I want to say - "This is like that but with this thing changed"

.this, .that {
// common properties
}

.this {
// things changed
}

Perhaps you should spend more than five seconds learning CSS?

Re:They _Should_ Replace It

[squiggleslash]

I can't comment on getskeleton, I've never heard of it and the one page summary is about as useful as a chocolate teapot, but I do use Bootstrap, and while it can produce nice results (yay responsiveness), I'm not remotely convinced it is somehow better than tables in terms of producing websites that separate content from presentation. You end up building tables anyway, except that instead of using tr/td you use divs with row/col-md-694 classes.

It's actually as if Bootstrap's designers know that actually you want to use tables but know it's politically incorrect to use them...

(Again, before you yell at me, yes, I like the fact there's some degree of responsiveness not possible with 1995 HTML tables, but you have to wonder whether if HTML had evolved with something other than CSS, we'd have a responsive websites system built around the tables designers have always found easier to use.)

Re: They _Should_ Replace It

[Anonymous Coward]

What if I want .somethingElseThatsLikeThisExceptSomething

I only dabble, so legit question. Can I "extend" .this without replacing it.

Re:They _Should_ Replace It

[FictionPimp]

You've just demonstrated your own stupidity for all to see. Skeleton does not use javascript.

In fact,

From the website you will see this nice changelog

V1.2 (6/20/2012): Pruning Skeleton down to some more bare bones :)
Remove tabs and all JS

Boostrap does use javascript, but not for the grid layout portion of boostrap. It uses it for all the other shit boostrap does. I picked these two examples because I feel the represent the two most popular, but there are dozens if not hundreds of projects out there that solve this problem. Many do not use javascript.

Re:They _Should_ Replace It

[RabidReindeer]

Grid based layout is a standard of just about every UI engine for a reason we like stuff to line up, we like stuff to scale gracefully, and grid based systems work very well for both. "But.. but.. in html tables were made for text" I can hear some web dev whine. That doesn’t mean the whole concept of grid based layout should be tossed out and replaced by the clusterfuck that is CSS layout.

Simple things like a complex form, which would be trivial with a grid (and are trivial with tables) are an epic pain with CSS layouts. And what great benefit has it given us? Panels that float around the screen (and break if something is resized, zoomed in, or a block of text is larger than expected).

And detaching content from style epic failure. The oft referenced CSS Zen Garden is to me an illustration of exactly how CSS failed at this goal. The layout is still being largely defined by the HTML. You can only _somewhat_ adjust how things are positioned in relation to each other with CSS, which requires you to have multiple layers of nested <div id="random_section_that_you_might_use_for_something_or_not"> to give the kind of flexibility that CSS Zen Garden does. Actually take a look at the HTML for those pages. This is not an example of how things should be done.

Well, after all, it's Cascading style Sheets. There's nothing in CSS itself that actually bounds an area - it has to borrow a container from HTML, be it DIV, TABLE, BODY, or whatever and define space within or relative to it.

I never bought into the "don't use tables" nonsense myself. Tables provide abstract organization of layout. It's a lot cleaner to apply some CSS to a table than to shoehorn it in to a whole lot of divs just for maintaine Ideotlogical Purity..

Re:They _Should_ Replace It

[jandrese]

CSS Zen Garden examples always kill me because they fall back to fixed positioning (which is horrible on phone screens, and one thing we were trying to get away from with CSS in the first place!) way too often. My first exercise with CSS was to create a slashdot style layout, with fixed columns on the left and right and the remainder of the space taken by an automatically re-flowing column of text/pictures in the middle. For a bonus I wanted the left and right columns to collapse if the screen got too narrow (smartphone). This turned out to be...challenging in CSS.

I also think that too many people threw the baby out with the bathwater when they ditched table based layouts entirely. There are lots of places where you have to got through a lot of effort to replicate in CSS what was relatively easy with tables, like making webforms. That three column layout I mentioned above is also dirt simple to do if you allow yourself to wrap the whole page in a giant table.

Re:They _Should_ Replace It

[Man On Pink Corner]

If the standards do not respect the users, the users will not respect the standards.

Re:They _Should_ Replace It

[Anonymous Coward]

He posted his comment 19 minutes before your comment.

Firefox was on version 23 back then.

Re: They _Should_ Replace It

[Anonymous Coward]

Dude, they SHOULD be pixel perfect.
Pixel perfection is not incompatible with flexible layouts. More so, layouts that scale nicel but have pixel perfect sync between areas instead of some random stupid element crapping itself. (Literally all input elements, for example!)

The worst feature, well, lack of, is vertical layout. Murdering myself trying to just get things right, suddenly there is one simple rule, box-model, that completely changes everything and it wor... NOPE, since we used those good ol' negative margins, now yer going to have to fiddle around with those pesky z-levels.

Flex box should have been in CSS1! After all, those divks were the ones wanting to add fantastic layout control to get away from tables, but instead literally just made syntactically meaningless DIVs with class bloat.

It is like arguing with a GOTO IS EVIL types when all of this comes up, then they go and use things like break, continue, branching statements everywhere! Bah, screw them all. Everyone should just do what they want until flex box is ironed out, then things will be less awful

Re:They _Should_ Replace It

[FictionPimp]

Let's face it, grid based layouts are tables and if all websites were static html, then html tables would suit us just fine. If we didn't want to cater to people with disabilities or screne readers then again, tables were fine.

It's a lot easier to replace, remove, or add a class on a article or div with javascript then to try to reflow a html table based layout (like when you go mobile and turn that 3 column layout into a single column. . It's a lot easier to parse the html to do something with it (like screen read) if you don't have a bunch of junk spacer images, tr's and tds, cluttering up the mix.

I wouldn't be opposed to something better than css, but I still think css layout is better than html table layout.

Re:They _Should_ Replace It

[JohnFen]

I do for my own web pages. The problem is that most of the pages on the web at large use CSS, and so the problems with CSS remain my problem regardless.

Re: They _Should_ Replace It

[Anrego]

It _kinda_ does if you do as was said and define all the common properties for both and then the specific properties for each individually.

It's not really inheritance as you would find in c++ or java, and not nearly as flexible, but it is kinda there.

Re:They _Should_ Replace It

[Anonymous Coward]

Two reasons not to use tables for layout on the web:

1. Tables are meant for tabular data. The table tag has a semantic meaning that is very different from layouting. This can cause trouble for blind people using screen readers to view web pages. The screen reader sees a table, thinks it is important information, similar in importance to a paragraph of text, and starts reading out it's contents. This works fine as long as the table tag is used for user digestible information as it was intended, but not when the entire page is one giant table full of menus, links, logos and other cruft. Any other software parsing webpages to extract meaning could run into the same issue.

2. As a consequence of point 1, the design and implementation of the table tag meant that tables would not be displayed on the page before the contents of the entire table were downloaded. (a table with missing values doesn't make much sense) So if you were to make a webpage as one giant table, then the entire page would only be displayed once all the contents of that table, such as images and walls of text were entirely downloaded. This meant if you wanted your website to be as responsive as possible, you would better avoid tables for layouting. I don't know if this particular issue is still relevant today with modern browsers.

Re:They _Should_ Replace It

[JohnFen]

The problem with tables is that they generally were very inflexible.

True, but this problem can be worked around by using dynamically generated web pages -- which brings an additional benefit of still separating layout from content, if you feel that's important.

Trying to resize your browser (back in the day) often caused strange layout issues (and lets not forget the 1px transparent GIFs).

A problem that CSS has not actually resolved, judging by the number of websites that become unusable when I make my browser window my preferred size.

Re:They _Should_ Replace It

[Noah Haders]

not to mention nuclear war, climate change, etc. who knows if we'll even be using computers in 500 years? oh yeah and the impending singularity. we'll all become beings of light.

Re:They _Should_ Replace It

[Lennie]

Luckily I'm seeing more and more of these issues being solved with newer CSS standards:
http://www.w3.org/TR/css3-mult...
http://caniuse.com/#feat=multi...
http://www.w3.org/TR/css3-flex...
http://caniuse.com/#feat=flexb...

Re:They _Should_ Replace It

[BarbaraHudson]

How about "In the Singularity, computer becomes YOU!"

Re:They _Should_ Replace It

[Noah Haders]

fair enough. if we all become beings of light, we'll likely still want to have some physical manifestation. we'd have to design the layout of this manifestation in some way, and I guess CSS could be of use here.

Re:They _Should_ Replace It

[SQLGuru]

Another feature that I would love to see in CSS is "relative to another element" via a selector.

Some Content

That is multiple lines tall

More Content

.SecondContainer{
height: ||.SomeContainer||.height
}

That should make layout simpler.

Re:They _Should_ Replace It

[AqD]

Not just CSS, the entire HTML/CSS stack should be ditched.

It was never intended for the sort of sophisticated UI we're doing on web today. It lacks abstraction and as a result complex visual representations have to be achieved by even more complex pieces of boilerplate code that couldn't be simplified, and even more difficult to be debugged - that is assume the design is largely correct, which it isn't.

It's like CISC/x86 assembly language with the performance of QBASIC. While I never liked plugins and google native client as an end-user, they're the only ways to implement things correctly, by bypassing the web entirely. I hope the flooding of apps on tablet and desktop will kill it one day.

Re:They _Should_ Replace It

[Anonymous Coward]

a decade? You're a newbie partner, barely getting started, a journeyman, a beginner, hardly even trained and eager the lap up what you've been told because you don't have the experience to actually form your own opinion. no worries though, we were all pretty green at one point, eventually you'll know what you're talking about. tell you what, come back to me in another decade and tell me all your wisdom.

Re:They _Should_ Replace It

[ShanghaiBill]

Look at what's come and gone in the last 50, and get back to me.

In the world of software, plenty of things have come, but nothing has gone. Any program from 50 years ago will still run today. You can still find compilers for the earliest versions of Fortran, Cobol and Lisp. There are emulators for any machine you can think of, so you can still run the binaries as well. He didn't say that CSS would be in widespread use 500 years from now, just that it would be readable. Unless civilization collapses, that is likely to be true.

Re:They _Should_ Replace It

[Anonymous Coward]

"Using a fluid grid based css layout is faster, easier to write/understand/support, and a hell of a lot cleaner than tables."

sources please, other than fanboism?

Re:They _Should_ Replace It

[K. S. Kyosuke]

Switch to PDF

For example by using PrinceXML? ;-)

Re:They _Should_ Replace It

[Tablizer]

Tables have one nice feature lacking in CSS equivalents: you can switch on the borders to visually study the cell boundaries using BORDER=1. And the equivalent of VALIGN control in CSS is either a mess or broken in existing browsers.

Re:They _Should_ Replace It

[FictionPimp]

My source is that for me, it's faster, easier to write/understand/support and a lot cleaner.

This is a subjective opinion.

Can you prove that tables are easier for me to understand?

Re:They _Should_ Replace It

[Animats]

Another feature that I would love to see in CSS is "relative to another element" via a selector.

Handling layout as a constraint-based system would be promising. If you could represent layout with "upper left corner of box A coincident with upper right corner of box B", or "left edge of box B coincident with right edge of box A", you could represent any box layout. This isn't a notation to be written as text by humans; it's something you do in a layout GUI. Autodesk Inventor, which is a 3D CAD program, has a constraint solver for things like this. 2D is much easier. You could even support curved box boundaries. The browser has to run a constraint solver, but that's not hard for the rectangular-box case.

In the end, CSS didn't matter, because now everybody uses some non-HTML "content management system".

Re:They _Should_ Replace It

[BarbaraHudson]

A LOT of things have gone. 12" floppies. 8" floppies. 5-1/4" floppies. 3-1/2" floppies. The programs with copy-protection built into those floppies won't run, even with an emulator. All those custom program backups stored on burnable optical disks that are now suffering chemical degradation?

How many computers still have the original cassette tape interface? Or a parallel port. Or a game port? Or can use a serial or ps2 mouse? Or a slot for a hercules card? So the software that uses them? Dead.

500 years from now web browsers will also be dead. They're far from the ideal way of delivering information.

Re: They _Should_ Replace It

[cyber-vandal]

So what. Firefox isn't the only browser. Good luck getting them to work in older versions of IE.

Re:They _Should_ Replace It

[ShanghaiBill]

A LOT of things have gone. 12" floppies. 8" floppies. 5-1/4" floppies. 3-1/2" floppies.

That is not software. That is media.

The programs with copy-protection built into those floppies won't run, even with an emulator.

The copy protection on floppies has always been trivial to defeat.

How many computers still have the original cassette tape interface? Or a parallel port. Or a game port? Or can use a serial or ps2 mouse? Or a slot for a hercules card? So the software that uses them? Dead.

No. All of these interfaces can be emulated.

Re:They _Should_ Replace It

[BarbaraHudson]

A lot of programs never made it from, say 5-1/4" media to another media. They had their heyday, and were then withdrawn from circulation. They are GONE. Even the original publisher no longer has them - if the publisher still exists. And any backups out there are unreadable after 40 years.

Same applies for the 3-1/2" floppies from 30 years ago. Especially with multi-floppy disk sets. It only takes one disk to crap out. So even the pack-rats no longer have a readable copy. The publisher is dead, the author quite possibly as well, and since stuff that was so much better has come along, the old stuff got thrown in the trash because you couldn't even give it away - same as an old-style color TV today.

Re:They _Should_ Replace It

[ShanghaiBill]

Check out http://www.getskeleton.com/

Okay, I did. The layout breaks when I resize, using Firefox. It would not break if the page used tables with the "colspan" property. CSS is harder to write than tables, and more fragile. Many common tasks are easy with tables, but basically impossible with pure CSS. An incredibly common task, is to center one element inside another. Yet CSS can't do that in the general case. Your only options are: 1. Use hard coded element sizes, 2. Use some non-portable hack, 3. Use tables, 4. Use Javascript. CSS is great in theory, but the actual implementation is horrible. For instance, it would be so nice if the "vertical-align" property controlled the vertical alignment.

Re:They _Should_ Replace It

[CauseBy]

If you like grid layouts then you can do grid layouts in CSS, can't you? What am I missing?

Re:They _Should_ Replace It

[Anonymous Coward]

CSS3? Modern browsers? You lucky bastard. I still have to cater for IE7. If grids had been in CSS 1 or 2 I would be much happier.

Re:They _Should_ Replace It

[Anonymous Coward]

Yup.

It has become trivial to keep data around forever, but that doesn't mean people bother.

Even where I work, stuff I produced as early as 7 years ago, that cost money, that was important at the time, is hard to track down and in some cases completely gone.

"Oh, there might be a copy of that on the old svn repo. Hey bill, what did we do with the drives from...".

Re:They _Should_ Replace It

[Anonymous Coward]

And looks like we've got a winner for "least pragmatic statement of the week"!

Re:They _Should_ Replace It

[JesseMcDonald]

There's nothing in CSS itself that actually bounds an area - it has to borrow a container from HTML, be it DIV, TABLE, BODY, or whatever and define space within or relative to it.

I think this is really the core of the problem. We're trying to express three things (layout, style, and semantics) with just two languages, HTML and CSS, which inevitable results in some overlap. Four things really, if you count scripting. CSS covers style and some layout; HTML covers semantics, scripts, and some more layout. To get a particular design you have to mix some elements of HTML with some elements of CSS. Using HTML tables for layout did have some legitimate usability issues, but turning some arbitrary <div> tag into a table via CSS doesn't really solve those issues. The one advantage which that brings is reserving the <table> for semantically tabular data, which is something, but you still need to arrange your HTML tags to match your intended presentation. You can't separate the semantics from the presentation because you need those "hook" elements in the HTML in order to apply your CSS styles.

There should be a top-level hierarchical layout description which references or embeds, with a strict boundary line, the semantic content and the stylesheet(s) to be applied to it. This layout portion would describe how the screen area is to be divided up into multiple content areas (boxes, grids, tabs, floating windows, etc.), whether those areas support scrolling, where to source the content from, and so on. Any scripts would be run in the context of the layout document; this is essentially the "application" portion of the web page. The semantic portion should not be capable of describing styles or positions, just the plain content with purely semantic tags, the presentation of which would be defined in the stylesheets. You could embed arbitrary content into a layout, but not vice-versa. The content and style languages should be "safe"—no embedded scripting. If you needed the document to be interactive then you could attach scripts to semantic tags at the layout level.

Re:They _Should_ Replace It

[srijon]

+1. Lets also not forget there is no good designer tooling story for CSS. With good-old-fashioned DTP apps, you could create a named style in your style catalog, click on an element in the document, and apply that style to it. You could even create based-on styles to manage large style catalogs. With the first wave of DTP apps, we gave designers WYSWIG, Drag-and-drop, and all that good stuff. But CSS didn't support this at all. Instead, designers had to learn to write CSS code in a code editor and then debug a non-trivial rule-based runtime. How many hours have we all spent sitting down with designers trying to debug some quirky CSS selector mess. What a headache. CSS slowed down good web design by years. Sure, CSS beats but we could easily have improved on by adding a few more layout tags to HTML, such as , , etc, like you find in most other content presentation frameworks. That, plus a simple named-style catalog with variables and based-on would have been so much more appropriate and effective.

Yes, the whole detach content from style is an epic fail. Because the HTML DOM *is* a presentation layer, not a business-content layer. Its got loads of presentation-specific tags, its just missing the ones that we actually need for responsive layout. A more useful content-presentation separation would be more like MVVM (Angular notably heads in that direction).

Re:They _Should_ Replace It

[srijon]

+1. Lets also not forget there is no good designer tooling story for CSS. With good-old-fashioned DTP apps, you could create a named style in your style catalog, click on an element in the document, and apply that style to it. You could even create based-on styles to manage large style catalogs. With the first wave of DTP apps, we gave designers WYSWIG, Drag-and-drop, and all that good stuff. But CSS didn't support this at all. Instead, designers had to learn to write CSS code in a code editor and then debug a non-trivial rule-based runtime. How many hours have we all spent sitting down with designers trying to debug some quirky CSS selector mess. What a headache. CSS slowed down good web design by years. Sure, CSS beats but we could easily have improved on by adding a few more layout tags to HTML, such as , , , etc, like you find in most other content presentation frameworks. That, plus a simple named-style catalog with variables and based-on would have been so much more appropriate and effective.

Yes, the whole detach content from style is an epic fail. Because the HTML DOM *is* a presentation layer, not a business-content layer. Its got loads of presentation-specific tags, its just missing the ones that we actually need for responsive layout. A more useful content-presentation separation would be more like MVVM (Angular notably heads in that direction).

Re:They _Should_ Replace It

[Grishnakh]

I'm not a web dev professionally, but I'm pretty sure you're wrong about centering elements inside each other. It doesn't have an explicit way of doing it, which is rather dumb, but you have to create a div within a div, and then set the margins in the CSS to "auto".

Re:They _Should_ Replace It

[Grishnakh]

Firefox implemented CSS variables back in version 31. Your claim is false.

Is that part of the CSS standard? No? Then it's irrelevant.

Re:They _Should_ Replace It

[Anonymous Coward]

I have a hard time believing it is easier for a screen reader to follow the flow of information with CSS than tables, despite empty shim/spacer images that were often used in tables.

Re:They _Should_ Replace It

[RedSteve]

I never bought into the "don't use tables" nonsense myself. Tables provide abstract organization of layout. It's a lot cleaner to apply some CSS to a table than to shoehorn it in to a whole lot of divs just for maintaine Ideotlogical Purity..

In my experience, a "simple" table layout still has more markup than an equivalent div layout. A three-column table layout will require a table, tbody, tr, and three td tag elements, all properly nested. A three-column div-based layout requires three div tags, possibly contained in a fourth div. That's hardly shoehorning.

Re:They _Should_ Replace It

[Art3x]

For styling and formatting it’s ok, but for layout it is a convoluted mess.

I'm one of the few who think you should not use CSS for layout.

If you use CSS for fonts, color, bold, italic, margins, padding, it's fine. What do these things have in common? They're traits of a box with little consideration about its relationship with other boxes. Margin sort of is, but it's just saying, "Keep this far away from me." These CSS properties are all sort of self-centered.

And then for layout if you use HTML, in particular, HTML tables, life is easy. At this point I casually step behind an embankment, to hide from the onslaught by the standardistas. They complain that using a table is not "semantic." Well, guess what? If you use a list tag for things that don't line up vertically, then you're also being unsemantic, because "list" meant "strip" or "edge," because the text lined up along a common edge. "Paragraph" means "a mark beside," so if you're not putting pilcrows beside each paragraph you're being unsemantic.

What does it even mean that tables should only be used for "tabular data"? Isn't that a tautology? It's like saying, only pour water on things that are already wet.

Cascading Style Sheets come from the style sheets publishers have used for years. Pre-Internet desktop publishing software like Quark had style sheets too. And neither letterpress nor desktop publishers used these stylesheets for layout to the extent that people say we should use CSS for it.

Re:They _Should_ Replace It

[StripedCow]

It would be running in a browser in ugly-quirks mode inside an emulator inside an emulator inside an emulator.

Re:They _Should_ Replace It

[Anonymous Coward]

So you want to force <table>s on people who prefer CSS? Try to be more liberal in what you accept.

Re:They _Should_ Replace It

[WillKemp]

What does it even mean that tables should only be used for "tabular data"? Isn't that a tautology? It's like saying, only pour water on things that are already wet.

No, not even close.

Tables should only be used for tabular data because tables have a semantic meaning. Making layout look like it has some meaning is stupid. If you only ever think in terms of sighted people looking at your web pages, then i guess you don't care. If you care about people using screen readers, etc, then maybe you should care.

Re:They _Should_ Replace It

[Dynedain]

Because using tables for layout was itself a hack.

Tables were meant for tabular content. You know, the kind of thing you might get out of a spreadsheet or report. The nice thing about tabluar content structure is you can have sort controls, or headers, footers, etc.

Try to achieve today's web designs with tables, and then try to place tabular content in the page.... yeah, good luck separating them and styling properly without CSS.

The worst part about table based layouts was that if you needed to remove or add something to the layout, you had to rework the entire layout table to make it work.

Re:They _Should_ Replace It

[ShanghaiBill]

you have to create a div within a div, and then set the margins in the CSS to "auto".

No. That only works for horizontal centering. There is NO WAY to center an element inside another element with pure CSS that will not fail in some cases. There are THOUSANDS of webpages addressing this issue, and many of them even say "this is how you do it", but ALL of them either fail in some cases, or use tables and/or JavaScript. Centering an element is one of the most trivial layout tasks, and CSS can't do it, which is incredibly lame.

Re:They _Should_ Replace It

[Euler]

Ahh, the classic arguments. I'll avoid my tirade about people who move the goalpost on every web-related standard rather than accepting success and moving on with new actual ideas. But I'll settle that you can have CSS layout and I'll use tables when I damn well feel like it. 20 years of evangelism hasn't really made the web a cleaner place. "Improving" web standards always missed the point that what we have is what we have; old pages will not get updated so we still support them. HTML 5, or whatever is fine, but browsers still have to support what is out there.

1) "Tables are for tabular data" Yeah, 'ya know why? Because tables are precise and predictable. Will puppies and and kittens die if I use tables for layout? No. You cannot deprecate tables and their ability to hold other elements because I could always claim that a series of pictures, links, and text is my tabular set of data. Therefore, why have this argument? Sub-argument: "blind people will be screwed" No, and how does CSS solve that problem? Are the rest of us to continuously suffer layout glitches? CSS creates a series of sections that don't specifically have a semantic order or significance either. The very definition of Zen garden is the ability to re-arrange parts of a web page in any visual orientation. The fundamental problem is that people create pages with too much complexity whether it be nested tables or CSS placement. If we can't design software that could use a few heuristics to locate the main text of a page, then the page is too complicated to be useful, or your screen reader sucks.
A few meta-tags, and reasonable discipline on nested tables would have been the simple approach to this supposed problem. Most web pages I see are still a basic 3-panel with header navbar and boilerplate footer. Anything else gets too complicated.

2) "The page has to totally load first" Not really a problem since tables have a variety of ways to define width, justification, etc. Plus, why do I care what a page looks like while it is downloading? This isn't 1994 anymore, we have decent bandwidth. Most websites that actually have tabular data like forums, Facebook, etc. ironically use some form of dynamic content anyway which is far more abusive in terms of the page layout changing unexpectedly. We may as well just deprecate scroll-bars, because they behave erratically when a webpage loads more content halfway through scrolling down a page.

CSS is a great way to take out the redundancy of style and font tags everywhere, but I think the idea of CSS layout is just confounding.

Re:They _Should_ Replace It

[Grishnakh]

No. That only works for horizontal centering

That's what I was talking about. I didn't realize you meant both vertically and horizontally.

Yes, it is rather lame.

Re:They _Should_ Replace It

[Anonymous Coward]

Being able to easily use an extremely convoluted framework made by someone else does not mean CSS is good. I know ignorance is bliss, but ignorance doesn't change reality.

You should try to create a "fluid grid based CSS layout" without using any kind of framework, only code you typed yourself. You'll see how bad CSS really is.

Re:They _Should_ Replace It

[Euler]

My tabular data happens to be an array on navbar buttons.

CSS is great - for controlling style.

Re:They _Should_ Replace It

[Bite The Pillow]

You need a third party framework to make better tables than tables?

When layout matters, and things need to be where I put them, tables are predictable. Absolute positioning works well if you want to support a single resolution.

The number of times we have had a blog post with the "holy grail" of any arbitrary layout is ridiculous. A fluid center column with a left and right column sized to content, is as common as it is frustrating. I'm sure you can wave your hand and pull the best off the top of the pile. But it's been a long hard road to get this far.

I've spent far too much time chasing down a CSS oddity to give a shit at this point. I don't get paid for clean. Maybe it's better now, but I'm not wasting any more time learning another framework just to do what tables already do.

Re:They _Should_ Replace It

[Euler]

Exactly, since approximately 1998, I haven't understood why we still called the web 'high'tech.' There is most certainly better ways to represent the information than HTML/CSS/Javascript.

It doesn't take much technology to design protocols and client/server apps to exceed this.

Phone apps and video games are really the only thing that seems able to break through this mindset. But they are all purpose-built. A generalized alternative to the http/html web is conspicuously absent.

Re:They _Should_ Replace It

[Euler]

totally, I thought that was just me that did stuff like that. I'm a very test-compile-test type programmer.

Even more points for actually using the header part of a table. For all the semantics evangelists people who say tables are for tabular data, I see hardly anyone using that effectively.

Re:They _Should_ Replace It

[Euler]

What is the semantic meaning of a div tag? How do I know where that div appears in logical order?

Re:They _Should_ Replace It

[Euler]

Exactly, I never understood why purging tables was so important yet we have let slip every list, paragraph, frameset, dynamic content, obfuscated Javascript, flash applet, hover elements, etc.. I feel the web is nearly unusable at this point and we cannot blame tables, not in the slightest.

Re:They _Should_ Replace It

[Anonymous Coward]

What if, six months later, I want theOther? I've never seen inheritance where you have to define the possible subclasses up front when you create the superclass.

Looks half-assed, to say the least.

Re: They _Should_ Replace It

[Anonymous Coward]

The principle of CSS was an awesome idea. The design sucks because of the limitation of the author. HÃ¥kon is not a skilled programmer and when he implemented it, he did what was within his limited skills. He isn't the type of person who understands things like lexers and parsers. He instead did what could be done using his limited abilities with string compare functions. As such, we ended up with yet another standard based on the shit skills of the original developer.

I am looking forward to a day when most HTML, CSS and JavaScript are generated from a clean language.

Re:They _Should_ Replace It

[Dogtanian]

How many computers still have the original cassette tape interface?

It's strange to think that even the original 1981 IBM PC (*) included a cassette interface. Can you imagine loading *any* program on an x86 PC like this?! (**)

I know that cassette decks were still common on home machines (and disc drives expensive) at the time, but on a business machine that cost $1565 at its launch- a little over $4000 in today's money- the concept seems bizarre.

Wikipedia says that very few of them left the factory without floppies, and I suspect that some of *those* were fitted with third-party models. It notes that MS-DOS required disc drives and that without it it defaulted to a ROM-based BASIC implementation... did anyone *ever* buy and use an IBM PC without drives and use it in this way..?!

(*) And the more home-oriented PCjr apparently included it too, but that flopped anyway.
(**) And can you imagine how long it would take to load a modern-sized program at speeds comparable to a Sinclair ZX Spectrum?! We're talking well over a month and a half per gigabyte of data. :-)

Re:They _Should_ Replace It

[BarbaraHudson]

Plenty of early machines used the audio cassette interface to load and save programs. The IBM PC had to include a cassette interface because pretty much *everyone* included one. BASIC is BASIC. Porting from one machine to another wasn't a big deal, and taking a couple of minutes to load or save a program was a lot more acceptable than having to re-enter it every time. Also, those old floppy drives weren't all that much faster.

Re:They _Should_ Replace It

[toddestan]

To be fair, he only claimed it will readable. That doesn't mean we'd be using CSS 500 years from now, but that a computer 500 years now would be able to understand it.

Re:They _Should_ Replace It

[awshidahak]

For a bonus I wanted the left and right columns to collapse if the screen got too narrow (smartphone). This turned out to be...challenging in CSS.

@media selectors are your friend here. You can supply one layout for a smaller, and a different layoutfor everyone else. Check out how I did it by viewing the source of FrillerWorks.com. You'll want to be looking at the link tags under the head.

Re:They _Should_ Replace It

[Anonymous Coward]

Fucking patronising old Grandad. Go back to your static tables then mate, instead of attacking devs and designers who HAVE moved forward with the times.

Re:They _Should_ Replace It

[Anonymous Coward]

Parent comments.. "In the world of software,"
You list... All obsolete hardware.

eh?

Re:They _Should_ Replace It

[BarbaraHudson]

I listed a bunch of storage media. Those storage media suffer from degradation. If you can't read it any more, it's lost forever.

Re:They _Should_ Replace It

[Dogtanian]

Plenty of early machines used the audio cassette interface to load and save programs. The IBM PC had to include a cassette interface because pretty much *everyone* included one.

That might have been the case had it used a standard cassette format and been needed for interoperability. But the linked article suggests that it used its own custom format anyway, so I'm not sure how the fact that "everyone" else included one meant IBM "had" to include one.

BASIC is BASIC. Porting from one machine to another wasn't a big deal

I'm assuming you misunderstood my point. I certainly wasn't criticising the inclusion of BASIC per se, but rather that the BASIC interpreter was your only option/envrionment (a la most 8-bit machines costing a fraction of the IBM PC's price) because the diskless configuration couldn't run MS-DOS, i.e. the PC's whole raison d'etre.

My point was, who- if anyone- would spend a huge amount of money on a PC, only to restrict themselves to the integrated BASIC and no DOS?

taking a couple of minutes to load or save a program was a lot more acceptable than having to re-enter it every time

Again, I'm not sure what point you think I was making, I'm well aware that cassette storage you *can* afford is better than a disk drive you can't, or no storage at all. But I doubt anyone in that position would be spending the equivalent of $4000 in today's prices on an IBM PC if they couldn't afford the disks required to fulfil its potential.

500 years! I hope not

[us7892]

Maybe he meant to say 50 years?

Wrong

[sootman]

"the web would have become a giant fax machine where pictures of text would be passed along"

No, we would have just kept using tables and <font> tags.

Re:Wrong

[Anrego]

I still just use tables when I delve into the wonderful world of web dev. CSS has replaced coloring and styling of text, but positioning.. screw that. Proper or not, tables worked fine then, and they still work fine.

Re:Wrong

[Anonymous Coward]

i still use tables. fuck off about that.

Re:Wrong

[vivaoporto]

What about webfonts? Any text with fonts outside the list of websafe fonts used to be passed as images.

Either that or dreaded hacks with Flash or, heaven forbids, Cufon.

Re:Wrong

[Spy Handler]

No, we would have just kept using tables and tags

and transparent GIFs. The day I found out you can use a 1x1 transparent GIF to fill any space by using "width=xx, height=yy" in the tag, was the greatest day of my life.

Re:Wrong

[ZorglubZ]

Or tags? Of which the only valid use is: Schroedinger's cat is not alive.

Re:Wrong

[Dr. Evil]

"The day I found out you can use a 1x1 transparent GIF to fill any space by using "width=xx, height=yy" in the tag, was the greatest day of my life."

Things will get better.

Re:Wrong

[Anonymous Coward]

LOL. Try to do a table layout that looks good (or even readable) on a phone (about 1/3 of web traffic). And on a tablet (5%, but growing). And when printed (I run a good sized website and during a recent user experience study I was surprised to see that the "print" link was the single most used link on the site). And on a screen reader. And a projector. Don't forget phablets.

You can't do it. The next time you are doing web dev, just grab bootstrap or skeleton and watch the quality of your work skyrocket while the time it takes you plummets.

You're welcome.

Re:Wrong

[Anrego]

Thus the invention of the "mobile version", which I think generally works out a lot better than a page designed to serve both (and _way_ better than a mobile version designed to look ok on a desktop).

But that said, I don't do much web dev. I'd certainly never do it professionally. Not just because I think it's an absolute mess of an industry, but because my skillset in that area is about 10 years out of date (as you probably guessed) and was never that solid to begin with.

Re:Wrong

[Euler]

So if I have tabular data that is semantically acceptable to be a table, how do I ensure that will look good?

Vacuously

[Anonymous Coward]

> I believe that the CSS code we write today will be readable by computers 500 years from now.

Perhaps vacuously this statement is true, as in 500 years, humanity will have unraveled itself and there will be no running computers left. So yes, all computers 500 years from now will be able to read CSS, because the set of all computers is the empty set.

readable in 500 years?

[Anonymous Coward]

Won't we be able to read most computer code that is ubiquitous today 500 years from now?

Re:readable in 500 years?

[__aaclcg7560]

Text files should still be readable in 500 years. Whether C2514 will be backwards compatible with C11 is a different story.

Re:readable in 500 years?

[Anonymous Coward]

FYI, 500 years ago we had Shakespeare. 500 years from now, ppl b 1drn y r wrds hv so mny ltrs.

Re:readable in 500 years?

[__aaclcg7560]

Have you ever read Shakespeare in Elizabethan English from 500 years ago? Plenty of letters then were missing, as many words were brand new and most words had multiple spellings. It took 500 years to standardized the language, and the British Commonwealth still misspell most of it.

Re:500 years! I hope not

[__aaclcg7560]

C is still going strong after 40+ years, and may continue for another 50 years. CSS should stick around a little bit longer.

Focus on the absurd statement

[Himmy32]

A little piece of web history, and then you have to end it with a statement about computing 500 years from now. Obviously current web standards still will still apply...

Nice piece of CSS history though.

Re:Focus on the absurd statement

[__aaclcg7560]

Printed books ruled for 500+ years. Scrolls for 1,000+ years before that.

Re:Focus on the absurd statement

[Anonymous Coward]

Printed books ruled for 500+ years. Scrolls for 1,000+ years before that.

Yes, but the execution environment didn't change much in that time.

Re:Focus on the absurd statement

[BarbaraHudson]

Printed books are dying. Scrolls are dead. And the rate of change is accelerating.

Re:Focus on the absurd statement

[__aaclcg7560]

Yes, but the execution environment didn't change much in that time.

Actually, the execution environment has changed quite a bit. When printed books were first published, the spoken language was French for the nobility, Latin for the ministry, and English/German for the commoners. Now printed and electronic books are available in many languages.

Re:Focus on the absurd statement

[__aaclcg7560]

Printed books are dying.

Never mind that printed books outsold ebooks in the first half of 2014.

Re:Focus on the absurd statement

[BarbaraHudson]

So what? The percentage of ebook sales is continuing to rise, and is set to surpass print before the end of the decade. The problem now is that publishers are trying to price ebooks close enough to their print books so as not to cannibalize their print sales. However, that's a practice that requires all the major publishers to "keep the faith" and hold the line on pricing. And that, of course, leaves them as prey for other publishers who will take advantage of the economies of ebooks to continue to take sales from the traditional publishers.

It'll be the same as what is happening right now with newspapers. One local paper has gone exclusively digital. Others have closed. Still others are trying to hang in, but more and more their print editions are out of date compared to what's on-line the same morning. Eventually they will have no choice but to go digital.

Hey, I love my printed book collection. However, I can see the writing on the wall ... and with an aging population, the ability to re-flow ebooks as you change font sizes, or have your smartphone or tablet read them out to you, is something that no printed book can compete with.

Re:Focus on the absurd statement

[__aaclcg7560]

The nice thing about printed books is that they require a light to read by while in bed. Once I get too tired to read further, I can turn off the light and go to sleep. An ebook reader doesn't make me tire, I can read in the dark, and have trouble going to sleep because I'm still thinking about the book or web article. Many printed books ARE NOT available as ebooks. Printed books -- like vinyl records -- are here to stay.

Re:Focus on the absurd statement

[BarbaraHudson]

You're doing it wrong :-) A really good book will keep you up until the sun rises and you wonder where the heck all the time has gone. One more chapter, one more chapter ... oh what the heck, the sky is clearing, might as well finish it and hope coffee gets me through the work day :-)

Books that have done that to me include "The Pillars of the Earth", about half of all Tom Clancy stories, and a lot of Stephen King books (do you really want to go to sleep after reading Stephen King?!? Can you???)

And 20 years ago

[OzPeter]

Kurt Cobain saw what was being proposed and . . . . (well you know the rest)

(Too soon?)

Re:And 20 years ago

[Anonymous Coward]

Who is Curt Cobain?

Re:And 20 years ago

[Anonymous Coward]

He was one of the guys in Hanson.

I can ensure you...

[Anonymous Coward]

that in 500 years i'll still hate the fucking "float: left;" bullshit

In 500 years???

[phantomfive]

I believe that the CSS code we write today will be readable by computers 500 years from now.

I was feeling so good this morning, the I read this. Thanks Debbie Downer, I'm going to go cry in the bathroom now, this is the saddest thing I've read all week.

Android

[future assassin]

Well I thought since this was 2014 the browser css rendering inconsistencies were pretty much gone and for the most part they seem to be yet after testing a few websites I just build using some basic designs the default Android browser is rendering horizontal list/text spacing all wrong vs PC/iThings.

So off I go to read up on it and all of a sudden there this @media query thing. After seeing some examples I'm liek WTF? People are using 100's of lines of extra markup or extra style sheets to make things cross platform. Talk about a flash back from the late 90's/early 2000's of nasty css.

Learned CSS in 1997

[__aaclcg7560]

I started learning CSS and HTML in 1997 on one of those free websites, Earthlink or something else that didin't survive the dot com bust. I later got a Unix shell account through my ISP and hosted my website from there. Cut my teeth on a text editor and never learned how to use a WYSISWYG editor (most wrote spaghetti HTML).

CSS is fine, devs are the bigger problem.

[Anonymous Coward]

People need to stop whining about CSS and learn how to use it. It's not that complex, guys and gals. It even has flexbox, calc, rgba, before/after/content, and all sorts of features that your average "let's use classes for everything" web dev would be shocked at. Hell, I've been able to replace gigantic JS functions with a single CSS3 selector in some cases and still had better performance.. and the dev didn't even know it was possible, despite calling themselves an advanced CSS user. Sure, if you STILL want to target IE under 9 or ancient iPhones/Droids you might need to resort to hackery, but that's not CSS's fault. That's the price of progress being stifled by people who don't want to progress.

Then there's all the people who claim that layout-centric markup (tables, font, etc) were a good enough solution that could have evolved into a superior tool... don't seem to realize how complex that would be. I guess it could work if you wanted to have several versions of a site's markup just to get the same result, but then you're mixing everything into one format. That's insane. HTML for semantics and CSS for presentation makes much more sense and is a lot less work these days, unless you still demand that your web page be viewed in one or two resolutions the way YOU want it to be viewed. Which makes you the problem, not CSS.

Also, advanced constraint-solving solutions are a nice way to ease the developer's time, but they make your site barely usable unless you use them sparingly. Given that modern computing devices can barely handle advanced CSS3 in some cases, I think people need to stop opining that these were a better solution for yesteryear, when even a powerful PC could barely handle CSS more complicated than the classitis and divitis ridden monstrosities we came up with back then.

Re:CSS is fine, devs are the bigger problem.

[tibit]

It's not complex, but it's about as intuitive as the PHP libraries, and it requires such a baroque approach to the simplest of things that I really think the whining is well-deserved. Just because you can learn how to use this abomination doesn't mean that it's any good. It seems to be tightly tied to whatever box model Opera A/S was using at the time. That box model was demonstrably decently performing back then, but that's no reason to *expose* such an optimization as an interface everyone has to use to lay out their pages, for crying out loud.

Re:CSS is fine, devs are the bigger problem.

[JohnFen]

I don't know. Given that most of the CSS-heavy sites I see routinely break or suck as a direct result of using CSS, its clear that most web developers don't know how to properly use it. And if, after 20 years, most developers don't know how to use a tool then I tend to think the fault is not the developers, the tool.

Re:CSS is fine, devs are the bigger problem.

[Anonymous Coward]

Layout is non-trivial, hence CSS is non-trivial. If you're just going to be upset that it's not simple, then perhaps you could also complain about how difficult the DOM is, how tough it is to reason about network requests, and how much of a royal pain it is to have to mark up your content.

I've yet to meet someone who calls CSS an abomination who does so because they aren't just too lazy to figure it out, rather than just dismissing it on grounds that don't really amount to anything. What else should they have done instead of the box model? Just not let us do any layout work at all? Or use something so inefficient that it wouldn't work anyway?

Re:CSS is fine, devs are the bigger problem.

[Anonymous Coward]

By that logic, everything sucks. C++, Haskell, HTML, all of it. Anyone can use 'em, but most will mess it up somehow... null dereferences, memory leaks, race conditions, or even just misunderstanding something about their object model. Clearly that's the fault of the developers of those languages for not writing something to hold everyone's hand.

I'd argue that CSS is actually a step above: sure, you can break things, but at least you'll usually get something that's still readable. It won't crash your computer. You can tinker with it until you've learned it and its tools. And even if a browser doesn't support something, odds are good that it will still have a sane fall back. I'm fairly certain that the biggest problems with CSS are ones to do with it being so easy to try and mess up, not that it can't make layout (an inherently non-trivial thing) magically trivial for everyone.

Re:CSS is fine, devs are the bigger problem.

[JohnFen]

By that logic, everything sucks. C++, Haskell, HTML, all of it.

And yet, most of the code written in those languages results in a better track record than CSS. In fact, most professionally produced code that has problems fails in edge cases. Most the the CSS I encounter has problems in the main use cases.

sure, you can break things, but at least you'll usually get something that's still readable.

True, about 80% of the time when I have a problem with CSS-based pages, I can still sorta read the pages. Often I have to do annoying things like resize my browser, reduce my font sizes, or other types of workarounds before the page becomes readable, though, so that's sorta weak sauce. Nonetheless, there's still an annoying high rate of breakage -- I'd say about half of the websites I go to present some amount of functionality loss or unreadable text due to CSS.

But even worse than that, the limitations of CSS make web designers choose designs that are just bad (for instance, my own pet peeve of pages that have a fixed width or limited ability to handle arbitrary window sizes. Yes, you can do these properly with CSS, but it's much more difficult to do, so most web designers don't.

I'm not saying it's impossible to make a great, robust web page using CSS. I've done it. I am saying, however, that for nontrivial web pages it's much more difficult than making the equivalent page without it and it's much easier to mess it all up. In my view, that makes it a poor tool.

Re:CSS is fine, devs are the bigger problem.

[Anonymous Coward]

When I started using CSS I was coming from experience with layout managers in Java's Swing. What was available in CSS was a massive step backwards. It's only just catching up.

Re:CSS is fine, devs are the bigger problem.

[Anonymous Coward]

> for nontrivial web pages it's much more difficult than making the equivalent page without it and it's much easier to mess it all up

What utter rubbish, unless perhaps you're designing for a single device with rigid resolution, DPI, etc. But show me a solution that wouldn't have these problems, which wouldn't have other equally bad problems for the web. We've tried. That's why we have Javascript and CSS extensions, to help us cover cases it's not good at and let developers eat their words at how their "superior" solutions can't even do as well as CSS in the grand scheme of things.

Floppies

[sootman]

One of Opera's claims to fame before I joined was that the browser would fit on a floppy disk (which is 1.44 MB). "Fits on a floppy" was a great slogan in those days. When CSS was added, a few more bytes were needed and Opera would no longer fit. "Almost fits on a floppy" doesn't quite have the same ring to it.

Even though I've been around long enough, it blows my mind now that *anything* ever fit on a floppy.

Re:Floppies

[Anonymous Coward]

I got my first hard drive for Christmas 1995. Before then it was nothing but 360K floppies for me.
So all of my stuff fit on a floppy back then!

Re:Floppies

[Anonymous Coward]

If you didn't have to install Slackware back then, be thankful. Just be thankful! 21 floppies for the original version And 1.44 MB ones at that.

Re:Floppies

[ledow]

How much data is actually in that Word file you made? Probably a handful of Kb at most.

How many instructions do you need to call the libraries included in Windows to tell it what you need to do. 1.44 MILLION instructions is a lot. Especially if one-in-ten of them is probably a call to a system routine (draw this window, create this object, etc.).

A problem with modern programming is that 1.44Mb is "nothing". That 10Mb library? Nothing. Just suck it in and put it in the installer. Compared to the GIGABYTES of 3D models and textures, the 500Mb program executable and libraries is "nothing". And what does it actually do beyond what, say, Quake did? Quake 1 was about 500Kb in executable. Sure, the data is larger, there's a shader or two to load, the resolution is higher so the memory requirements and CPU/GPU use are much higher and there's a couple of libraries to suck in - but actual executable size is HUMUNGOUS nowadays compared to what's needed.

It's one of my bugbears. Executables should be tiny. Data shouldn't be in the executable, and generally isn't. Where the fuck most of that code comes from, I can only imagine - there's no way that a modern game has ORDERS OF MAGNITUDE more code written for it than Quake did (with all it's moddability, AI, QuakeC scripting inside it, etc.)

Re:Floppies

[Anonymous Coward]

Even though I've been around long enough, it blows my mind now that *anything* ever fit on a floppy.

I remember my first Windows 95 installer included 25 floppies...

Re:Floppies

[WillKemp]

[......] 21 floppies for the original version [......]

Not according to the article you linked to. It says there were 13 floppies in series A and 11 floppies in series X. That equals 24.

I have to say i'm surprised there were that many. I first installed Slackware on my Digital HiNote laptop in 1995 - after downloading the floppy images via Digital Equipment Corporation's "FTP by mail" service (my only internet access was via UUCP). I don't remember there being that many floppies. But maybe you didn't need all of them to install a basic system. I installed X that way too, but probably once i'd got the core Linux system up and running, so i probably reused the floppies.

Opera

[pigsycyberbully]

The Opera web browser it is dead now it has become a Google spyware dominated by Google. The first version of the Opera web browser had advertising in the corner of the browser. The second version I paid for it was called the pay for version of the Opera web browser, it was a truly locale as the French, say locale LANG=cs_blah blah. I also use their first Linux desktop version the first one which crashed quite a lot but eventually ended up working just great considering Linux desktops are shit. The Apple version look very nice. Even the virus security products started supporting it with add-ons for the Windows, version sandboxing. I have seen their latest offering and Opera is truly dead it is a Google product.

nuke it from orbit

[silfen]

It's the only way to be sure.

Geometry-based layout

[dskoll]

The wonderful Tcl/Tk toolkit solved the layout problem in the 1990's with its excellent constraint-based geometry managers: The grid engine, the packer and the placer. I'm sure it would have been possible to express each of those layout engine's rules in something analogous to CSS.

That would have made page layout so simple it'd almost be fun.

Re:Geometry-based layout

[Euler]

But then how could we make annoying 'hover' elements?

But seriously, the pack manager is all I use in Tk/Python, it would have made excellent web pages. HTML tables work almost as well. I don't even bother with grid manager in Tk unless I need strict alignment in 2-D.

Love CSS

[WaffleMonster]

While I have a laundry list of complaints I like the underlying idea more than I dislike it. Amazing how simple html content ends up being and how flexible changes become once you have made a reasonable attempt to declare content and decouple style.

This said I'm very much less certain what my sentiment of CSS actually translates to in the real world.

The underlying problem while technology wants data presentation to work across maximal number of display sizes and capabilities such things too often appear as intolerable annoyances to designers. The world is teaming with fixed width websites and crap like zen garden is a joke. Without assumptions of fixed content tailored specifically for the garden those layouts would fall apart.

It often takes different skill sets to design something that both looks cool and is able to survive with coolness intact across a number of different and perhaps unknowable parameter changes.

This in my opinion is responsible for about half of the great tables v CSS layout arguments. What designers really want is for each page to have a known width and a known height without all of the compatibility bullshit or having to think about unknowns... what they actually want looks a heck of a lot more like PDF than it does HTML/CSS.

Without significant design / technology change to bring competing interests into better alignment I wouldn't bet on CSS lasting 50 years.

I can ensure you...

[Anonymous Coward]

Lol, in 500 years from now you may be get acquainted with clear: both

Fuuuuuu....

[tibit]

It is my very firm opinion that whoever came up with CSS should not be putting it on his/her resume, because I wouldn't be hiring them for this monstrosity. It is a mess that's so thoroughly convoluted and unintuitive to use as to make the people involved in the core design essentially persona non grata of the tech world. I wouldn't want those people designing anything that I myself would have to deal with, no, thank you.

The idea behind the CSS is sound. The implementation is beyond horrible. It tells you something when you need to go through less hoops to get the layout you want in TeX, than in CSS, and TeX's basic block model was not designed for most of what it's being used for nowadays. CSS's design is an abomination that perhaps resulted from not having much in the way of exposure to the high-level designs of any layout software, or perhaps in the designers having grandiose aims with not much experience to back it up. Either way, it's just bad. I'd call CSS barely functional, like you have with some alcoholics who can hold a job and go through life "mostly fine" - as in without quite killing themselves or anyone else around them.

As an example of an API/interface design, CSS is precisely the way nobody should be doing it.

Re:Fuuuuuu....

[Dynedain]

I'd blame most of the problems with CSS on the lack of support across browser vendors. It took soooo long for even the most basic features to be supported, that rendering differences lead to a culture of hacks (remember when people would put in explicitly invalid CSS to trigger certain IE behaviors?) because styles couldn't be built the right way.

Event today there are some fairly cool pieces of CSS (background-position: center center; background-size: cover) that are amazingly useful, but because of incomplete browser support, people end up with lots of extra HTML, CSS, and Javascript.

Re:Fuuuuuu....

[tibit]

The fucking reason for all of that is precisely the baroque non-design of CSS, the lack of a formal specification (whatever passes for it nowadays is a joke), and the fact that noone really can truly claim how this monstrosity was supposed to work. Most "introductions" to CSS are using analogies that are really unhelpful. Whatever "models" model the behavior of CSS are really not very useful, because the number of cases where those abstractions break down hopelessly is so high as to make them useless. It's like teaching quantum mechanics using any of the historical analogies (balls joined by springs, oscillators, waves, whatever). The only true "spec" of the CSS, in practice, is the browser behavior, as implemented. That's just sad. The main problem is that all CSS users, and I mean all accurate down to 10ppm or so, have no formal CS education, and if they do, they didn't internalize enough of it to understand what's wrong, and what should be done to fix it. It's like the Lemmings game (cuz the real lemmings don't).

Floppies

[Anonymous Coward]

Lol, thats not a great feat, the problem is that as computers became more powerful, the standard for developers have been going down (exponentially, if Moore's law has any credibility).

But if you seriously want to get your mind blown away and get inspired for life, google "HEAVEN7W.exe", download it and run it. Just make sure to take the normal precautions (since the file it is an executable)

Obligatory

[ShaunC]

On 10 October 1994, Opera CTO Hakon Lie posted a proposal for Cascading HTML style sheets.

How come?

Sorry, someone had to do it. :)

Still a dumb idea

[putaro]

Yeah, all the CSS lovers will pile on. Have a party. I still think CSS is a stupid idea.

1) Cascading. What the F? In order to figure out what is going on I have to work back through all the cascaded sheets to figure out what's going on
2) "Separation of content and presentation" Yeah, that's a great idea, but not in HTML. HTML *is* a presentation layer. Who writes content in plain jane HTML? Idiots, that's who. Everyone else writes in something else (Markdown, XML) and compiles to HTML.. CSS is a negative there.
3) CSS syntax is completely unrelated to HTML syntax. Thanks a lot

It still sucks.

Re:Still a dumb idea

[RedSteve]

1) Cascading. What the F? In order to figure out what is going on I have to work back through all the cascaded sheets to figure out what's going on

Yeah! Why can't CSS be like any other language or framework where the functions, classes, methods, etc. are always automagically available to the developer without having to look through the codebase at all? If only developers had some sort of debugging type tool where they could trace where styles come from. Something like...Firebug. Or Developer Tools. Or Web Inspector. Or basically the tools that come packaged in any major browser....

2) "Separation of content and presentation" Yeah, that's a great idea, but not in HTML. HTML *is* a presentation layer. Who writes content in plain jane HTML? Idiots, that's who. Everyone else writes in something else (Markdown, XML) and compiles to HTML.. CSS is a negative there.

HTML is *not* a presentation layer, it's a content layer. That's why the elements used in HTML are primarily semantic - paragraphs, headings, lists, tables, field sets, inputs, labels, etc. Even the HTML 5 elements - navigation, callouts (secondary content), video, audio, etc. - are semantic and have no intrinsic visual/presentation value beyond what the browser assigns to it.

And even if you do use another means of authoring your content, the fact that it compiles to HTML only underscores the fact that HTML is a content layer. Markdown in particular compiles to some of the most vanilla HTML you will ever find.

3) CSS syntax is completely unrelated to HTML syntax. Thanks a lot

Why would CSS syntax be the same as HTML? The two languages have different purposes and areas of concerns. Are you also irritated that javascript has a different syntax than HTML? At any rate, CSS is well designed for doing its job: *describing* how to select an HTML element and assign appropriate styling to it.

Re:Still a dumb idea

[Anonymous Coward]

> Cascading.
Yes, terrible. Set font style oncee. Change it in one place in future rather than individual tags ( was a disaster). Specificity is actually fairly simple (if you bother to look it up).

> Separation
Kinda, layout (HTML) and style. As above, I'd rather not have to repeat this nonsense on every single page.

> Syntax
Yes, but: CSS syntax is pretty trivial but comparison to virtually everything else. Really? It's got curly braces and everything.

I have a strong love/hate (mostly hate) with CSS for layout but it's not that bad. There are arguments against; shame you've not mentioned any...

20 years and I still hate it

[JohnFen]

CSS has been a thorn in my side since it came out, and it still is (even though I don't do web development anymore). It's because of the difficulties with CSS that we have such terrible things as my personal pet peeve -- web pages that have fixed minimum or maximum widths. While CSS does have advantages, it also has disadvantages -- and the effects of those disadvantages on web site design in general very often makes the web less useful to me than it would otherwise be.

Re:20 years and I still hate it

[narcc]

It's because of the difficulties with CSS that we have such terrible things as my personal pet peeve -- web pages that have fixed minimum or maximum widths.

We had that with tables. Remember "Best viewed in 1024x768" and similar notices?

CSS actually improved things there. Today, if the designer is competent, you can do something like a single page app that perfectly fills the viewport and everything, including fonts, scale perfectly with the size of the window. No JS required.

CSS could certainly be improved, I won't argue that, but it has helped far more than it hurt.

Re:20 years and I still hate it

[0123456]

Today, if the designer is competent, you can do something like a single page app that perfectly fills the viewport and everything, including fonts, scale perfectly with the size of the window.

And looks like crap on a 6" tablet screen.

Allowing the designer to control layout, rather than the web browser, was the original sin. If content and layout had remained separate, we wouldn't need to deal with crap like blogs and news sites randomly deciding to send me to their mobile version instead of the desktop version when I'm sitting in front of a 24" monitor.

Re:20 years and I still hate it

[Euler]

I really never get the 'tables aren't scalable' argument. Maybe people are just thinking in fixed page size mentality. Tables are about the only thing that lays out a page in a scaleable way. You just have to know what table properties to use and be willing to allow your page to adjust to window size. I can't predict the exact font scaling on every browser, so why do I care? The table just correctly bounds the text. CSS still seems to get confused or misused quite easily in this regard. It's like web devs are control freaks who need every sentence to be press-ready layout down to the pixel.

500 years! I hope not

[Anonymous Coward]

Too long to paste in its entirety, but instantly made me think of this:

http://leonsbuddydave.tumblr.com/post/54879645535/today-css-is-the-worst-possible-way-to-describe

500 Years?

[Suffering Bastard]

CSS still readable in 500 years? I think this guy has an over-inflated sense of personal legacy.

The tragedy of CSS

[tigersha]

CSS is good. Really. It is not too bad, has a few warts and so, but we are finally there. Or will be in 5 years when all the browsers finally support the new Grid layout module.

The problem with CSS is that it took 25 damn years to get to the point where windowing system were already in the 90s. There are 2 main problems up to now

First, the block model. Seriously people, if I specify that a block has a width of 300 pixels I mean that the block has 300 pixels, and not the content inside the block without the padding. Really. That makes no sense. For some reason it did to the authors of the standard. It hurts me to say this, but Internet Explorer 5.5 got this right and simply ignored the stupid, dumb standard. Most of the nightare that is CSS layout was caused by this clusterfck of stupidity. Now there is finally a solution, one can set the box-sizing and almost all browsers support it. Those that do not are old and can fly.

Secondly, tables vs grid. I get the whole tag is not semantic thing. Really. But often, strangely standards people, we DO WANT THINGS TO BLOODY LINE UP IN A TABLE. But nooooo, we must not use tables because it is not fashionable or something.

Floats were meant to be used to put pictures inside a large block of text. It is great for that. Now it is used for laying out elements on a page. And this is supposed to be LESS hacky than using a table? Seriously??

CSS grid layout finally, finally, finally solves all of this hacker bull. It does something that should have been in there since the 90s. After all, pretty much any window manage on the planet could deal with this back then. People still use tables because it is easier. Grid also decouples the sequence of the elements in the markup from the sequence on the screen, which is cool. But, but even Chrome only experimentally supports grid layout so I have to wait another 5 years.

A couple of other things on my wishlist.

Calculation. Based on the current state of the screen. Sometimes saying that I want the thing should be 500px - the width of the div with id #blabla would make a lot of all the CSS shenanigans unnecessary. Yes, I know that some designers can't add, but I can and I want to. And no, I do not want mathematica in there. Simple basic arithmetic would be fine. Right now you can do 3D transform in CSS3 but you can't subtract the width of an element??!! FFS why??!!! There is a new calc module but that will take another 5 yars to become commonplace.

Better control of height. I want to say "This div fills the rest of the container vertically/horizontally" One of the reasons tables are useful for layout is that you CAN do this by setting the width of a column to *. Layout engines in GUI land, such as Interface builder and the oooold News uses a concept called Springs which expand. Coool feature, missing from CSS.

The fact that you can book loads of courses and read lots of book on how to arrange things on a page with CSS is a real shame. It simply should not be necessary to have that level of expertise just to such a trivial thing.

25 years. This is the time from the end of WW2 to the day I was born (almost precisely). 25 years is the time between the invention of the transistor and the invention of the CPU. 25 years is the time between the first flight and the first ocean crossing over the Atlantic. 25 years is the time that someone goes from being born to being a working productive adult. 26 years is the time between Columbus' discovery of the new world and Hernando Cortes conquest of the entire Aztec empire.

25 years is a quarter of a century.

25 years is the time between the invention of CSS and the moment it is viable to lay out a page without being an expert in some very arcane hackery. Why was this really necessary??!!!

Re:The tragedy of CSS

[Anonymous Coward]

> Box sizing
Agreed... but look up "box-sizing".Not saying it's not overdue, but it's there now...

Re:The tragedy of CSS

[narcc]

Calculation. Based on the current state of the screen.

Try these CSS Units: vh, vw, vmax, vmin, and %

Better control of height. I want to say "This div fills the rest of the container vertically/horizontally" One of the reasons tables are useful for layout is that you CAN do this by setting the width of a column to *. [...] Coool feature, missing from CSS.

display: table, display: table-cell, etc. should help you with that.

First, the block model. Seriously people, if I specify that a block has a width of 300 pixels I mean that the block has 300 pixels, and not the content inside the block without the padding. Really.

You could make an argument either way. Thankfully, we have box-sizing: border-box and box-sizing: content-box

It simply should not be necessary to have that level of expertise just to such a trivial thing.

Layout is not a trivial problem. Particularly when the layout needs to react to the viewport.

Re:The tragedy of CSS

[RedSteve]

The problem with CSS is that it took 25 damn years to get to the point where windowing system were already in the 90s....

TFA says that CSS was proposed 20 years ago today. It wasn't released as a spec until December 1996. While the number 25 plays nicely into your rant, in reality, CSS isn't old enough to vote. Hell, even HTML is barely old enough to drink.

Re:The tragedy of CSS

[Anonymous Coward]

> CSS is good. Really. It is not too bad, has a few warts and so, but we are finally there. Or will be in 5 years when all the browsers finally support the new Grid layout module.

And finally catch up to the 1995 HTML tables of yore... :)

Re:The tragedy of CSS

[ZZane]

Layout is not a trivial problem. Particularly when the layout needs to react to the viewport.

Yes, because layouts have never had to react to a viewport before browsers came along. All those windows apps that had to respond to whatever resolution they were resized to never existed. There were also absolutely zero solutions for this problem, definitely not solutions provided by Visual Studio or other RAD development tools that made things measurably easier than CSS.

Re:The tragedy of CSS

[narcc]

Yeah, we know. They were also universally inadequate, if you'll recall. The most sophisticated approach to layout management from the bad old days was provided by Java, which no one in their right mind would defend. Visual Studio was even worse, and still is today. If you hadn't noticed, developers still have difficultly dealing with different display resolutions, particularly on mobile. (It's a common complaint.) Few applications even bother, as you can easily see for yourself by trying out a few on your desktop.

Yes, it can be solved for individual applications, and has been solved many times, but there has never been a simple general solution. Further, websites are not the same as applications so, even if your mythical solution existed, it isn't likely to be applicable.

Again, there isn't a simple solution because it's not a simple problem. If you believe otherwise, make your proposal. In the simplest terms: "Put-up or shut-up."

Re:The tragedy of CSS

[tigersha]

I said that in 5 years CSS will be at the point where the elimination of the main pain points are supported widely enough to be able to use them in actual websites. The grid module in particular. It is there now, but few browsers implement it. Grid will remove most of CSS's pain points and it will be actually useful in the real world where CSS is 25 years old. I can't use the grid module now in production. I will be able to in 5 years.

And I actually like CSS, I just think it took too long to get to this point. Why this is so is beyond me. Other technologies have advanced much, much faster.

Re:The tragedy of CSS

[tigersha]

> Try these CSS Units: vh, vw, vmax, vmin, and %

% is not quite what you want. The other units are not supported widely enough yet. IE still does not support them correctly, IE 8 (and I have IE8 users) does not. canIuse: Global 57.35% + 20.71% = 78.07%

> display: table, display: table-cell, etc. should help you with that.

I know display-table can emulate width="*" for HORIZONTAL spacing. It is not usable for VERTICAL spacing. And a spring is still a easier abstraction IMHO.

> Thankfully, we have box-sizing: border-box and box-sizing: content-box
I know that. I use it too. It took 20 years to get to this point which was by far the most stupid part of the CSS spec. box-sizing content-box was a catastrophe.
You could not use these things 2-3 years ago.

> Layout is not a trivial problem. Particularly when the layout needs to react to the viewport.

I know it is not a trivial problem. But is was mostly solved before CSS came to the scene and CSS put us 20 years backwards.

Re:The tragedy of CSS

[tigersha]

> Yes, because layouts have never had to react to a viewport before browsers came along

Programs written in C++ for Windows and MacOS/X and Qt and Xwindows can, and often does, react to resizing viewports (Ok, windows used to suck in this regard). They could do a lot of what CSS can only do now 20 years ago.

Java 1.2 was released on December 8, 1998 with Swing as the GUI toolkit. While resizable viewport programming was (and still is, I maintain a Swing app) a PITA it was possible and most Java programs did support it. Much better than most Windows programs of the era, I might add. Swing had a spring abstraction for flexible layout from day 1.

> Visual Studio or other RAD development tools that made things measurably easier than CSS.

I agree with this. this has always been a tooling problem. I also agree that it is hard to do, and many programmers won't bother. But the tools used for GUI apps did support this and CSS did not.

Re:The tragedy of CSS

[tigersha]

Also, the viewport units only work for calculations based on the size of the whole screen. It is not possible to do something
like set the width of element X to be the same as the width of element Y on another part of the screen. Sizes between elements cannot be used. I know it is a hard problem, and might (or might not, depending on how you do it) require a constraint solver, but often a simple calculation would solve a lot of CSS problems.

Re:The tragedy of CSS

[Anonymous Coward]

Where are you from where 20 year olds cannot vote but 21 year olds can "barely" drink? Other than small island nations, only the US has a drinking age that high, and that has voting at 18. (I actually fact-checked this and it turns out that a year ago, Fiji would have met the criteria, but not anymore).

If you're going by the date of a w3c standard date rather than proposal, then CSS is just under 18 but HTML is just over 18. I know Alberta, Manitoba, and Quebec allow that.

Re:The tragedy of CSS

[RedSteve]

Just because CSS was proposed 20 years ago doesn't mean it sprang fully grown from Hakon Lie's head on that day. For that reason, I was referencing the date when CSS became a recommendation - December 1996 - which means that CSS is almost 18.

HTML's first draft was released in mid-1993. However, since this pre-dates the W3C and its recommendation standards, and because it was being used in NCSA Mosaic at that time, I was using this release date as its birthdate.

Re:The tragedy of CSS

[RedSteve]

I said that in 5 years CSS will be at the point where the elimination of the main pain points are supported widely enough to be able to use them in actual websites

My apologies. Since your original post used the past tense ("The problem with CSS is that it took 25 damn years to get to the point...") I took that to mean the 25 years prior to your post.

Also, it's good to know that in 5 years I will finally be able to work on "actual" web sites and not the imaginary web sites I've been working on for the past 18 years... ;-)

And I actually like CSS, I just think it took too long to get to this point. Why this is so is beyond me. Other technologies have advanced much, much faster.

What other technology has had to provide a consistent UI experience on multiple platforms through multiple applications, even while those application providers are trying to incorporate their own - often competing - interpretations of a standard? As alluded to in TFA, it didn't help that the original CSS spec didn't include a test suite. But beyond that, the browser wars were enough to freeze any meaningful implementation of web standards for at least a decade.

Re:500 years! I hope not

[hackingbear]

Well... he can't tell the truth.

Good and bad...

[Anonymous Coward]

Nice to styling. Mostly terrible for layout:
- float: center - how hard can that be? Content to flow around an object, please (And I know, MS, have proposed float: center - finally...)
- CSS regions - get on with it, ffs. A basic DTP concept from when DTP was actually a concept.
- Vertical centering - shouldn't be that much of a fudge
- centering elements that aren't fixed width - yes, it's possible but really, should be easier.
- anything that requires a negative margin: this isn't a workaround but a sign that it's not quite descriptive enough.
- :after & :before - nice but abused for adding stuff; why not multiple instances of each? And also by doesn't content has a default?

At least it's mostly consistent (bleeding edge aside) across browsers (in a way this nonsense was worse a few years ago).

if these standards were not made...

[paulpach]

He says that if these standards were not made, "the web would have become a giant fax machine where pictures of text would be passed along."

Self righteous nonsense. If these standards were not made, others would have been made instead.

Re:500 years! I hope not

[Anonymous Coward]

C is dead for mass market, it bowed out of client/server software...C++ devs are under delusion of embeded hardware and they may win that area so..

Bummer

[StripedCow]

Proposed 20 years ago, and it's still not Turing complete.
What a bummer.

500 years?

[WillKemp]

I'll bet a million dollars in 500 years time money that there won't be any such thing as computers in 500 years!

CSS should have been a product, not a standard

[PJ6]

The web should have been given a low-level, machine readable standard which human-friendly formats and tools could have formed and evolved around. Sure we'd still have markup and CSS and script, but you can bet your ass applications wouldn't have been built on that crap. We are easily 10 years behind where we could have been because of a poor choice of level of abstraction.

Re:500 years! I hope not

[mirix]

I think C will make it 500 years, if we still have embedded things then, and civilization.

Apply named

[Anonymous Coward]

Yes, CSS is a "hacked-on lie".

Re:500 years! I hope not

[Euler]

Depends what you call embedded. But C++ in the embedded world is not very likely for a variety of reasons. C itself vs. Asm is still a debate I have with my colleagues on a daily basis. I have delusions of a replacement for C in the low-level embedded world - but chances are it would be hard to displace even with all of its flaws.

The obvious contradiction

[Circlotron]

The article summary says "I believe that the CSS code we write today will be readable by computers 500 years from now." Yet at the bottom of the Slashdot main page it says "All seems condemned in the long run to approximate a state akin to Gaussian noise. -- James Martin"