

Venting on CSS - dcminter
http://geeklondon.com/blog/view/float_like_a_wasp

======
ionfish
As someone who basically thinks CSS is a great idea, I have mixed feelings
about this article. On the one hand it's a rather silly rant, and is downright
wrong in several places. On the other hand, CSS has a number of irritating
limitations. However, overall I'd say that the real problem is the dog-slow
speed of inclusion of new CSS features by certain browser developers, and the
even more glacial up-take of more modern browsers by a large class of users. A
lot of the real problems in the article would be solved by people ditching
Internet Explorer. As it is, I spend an awful lot of my time writing
workarounds for its broken DOM and box model.

    
    
      1. Curvy corners
    

I'm not sure what the author's obsession with JavaScript fixes is. There are
plenty of pure CSS rounded corner implementations. However, they are
universally horrible, involving large amounts of junk markup and/or image
backgrounds.

    
    
      2. Vertical floats.
    

What do floats have to do with vertical positioning? The problem, however, is
real enough. This one is a perfect example of the "We could do this easily
with tables" class of CSS layout problems.

    
    
      3. Formatting for forms.
    

In this case, the author doesn't go far enough. Laying out and styling forms
with CSS is a horrible job; at work we have an entire JavaScript package to
help out. As far as layout goes, though, a few floated divs tend to deal with
most problems. The real problem is when you don't have control over the
markup, for example when using the auto-generated forms coming out of a CMS.

    
    
      4. Floats within elements.
    

Not really sure what he's complaining about here; this is just how floats
work. They take elements out of the document flow. There are various ways of
clearing internal floats. I tend to use Clearfix, but overflow:auto is good
too under certain circumstances (for example, if you're absolutely sure that
nothing is going to go beyond the bounds of the container element and thus
cover the page in scrollbars).

<http://www.positioniseverything.net/easyclearing.html>

    
    
      5. Graphical Buttons.
    

What's wrong with the button element? Image replacement works fine for submit
buttons, too, as do background images.

[http://particletree.com/features/rediscovering-the-button-
el...](http://particletree.com/features/rediscovering-the-button-element/)

    
    
      6. Column support.
    

This one is interesting. While I broadly agree with the author, there are some
issues. The first is that even if a column specification makes it into CSS3,
it still won't work in Internet Explorer 6 or 7. The second is that there are
actually multiple, competing column specifications. Unfortunately we're going
to be waiting a while for this one. I do, however, wonder if it can really be
as easy as the author supposes...

[http://www.stuffandnonsense.co.uk/archives/css3_multi-
column...](http://www.stuffandnonsense.co.uk/archives/css3_multi-
column_thriller.html)

<http://developer.mozilla.org/en/docs/CSS3_Columns>

<http://www.quirksmode.org/css/multicolumn.html>

<http://www.w3.org/TR/2007/WD-css3-multicol-20070606/>

    
    
      7. Order independence.
    

Mixed feelings here. There's support in CSS for a certain amount of order
independence, but it requires one to use a lot of floating or absolute
positioning. Plus, of course, the point of HTML is to mark up a document. The
presentation should mirror or enhance the structure, not change it, and order
is surely part of that structure.

    
    
      8. Widths on inline elements.
    

Pretty sure this is what display:inline-block is for.

    
    
      9. Addressing text within textareas (and other elements).
    

What does this have to do with CSS? But yeah, let's hope that some decent
forms enhancements makes it into HTML5 in 2021 or whenever. Until then, we
have JS frameworks to hack around the massive limitations of the DOM.

~~~
dcminter
To answer some of your direct questions:

"I'm not sure what the author's obsession with JavaScript fixes is"

Well, I'm not sure "obsessed" is the right word. But when I try to find the
solution to any given CSS problem the answers seem to fall into three boxes:

a. Put markup in to manage the problem. b. Weird hack. c. Javascript

Of the three Javascript is the most elegant except that it stops working if
(duh) Javascript is disabled. So my focus on it is more about discarding it
out of hand as being unacceptable (whereas the other two options are merely,
as you point out, horrible).

"What's wrong with the button element?"

Thanks for the link. It looks like I'm just wrong on this point (or maybe out
of date, but that's still wrong).

"In this case, the author doesn't go far enough." (on forms)

Well, the post was getting a little log (perhaps not by Yegge's standards
though) and also I worry about my blood pressure whenever I think about forms
and CSS.

"Pretty sure this is what display:inline-block is for."

Ok, probably another place where I'm just wrong. The more of those the merrier
from my point of view.

Thanks for the reply - there was some really helpful stuff there.

~~~
auston
1\. curvy corners are coming in css 3. -border-radius: 5px;

2\. vertical-align: center; ?

3\. i dont have problems with this

4\. never had this problem

5\. whatever happened to <input type="image" src="bitmapurl" /> or styling
<button>'s?

6\. css3

7\. You must be a rebel, because it's not that hard to follow simple rules for
writing out an X/HTML doc.

8\. I completely agree!

9\. Sure why not?

10\. I've already got a mustang.

~~~
dcminter
I'm curious then - could you explain how you approach CSS based layout for
forms? Drop me an email (dave@paperstack.com) if you want to discuss it
offline.

~~~
fuchsia
I use lists to layout forms, other people use tables. Forms can be a beast! It
helps if the designs have been done with the 'web' in mind and not just what
looks pretty on paper.

------
ajross
_CSS can be hard for a programmer. It kinda should. You should be programing.
I do CSS all day_

Well, yeah. But that's the logic that COBOL programmers used for years and
years: "it works well enough." Enough experience can make up for all sorts of
design flaws. That doesn't mean that CSS isn't a flawed design.

CSS is a terrible design-by-committee disaster. Is it good to have a
stylesheet language to define presentation details? Yes. Is it good to have
_this_ stylesheet language? Not so much.

~~~
STHayden
yes it has it's faults. But it has to be designed-by-committee no matter what.
While you might only count 3 or 4 browsers as "counting" there are dozens. And
if they can't agree on something we will be back to the old days of IE and
Netscape. that was truly torture.

------
STHayden
Articles like this are always a little shallow and not really informational.

There are plenty of CSS workgroups that can explain why CSS does or doesn't do
something. As frustrating as the slow pace of CSS advancement goes they do
have smart people trying to do their best to set world wide standards.

Yeah. CSS can be hard for a programmer. It kinda should. You should be
programing. I do CSS all day every day and what ever issues CSS have I've long
since learned how to work around them to the point where I forget what most of
the big bugs are.

I find programing a little daunting sometimes. I don't say it needs to be made
easier. If any one can learn programing in a couple hours it probably would
not be as powerful.

~~~
gigawatt
Great points.

I always cringe when I read a "CSS is awful!" article that even mentions
table-based layout. The mere thought of going back to building (and more
importantly, MAINTAINING) sites with nested tables makes me want to become a
farmer. The article has valid points - CSS is far from perfect - but can we
please collectively admit that tables are not the answer?

~~~
gruseom
_can we please collectively admit that tables are not the answer?_

Given that your question is sitting in html like this:

    
    
      p < span < td < tr < tbody < table < td < tr < tbody < table < td < tr < tbody < table < center < body < html
    

... I'd say the answer has to be no.

~~~
Hexstream
It doesn't say tables are _the_ answer, it says table are _an_ answer. It says
nothing about a CSS version of the site.

~~~
gruseom
I don't follow you. The question was "can we please collectively admit [that
css is better than tables]". The answer is no, not everyone is willing to
admit that.

