Slashdot Mirror
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."
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. ::before and ::after support, favour using those instead.
These days we have full
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!
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/
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.