Exploration

Adam Bosworth recently gave a talk about simplicity in technology, and how it’s far more important to be simple and sloppy than complex and pure. For the most part I agree with him; my first draft of XFN and FOAF was, basically, “FOAF is complicated. XFN isn’t.” While that was a flip way to amuse the reviewers, it also summarizes the core reason I took to XFN when Tantek and Matt explained it to me. Making things easy is always preferable to making them hard. As RFC 1925 so correctly states, “In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.”

There are two places where I’d like to take issue with Adam, however. (And I hope it’s not presumptuous of me to call him “Adam” instead of “Mr. Bosworth”.)

The first is the idea that the Web should never be more complicated than plain old HTML. Adam says: “I very much doubt that an HTML that had initially shipped as a clean layered set of content (XML, Layout rules – XSLT, and Formatting- CSS) would have had anything like the explosive uptake.” This is absolutely common sense. I think it’s also common sense that any truly popular and useful system starts out basic—’primitive’, if you like—and grows in complexity. The best such systems hide the complexity from the end user. Automobiles have gone from a few very basic controls (steering, acceleration, braking) to the mobile gadget factories we pilot today. I still don’t have to know how the engine works to drive one.

So I absolutely agree that HTML caught on because it was simple. It had to be, because there was nothing to shield us from the system’s innards. When the popular Web was getting started, I did my best to promote its use by writing a trilogy of HTML tutorials (1, 2, 3). My entire goal there was to make it easier for anyone to publish their own content. Want to publish your grandmother’s Apple Pan Dowdy recipe? More pictures of pets? Bring ‘em on! They way I figured, if everyone published what they knew, the best information would slowly rise to the top by virtue of gathering more links. Years later, Google built an empire around the concept of the best information being the most heavily linked. Ah well, another fortune lost.

Even then, I did take the time to teach well-formed markup because I knew that malformed markup was likely to cause trouble. This wasn’t an elitist thing, or some sort of far-reaching clairvoyance: at the time, it was possible to break browsers with incorrect nesting of inline elements. So it only made sense to tell readers, “Hey, if you nest elements, make sure they actually nest instead of just closing them at random. Otherwise your page might not get displayed.” Eventually, browsers got more tolerant of sloppy markup, and those kinds of warnings weren’t really needed any longer.

So anyway, here we are ten-plus years later, and we’re still arguing about table layout and XHTML being lower-case and blah blah blah. In the first place, table-driven layout isn’t simple. It’s flexible and sloppy, but not simple. The vast majority of table-layout authors have never touched a tag in their lives. They’ve just told some tool “do this”, and it did it. They don’t care how. They shouldn’t have to care how. So whether the tool generates 50KB of table-and-spacer markup, or 15KB of semantic markup with another 5KB of CSS, is wholly irrelevant to the user. As it should be.

It is, however, relevant to those of us who ply the back end of the Web. I’m not going to go over the arguments now; you probably know them, and know how you feel. But my feeling has always been that once word processors stopped fighting over file formats, and got on to fighting over ease of use and features while all reading the same formats, that’s when word processing software took off. I feel the same about the Web.

Now, I’m kind of a fan of CSS. Have been for a while. I like it because it lets the design (largely) happen away from the markup, where changes are easier, and it allows all kinds of stuff that HTML layout never managed. (Two examples right off the top of my head: letter-spacing and border-style.) I also like JavaScript and the DOM—not because they’re pure, but because they do what they need to do. Inspired by the work of others, I put all those pieces together recently and created a lightweight slide show system. It isn’t perfect, and because there are DOM actions it doesn’t always tolerate sloppiness, but it’s pretty simple. Once editors exist to let people just point, click, and type slides (and I suspect that such editors may exist in the relatively near future), it will be even easier. And the underlying format will not matter to 95% of its users. Nor should it.

Anyway, this brings me round to the other thing I wanted to talk about. Early in the talk, Adam says:

…in one of the unintended ironies of software history, HTML was intended to be used as a way to provide a truly malleable plastic layout language which never would be bound by 2 dimensional limitations, ironic because hordes of CSS fanatics have been trying to bind it with straight jackets ever since, bad mouthing tables and generations of tools have been layering pixel precise 2 dimensional layout on top of it.

First off, I think that Tim Berners-Lee might have a slightly different perspective on what HTML was intended to do, but let’s skip that. The part I don’t get is the perception that “CSS fanatics have been trying to bind” HTML. Personally, I’ve been trying to free Web design from the limitations it’s long experienced. I’ve been working in that direction for years now. I won’t argue that the job is finished: far from it. But a big reason I’ve long been an advocate of using CSS is that it loosens the straightjacket, not tightens it. The work I did within the context of the CSS Working Group was intended to loosen the bonds even further.

Maybe that means I don’t meet Adam’s definition of a “CSS fanatic”, I don’t know. Maybe I’m not one of the “hordes” of jackbooted geeks, seeking to impose my tyrranical notions on the unwashed. Either way, this does bring me to the question I want to ask: where does this perception come from, that CSS is promoted a way to make the Web harder and HTML more difficult? I’m not trying to belittle the idea by asking; I’m genuinely curious, and a little dismayed. I know I’ve worked very hard to clearly describe what’s good and bad about CSS, just as I have about table-based design. I’ve put a lot of effort into helping people who want to learn CSS do so, and explaining to those who ask why I think using CSS is a good idea. Most of the other CSS advocates I know have done the same. What is it that we did or didn’t do that got across this idea of inflexibility, or intolerance, or just plain elitism?

Because when you get right down to it, I’m still all in favor of people putting their stuff up for the world to see. These days, I’m also in favor of making it easier for everyone else to see that stuff, and for tools to collect and analyze that stuff. Standards make that easier—CSS makes that easier, although not as a standalone savior, but as part of a mosaic. If someone as well-regarded and experienced as Adam Bosworth doesn’t see that, then I can’t help but feel there’s been a failure to communicate.

Dear Eric, I applaud your response. I’ve only recently begun using CSS and found out how hard it can be to use it (coding my own website) for the first time. You may not remember!

But this is not due to CSS (imho). It’s due to browser support of CSS. If browsers would support CSS 2 (better yet 3) fully, then I think non CSS-fanatic web developers would be much more willing to learn it.

Certainly designers brought up on styles from the print world would find the transition easy. I’ve even begun to think that it might be a step forward if CSS were to be integrated into styles in InDesign/Quark. Or at least the concept of the cascade and nesting.

Seems to me that blogs have taken the pressure off of individuals who want to go express themselves, but lack computer skills or the funds to develop their own sites or have them developed. So now a little more complexity won’t scare them off, since they can always use free or off the shelf blogging solutions.

I agree it’s a shame if Mr. Bosworth doesn’t understand your point. And I find it a shame the browser developers (all of them) haven’t come around to full CSS support yet. I attended the IDEA Showcase (showcase of accessibility technologies and products) in Washington, DC recently and asked why the Section 508 people couldn’t include CSS support in browsers when they send out rfps. That would put some muscle in the requests for browser companies to support CSS.

Anyway I appreciate your work. It’s tremendous. And your willingness to share it with us.

Yes, I don’t think you are the type of “CSS fanatic” that Adam is talking about. The CSS fanatic that Adam is talking about is the person who says you should build a 20-field form using floats and crazy amounts of CSS instead of a simple table-based grid.

The key to proper CSS usage is to use it whenever it makes sense, but never when it doesn’t make sense. The CSS fanatic says to use it always.

Since I wrote the ‘tyrannical’ post, let me try and answer your question. The problem here is that CSS (in its current form) sets a high barrier of entry to non-technical users.

For example,look at the tons of tutorials on the net today on how to do 2-column and 3-column layouts using floats. Now, this used to be very simple with table tags – but something as simple as showing text in 3 columns now requires a ton of code.

Now, tables may suck and may be the bane of the web – but try to look at it from the perspective of someone learning web designing. He/she knows that CSS is the *right* way to do things – but is absolutely frustrated at how much work it takes for such a simple thing.

