homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderators: not2easy

CSS Forum

This 64 message thread spans 3 pages: 64 ( [1] 2 3 > >     
Debate: While css goal is noble, it needs to be rebuilt from scratch
CSS does NOT follow KISS

 2:59 pm on Jun 2, 2008 (gmt 0)

While there have been many css debates, I think this one takes a new angle.

I was reading this thread [webmasterworld.com] while in the middle of "Psychology of Everyday Things" by Donald Norman (partner of usability guru Jakob Nielson) and got an epiphany.

Norman became fascinated by both what causes products to be designed poorly and the psychology of people faced with such products.

Ironically, the more features you add to a product, the more complicated the design must become. Sometimes rendering the most basic features useless.

Even more ironic, when users can't master a product, instead of blaming the design, they tend to blame themselves.

It hit me that those of us struggling with css need to stop blaming ourselves and start to blame css for being poorly designed.

Here is an example from the book (to the best of my memory).

They got a new telephone system with tons of new features that might have been welcome had they been usable. For example, even if there were a large number of extensions, you could put a call on hold on one phone on the 5th floor and pick it up from another extension on another floor. Clearly a great feature. But to access it you need to remember what extension# you put it on hold from and an arbitrary number that denotes "pick up from hold".

No one could remember the instructions. And people blamed themselves for their difficulty.

The end result was that the phone system was not intuitive or usable and the features were not used... If someone memorized the manual, they might find it a fantastic system.

Which is why the css experts feel that it does NOT need a redesign. They are so close to it, that like the designers of the system, they can no longer even see why it's flawed... Which is a shame because the people who have the power in css circles to begin a movement to change this beast are the people least likely to realize the enormity of the problem...

If so few people can use something that is supposed to be as global as css, we've got an issue...
When it comes to usability, KISS is king. Keep it simple.

I will give you an example of why I say css is too complex and too flexible (which was used against me in an argument).

Keep in mind Norman's rule that the more features/functions, the more difficult it is to make a product usable... (it applies to software as well)

Take this bit of html.

<html><head><title>hello world</title></head><body>

<h1>What color am I?</h1>


How do you style the one line of text in there using css?

Let's see. You can point to an external stylesheet with:

<LINK REL=StyleSheet HREF="style.css" TYPE="text/css" MEDIA=screen>

or embed in a style directive and @import it:

<STYLE TYPE="text/css" MEDIA="screen, projection">
@import url(http://urlhere/style.css);

or embed it in the header:

<STYLE TYPE="text/css" MEDIA=screen>
h1 { background: url(foo.gif) red; color: black }

Now you want to give it a color, right? How?

Give it an id, or a class or embed the style inline, or use descendant selectors (or whatever it's called). So it can be

<h1 id="pleasereleaseme">Hello World</h1>


<h1 class="pleasereleaseme">Hello World</h1>


<h1 style="color:red;">Hello World</h1>


<h1 class="pleasereleaseme" id="metoo" style="color:white;">Hello World</h1>

Then the stylesheet can have:


but that's not complex enough to remember so you also can do:




still not complex enough so you can do:

#metoo h1

but in case you need yet another way to access something don't forget the power in doing:

html>metoo h1

On top of all those ways to access one element, don't forget if you want the background color changed you can do:




and I love this, align stuff to the right:



but don't forget, when you float it right, instead of a big box, it collapses the box and moves the other stuff up. Because it becomes inline.

And if you've got all that straight (after about a year of frustration), thanks to Microsoft, you can look forward to perfectly good css not working on all browsers...

If you want to debug, you need to know something that's not intuitive. The cascade. Not to mention hidden defaults. Use global resets and all sorts of funny stuff happens.

I'm aware that there are reasons it was built this way and good uses for some of the features. e.g. A class without an id would mean no dom. And the dom is one of the best gifts the Internet was given.

There are some good uses to be made of collapsing a box.

But the end result is that it's too counterintuitive right now.

And complexity is the price to pay for offering too many ways of doing the same thing.

CSS needs to be simplified. If we don't accept that there is a huge problem, then boy will we be frustrated when all the browser makers finally support the protocols we've built. Because we'll still have a heck of a time building a website that looks good and we won't be able to blame microsoft anymore...only ourselves...

In fact, perhaps if the protocol had been less complex in the first place, the browser developers wouldn't have had as hard a time conforming once they decided to do so...



 8:47 pm on Jun 2, 2008 (gmt 0)

Personally I think there are 2 fundamental problems surrounding CSS:
  • IE's (and other browsers, but far less) buggy implementation, the broken box model, the bugs that became features for new versions to mimic, ... setting people on the wrong foot is they start there, and worse making it a nightmare to get it right in all browsers.
    Somehow MSFT needs to be forced to stick to standards and only standards. Making more standard won;t fix a thing: they'll happily join in creating it, only to ignore it afterwards
  • People new to CSS systematically trying to ignore what CSS is about and instead try to replicate what they did with tables: think in the sense of square boxes sitting next to one another. If you try to use CSS with that approach, you will run into trouble, and you'd be better off to stick with the tables to some extend (note: I'm not advocating the use of nested tables).

Perhaps the first problem needs to be fixed by more public humiliation of Microsoft (but they have very thick skin).
The second is probably easiest fixed by tutorials, not focusing on what the individual things of CSS do, but focussed on what the ideas and the current state fo the art way to do things and how to approach the problem.

Other systems of doing layout aren't always all that easy to use, but the same goes for e.g. word: 99% of those swearing by it have no idea how to properly use and they just continue to kludge their way, yet they're not unhappy about it, and even if you try to show them the way they are unlikely to be interested in learning...
The average joe isn't dumb, he's lazy. But let's not design something like CSS -that the average joe never will see- for the lowest common denominator, let's aim substantially higher.


 9:15 pm on Jun 2, 2008 (gmt 0)

I see the biggest problem with CSS as a standard is that there are many too many SHOULDs in the spec; a few more MUSTs would have gone a long way toward resolving differences in interpretation.

Coming from the paper and ink side of publishing to the web side was a fairly easy transition. After all, HTML and the initial CSS styling specs were fairly evolutionary outgrowths of the specs developed on the print side. Then CSS-P came along with its "suggestions" on standards. More than 10 years later I'm kind of, well, I guess shocked is the word, that I'm still coding my web page layouts by hand. Could you imagine having to do that in PageMaker or Quark?


 11:30 am on Jun 3, 2008 (gmt 0)

It hit me that those of us struggling with css need to stop blaming ourselves and start to blame css for being poorly designed.

Or put the pyshcobabble book down and sit and read the CSS specs ;p


 2:28 pm on Jun 3, 2008 (gmt 0)


Or put the pyshcobabble book down and sit and read the CSS specs ;p

I could take your cue and insult your intelligence by citing a spelling mistake in the one sentence you bothered to write, but that doesn't further quality conversation.

If you read the book and have a criticism of it, bring it on.

If you didn't then how about saying something a little more useful? Thanks in advance.


 3:10 pm on Jun 3, 2008 (gmt 0)

Clark, you asked me if I would still disagree with you after reading, I'm afraid I do ;) and this is a debate so..

I believe CSS, as a language, could not be simpler.. those constructs you mention are simple element/id/class selectors, it doesn't get much simpler than that

as for how the property:values work well again that's just a learning curve thing, but if you already understand your HTML elements and attribute (the base of every web page) then the properties should quickly follow

to carry on your phone sytem analogy,
It's not the responsibility of the phone system maker/developer to ensure their system is transparent, or fits precisely the level of knowledge of each of its users. They build the system to specifications that are required by a lot of different applications. While doing this they have to deal with other things that users can't possibly know (or even care) about.. like internal wiring conflicts, the ability to plug in another twenty phones, etc.. and of course they realise that not every use case of their system is likely to be the same no matter which stage they release it at, so unless they're to solely build bespoke systems, with their higher prices and limited markets, are you going to tell them to dumb down their system?

No one could remember the instructions. And people blamed themselves for their difficulty.

Those people were lazy or the company were too far ahead of their time installing such a complex system (although they were probably thinking ahead to a time where, due to the rate of expansion in the technology industry it will be required). It was not the phone system itself which was to blame it was the company management for not explaining its expectations regarding the use (and learning curve) of the phone system, to the staff.

As is often the case, if the staff had needed the functionality, they would've learned the rules, if they couldn't remember the codes, they would have read the manual and organised to have charts of offices with the various extensions beside each phone - they would've organised "cheatsheets" because while they neede to learn the system for their job, it's not their job to work for the phone company by swallowing the whole manual.

Which is why the css experts feel that it does NOT need a redesign. They are so close to it, that like the designers of the system, they can no longer even see why it's flawed... Which is a shame because the people who have the power in css circles to begin a movement to change this beast are the people least likely to realize the enormity of the problem...

That statement very likely offends a great many people who have dedicated a lot of time over the last 10 years, are you saying they weren't keeping up properly and created a beast and now you want them to stop what they're doing and change it? How would you have them change it, any suggestions, what would make it simpler?

There are many many CSS experts who have actively worked and still are working to try to help ensure that CSS remains as simple as it is. It's them who built/build the test suites for every perceivable use case and test it where possible under very stretched conditions (not always for the web!) if it weren't for such people and a lot of spec reading/writing and working with browser manufacturers to ensure it can be implemented. I've a feeling things would be infinitely more difficult.

Someone once said to me that CSS was not simple because it was not logical, I didn't understand it at the time because I'm a very logical person, and if I can get it then that must mean it's logical. However I think they were right in that they found CSS wasn't simple because they couldn't apply it logically like a "scripting" language. CSS is not a scripting language, it's simply a language, and with that possibly comes flaws that it had to deal with while "talking" to other applications when it was being born.

But it's like any language, it's best to learn it as a child learns, i.e. remove the preconceptions and go with the flow, or memorise the bits you don't understand yet - we can't change HTML or its attributes, so we go with them, it's fairly easy ;)

The basic principle of CSS is very simple, the same as any language, although you can construct complex phrases from simple words, I wouldn't expect everyone to understand just how complex a phrase might be required in later life :)

I've no idea were the "scratch" would be now anyway.. things have changed so much and it has come from the ground up already!


 3:27 pm on Jun 3, 2008 (gmt 0)

Clark sorry if your offended but no offence is meant. But thanks for pointing out the spelling. I dunny care. Sorry I know I don't have the intellijense ;) for big long paragraphs of retorik ;) but it twas but a little joke.

I probably should have mentioned, I had the same theory on flash and papervision. But then I just sucked it up and got on with learning.

Anyway, I've probably offended you more and I'll get a slap from the mods.


 3:46 pm on Jun 3, 2008 (gmt 0)


I'm not offended. I was vainly trying to entice you to provide some kind of useful post.

You're assuming that I'm not sucking it up and this is all some stupid complaint.

But you're wrong, because I'm in the 1% of people who is learning css in all it's glory and sucking it up. I still think it needs to be rebuilt and brought it up in the hopes of making people really think about it.


Clark, you asked me if I would still disagree with you after reading, I'm afraid I do ;) and this is a debate so..

Meaning you have read the book or my post?

I don't remember what I stickied you but I meant to say after reading the book.

I didn't actually think my argument alone would be enough to convince you ;)

Those people were lazy

You're reminding me of the developers I had to argue with when I was manager of tech support. Our customers didn't like certain "features" because they were hard to use and confusing. So we had this big meeting to discuss what would be fixed and what frozen. When starting the meeting the CTO said "Is the user the enemy or a friend"? ;)

That statement very likely offends a great many people who have dedicated a lot of time over the last 10 years, are you saying they weren't keeping up properly

On the contrary. I actually have great admiration of the people who built it. They did great with what they had to deal with...

What I mean is that a designer/developer is too close to his work to be objective. Having developed a fair number of systems myself, I'm always amazed that what I think is so simple looks very different once you test it in front of a user. Usability testing is key to any serious website, let alone software development.

One question. Do you honestly believe that when css was developed, they regularly put their new features through usability testing?

[edited by: Clark at 3:50 pm (utc) on June 3, 2008]


 6:51 pm on Jun 3, 2008 (gmt 0)

I read the book. (Norman's)
However, you should also read his more recent book called Emotional Design. In it, Norman admits to having had an epiphany of sorts regarding the need to have usability give way, at times, to making something that's aesthetically attractive. Plus, scientifically proven out by studies, is that things designed attractively SEEM to work better, even if they don't really. (We humans and our craziness.)

That said, I sympathize with Clark's stance.
It has been bothering me a lot that creating web pages has become so technicized. The learning curve is too great. Amateurs are no longer welcome.
Which is why, I guess, most people turn to Facebook and like sites and Wordpress and other template based systems and developers turn to cross-browser libraries - making your own way has become way too complicated.
However, my philosophy is that content should dictate form, so I'm doomed.

I find CSS counter-intuitive in only one sense, it uses a model of contiguous or overlapping boxes rather than a grid model like tables and every graphic arts program I've ever seen. (Snap to Grid, Show Grid, sound familiar?)
I used to turn my nose up at table-based layouts. Not anymore.


 7:18 pm on Jun 3, 2008 (gmt 0)

hehe.. I think appi2's reply was close to what a lot might want to say, and possibly might have got shortened to RTFM on forums which are not quite as polite as this one ;)

I think this is a great topic for debate, thanks for starting it! I know you are genuinely interested and trying to learn, but striking out at the system out of frustration possibly?

Meaning you have read the book or my post?

Just your post and the example, and some pages/reviews while I have respect for Norman and Neilson, I believe they only have a part to play, in this particular debate.. the book you refer to is the Psychology as Applied to Everyday Things, it was written at the start of the boom age of the technology you're now applying it to.. everbody learns..

I had to smile when I saw this quote in reference to it:
Anybody who has ever complained that "they don't make things like they used to" will immediately connect with this book. Norman's thesis is that when designers fail to understand the processes by which devices work, they create unworkable technology.

while there isn't a "used to" as far as CSS is concerned, I have to wonder if (the bolded part) is EXACTLY what would have happened to CSS if the designers behind it had not understood the processes by which (the at the time uninvented) devices that it might have required to work on, if they had simply written it with the screen media in mind, you might very well have your tabular layouts but it might very well have been an unworkable technology for a lot of other devices?

You say CSS "needs to be rebuilt from scratch", with that I'm likely never going to agree as I've put a very lot into it during the last 10 years, but I am interested as to what exactly you, or anyone, think is so wrong with it.

One question. Do you honestly believe that when css was developed, they regularly put their new features through usability testing?

What new features? CSS is a styling language it hasn't added any extra functionality that wasn't already there. It simply brought some aesthetic features out of the scripting layer into the theme/design layer - floats already existed as the HTML "align" attribute, absolute positioning always existed as position fixed or in the early days NN 'layers', hover was always possible using onmouseover/onmouseout - so what exactly did CSS introduce that is so monstrous?

Are you talking about usability from the design or developer side? CSS is not simply about WEB Page design, its bigger scale usage is probably applications, browser chrome (skins), plug-ins, addons, XML/RSS transformations .. exactly what kind of "usability" testing is required for skinning (presentation of content)

I'm confused as to exactly which users you are debating on behalf of, as far as I can tell the only ones who have a problem are those that try to squash "CSS" into a "Web Layout" or template/design box.. and the direction of that particular bit (CSS3 module) has not been decided on yet.

They did great with what they had to deal with...

and are still dealing with ;) it's the ever changing goal posts again, CSS can't just stop and take a rest (well it did but in hindsight that's possibly not a bad thing) we play with the hand we've been dealt, the game, meanwhile is still playing out

I'm sorry, I am willing to believe I'm too close to see a lot of what might be wrong, but I really do fail to see not only what is wrong with its basics, but also I fail to see that CSS is a goal (noble or otherwise) CSS is not the goal, it is simply a player in the team that participates in the goal scoring, The goal, is an accessible web for all, I believe, or going forward, accessible/usable web applications as well as a web page or two - what it is NOT, is just a web page layout method - to have believed that at the outset would have meant we might have got stuck "copying" tables ..

I find CSS counter-intuitive in only one sense, it uses a model of contiguous or overlapping boxes rather than a grid model like tables and every graphic arts program I've ever seen. (Snap to Grid, Show Grid, sound familiar?)

to wit, that's what I mean about it not being simply a layout method, and thankfully it didn't go that route whether by accident or design I don't know but I know that by the time A "Layout Module" arrives it will possibly be better understood that more thought went into it than just "we need a grid layout" - it will, to many, simply be another tool that CSS has in its box, and if you want to use that to mimic a table layout in a web page then that's what that particular module will be for!

tools for the job and all that..


 8:34 pm on Jun 3, 2008 (gmt 0)

It's not that I agree with everything Norman says, nor Nielsen...and sure, the book is outdated...and to be honest, not even written that well (imo). And there is a middle ground between the usability folks and the others.

But at the same time, when talented developers and designers alike find css so hard to learn, there is a problem.

Let's just take floats for one example. Why do they have to be so complicated? Why can't you float something to the right without messing up the whole layout? Who hasn't wasted hours on just that one issue? Every time I think I figured it out, something new causes the same problem to reappear. Yesterday it happened to me again. Luckily I had firebug installed, and saw that two statements were having an effect on the same item, and one of them was an id the other a class. I happened to figure out that probably the id overrode the class because an id is more specific. But how many people would have even realized that they had conflicting statements affecting one item, let alone figure out which one and why? Is there really no better way than this?

I understand and respect why we got here. But this whole meshugas reminds me of the old story of the qwerty keyboard...where supposedly the intended placement of the keys was to slow down typing so the hammers wouldn't hit each other...and long after the typewriter is obsolete, we are still using qwerty.

The Internet is such a new technology and yet we are reduced to so many workarounds already. What will be when css is 30 years old? I hope it gets easier but I doubt it...

Anyway, I agree we're real far apart.

I hope the thread provided some positive food for thought. But I doubt we'll be doing much more than repeating ourselves using different words from here on out... So I'll try to stop unless I have something valuable to add.


 1:00 pm on Jun 4, 2008 (gmt 0)

when talented developers and designers alike find css so hard to learn, there is a problem.
I don't come into either category I'm more like a "thick old amateur", but I didn't and still don't find CSS that hard.

It's a logical system, and although I tend to use a different "logic" to most people, I find that I can usually work things out for myself or if all else fails I ask a question here or on one of the other web design/coding fora. Some things may take a while to understand, but once you've got there you know it and then on to the next thing.

Levels of difficulty are in most cases subjective, but for comparison; I consider that learning CSS is a doddle compared to trying to learn calculus for "A" level maths nearly half a century ago.

My father used to say that if a thing was easy it usually wasn't worth doing.


 2:02 pm on Jun 4, 2008 (gmt 0)

FWIW, I'll testify that not being one of those rare individuals who has an intuitive and inately conceptual grasp of CSS, it's considerably harder to get the hang of CSS - particularly specificity and inheritance - than it is to program a huge mainframe computer in IBM/Assembler language code (low level machine language, step by step for every jot & tittle) than to code a site in CSS.

If you disagree, then I'd venture to guess that you're *probably* one of those rare and talented individuals (aka CSS_gurus), and I applaud you for it. But not all folks are so gifted; some have succumbed to despair, caving in under the pressure and mystification of the push to create webpages that work without a table or a font tag in sight.


 2:26 pm on Jun 4, 2008 (gmt 0)


You know Assembler? Not bad!


 2:36 pm on Jun 4, 2008 (gmt 0)

I got into web work - moving into it from network administration - around 2001. At that time, my research convinced me that CSS was the wave of the future so that was what I learned first. I was doing intranet work with IE as the only user agent so that simplified things a bit. (Besides, in 2001, what viable alternative was there?)
If I had learned web design using tables, I might have felt differently.

Frankly, I picked CSS up rather quickly and hearing an opposite story from others is really interesting. (Hey, inheritance and specificity are your friends!) But that's not to say that creating a good stylesheet isn't difficult. I have always found it a lot of work. Grueling.

On occasion, when I had to make changes to existing pages with table-base layouts, the thing that drove me crazy was the clutter. Having to find the cells, columns, and rows involved really drove me nuts.
So much markup to sift through. At least with stylesheets, HTML elements get labeled with hooks of some kind - id, class, etc - which, to me, being short on patience and astygmatic to begin with and with presbyopia due to aging getting worse by the day - so it's easier to find what's gone wrong stylistically and content-wise also, since things get labeled.
I have no doubt that others have found exactly the opposite.
Meshugas, indeed.

Anyway, Suzy, clue us in - where does the new table-layout rule fit into all this? Is a middle-ground on the way?


 5:39 pm on Jun 4, 2008 (gmt 0)


I am by no means a guru but to me CSS is a lot easier to understand and way less complicated than programming and database languages which frighten the hell out of me. Assembler sounds difficult, many times I've tried and failed to understand perl, php and mysql but for me those particular light bulbs don't go on. I am in admiration of those of you who use these programs so easily. I'm far from being an expert in CSS but I've grasped most of the basics and to me the learning curve seems way below that needed for "real" programming languages.


 5:47 pm on Jun 4, 2008 (gmt 0)

Let's differentiate between learning to "do some stuff" in css and becoming "real good" at css.

It's easy to "use" css.

But when you try to make sure it looks good in a wide variety of browsers, operating systems and layouts (e.g. 800x600 AND 1600x1200) that it holds to web standards and accessibility, that it's semantic and not cluttered, that fonts can be resized, that it works in a templated environment like Wordpress, that it scales so that you aren't creating a workaround in your global sheet for one page when you have thousands of pages that will use the same sheet...then it can get crazy and convoluted.


 6:51 pm on Jun 4, 2008 (gmt 0)

It's my opinion those who first learned developing web pages when the nested tables were in their full glory have the most problems with adapting to the CSS way of doing things.

Those who learned HTML back in the early days (1994 for myself), find it a nice way to step back to simple html , where you don't get lost what td belongs where, but instead can layout the much simpler html, and the concepts of cascading etc aren't that hard to learn, a float is relatively simple in it's basic form, ...

I think we also see often relatively new people to CSS associate CSS with a <div> html tag. Or (more advanced ones) trying to mimic tables in CSS. I honestly believe both are misguided. Stick to the html that makes sense on it's own (yes, the purist view), only use those spans/divs as a last resort cause the tag you need doesn't exist. (x)html 5 will have more tags that'll do away with typical divs like for a menu etc. After that the layout stays in the CSS file, might be hard, might be easy, depends on how complex you want to go. As the html makes sense on it's own, all complexity increments can be doen as the author matures in his skills/experience.

I don't think CSS should be compared to a programming language any more than a xml file should, or a BIND configuration file (the syntax with that one is somewhat similar). There's also more to programming than procedural languages, take a look at e.g. Prolog or Lisp.

It gets harder when IE and it's bugs/broken box model/... start to influence people still early on the learning curve as it'll confuse the hell out of you what the box model is supposed to be.
So instead of throwing out CSS and starting over, let's throw out IE (at least in the learning CSS process). Hopefully IE8 will be truly standards compliant (and nothing more), but I'm not holding my breath.


 7:32 pm on Jun 4, 2008 (gmt 0)

Maybe when IE sorts out it's problems things will be easier and I'll feel different...

Although I learned some great tips from Suzy that had me separate out the IE hacks to its own css file and that has done wonders!


 7:34 pm on Jun 4, 2008 (gmt 0)

It's horses for courses, most people who have anything to do with sites/applications from scratch are often a 'Jack of all Trades' but are possibly particularly good at one or two parts. that's what changed from before imho.. now it is more specialised in all areas of web development

poppyrich, says the barrier to entry is much higher, I agree with that and also the explosion of social networking means the "amateurs" no longer need to build their own sites when they're getting all that functionality without the effort ;)

because they're not having to go on the same learning curve some of us oldies did, tinkering with static pages and testing, for hours on end, they will likely think all (any language) is witchcraft (even HTML probably falls in that category now!) - however it's those who have learned a trade which are now needed to keep the applications looking/running smoothly.

Anyway, Suzy, clue us in - where does the new table-layout rule fit into all this? Is a middle-ground on the way?

I think you just hit the nail on the head, the middle ground is right here.. the (or a) solution is on its way. This thread, and it's different slant, is probably the start of people even seeing that this is possibly the middle ground? (I should start a new thread about the Layout modules, though, and not take this discussion too far from its topic, as that will be CSS doing more a job than simply styling.)

Anyway related and by way of an answer to "Why do they [floats] have to be so complicated?". Neither tables nor float were meant for web page layout, Clark, perhaps this is why people find them difficult (well that and the fact IE didn't really get them nearly right until IE6)? Just using them like "align" for floating images, tables, sidequotes, etc. into text, is absolutely fine and won't break layouts, i.e CSS floats do work fine. But when they're used for entire layouts their and CSS edges are being pushed.

That might be what is so difficult to get, the struggle that many (more) can now see. CSS Layouts are the way to go because many more can now see the connection between accessibilty and the semantic nature of HTML (and microformats and XML and SEO).

I think many come to CSS and do see the "obviousness" of it all but for layout because that's what they want, they already know it can change colors and stuff, but the facilities they want from CSS aren't quite there yet, rebuilding it will not make that happen any quicker.

CSS as a language is not so obvious when looked at that way as you're looking at it at it's most stretched, it's not its base that's wrong. The bar has been raised for everyone, including CSS, the social web networking explosion and applications, and plugin/addon demands has seen to that too,and all this has happened in what 2-3 years?

We were forced to bend CSS (as no-one thought it important enough before?), we're still bending it to do more than it was originally meant to do.

If table layout properties had come in to a more widescale usage, I think that all that would have happened is that CSS "purists", would've substituted table cells for <divs> (same source order and unnecessary elements would be required) just so they would have a CSS layout, but sooner or later that wouldn't have been good enough either as the HTML questions about tables show (cell heights and widths don't quite work the way folk want either) Table properties are exciting for those who actually want to reformat their tables [moronicbajebus.com]

At least with floats people are thinking more about the semantics of Markup and the actual HTML itself, you should not get bogged down with the how or why unless you actually want to, this "problem" will not exist forever.. (though if you want to help I've always said use CSS to its limits, it's how things get adopted quicker ;))

why is it middle ground?
none of us should have to worry when writing a page where a particular block should go, or if a wrapper div is needed for legacy layout(bug) reasons..

..but then, I defend doing it, because if we weren't still pushing, then the CSS3 module we're waiting for would still be shelved ;)


 5:26 am on Jun 5, 2008 (gmt 0)

It's my opinion those who first learned developing web pages when the nested tables were in their full glory have the most problems with adapting to the CSS way of doing things.

I disagree. That is a very presumptuous if not arrogant statement.



 8:48 am on Jun 5, 2008 (gmt 0)

I first started trying to learn CSS in 1997 - with great excitement. Of course browser support was so insanely poor that the effort was a waste of time. And when I re-approached CSS many years later, browser support was still way too buggy.

It's very hard to learn anything if the feedback you get from your early attempts tells you you're wrong - when you're right! This is the first complication of CSS that sends even intelligent, logical people running - but it's not a flaw of the language itself but rather of the browser builders.

By 2004 I moved our company to start developing with CSS positioning instead of table layouts. That lasted for three months. The extra development time to get cross-browser pages was financially prohibitive.

Even today, we develop with a basic table grid for the layout, and then CSS within that established grid.

The most frustrating area of CSS for me is still positioning, not basic styles. I used to do typography - and that's why I loved the promise of CSS. And I still do - you can get a MUCH better looking page with CSS than with old style font tags. But unless I am re-deploying already proven all-CSS layouts, developing new pages from scratch using CSS for positioning is still out of line I feel, from a practical, business oriented point of view.

CSS in practice today (and I do see a lot of it) is implemented horribly by a whole lot of professionals. CSS files are particularly hard to coordinate when a team is working the website. It's common for teams to end up with very unweildy CSS files, simply because the pressures of time and economy must rule out refactoring the existing code.

So I am one of those who feels like something is very wrong here. The practical evidence, more than a decade down the line, screams this at us. No matter how elegant and logical CSS may be in concept, when the general population of web authors can't get it right after all this time, it's not a very good tool. At least not yet.

The challenge of specificity is probably my biggest bugaboo. That one just breaks my head all the time and eats up many hours.


 9:54 am on Jun 5, 2008 (gmt 0)

Let's differentiate between learning to "do some stuff" in css and becoming "real good" at css.
As this comes straight after my last post I can only assume that you have made an assumption that I am way down the learning curve. You tend to jump to conclusions, and to me this makes all your arguments suspect.

 11:50 am on Jun 5, 2008 (gmt 0)

Old_Honky I'm sure it wasn't and so far (to me) that's the best statement in this thread.


 12:12 pm on Jun 5, 2008 (gmt 0)

The problem with css is that it is not easy for IDE editors (Adobe...) to build software that could allow web workers to visually build stylesheets as easy as they can build html, you almost always need to code CSS by hand if you want to take atvantage of the most usufull features, thus it is very frustrating for people who hate to write code... like designers, the intended audience for CSS, if i'am not wrong.

Other than that, it's a great tool, missing just a few features and wider support from browsers


 1:07 pm on Jun 5, 2008 (gmt 0)

As this comes straight after my last post I can only assume that you have made an assumption that I am way down the learning curve.

Appi2 is right. That's not the case at all. I have no idea if you are a css guru or beginner but I'd bet more like guru...

By the way, it sounds like you've spent the effort to read the conceptual model of css carefully which is why you have less issue with it.

I spent the time to do so a couple times also, but unfortunately my memory is not what it used to be and it hasn't "stuck" yet. I keep meaning to read some more tutorials on positioning and floats but who has time?

Thanks for weighing in Ted. At certain points of this discussion I began to regret starting it. But you are one of those people whose posts are all gems. And Marcia ain't too shabby either... The both of you have helped crystallize for me what parts of css to focus the criticism on. Perhaps just fixing those would go a long way to improving it.

The points you've both mentioned:

The conceptual model. The positioning. And the specificity/inheritance...

Conceptually, classes and id's are easy enough to understand. The idea that you globally set properties of (x)html tags is simple too. But where it gets hairy I think is this example:

<div class="foo">

You can style the contents of li with:
(not sure syntax here:)html>body>foo>ul>li { styles here }


#foo li


#foo ul li


div#foo ul li

I think the last one really throws you. Plus it's not 100% consistent.
I've come across an instance where it's not enough to say:

#foo li

but you are required to specify the full path to the item. And that kills me because I can't figure out why or specifically which cases this works or doesn't work...

This is particularly a problem with styling links (e.g. a:link, a:active etc...)

Another place where conceptually it's difficult is floats.
Although separating content and style has it's value, floating is an exception. I just had this problem yesterday.

You have an image. You float it left. Layout looks great. Until you look at it on someone else's computer at a different resolution and you find that stuff you thought was in a new paragraph is actually bunched up slightly to the left of the previous paragraph.

Adding a hook right into the paragraph you are floating so that you can float and end the float would do wonders in getting people to understand this thing better.

for example, say "clear=1" meant that the element would clear:both on closing the tag below the section meant to apply the float:

<div class="imagepretty" clear="1"><img class="thisfloatsitleft" href="image1.gif">Some text that will float around the image</div>
<div class="imagepretty" clear="1"><img class="thisfloatsitleft" href="image2.gif">More text that will float around the image</div>

If you don't have a hook like that in the code, you have to mess with the stylesheet on one specific page to manage floats properly. Even if you have thousands of pages.


 1:24 pm on Jun 5, 2008 (gmt 0)

To follow up on what I see as a key question with "the standards" such as CSS posed by Clark:

One question. Do you honestly believe that when css was developed, they regularly put their new features through usability testing?

The answer is, of course not. We are all guinea pigs. The "standards" are untested hypotheses. They are best guesses as to what will work best. They are what one, but only one, smart group of people think is the right way to go.

Many proposed CSS properties have never seen the light of deployment because they are just too complicated or, frankly, too trivial or too weird to implement.

John Ressig, creator of jQuery has this to report on his blog [shortened slightly by me]:

In preparation for jQuery 1.0 I decide to analyze the features of the engine to see what people are actually using. I ran a poll in which I asked the users which selectors they used. As it turned out there were a great number that no-one had any use for, whatsoever (and, in fact, this remains true to this day). At this point I removed them from the engine, breaking compliance with the CSS 3 Selector spec. Here's some of the selectors that were removed:

E:root - Rarely used in HTML. You already know what the root node is - it's named 'html'.
E:empty - This might be useful if it could include empty whitespace text nodes, but it doesn't. This will only match elements like <img/> and <hr/>, for whatever use that is.
E:lang(fr) - This could be achieved in so many other ways - but in the end, how many multi-language-on-the-same-page sites are there?
E:nth-of-type(n) - I'm not sure what the motivation was for creating all the -of-type methods, I'm sure it sounded great on paper, but in the world of HTML it's not very useful.
E:nth-last-child(n) - Another "great on paper" method. Don't think I've ever seen it used.
[/b]E:only-child[/b] - When does this occur? and why would you need to select it?
E ~ F[\b] - Only selects adjacent elements, in one direction. Why [b]a ~? Why only one direction?
E + F - Only the next element - rarely useful.
E[foo~="bar"] - Only matches values in a space-separated list. This is only useful for classes (which is taken care of with .class) and the ref attribute. Why not just use *=?
E[hreflang¶="en"] - Another selector that is really only useful for a single attribute - and not a popular one, at that

In other words, these things are in the spec but nobody seems to have any use for them.
Another example from some years ago is the spec for alternate style sheets. Articles were written about how cool they were. Font-sizing systems were developed and published based on them. (Invasion of the Body Switchers) And for years, Opera - who's top guy Hakon Wium Lie is a co-creator along with Bert Bos of the CSS spec and has, presumably an ego-driven stake in proving the worth of the specs he was central in creating - featured an Alternate Style Sheet menu which, we were assured by some, was the wave of the future. (Where, oh where, did it go?)
The bottom line is that creating multiple style sheets for different layouts is just too much work except in special circumstances. It just does not fit into the time-pressured priorities of the business. And so, you don't hear much or see anything about them anymore.

To sum up. Let us not be naive. Anyone who marches along blindly holding up the banner of "standards" as the be-all and end-all of what web development should be and how it should evolve, is mis-placing their faith.

Like SuzyUK sort of said - we're all stuck in the middle right now.
(Wasn't that a song?)

[edited by: tedster at 5:01 pm (utc) on June 5, 2008]
[edit reason] turn off graphic smile faces [/edit]


 2:54 pm on Jun 5, 2008 (gmt 0)

It seems to me like a general problem as software:

1. There goes the first version ok!
2. The second version fixes a lot of problems of the first one
3. The third version is dedicated to the "so called experts" constantly demanding users
4. The software becomes BIIIGGGG and unuseful
5. There you have it, now "hello world" requires 50 lines of code and lots of cpu power...

Simple is better.


 3:10 pm on Jun 5, 2008 (gmt 0)

like designers, the intended audience for CSS

I think designers were the ones who helped drag CSS kicking and screaming to where it is today, but I don't they are its intended audience.

Though I agree there will be a split (already splitting) because you can't WYSIWYG the most useful CSS as you say. What I think will happen is that will simply split further the hand-coders (site development teams) from the WYSIWYG users. Nothing against WYSIWYG users btw, a lot of them are very capable of writing code by hand but choose to use and tweak their editors to suit themselves for speed and comfort.

I think HTML editors will be able to support the basic coloring/styling features but in order to do so will continue to add to the divitis/classitis/template mess we're already seeing, don't think they'll ever get specificity so they will add another span/div instead ;) - So is that CSS's fault or is simply that by trying and failing to standardise a process that is this flexible, the HTML editors and users of them get their way and the HTML tag soup remains. CSS is flexible because it's not simply for WEB Page design, yet it could be the designers/HTML editor users who dictate this complex perception of it going forward.. hmmm


 3:31 pm on Jun 5, 2008 (gmt 0)


I donít think IMG tag has HREF, I think you meant SRC.

Great read.

Back to reading..

This 64 message thread spans 3 pages: 64 ( [1] 2 3 > >
Global Options:
 top home search open messages active posts  

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved