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...
You hit the nail on the head except you missed the last item. A brand new rewrite now that you know what you need. After the last step you begin the same cycle again :)
Blend...you are right..
Edited to add, appi, you are also right. I knew I was going to mangle that code, heheh. I had a conference call coming up so had to rush the post as it got to the end...
[edited by: Clark at 3:55 pm (utc) on June 5, 2008]
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.
I'd use e.g. E + F if only the most commonly used browser's vendor would pull their act together and fix their poor excuse for a browser instead of making slightly better (read:different set of bugs) new versions still rejected by a majority of end users.
Designers, by and large, want to do what they are good at and enjoy: designing, not coding.
Roger, I like how you summarized that point. I take notepad coding for granted because all those gui tools/rads that vomit code (as we used to call it) make it impossible to debug and just don't get it right.
====
By the way I'm glad to see this thread made the front page. Didn't expect that...
Did anyone really change their mind about anything? I doubt it. But just in case, would it be fair to say that where we'd like to see css be, is a place where it's possible to caress the hope that a graphical tool for the masses could be conceivably built around css?
I think satisfying that acid test would solve the problems the notepad coders have with css at the same time...
I'm in the process of learning HTML and CSS for the first time and I'm learning them concurrently. The class I took introduced CSS first and later showed table based layouts just so we could understand them. They used a bit of brainwashing along the way so all of us students would NEVER use table based layouts.
So, as someone who knew nothing about HTML layouts a year ago today, I think CSS is easier than using table based layouts, brainwashing aside. I had a moral conflict when I wanted to use a table within my website to display pictures. I quickly got over it when I realized CSS is here to provide accessibility...faster loading times initially and between pages. And the code I would have to write to make these pictures line up would be larger using CSS than using a simple table within a page.
I've guiltily had the thought that CSS is too difficult, especially after looking at some "professional" CSS templates that looks more like a roller coaster than something that simplifies style. But my opinion is that you can make it as difficult as you want to. You don't have to write 6 pages of style for a blog! You can also make it as easy as you want to and still make some great designs.
Maybe it is the W3c's way of separating designers and letting the cream float to the top. "Get Creative! or lose your business!"
Also, perhaps I am making this discussion obsolete, or merely adding fuel to the fire, but CSS3 is coming out and adding a few changes. It looks like it's more logical, but the "suggested" standards document is too confusing to sift through. Find it here:
[w3.org...]
So maybe that will help?! Who knows. I'm reading the book.
P.S. I'm a little confused, as a beginner HTML enthusiast, because the xhtml is all in uppercase letters and I thought it was "suggested" to only use lowercase for XHTML. Maybe that is a indicator of the developers thought process.
BUT I am am going to disagree with some of it, although I doubt whether it need affect any decision he would make about jQuery. It's more to show how specificity and the bad implementation of CSS will continue to make this perceived "problem" worse unless people acknowledge that CSS is already basic, it's developers' implementations of it that will keep it "complicated".
Here's the thing about some of those "rarely useful" selectors, they are a catch22, that is just catching up with itself now ;) Without them, some sites can't take advantage of CSS without a complete rewrite, and CSS will remain too high a barrier for them to even partially incorporate (not for layout, let's separate the two.. but for tag soup and stepping toe in water, accessibility reasons), without major, possibly prohibitive changes, and CSS will get the blame again. However the title and others want to keep CSS simple.. so in order to help keep it simple you're offered selectors that mean you don't need to re-write your HTML or add classes (CSS Hooks) - and they're not necessary!? seems to me to be exactly the answer for the simple side of this debate.
here's an example that close to home. ;) about just where those "unnecessary" selectors would help in an economic sense too, if they were adopted fully.
Brett (disclaimer: not saying he wants to) needn't rewrite all his code to remove the table tag soup in order to take advantage of CSS.. he doesn't have to go in there in order to provide HTML classes/CSS Hooks to hang a theme engine off
he could simply do nothing (bet he would like that ;)) and let would be themers provide skins for him
here for example is a snippet from my stylesheet for WebmasterWorld (no, it's a work in progress because it's my best testcase)
/* third table menu & Heading */
center:first-child+center+center {}
center:first-child+center+center td {padding: 0 3px;}
center:first-child+center+center h1 {}
it would actually have been a LOT easier if I (as a CSS'er) could use :nth-of-type(n) selector but hopefully you see the difficulty I'm having. I want to keep it simple.. I don't want to go to Brett and tell him he has to add selectors all over the place if he wants to use basic CSS....
there's always another side isn't there.. and you think what we've got is difficult, and some are removing things that would help both sides out
hmm.. Clark no you can't have a rewrite but you can help keep the easy stuff in there :)
As far as the "useless" CSS3 properties quoted from Ressig in my previous post goes - I think there is a point where the palette gets too large for practical purposes. The extra tool isn't worth the price of a larger toolbox and then, having to lug it around in my head.
Sometimes I think people make things more complicated than they need to be. Let's face it...even though this is all the latest and greatest, we all still code for the browsers with CSS rendering inconsistencies.
Until IE gets on its game and truly plays well with CSS, we are all coding for the lowest common denominator.
Actually, once I could do it, designing new pages using CSS which worked across all browsers (I found I could get rid of most layout problems most of the time by substituting padding for margins, which enabled me to avoid having to use box-model hacks) felt like being a 7 year old waking up on Christmas morning.
I look forward to the innovations which will be introduced in CSS3 and I certainly don't agree that CSS needs to be rebuilt from scratch.
When designing the page, the choice of which code to use would depend on whether you wanted to style all the h1 headings the same or not, whether you wanted to style all headings the same or not, and so on.
Answering those questions leads to the right code to use.
from CSS2.1 collapsing margins
8.3.1 Collapsing marginsIn this specification, the expression collapsing margins means that adjoining margins (no non-empty content, padding or border areas or clearance separate them) of two or more boxes (which may be next to one another or nested) combine to form a single margin.
In CSS 2.1, horizontal margins never collapse.
Vertical margins may collapse between certain boxes:
* Two or more adjoining vertical margins of block boxes in the normal flow collapse. The resulting margin width is the maximum of the adjoining margin widths. In the case of negative margins, the maximum of the absolute values of the negative adjoining margins is deducted from the maximum of the positive adjoining margins. If there are no positive margins, the absolute maximum of the negative adjoining margins is deducted from zero. Note. Adjoining boxes may be generated by elements that are not related as siblings or ancestors.
obvious.
Look at PERL. So many ways to do the same thing that it is often hard to make sense of another's code.
How about the use of if/else or select statements - two ways to the same goal.
Terniary operations? a ? b : c; What is that supposed to mean to the uninitiated?
PHP? How about variable variables?
Don't even get me going on regular expressions... There's a real mind warp!
CSS is much closer to traditional "coding" in my mind, and subject to a much steeper learning curve.
HTML is "markup" and relatively easy. If one knows proper grammer, then they know HTML. Paragraphs, headings, lists, etc., all set apart from the text in simple formatted tags < >
Yes, all would be rosy if Internet Explorer would simply "comply", (whatever that means) and, of course, the one other thing you failed to mention:
a half a billion IE users should simply and instantly upgrade just to make you happy!
Excuse us, but we're discussing the nature of the problem here, not fixing blame. And the idea that IE's implementation is responsible for the CSS learning curve is, well, without much foundation.
However I am intrigued by this discussion.
If CSS were to be rewritten, what form would it take? if "float:right" is so unintuitive, what would the new anti-CSS language have in its stead? What syntax would be better than the selector{property:value} syntax of CSS?
Would the new anti-CSS emulate the syntax of some other language like XML or JSON? Or would it be procedural? OOP?
Script-esque
style h1(){
if(this.above('p')){
this.marginbottom = 6
}else{
this.marginbottom = 2
}}
XML-ish
<anticss:style selector="h1">
<anticss:property name="margin-bottom">2</anticss:property>
</anticss:style>
JSON-like
{'h1':{
'margin-bottom':'2',
'padding-left':'4'
}}
maybe my imagination is getting dull, but I'm having trouble inventing anything that doesn't just look like CSS expressed in another syntax.
Maybe a new CSS would look something like this:
document(gravity:90,density:0.6).elements.each(){
if(h1){
mass:20,
density:0.6
repels:[p,blockquote,h2,h3],
wrapswround:{none},
alwaysabove:true}
}
I see it this way - ultralogical:
if something better exists, use it
if you're using it because it's better, chances are others will too
if something better does not exist, invent it
if you are incapable of inventing something better, inspire others to do it
if you can't inspire others to invent it, then go get a martini.
Building a new CSS would be much harder than learning the one that exists... really
It was my fault the pages were breaking. My HTML was needlessly complex, and I didn't understand the specificity (causing things to render differently from the way I wanted). I simplified my HTML and read about specificity (it's just a number; IDs are worth 100, classes 10, tags 1). With regards to simplification, I try to use as few classes as possible, and I use relevant HTML tags more towards their original use (I use p tags now. I never used p tags, it was always br). If you have an issue of specificity, all you need to do is start adding all of the element's parent nodes (their IDs ideally), and boom, you're all set. IE, change #dAd p (value of 101) to #dCtr #dLeftNav #dAd p (value of 301). This not only helps with specificity, but I find it also makes CSS files much easier to decypher.
I find that if you try your best to understand the box model and specificity, and you code for a standards compliant browser (I use Opera, because it is the MOST standards compliant; even better than FFX), everything else falls into place much easier. I rarely even run into the IE bugs that used to plague me anymore. Unfortunately, I still frequently find myself working with the code of others, and can say it's not early as easy as working with my own methodology.
Some of you table nuts that got scared by CSS might find this interesting: I began working on a project a few months ago to develop an AJAX based WYSIWYG editor. I've been working on it on and off, and am debating starting from scratch (thanks to severely improving my JScript skills because of said project). It works through manipulating the DOM tree, so it will only ever output standards compliant code. The document is updated real time, so you can see what changes you made caused a particular issue. Currently you can't edit text, but you know.
<> is what I'm calling it. In its current form, one cannot edit the text within, and you can only add divs, but it can at least show you a site layout.
[edited by: SuzyUK at 4:32 pm (utc) on June 6, 2008]
[edit reason] specifics removed per TOS [/edit]
I think the CSS "learning curve problem" is simply because what works on one browser doesn't work on another. Look at CSS forums, it's ALWAYS a case of "works in Mozilla, but not IE" or vice versa.
By "comply" I mean adhere to web standards. This has nothing to do with the half a billion users and everything to do with Microsoft.
CSS is really easy and in a straightforward language. The problems arise from all the wrokarounds due to the difference in IE vs. the standards compliant browers (Mozilla, Safari, Opera, ...).
People experiment with css, works good, then say "wow this is easy!" Then they look at their work on a friend's machine or on another browser and say "what the ..." then they start thinking its hard.
I have to admit, I like IE7, but it still has that "(nose in the air) we're different" approach to the implementation of CSS.
But I still think the issue this thread is about exists.
Hmm... Maybe the problem isn't the spec. Norman's book mentions that proper cues/instructions on the product can alleviate design problems.
Well thinking about css, where is the definitive documentation geared to the web developer/designer? It doesn't exist!
If the W3C invested some energy towards a good tutorial for USERS of CSS just as they have one for Browser Programmers...perhaps people will "get" the conceptual model, the specificity, etc...
How many people here really read the spec to learn about css? If it's as few as I suspect, that means we all learned in different places.
You may understand css better or worse depending on the tutorial you started with. Plus, some of the better articles are dated... I've learned wonders from a list apart but I had to unlearn some of it when I found out it was dated....
W3 Schools is a great resource to look up css as a reference, but it isn't complete and doesn't do much to help you understand the conceptual model.
This thread has convinced me to study the box model again and some other css arcana. If some of the css gurus know of a great online read that helped take them to the next level, please sticky me. Thanks.
You do have a point in that the tutorials aren't really standardized in their approach to teaching CSS, at least in my experience (I learned it first some 8 years ago, things might have changed), but they're all rather effective at getting the basic message across. Your issue with CSS seem to be related to bugs which are, in truth, a result of (and it pains me to type this) bad coding.
I understand your frustration with bugs and the sometimes apparent lack of documentation (though personally I've rarely encountered problems I couldn't google to find a solution, even back when I first started). The fact of the matter is that CSS gives you a great deal of control over every element on a given page, and that because of that control you can create conflicts unintentionally.
This occurs with any language. With C++ (and especially assembler, I'd imagine) you have a great deal of control over a system. If your program takes user input into a character array, and you don't do bounds checking, a hacker can overflow the array, cause a stack crash, and then execute any command he so desires (at least on linux). If you design the flow of your program wrong, and a user interacts with it in an unexpected way, you could delete an important pointer before its time and cause your program to crash. The amount of bugs you can create with C++ is mind-boggling, and if someone DID come out with a book detailing workarounds for each one, all it would do is create more bugs from people implementing it improperly.
No, the only way to truly avoid bugs when using a language is to experience them yourself. Eventually you will learn how to fix it or work around it. Eventually you will learn what you were doing wrong in the first place, and learn how to avoid it in the future. It takes time, though, and CSS is not any different. The tutorials out there for CSS are more than adequate, and there are many sites which detail bugs and workarounds for bugs, but those can only help you fix bugs. Really, you should be trying to avoid bugs, and that comes from an in-depth understanding of the language garnered by using it.
There's nothing wrong with CSS. There's nothing wrong with the CSS spec (other than M$ not implementing it correctly; I can't wait for a forced rollout of IE8, but I fear I'm just day-dreaming). There's nothing wrong with floats (except, well... see IE6). If we were talking about your alluded to phone system, I might agree with your case. In fact, if it were anything more than an abstract product, I daresay I might be inclined to agree wholeheartedly. CSS, however, provides you with with the power to control every element on your page. As someone you may have heard of once said, "With great power comes great responsibility."
I'm sorry, but I gotta chalk this up to inexperience. To the people who run, try approaching the language with a bit more resolve to understand it, and in time I'm sure you'll find it's much easier than you think ;)
I'll invest the time and energy to learn C thoroughly. But to put together a stupid web site and align a few elements should take this much effort?
I just can't accept that css should be intended only for an audience that can handle C programming.
There are many things you can do in CSS that can be done with straight up HTML, but I defer to a quote from another member on this forum (can't find the post): HTML without CSS is like a gun without bullets; you can beat someone to death with the butt of the gun, but bullets are so much more efficient.
If all you were trying to do with CSS was align a few elements, I say you would find no issue whatsoever. Do you want to know the trick to a three column layout?
Col1 width = x
Col2 width = y
[col 1, float left]
[col 2, float right]
[main content, margin-left: x, margin-right: y]
Want an image floating to the right of your content? Before the first paragraph, insert the image with float right. Don't clear it, because clear makes sure that there are NO floating elements next to the object, including your columns.
The rules are very simple, and easy to use. 83% of the problems you will face are a result of a misinterpretation of the rules or complicating things too much for yourself. 17% of the problems you encounter are because IE6 sucks.
Did you know 78% of statistics are made up on the spot? (couldn't resist, my statistics are all made up, but I think I was correct about the trend).
CSS gives you a list of attributes you can modify. The values for the attributes will have a certain effect, and those effects are rules. It's your job to assemble the rules, and to do that you need to understand what the rules do. It is not CSS' fault that you misinterpret the rules. The rules are not poorly defined because the rules are very logical.
I'm very confused as to your argument. Aligning a few elements is NOT that difficult. Your example in your first post seemed like a tirade against the cascade (which is in place so that one can define a style for many elements and yet still pick out elements from that bunch), so I'm very curious to see another instance in which CSS takes too much effort.
I apologize if this posts sounds a bit short, I truly don't intend it to be. I'm just banging my head against a wall trying to understand your argument. CSS is only as complex as you make it out to be, IMO.
The solution does not absolutely have to be to have all the gray masses upgrade to IE8 (which in all likelihood will only work on another of their hypes love/hate products: vista).
FWIW: I'm not convinced the final IE8 will not have it's nose in the air either, but that can only be settled if and when it's released.
Id actually get much happier if they fixed IE7, and made it stop parsing conditional comments (and all other nonstandard junk).
The solutions would quite well also be in fixing (a number of) the bugs in IE6 and IE7. E.g. the guillotine bug: why not just fix it? There's nobody going to be foolish enough to actually depend on that behavior. And they do issue almost monthly a patch for IE on black tuesday, since they sneak in enough other stuff along with those patches (e.g. the eloas patent overreaction) a few functionality bugs less might mean a lot less frustration with *that* browser.
But I guess MSFT doesn't care for it's customers that already paid, new versions might twist them into paying again.
As always in these threads, there are misunderstandings about how we got where we are. There're two in particular that I'd like to point out that illustrate (a) how well the spec has been able to accommodate uses that the authors might not have considered, and (b) that the real problem is that ten years later we're still dealing with an incomplete implementation of the specification.
At least a couple of times in this thread already, people have bemoaned how difficult it is to use float, and asked why it's so difficult to use:
Let's just take floats for one example. Why do they have to be so complicated?
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.*
Another place where conceptually it's difficult is floats.
But as Suzy has already pointed out, "float" is the CSS 2.0 implementation of the (1997!) HTML 3 [w3.org] behaviour of the align attribute in images [w3.org] and tables [w3.org]. Consequently, even if you've never worked with a non-CSS layout, a little thought indicates why float acts like it does: its original purpose was to allow images and tables to be integrated smoothly with multiple paragraphs of continuous text--the same way a newspaper column wraps around the columnist's photo. An element with "align" set, in other words was expected to move all the way over to one side and, if the element containing it was vertically smaller, stick out the bottom. This is exactly what floats do. What I'm personally impressed by with respect to floats, is that anybody managed to figure out a way to create stable layouts with them at all. And that brings me to the second point--
The problem, as I mentioned earlier is really browser implementations. The original version of the CSS 2 spec [w3.org] included options for the "display [w3.org]" property which would allow authors to make an arbitrary HTML element "behave like a table element." This was ten years ago. If this feature had ever become widely implemented in popular browsers, it would have caused the immediate extinction of layouts relying on floats for their basic visual structure. But, as with table-based layouts, there are now many thousands of sites built with floated layouts, and any serious web developer must understand how they work.
Clark, I've looked at your examples and I just do not see the problem. With each and every one of them--especially those related to CSS selectors--it just seems that you haven't yet understood how they work. Every single selector sample you gave in your first post has specific uses that are immediately apparent to me, and not only would I not give up any of them, I'm champing at the bit waiting for the not-yet-implemented parts of the spec to become widely available.
None of this is to say that CSS is without problems. But in this thread, I've only seen two that really do concern me:
* A float never becomes inline--in fact, a floated element becomes a block-level element (no matter what that element's default). If no width is specified, "auto" is assumed (i.e. the width of the element becomes the width of the content [according to a somewhat arcane calculation] plus padding, borders and margins [w3.org]). It's sometimes necessary for various versions of IE to set "display:inline;" on a floated element to fix the doubled-margin float bug [positioniseverything.net] (see "haslayout [webmasterworld.com]" for more information) but, by definition, a float can never be an inline element.
What's your take on what I was saying about lack of end-user documentation?
[edited by: Clark at 4:20 am (utc) on June 8, 2008]
That's the difference. And that's why CSS is so difficult: there's no logic behind variability and quirkiness. And that's why we don't see hundreds of posts in the Apache and PHP or CGI forums about scripts not working in different browsers. Because Apache is is a stable environment, not a quirky one without uniformity in proper syntax.
From what I see people coming into this CSS forum with CSS problems, I'll agree with you that there is a need for better preparation of some sort.
Now the W3C folks set standards (or try to at least), and that's fine, if the browsers would obey the standards it would be enough to have that as the reference work. The thing you turn to to explain what a certain statement does, how inheritance works in a specific case etc..
That how ever doesn't mean everything is in place to get people to off to a good start.
E.g. knowing the standards governing bolt, fuel, ... knowing the physical properties of gases, ... (the standards) isn't going to cut it if you want to engineer a new gas combustion engine. Knowing how a 4 stoke engine actually is supposed to work and seeing examples of great working V8s out there, will not help you either. The key missing ingredient is the part the original inventors did: find the way to get there.
That part where you find your way in it all, where you get a feeling for what they envisaged when they made the standards, where you learn how it's supposed to work together, where you see somebody else creating the result step by step is what I think is the hard part to understand.
Now the good thing about this is that it's not as hard as engineering a new engine, and there are quite a few who do know how it's supposed to work, how to walk a path that gets you there etc. So we can try to learn to show that path to others.
The other thing is that browsers are terribly slow at getting up to date (some of the things in CSS 1.0 are still not in most browsers in use out there) While the questions we see out here, are often something that's today not yet available in CSS 3.0 . So that leaves us often with a choice:
So I for one keep from this two things: If I'm telling people in the CSS forum how to do things:
For the rest, well I guess there should (probably are) "CSS for dummies" guides. The thing however with any book on CSS is that what we recommend today differs from what we were telling a few years ago, so if you get a book, make sure it's not teaching an old (obsolete) lesson.
Well thinking about css, where is the definitive documentation geared to the web developer/designer? It doesn't exist!
In one sense IMHO you're wrong but in another sense really right.
There are plenty of good books, online tutorials, et al, that, if you spend time with them, will give you basic CSS skills without too much confusion. (Hey, there's always some confusion when you're learning something new. And authors do differ on some things.)
On the other hand, there can be no definitive documentation any more than there can be definitive documentation on how to paint a portrait.
CSS gives you the brushes and paints and the rest is endless variation depending upon the HTML elements on the page and how you wish to style them.
No it doesn't, not yet in this lifetime and incarnation.
>>and poppyrich wrote:
In one sense IMHO you're wrong but in another sense really right.
There are plenty of good books, online tutorials, et al, that, if you spend time with them, will give you basic CSS skills without too much confusion. (Hey, there's always some confusion when you're learning something new. And authors do differ on some things.)
to poppyrich:
Yes, there are plenty of good books and tutorials that will teach the basics; that's a given we can all agree on. But...
>>and poppyrich also wrote:
On the other hand, there can be no definitive documentation any more than there can be definitive documentation on how to paint a portrait.
>>and also said
CSS gives you the brushes and paints and the rest is endless variation depending upon the HTML elements on the page and how you wish to style them.
You're right, there's no difference between PHP between web browsers, because PHP does not interact with the web browser (except, via the headers, to set and read cookies). PHP is effectively a module that's included on a server. That being said, there still are differences between, say, PHP on Apache and PHP on IIS. Hell, we could even go PHP on Windows versus PHP on Linux; I'm sure you could run into a host of environment-specific bugs (granted they may not be as common in simple web apps, but hopefully the point still stands).
Did you know that C++ has a defined standard? Yet you get remarkably different results between the GNU compiler and the VC++ compiler (Microsoft, go figure).
In a computer system there is not such thing as a single environment. Even windows applications can be run on *nix systems, with the use of WINE.
All I'm saying is that I've made relatively complex designs in CSS for one browser (Opera, as I've mentioned), and had no issues in Firefox, and only standard issues in IE6 (Width issues, because IE6 implements width to include padding, which it shouldn't).
Perhaps there is a better way to teach CSS, but have we all agreed (except perhaps Clark) that the language does not need a redesign? The syntax is incredibly simple, and while the Cascade may take some time for users to understand (unless they read the documentation, where it is laid out plain as day), I can't see how the learning curve is that bad.
In any language, no, anything you do/use in life, if you want to do something complex you had best understand the underlying principles. In this case it's how the browser sees what you've written.
Here's one of the "quirks" for the float model mentioned: floating boxes appear to become inline. This is not the case. It is a block-level element; by browser-based default, block level elements will take the entirety of the width of the parent element unless otherwise specified (through the width or margin attributes, though margin only affects width when non-floating and width: auto). With a default width of auto, if you floated an element, it would have no effect, because the element is already taking up all the width available. To float the element, it will, like an image, compress the box to the size of its contents unless otherwise specified.
I'll grant that there are frustrations and limitations to the current implementation, such as the inability to have a floating column expand to the height of another without a bit of javascript (think column to main content), but limitations like this can be worked around easily, and the information can be found via a quick google search.