I’m a coder – I’m no designer. Some time back, I was trying to implement a 3-column layout for a personal website. As a strickler for standards, I wanted to make sure it was XHTML and CSS friendly. But I got totally frustrated at how tough it was to get something so simple to render consistently across all browsers with simple code. Finally, I said ‘Shove it’ and used a couple of tables.

Now, my question is, as a guy who’s probably never going to update that site again save for minor updates, what does all this CSS-correctness give me? What does the extra effort give me?

But still, that’s irrelevant to the user. That’s the point Eric’s trying to make – in the same way that he doesn’t understand how his car engine works but can still drive a car, it isn’t (and shouldn’t necessarily be) necessary for a user of the web to know the ins and outs of CSS2 (for example). Eric probably doesn’t mind that his car isn’t the most efficient at its job – it gets the job done.

And then when said user gets sick of low ratings in google, they go and search “SEO” in google, and discover that a more semantic solution is better. Just as if you begin to worry too much about the environment you read up and find that this car is better than that one, and you’re happy to fork out the extra cash for it.

Ryan Johnson wrote in to say...

The key to proper CSS usage is to use it whenever it makes sense, but never when it doesn’t make sense. The CSS fanatic says to use it always.

This is a very valid point. I have been working with the web on and off since 1998. When I made my triumphant return to almost full time this year I was shocked to see all this CSS tableless stuff goin’ on.
And when I finally learned CSS for real I was tempted to just say CSS EVERYWERE!!! I have sobered since then.

In reality though, Tables should be used to display tabular data. That’s fine, that’s what its for.

But I am also of the opinion that semantically correct code is remakably simpler than the table hacking markup of the day, and that it actually lowers the cost of entry, at least on the HTML Side.

I will agree the initial curve of CSS appears steep, but it is the kind of thing anyone can learn. Maybe the effort just needs to be expended. I would personally say that it isn’t that much more difficult to make your first 3-col CSS layout than it was to work out the same code in table form.

Maybe I am an elitist… :)

Like mentioned above though, all we need are supporting browsers, and maybe some supporting WYSIWYGs.

Boris wrote in to say...

It think a key fact a lot of people are missing is that the complicated ways to do 2 and 3 column layouts in CSS are needed because IE does not support the easy ways CSS provides (using table display types with semantic markup).

So the real problem is no that CSS is hard but rather that working around the mess that is browser support is hard.

pb wrote in to say...

The car analogy isn’t great. Knowing how to work on a car rarely benefits anyone other than you (unless you become a mechanic). Whereas even the tiniest web site developer is likely to benefit many others. That is to say, it’s a good thing that making web pages is easy enough for mere mortals.

Paul Martin wrote in to say...

CSS isn’t promoted as a way to make the web harder, but that may be its effect for some people. Let me take a stab at why that statement might be true.

I do my web sites with hand coded XHTML and CSS. From what I’ve observed around the web, that is rare. Most people use WYSIWYG tools like Front Page or Dreamweaver or whatever. I don’t know much about those tools because I’ve never used them, but my impression is that only the newer versions support CSS at all, and even then, you have to know what you are doing in order to take advantage of that support. If you are new to web design, and all you know is that you want red text here and a blue background over there and so forth, I doubt if that tool is going to generate standards compliant XHTML/CSS markup, let alone section 508 compliance.

Part of me says that hand coding XHTML and CSS is a silly way to approach web design. HTML reminds me of the first attempts at word processing software in BSD 4.2 UNIX, where we would embed tags to underline words, other tags to turn the underline off, and so forth. (Come to think of it, maybe that’s where the idea for HTML came from.) If you forgot to turn off underlining, you ended up printing several pages of underlined text and wasting precious time on the building’s only laser printer. It was ugly, and the first WYSIWYG word processors were a welcome relief. Now, here I am doing the same thing with HTML. My problem is that I want to generate standards compliant, accessible sites, and I don’t know any other way to do it other than hand coding.

I suspect that it is the hand coding that is responsible for making things hard, rather than the CSS per se. I remember the first time I struggled with laying out tables by hand; that wasn’t easy, either.

