Forum Moderators: not2easy
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>
</body></html>
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);
-->
</STYLE>
or embed it in the header:
<STYLE TYPE="text/css" MEDIA=screen>
<!--
h1 { background: url(foo.gif) red; color: black }
-->
</STYLE>
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>
or
<h1 class="pleasereleaseme">Hello World</h1>
or
<h1 style="color:red;">Hello World</h1>
or
<h1 class="pleasereleaseme" id="metoo" style="color:white;">Hello World</h1>
Then the stylesheet can have:
h1
{
color:blue;
}
.pleasereleaseme
{
color:red;
}
#metoo
{
color:green;
}
but that's not complex enough to remember so you also can do:
h1.pleasereleaseme
{
color:yellow;
}
and
h1#metoo
{
color:pink;
}
still not complex enough so you can do:
#metoo h1
{
color:purple;
}
but in case you need yet another way to access something don't forget the power in doing:
html>metoo h1
{
color:brown;
}
On top of all those ways to access one element, don't forget if you want the background color changed you can do:
background:red;
OR
background-color:blue;
and I love this, align stuff to the right:
float:right;
text-align: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...
the "Specs" or "Recommendations" are and were the documentation, the reason they are not black and white as someone mentioned, is that it is a constantly evolving craft. Like two painters given the same tools, the missing ingredient is INTERPRETATION. That interpretation is not only up to us as users, but up to the browsers and their implementation, it's obviously in everyone's benefit that they implement it as similarly as possible, but it is not a necessity. Watch for those vendor specific extensions [w3.org] which allow them to implement new features for usage and testing, OR they could just give up and use them to do what the heck they like, while nice that they exist that would really would make x-browser CSS a nightmare :)
Asking for complete documentation on something that is not a scripting language is like asking a master painter "how do I paint like you" - He can make sure you have the same canvas and the same tools, he can explain (or document) how he mixes his paints so you get the same colors on your palette, but he cannot always express how you should apply the paint to create the exact same texture, without a lot of unnecessarily complex mathematical equations I presume and/or bending some "rules" that you were taught at ART school. You need to take the basics and develop your own technique.
CSS Standards "Evangelists" had/have a lot more to do than simply flying the "standards" flag, a job which often unfairly, earned them the title "purists". They could see even back then that this was not something that could have a rule book written for it and still move forward with the times, and be extensible. Browser capabilities simply moved too fast, that is all but over now, FF and Opera Users (Safari/Mac probably yes ;)) can no longer be relied upon to update their browsers on each latest release, just like the tanker that is IE, so the days of rushing through the bug fixes(not security bugs.. CSS Bugs!) are through. It was fun and I really appreciate the fact that we've even arrived at the point we're at, in a somewhat uniform fashion.
I do not forsee a "CSS" manual anytime soon, each browser will have their own documentation, and each of those will or should have its roots based on the original recommendations hopefully.
As for CSS, I see progressive enhancement, with the occasional "new" thing (like a layout module) if it works along with the basics that are already in place. Mozilla flex box thing would be good, but again we're at the point where no single browser should be able to dictate.
When I'm working on layout, I have open these browsers:
IE, Google FireFox (hey, let's call a spade a spade, shall we?), Opera, and Safari.
Nearly always, usually with something relatively positioned, I reach a point where Safari, GFF, and Opera all "agree" on a rendering and IE7, of course, issues its "minority report". IE6, usually does too, and many times there's a difference between IE6 and IE7's rendering.
My assumption - soon to be proved true or not - is that with IE8 in IE8 mode - IE will no longer issue that minority report that I'm so accustomed to seeing.
And so, with a sigh and another cup of coffee, I move on to reconcile the differences in some way. I might change my approach to the box I'm styling, I might give up and use conditional comments, whatever.
I am not, however, enraged.
IE6 came out in August of 2001 and IE7 is essentially a bug fix release of IE6 that addressed only the most glaring of issues. IE6 AND 7 are both seven years old.
Of course, Google FireFox doesn't have any quirky rendering issues dating back to 2001 because it didn't exist.
Why fault Microsoft? Who not the hundreds of millions of users who don't upgrade? Why not site owners who continue to support older browsers without so much as an alert box advising users that they can do better?
The Internet as we know it today was built on the back of IE6 and we don't seem to have done all that badly. Empires did not rise or fall because of the three pixel text jog or lack of the CSS Child Combinator. The kids who are dead and dying in Darfur were not affected by this one way or the other.
Anyway, there is an attrition rate - the rate at which people buy new computers, upgrade their operating systems, upgrade their browsers, and all such... - and there is no choice for those who produce content but to wait it out until older browsers with poor CSS support fall off the map, so to speak.
Thankfully that has finally happened to IE5.x (or nearly so) and many of us no longer feel the need to support both box models - standards and quirks - for the same content just because IE5.x has no standards mode and X% of users are still using 5.x.
Microsoft ships its browser to customers. Those who've paid good money for Windows. Google FireFox ships its browser to - well, I'm not really sure HOW or as WHAT they refer to their users or how exactly they view the relationship and their responsibilities- and therein lies all the difference in the world.
And so, those currently climbing the CSS learning curve have to deal with how things are, today. Does it add a little confusion? Sure.
So what else is new?
ciao all, its been a great debate!
Let's not forget that Opera is a browser primarily by "technically adept" people, and that thus they are more likely to download updates as they learn of them.
With regards to Firefox: it has a nifty feature that alerts you of major version updates when you start the browser. The update process is quick and painless, and the updates, as I recall (I use Opera primarily these days) will install automatically the next time you restart the browser anyway. I could be wrong; please correct me if I am. That's something I want to know for sure!
@poppyrich (though I suspect he may not be contributing anymore):
My opinion on conditional comments: They are a blessing. There is nothing more effective for resolving browser disputes than a command that's only interpretted by the offending browser! It may not be technically standards compliant, but it is a good method of saying to developers "Hey, we messed up, we're sorry. We hope this eases the pain."
I suspect I may be dropping out of this one at this point as well; it seems concurred that the debate here at least is over. However, in the field, much like the battle for Jerusalem, I suspect this debate will carry on far longer than it should (maybe not centuries, but you get the idea).
Edit: The difference between grammatical correctness and a run-on sentence is a semicolon.
Html was created in an earlier time, when browser/device independence and layout was expected to differ in interpretation. Semantic Html says <H1> for Heading1 which can be interpreted any way a browser wants to.
If CSS wants to make all browsers depict things the same way, then the documentation on coding it belongs in their camp, not giving the browsers "freedom" to interpret H1 or border-bottom any old way they want to...and therefore pass the browser the responsibility to document to web designers how to code it...
Sorry, but that just doesn't make sense to me...
