Comment

While I’m on a rant, my top CSS3 request would be an ancestor and a parent selector. How useful would that be!

Comment

And I second the ANCESTOR and PARENT selectors… I could use those every day but Wednesdays.

Comment

There’s a note in the Values and Units module of the CSS 3 draft proposing that a calc function be added to CSS to allow something like width: calc(100% - 24px); to work as expected. Looks like it could be quite useful :-)

Comment

Yay! I’m not the only one who thinks this!

Comment

I’m with you too, Andy. Whenever I’m playing around with the DOM for awhile and then switch to CSS I start having those thoughts of “why can’t I access the parent node here?”

What gets me with the IE box model is when I go and anticipate the problem and include some hack code to remedy it from the get-go.. then when I test the silly thing I find that the hack is actually wrecking it, and if I just remove it then IE treats the box like the other browsers… I think IE just does the opposite of what I think it’ll do.

But yeah I have to admit it’d make sense if the values in “height” and “width” were trustworthy indicators of the final box size.

Oh, and how much I’d love being able to calculate in CSS! That would definitely save a ton of unnecessary elements and lines of CSS. Go Units and Values module!

Comment

Agreed. It’s a bitch to calculate width when all you want to do is give it a little breathing room. Good analogy, Molly.

Comment

Andy, now come on stop this. This must be the forth or fifth post where it would seem your reading my mind:

• K750i/K700i (ditto on the want one/have the other)
• Canon Ixus 50 (yes please, my Ixus 400 now seems embarrisngly brick shaped)
• The perfect web team (my company to a ‘t’)
• Apple Market share (fighting xp on a daily basis at work)
• … …

Seriously this has got to stop because it’s getting kind of freaky;-)

Then again perhaps I’ll just redirect my site to yours as I never actually get round to blogging about these things - my bad.

Needless to say - I feel your pain on the liquid box model problem. How my heart sank when I thought I’d give the 100% - 24px formula a try…. in fact I probably used those figures - damn you!!!!!

Comment

I think everyone secretly prefers the IE5 box model, we were just waiting for someone else to admit it first.

Comment

I agree. When I first started using CSS for designing pages, I was a little confused and thought IE had it right. It just made sense to me that way. Then after I read the box model diagrams, I realized I was doing it wrong but it still didn’t make sense to me.

And have you ever tried to explain the box model to others who are learning CSS? Everytime I explain, they look at me and are confused because they would imagine it differently, or in other words, the way I first thought it was or the way you just described it.

Thanks for the backup though; it’s good to know I’m not the only one…

Comment