Exactly – if you become a mechanic. I guess you’re a developer and so am I – we’re the mechanics who care. Joe user couldn’t care less though – just as his bloated markup hinders his SEO and slows downloading time, his car pollutes the atmosphere faster.

Here is the problem: The evolution of both CSS and browsers is not moving fast enough. We want CSS to be a as good of a design tool as InDesign, Illustrator, Quark, etc. Is it a good design tool? Yes. Is it great? No. It will be eventually, but the frustration is in how long things take to evolve.

It think a key fact a lot of people are missing is that the complicated ways to do 2 and 3 column layouts in CSS are needed because IE does not support the easy ways CSS provides (using table display types with semantic markup).

Yes, I agree with your point that the complicated ways are caused by IE not supporting the easy CSS ways. However, I do not agree that table display types are the solution. In order for them to work well, they bind you to a specific document markup. For example, you can’t put a menu at the bottom in document order if you want to place it on the left using a table display type.

The proper thing to use is absolute positioning. Because IE is such a pain in the ahem with its stupid box model and lack of support for resolving “left:100px; right:100px; width:auto;” and understanding stuff like min-width, creating layouts has become much more difficult than it should be.

However, I wouldn’t just blame it all on the browser – CSS has its deficiencies too. They would be less of a problem, sure, but you still run into problems. Just try making one of those layouts for a browser which does support most CSS properly, like Mozilla.

I’ve been building web sites with HTML tables and .gif spacers for about five years. This year after stumbling into the Web Standards “subculture” and the multitude of blogs that lead to Meyer, Zeldman, Shea, et. al., I took it upon myself to learn how to build valid XHTML sites and style them with CSS.

In some ways I agree with Sriram that there is a technical barrier to moving to this new way of thinking. If you are not comfortable using a text editor to write CSS you may as well give up; and don’t get me started on the pain of learning the browser hacks.

With that said, I believe that for a web designer/developer the benefits of thinking in “web standards” are worth the cost of being retrained. We are probably years away from having good tools that allow non-technical folk to design web sites that rely on CSS positioning. But let’s be honest, how many well designed sites that today are based on HTML tables are maintained by non-technical people? Even with Dreamweaver and other tools you can’t escape having to get into the HTML code and mess with the percentages, pixel width and height of TABLE, TR and TD tags as well as .gif spacer sizes.

What sold me on using web standards was when I started viewing source of sites that were styled in CSS and were valid XHTML. If I could actually read the source and understand what was there, then a Google robot or a blind user would have an easier job of “reading” the source as well. The icing on the cake was the increased efficiency to using smaller source files and browser caching of CSS and images.

After having read scores of sites and blogs maintained by web standards advocates I must admit that there is a common attitude of web standards being the RIGHT way and that you suck if you don’t use CSS. This might have something to do with Bosworth’s and other’s labeling of CSS fanatics. Yet someone at the CTO level should be able to see past the passionate blog entries and recognize the true benefits of the principles of using web standards.

Nathan Herald wrote in to say...

I taught a class that the students had to pay for in my community not long ago. My average age in that class was around 40. Only one person in that class had tried to make a website before and she was a librarian.

In three days (three hours each day) I taught them about XHTML and CSS. They only knew going into this class that it would be about making websites.

In those three days each student understood the concepts and was building sites with Dreamweaver, Notepad, or anything else you can think of.

It was easy to explain to these people what a ‘tag’ was and a ‘style’ and what it did. I explained that as living objects that you put in a document to do things.

This proved to me that it is far easier to use CSS to style something, I have people saying the entire time This just makes alot of sense.

The comments seem to be running away on the “is css easy/difficult” thread, which is not absolutely germane to Eric’s post. I’m afraid I’m going to continue along the same line, though.

I have taught people from scratch both to do table-layouts (I no longer remember how I used to do them though) and css-layouts. Although sometimes the rules which are needed are a bit obscure, the basic principle of a 3col layout is simple: have main content in the middle, put the rest in the margin.

I did this again last night: took us one hour from scratch to code a semantically marked up sample page, with embeded sub-menus, javascript, the lot. For someone who has never coded html before, the current ways of doing it make sense. In other words, the cost of entry is not high.