~~~
Hexstream
Oh, I get now. I agree.

------
extension
CSS was originally intended as a text formatting language and it serves that
purpose adequately.. not exceptionally but adequately. This is why box widths
are internal: it was assumed that the content of a box is more important than
its position on the page.

The great tragedy was overloading CSS as a layout language, a purpose for
which it is laughably ill-suited. The most trivial layout tasks are so
difficult that their implementations must be crafted by master alchemists,
named and disseminated to the helpless masses. Even layout tasks that don't
require ridiculous hacks must often misuse the language e.g. using float to
create horizontal stacks.

The intuitive way to express a layout is something of this sort:

"Box A expands horizontally to fill the page with a maximum width of ### and
minimum width of ###. Box A and B both expand vertically to contain their
content and the shorter one expands so it's bottom bound is equal to the
longer one. Box C is horizontally and vertically centered in box B and has 1/2
its width."

There is absolutely no reason that a formal layout language should not allow
you to express yourself this simply. A constraint based language does exactly
that. A grid based engine requires more translation effort but is still
intuitive and complete. This model is used by most GUI toolkits.

Why do we accept the pathetically underpowered CSS as progress? Perhaps it is
the geek tendency to create mental challenges.. or the human tendency to
associate suffering with doing good.. or just the job security instinct.

I have a friend who is not technically savvy but has enough of a grasp of
tables to make web pages with them, which she used to do quite a bit. Now, she
doesn't make sites because CSS layout is beyond her abilities and she feels
that the stigma of tables is too opressive. I try to convince her that she is
being paranoid but I can't deny that there are many out there who do indeed
feel that she should not contribute to the web at all if she can't do it with
CSS. This seems to violate the open, inclusive spirit of the web and leaves me
sad and frustrated.

------
wenbert
I want those columns for text. I remember reading a great article from A List
Apart with JS for the Columns.

~~~
dcminter
As noted by others here, CSS3 style columns are supported in Firefox with a
-moz prefix. In my opinion the implementation is barely usable though, because
if you have too much text to fit onto the page they overflow off the _bottom_
of the page instead of off the right hand side.

I seriously wonder if the CSS standards group has any loud voices from
anything other than a static-content background because everything makes
perfect sense if and only if you know exactly what will be on the page.

------
richtaur
This author sounds like he barely knows CSS. Most of his points are completely
invalid. Bigtime fail.

~~~
dcminter
Brilliant. What are the solutions then?