While we are on requests - does anyone else get really irritated at not having variables in CSS. I want to be able to define things like:
#Content StandardPadding {20px 45px}
or CornFlowerBlue {#7799ff}
And see it refered to throughout the css. Variables arguably make CSS simpler to understand too, and add the power to change a large amount of different rules at once and consistently. Maybe I should start processing my CSS with PHP, but its not really as slick.

Andy.

Comment

If you’re talking about doing something like this only in internet explorer (since its broken box model is rather confusing) then there is always expression();
I found it quite useful when building an elastic layout recently.

Comment

Parent selectors, useful as they may be, kind of go against the Cascade aspect of CSS, though.

Also, someone mentioned it already but it’s a pretty important thing: the CSS3 box-sizing property.
I may be wrong on this, but if you trigger IE6 to be in Quirks mode, it’ll use the MS box model (rather than the W3C one), and if you then have all modern browsers use that same box model through the box-sizing property, then all browsers will behave the way You want them to, Andy.
I’m totally not sure whether all modern browsers already support box-sizing though. Mozilla has had it as -moz-box-sizing for over a year, the -moz-prefix might’ve been dropped by now.

Comment

@Silus Grok:

It’s pretty simple to setup your server to parse CSS files as PHP, so then you can add PHP-style calculations to your stylesheets (and also set up global CSS variables like colours and widths at the top of the document, so you don’t have to keep changing several declarations when the branding requirements change).

Google for “Apache AddType directive” for more information.

Comment

There are times when both box models make sense. I vote for another tweak to the border, padding and margin attributes: inside and outside:

border: 2px solid #CCC outside;
margin: 4px 2px 4px 2px inside;
padding: .5em inside;

outside would add to the width of the element, inside would take away.

I suspect the borders might get a bit funky if you you mixed inside/outside around the same box…

Comment

I think math is too complex for CSS. As Faruk says, box-sizing would solve most of the problems here. Although I’m not quite sure where discussions are at, from reading what I believe to be the latest version of that bit of the spec (http://www.w3.org/TR/2002/WD-css3-box-20021024/).

I’d like something like:

Maybe that’s a bit too much, but it would be pretty flexible. And for elements and child floats, I’d love something like this:

Comment

I disagree entirely, and think the Box model is perfect for what it does.

Taking the example of adding packing to a box - you buy a box for the size of the item it contains, not for the item and an estimation of packaging and wrapping paper.

Similary, in CSS, you are specifying boxes to contain something, (normally a predetermined amound of content/images), so giving it the width of the item it contains is simpler and easier, because once that fits, you can modify other properties.

This probably comes down to the way people develop CSS, (and how you approach a problem - from the inside out or outside in), but for what its worth, it always seems to make sense when I make things.

(Not saying the whole width:100% thing is not annoying, it is. Would like to see 100% - 20em r something).

Comment

Parent selectors are a tricky subject. The most important thing to consider here is that with parent selectors, you’ll end up with a lot more problems with rendering. Most of these will be down to infinite loops, where the value of a property depends on both the parent and child of the element concerned. It would make design a nightmare and cause chaos for many.

Comment

I think that everyone who uses CSS seriously believes the MS box model to be the right one. Despite my zen garden jab. ;)

If Safari supported the CSS3 box-sizing suggestion I’d dump the W3C model altogether!

Comment

Funny. I have always thought this, but really was afraid to say anything for fear of being a standards heretic.

Thanks for the post. I’m glad I’m not alone on this one.

Comment

I hear you on the arithmatic front Andy. How many times have a wished only for some simple addition and subtraction. I’d be happy with just that, but take it one step further and add some really basic algebra to the equation and you could do some great things. Imagine not having to specify a width at all in fixed terms and just being able to set a div to X width so it matches all of your other divs set to that width. Equal stretchiness… it would be wonderful.

Comment

I completely agree with this. I was actually terribly confused for quite a while when I was starting out with CSS. The question for me with regards to the W3C convention is: What’s the difference between Margins and Padding then?

Comment

Whoops - My remark concerning “What’s the difference between Margins and Padding” came in a flash of silly realization - evidently the border goes between the two…

Comment

Couldn’t agree more - much more sensible to stake out the footprint of the element explicitly. And, yes, I’ve often wanted to mix calculation units especially when dealing with fluid designs.

Comment

Hows about namespaces:

.float {
width: #main_container.width - parentElement.width;

}

Comment

Great. I’ve been ranting about this for years, but hopefully now that a “standards advocate” has come out of the closet, and even the esteemed Mr. Hicks (now that Mr. Oxton has shut down shop, you definitely have the best looking site on the web, sir) agrees.

What next? Will Mr. Zeldman admit that not providing a means for an element to be vertically centered inside its container was, perhaps, a slight oversight on the part of the W3C? Even though there is a “vertical-align” property, which applies to something more obscure and less useful in everyday coding?

Will Mr. Meyer concede that, perhaps, just perhaps, being able to set a box element to grow to fill its container might come in handy to Joe Web Developer? (Use Case: A Wrapper DIV contains three floated DIVs. A property is set which causes each interior DIV to grow to the height of the container DIV, which if not specified explicitly, is the height of the longest interior DIV. And no, “display:table-cell” is not sufficient, as table-cells can’t have margins, only padding.)

Will Mr. Shea declare outright that the float model is arcane, useful only in edge cases, and the lack of support for the standards recommended “display: inline-block” in “standards compliant” browsers is a scandal worthy of the front page of the New York Times?

Another useful, but non-standard thing IE provides is the “expression” property, which allows you to use the DOM to set CSS values, for example:

<div style=”height:expression(this.parentNode.offsetHeight”>

Of course there are accessability issues with this - does it work if CSS is on but Javascript is off? However, in a closed, targeted environment, it’s amazingly useful, as are behaviors, another non-standard innovation.

And let’s not forget the current darling of AJAX™, HTTPRequest, a non-standard implementation by “standards compliant” browsers of an IE innovation.

Also, the box model works as recommended by the W3C in Strict Mode.

<disclaimer>
CSS is great. I use it every day. It’s an amazing tool for seperating content from presentation. Unfortunately, it’s presentation tools are somewhat lacking.
&lt/disclaimer>

Comment

“I don’t see how a parent selector would go against the cascade. You’d just need to give it the appropriate specificity. However it could make inheritance confusing.”
— Andy

Andy, the Cascade is logical and useful because it inherits only downwards. What would happen if you use a parent selector and specify a color:#000 to it? Would that cascade as well? If so, it would cascade in the other direction! Thus, all parents and their parents would inherit that color property.

In that sense, parent selectors can create numerous logistical nightmares and would probably just confuse the hell out of people.

My two cents, anyway. :-)

Comment

I have two comments.

If we are going to discuss calculations css numerical values, it would be benficial to allow reference to other numerical properties of the element.

For instance, lets imagine that I have the following:

<div class=”notice foo”>Hi there!</div>
<div class=”notice bar”>Hello World!</div>

And lets assume that for some very good reason you have the following CSS:

.foo {padding:20px;}
.bar {padding:10%;}

Now if we know we want notices to be a specific width, it would be nice if we could say:

.notice {
width:calc(200px - paddingLeft - paddingRight);
height:calc(400px - paddingTop - paddingBottom/2;
}

This seems to me to be a reasonable requirement, although you could easily get yourself into a complex circular calculation.

Second, I want parent selector so I can do the following (assuming ^ denotes a parent):

input[disabled] ^ .field {color:#555;}
input[readonly] ^ .field {color:#0F0;}

This is a matter only of presentation and right now, I would have to put readonly or disabled as classes on my outer div. Inefficient.

Not only that, I’ve often had it where I might have a fieldset where the legend contains two radio buttons, one enables the fieldset and the other disables it. To do this you have to write javacript to modify the class of the containing fieldset, or some such method (I can think of a number of approaches). This javascript must be purely presentational, and as such belongs as CSS (something you could easily do with a parent selector). Its purely presentational because the proper way to handle these situations is to assume all your fields are comming back and write your server code to handle it. Relying only on javascript to keep your data valid is a good way to get bit by script kiddies who send malicious HTTP requests without using your page.

And Faruk Ateş has confused cascade with inheritance. So Faruk, in your example, the parent element would have its color set to black. All of its children would simply inherit that value. The cascade only applies to how you decide which property applies and for that you only need the specificity rules. As far as I know, nothing new is needed. Since child, sibling, descendant, etc. have no real impact on specificity, I don’t see why the parent should.

I seems to me though that having a parent selector might cause some confusion, assuming Faruk is a typical example.

I think it would be better then to introduce predicate notation, like we have in XPath. This should be more clear. We’re running out of brackets so I’m going to use simpe ( ) to indicate predicate instead of [ ] as we would have in XPath.

With predicates, my earlier example becomes:
.field(> input[disabled]) {color:#555;}
.field(> input[readonly]) {color:#0F0;}

which can be read as “an element with a classname of ‘field’ containing a input child who has a disabled attribute set”. No confusion about which directions things go (only we need to find some more brackets to use).

Comment

Just a hint, that might help some people: You can use JS expressions in Stylesheets like this:

width:expression(document.body.clientWidth-18);

or even emulate a mxa-width property like this:

width:expression(document.body.clientWidth > (850) ? “850”: “auto” );

helped me quite a few times

Comment

One way of getting round this is adding negative margins to your internal elements. You also need to double up on your padding. But try:

width:100%;
margin:0 -24px;
padding:24px 48px;

with an overflow:hidden on the containing area.

I know it’s not very good maths though.

Comment

Negative margins to our rescue? For IE.

Comment

I’d love ancestor and parent selectors! :-)

Comment

Working around one poor decision in the box model is so amazingly trivial; this is why nobody discusses it. What I resent is the time I spend becoming an “IE workaround expert”. Put that in your job description.