Ooh damn, I seem to be reiterating the same thing as Nathan. This is no coincidence…

you should build a 20-field form using floats and crazy amounts of CSS instead of a simple table-based grid.

There are plenty other ways of styling forms that like using dls, for example. I guess that making a for by using CSS is just to show it can be done (i’ve done it). But if using a table, it is important to make it not nested and accesible, something that few developers pay attention to, in part because web design tools don’t promote it either, so, it is a “craft fault” right from the beggining.

On other thoughts; true, better WYSWYG tools are needed to make the use of CSS a common pracitice. But we are on track, thanks to people like Eric and the members at the WaSP project. We (and I count myself for promoting the use of standads as much as I can) are participating in a slow transition. But we are, in fact, better than three years before: the browswer developing companies are more into supporting standards and there is some kind of hype for using them on pages around the world.

It’s like a wave, the more we promote the use of standards (for the right reasons such as accesibility as noted on a previous post) the bigger it gets and people/companies will take action into making better browsers and better tools to support what the consumer wants! (or needs).

In the mean time, “technical people”, like web developers/designers, have the responsability to make the change happen for it will affect directly our line of work. The method is not by elitism and looking down on people (as it seems is the common perception) that use tables for layout purposes but by showing the benefits of using and maintaining standards.

-jl

p.s. IMHO it is not so technical to understand that a p tag is used for a paragraph and not for leaving a blank space.

I agree wholeheartedly with those who say that learning XHTML+CSS from the start is easy. That’s the only way I learned – I didn’t even know what a font tag was until I’d been designing for a while!

And now I look at people trying to change widths of spacers and pity them, because I know I can do it so much faster. CSS is not a hard language to learn – most of the keywords are in plain english, and there’s only a few rules like LVHA to remember. And semantically correct XHTML is so much easier to produce and understand than tables within tables within tables…

I agree that HTML and CSS is easier to learn from the start. I used to hate, and I mean HATE CSS and web standards. I spent many fruitless hours trying to graft CSS onto my regular table-and-spacer layouts, and wound up just frustrated. The only way I was able to really learn about CSS was to completely abandon all my previous HTML instincts and learn new ones. But after I did, the learning was fast and a lot easier than learning the old way was.

Charles Belov wrote in to say...

I notice your site doesn’t do this, but many sites using CSS render with text overlapping other text if the visitor is using a font that is larger than the designer anticipated. (The comment box, however, does go outside the browser window at 200%, which is a problem.) I, and other designers, need to remember to test the usability of sites at different window and text sizes when using CSS in place of table layout. Table layout definitely prevents the text overlap problem.

It is possible to have left-side site navigation occur semantically below right-side content. Consider the following table, 2 rows by 2 columns:

ab
cd

Cell a contains a one-pixel spacer gif.
Cells b and d are joined via rowspan, aligned top, and contain the content.
Cell c contains the site navigation and is aligned top.

Joel Goldstick wrote in to say...

where does this perception come from, that CSS is promoted a way to make the Web harder and HTML more difficult?

Unencumbered by the facts, my guess is that there are many people who make websites with frontpage, or photoshop, or other wisywig tools. Many of these people don’t know or care about html, css, etc. It scares them. Many of these people hold corporate positions, or have images as ‘experts’ to uphold, and so they vocally ‘dis’ what they don’t have skill in, or understand because it scares them. If it is necessary to understand a bit about what is going on behind the screen, then they are in a sense frauds. So I think it has to do with survival in a very difficult economic time.

i taught myself html by sitting in front of my computer with a document that had information i wanted, without the extra stuff. i think my first reaction when looking at the source code of most pages was ‘g*d, what a mess: there has to be an easier way to do this …’

so i taught myself css the same way i had taught myself html: by sitting down in front of my computer with a plain-text editor (not even syntax-highlighting). fortunately, i had a great guidebook this time — Cascading Style Sheets: The Definitive Guide published by o’reilly.

and it is much simpler … as long as you can give some things up, like anal-retentively pixel-perfect layouts. i found my simpler way and i’m never going back.

