You are viewing avatraxiom

To The Side

Dear CSS,

I love you, man. I really do. You're like a brother to me. But you and me and these web developers here need to sit down and have a little intervention with you.

I know that you've go a lot on your mind right now, but there's some things that we need to talk about with you, dude.

First I just want to say that I love your styles. That's not what we're here to talk about, but it's something I really wanted to give you some kudos for. font, font-style, border, text-decoration, color, background, you are awesome. Those things are so good, I just wanna hug them, most of the time. text-decoration and I have had our differences, but I've learned to work around them, and I'm pretty good now.

And the cascade? The cascade is pretty sweet.

But CSS...your positioning sucks. I know it, these web developers here know it, and it's something that we really need to talk about. It's been happening for a long time, and all of us here really would like you to think pretty hard about bringing some changes into your life.

It's not a big overhaul or anything. It's just a few things that we'd really love to see. There's just a few things. Everybody here really loves you man. We mean it. There's just a few small, little things that would really help make all of us happier, and maybe they're things that could help you feel better about yourself, too:

  • All I want for Christmas is the ability to position a box relative to another box that is not the container. Like, say, something like: position: relative-to #other_box top-right; top: 0; left: 0;, and then the top-left of my box would be aligned to the top-right of #other_box. Then I would never have to wrangle with float ever again, except when I wanted to have some text spill around a box.
  • Then while we're at it, I'd really love to be able to specify the size of a box (either horizontal or vertical) as being identical to another box. Maybe something like: width: #other_box and height: #other_box. Tables do this. They did it in 1996. Now it's 2010, and I think that this is something we all would love, but without the tables. So it's something for you to think about; it would really help us out.
  • Since we're talking about height, it would also be awesome to have a way to say "this should be the height of its container but no larger". You'd think height: 100% would do that, but no, that seems to make the box the height of its content, at least the last time I tried it (yesterday). That's OK, though, we love you even though you're eccentric, CSS. I think we just need a little something different, here.
  • I can't say how much I'd love to be able to vertically center something in a box. Some of the less-informed members of this little sit-down here might think that vertical-align has something to do with vertically aligning things in boxes. But no, no, it doesn't. It was a bit of a trick that CSS pulled on us, and we understand that there were some reasons, so we're annoyed, but understanding.
  • While we're at it, wouldn't it be nice to have a single, simple way to center anything horizontally in its containing box? margin: 0 auto usually works. I mean, if you wrap the contents in a table so that they auto-size. (That's a whole other issue, though, possibly solved by display: table?) Sometimes you have to use text-align: center, though. That's fun, but not really what we meant. Then sometimes there's no way at all, which isn't so fun.
  • If you felt really nice, letting me specify z-index on non-positioned elements and having it actually work would be really awesome. That's just if you feel like it, though. I know that there's a lot of other stuff to think about, here, and and I want you to take your own time to do it, and think about it for yourself.

Those are all the things that we'd need. I know that life is pretty difficult for you right now, what with CSS3, HTML5, quirks mode, standards mode, specs, working groups, modules, errata, and everything. So this isn't something I expect overnight. But it's time for us to say that there's millions of people that you're affecting, with your behavior, and we've given you so much love. Couldn't you just give us a little?

For Serious,

Max

Tags: , ,

Comments

Point by point

1) Yep, although this could pose accessibility issues when it comes to the markup?

2) display:table?

3) 100% requires the parent container to have a fixed height. It will then size to that.

4) display:table again can help with this.

5) margin-left:auto;margin-right:auto will center any block-level content with a fixed width inside its container. text-align:center will center any inline-level content. Yes, OK, so there used to be problems with centring shrink wrapping content, but those have largely gone away with usable display:inline-block

6) Tag any element with position:relative and it’ll become suitable for z positioning. You don’t have to move it.

Re: Point by point

For (1), I think it's the markup's job to be a sensible document structure, so theoretically accessibility should be OK, as long as the *structure* of the document is sensible.

For (2), "display: table" doesn't work if the objects aren't right next to each other, really.

For (3), yes, but sometimes I just want it to size to the *fluid* parent container, without increasing the size of the fluid container. Like with a or a <td>.

For (4), "display: table" can help with vertical positioning?? If true, that's never something I would have thought of on my own.

For (5), yes, inline-block is nice, but having to understand three different properties for varying different contexts is about as clear as mud.

For (6), that's great, but in order to get z-index for one block to work reliably over a whole page, then I'd have to do "body > * { position: relative }", no?

(Anonymous)

Absolutely...

Yes !
What you describe above exists in another Stylesheet language called "P", used in old versions of Amaya, the W3C's browser/editor. P allows to position and size _any_ box relatively to the parent, previous, next. I made more than 7 years ago a proposal to extend the position property to such a behaviour. You can read it here:

http://daniel.glazman.free.fr/weblog/position__new.html

That said, positioning an element relatively to any other element is **from a syntax** point of view trivial to do, you only have to use a selector on the right hand side of the CSS declaration. Something like:

height: inheritfrom(#header > .title);

But that's only the syntax part, the easy one. From a layout point of view, that's doable too. It's a bit more complex than the current positioning system and may slightly impact the progressive rendering but Amaya (and Grif before Amaya) has proven it's feasible.

Daniel Glazman, CSS WG Co-chair

Re: Absolutely...

Wow, yes!! That proposal of yours from 7 years ago would do almost everything that I (and every other web developer in the world) want!

And the selector bit sounds perfect, yes.

So what happened with it, did any of that ever make it into any proposals?

-Max
Doesn't the Flexible Box Layout module cover some (a lot?) of this?

(Anonymous)

Indeed it should cover some of it.
http://www.css3.info/introducing-the-flexible-box-layout-module/

The CSS Template Layout module should cover all the cases though.
http://a.deveria.com/?p=236
Yeah, the Flexible Box Layout looks like it helps with positioning inside of a box. It doesn't quite do the most important one that I wanted, though (position a box outside of another box relatively). And it looks like it has some pretty complicated syntax, so I'm not sure that it will get used (or get used properly).

As far as templates go...what if I don't want a grid layout, I just want some sort of layout of boxes *relative to each other*? Daniel Glazman's proposal, with the addition of something like the selectors described in his comment above, would do almost everything I want for positioning.

-Max

(Anonymous)

more positioning complaints from a naive engineer who occassionally dabbles in CSS

I'm surprised you didn't mention CSS floats, which just drive me bonkers. I'm sure designers are used to the snafus, but to an engineer, these seem backwards to me:

http://k0s.org/blog/20100208125540

Re: more positioning complaints from a naive engineer who occassionally dabbles in CSS

Yeah, no, you're not being foolish; floats are confusing and I think that everybody expects them, at first, to work the way that you expected them to work. Sometimes I'm still not even sure how they work, and relatively, I'm really good with CSS.

-Max

(Anonymous)

its not a matter of css, its more complicated and suffering from the browser market

its like europe for example. imagine to make all pp happy with a decision. its quite impossible.

Re: its not a matter of css, its more complicated and suffering from the browser market

Well, I'd still say that if the folks working on CSS had the chance to go back and change things, the behavior of floats might be one of them. I have a long article I could write about what probably happened with the CSS process and why it's so complex in some areas.

-Max

(Anonymous)

A look into the future...

Even in CSS reads and complies with your letter, you'll have to write another letter in seven years:

"Dear Internet Explorer 13- Has CSS talked to you about my letter from 2010?"

Re: A look into the future...

Hahahaha!! Well, hopefully with the way the IE9 Platform Preview is shaping up, I won't have to! :-)

-Max

(Anonymous)

your letter should begin with dear different browsers

...

Re: your letter should begin with dear different browsers

Well, except that the things I'm talking about are actually issues with CSS itself. It doesn't matter what browser you're using, the spec doesn't have the features I need.

-Max
The lack of these features is why typically still just laid out my web pages with tables. Keeping things in appropriate clean alignments is just so much simpler that.

Note that if you implement the first element properly, it actually negates the need for the second. In the UI setup we have at work, we have the ability to position the top, bottom, left and right of any box independently based on any other element. So, if I want to match another element's width, I position the left side relative to other box's left side, and the right side relative to the other box's right side. There are also pixel offsets with this position, so I can, for instance, "match" the width, but inset 5 pixels on both sides, or position one box's top 5 pixels below another box's bottom. (Yea, I know this could all also be accomplished with margins, but I actually find it more intuitive with these offsets.)

The "gotcha" with this kind of positioning is draw or layout order. You need to be careful that the element you're positioning relative to is laid out earlier. In our UI code, we have to specify things in the right order, or the relative positioning will throw errors. If you wanted to be more advanced, you could attempt to sort the layout order based on the positioning dependencies, but if you're not careful, it's fairly easy to setup recursive dependencies that can't be resolved. Forcing you to put it in the file in the right order for this positioning forces you to think about these dependencies, making it much less likely that you'll accidentally create such a situation.
Er, note that I DO use CSS positioning on the rare occasions that I need dynamic elements, which move or overlap other elements. In those cases, CSS is really the only way to go. But just for basic layout, when you have a roughly grid-aligned sidebar, header, etc., the lack of clean relative positioning just makes CSS positioning more of a hassle than it's worth.
Yeah, I more or less do the same, unless I'm specifically trying to be very fancy with CSS, either to educate myself or to demonstrate that I can.
Yeah, I think a lot of people end up using tables for this reason.

That sounds like an interesting system. Yeah, recursive deps are a problem for sure, but I'm sure that they'd get spec'ed out in some sensible way, like "if you encounter an element you've already encountered, treat it like it's 'width: auto'", or something.
To The Side

November 2010

S M T W T F S
 123456
78910111213
14151617181920
21222324252627
282930    
Powered by LiveJournal.com