My problem is that I want to generate standards compliant, accessible sites, and I don’t know any other way to do it other than hand coding.
Because there is no other way to do it.As far as I know, there isn’t any wysiwyg editor that produce clean smart semantic code. NVU, the new GNU wysiwyg editor doesn’t seem too either.

By the way, this debate and these uses are not from the web. It’s exactly the same about word processors… you could design your documents with nice first line indenting (non-break spaces and tabulations), smart page using (invisibles tables), and so on. Or you could define styles, and use them on semantic elements.

With generations of kids using tables and nbr-spaces/tabulations for layout in MS Word, we need really good webediting tools. Really, really, really.

Everybody that is currently discussing the fact that there are no WYSIWYG editors that produce smart symantic code are partially correct. All the people that say there are no WYSIWYG editors that have good support for CSS are partially correct. Sure there is the ever abundant MS Frontpage that seems to be what most people learn on. But lets look at what Dreamweaver is doing. Yes, it will automatically create code that is non-semantic and inaccesible, but by spending a couple of minutes in the preferences and already knowing what you’re doing, Dreamweaver can produce some beautiful code if you tell it to. So many people rely on using a WYSIWG editor for nothing more than a word processor. That’s not what these tools were designed for. They were designed to allow people who have no knowledge of (X)HTML to create a website that they can put up on the web and finally say they too have a website.
When I first started getting into web design, I started out with Frontpage. Not because I wanted to, but because that’s what was provided to me by my school, and to be perfectly honest, I didn’t know any better. Soon after I created my first site with Frontpage, I took an introductory class on HTML. This lead me to the realization that I prefered to hand code my designs. Soon after that I began to teach myself Javascript and more HTML. All the time I was hand coding just to produce a smaller footprint that users would have to download. I then started going to my current school and started getting a background in print design and using the stylesheet feature of Quark and InDesign. Then I took a class on Dreamweaver still knowing nothing about CSS other than the fact that I can create text based hyperlink rollovers. Wow big leap there huh? While in my Dreamweaver class I started learning more about CSS because that’s what the program is setup to use, at least as of MX2004. Now at this moment in my background, I am still using Photoshop to layout the design ahead of time, and then using ImageReady to create the slices and then creating the table myself so that I have more control over it. Shortly after my first dreamweaver class I began reading A List Apart, as well as the countless blogs of people that are advocates of using CSS and semantic markup. I now use dreamweaver not as a WYSIWYG editor but as a tool that enhances my workflow. I use it to create the basic markup in an XHTML 1.0 Strict environment usually, and I also use the ability for it to quicly edit my CSS. Even when I’m hand coding my CSS, Dreamweaver’s ability to pop in the common values, or give me a tool tip with the proper shorthand syntax is a huge timesaver.
Now as far as HTML becoming too complex and not allowing the simplicity of design that it should, I find that to be completely absurd. As a programming language such as HTML goes through revisions, things are added and removed to make the process easier. Take the <img /> tag for instance. It was added to make the ability to embed an image to a page easier. Now I know that the <img /> originated as a proprietary tag in Mosaic, but compared to the suggestion the W3C was facing of using <embed>, the <img /> tag is by far easier. Another item that has added to the ease of HTML was the creation of the dreaded <table> tag. Imagine if the tag had never been created and we were still displaying tables using a fixed-width font and dashes (-) and pipes (|). It would make the web a nightmare for anybody to try and get into.

For all those who think that XHTML/CSS is hard, I have 5 classes of Year 8 kids who can refute that easily after only 1 lesson a week for the last 3 weeks

So why are we teaching XHTML/CSS to 13 and 14-year-olds? Because I, like Eric, want to help people put things up on the web. The web should be easy and it should be accessible

Until someone manages to build a decent WYSIWYG standards-compliant web-building tool, the best way to do that is to handcode XHTML/CSS (or HTML, Anne, but I know which I think is easier to teach to a class)

After a few lessons, most of the students have a 6-page site filled with information and styled with hideous clashing colours (they are in Year 8). All of which validate perfectly

Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...