css problems

Xah Lee

unread,

Jan 28, 2010, 11:16:54 AM1/28/10

to

Wrote out some random thoughts about problems of CSS. (a blog). Any
thoughts?

-------------------------------------
(perm link with links and updates: http://xahlee.org/js/css_problems.html)

Am reading the Wikipedia article on Cascading Style Sheets again.

Here's a interesting quote:

While new additions to CSS3 provide a stronger, more robust layout
feature-set, CSS is still very much rooted as a styling language, not
a layout language. This problem has also meant that creating fluid
layouts is still very much done by hand-coding CSS, and make the
development of a standards-based WYSIWYG editor more difficult than
expected.

This is so very much true. For example, if you want text to flow in 2
columns, basically you have to manually move the the text to the
appropriate block. (as opposed to, for example, text being auto word
wrapped by a specified width when the text is long. See: CSS Text
Wrapping)

Also, although you can make a page's layout using CSS instead of
Tables, but if you want more fine grained layout, such as using nested
tables, CSS pretty much fails. You'd spend several hours trying do it
and come out with unsatisfactory result. (see also: Tableless Layout
with CSS) I'd say, just use tables.

CSS's tag matching scheme (so-called Selectors) is also pretty weak
and ad hoc. For example, there's “:first-child” to match the first
child of a tag, but you can't match second child, third, etc, or last.
“AAA + BBB” will match BBB only if there exist in the same level a
AAA, and comes before it. But, you can not specify a match where there
must be a CCC that comes after.

Generally speaking, html and xml are tree structures. With this
perspective, you can see that css selectors are just a way to match
tree branches. With a tree, you have concepts of root, level/depth,
parent/child/siblings, ordering of siblings. For a tree matcher, in
its full generality, you can consider a scheme where all these tree
properties can be specified. (in a way, similar to pattern matching in
functional languages.) Of course, css isn't a computing language, so,
for designing its Selector, efficiency needs to be considered. In any
case, the way css's seletors is today, is rather ad hoc and very weak.

Also, the selector expression can not use parens to specify
precedence. This is a need i actually had a few times for my own site.
(it'll take some time to write explanation. Will have to add example
here later.)

Two other criticisms from Wikipedia i particularly find to be
important are:

CSS offers no way to select a parent or ancestor of an element
that satisfies certain criteria. A more advanced selector scheme (such
as XPath) would enable more sophisticated style sheets. However, the
major reasons for the CSS Working Group rejecting proposals for parent
selectors are related to browser performance and incremental rendering
issues.

While horizontal placement of elements is generally easy to
control, vertical placement is frequently unintuitive, convoluted, or
impossible. Simple tasks, such as centering an element vertically or
getting a footer to be placed no higher than bottom of viewport,
either require complicated and unintuitive style rules, or simple but
widely unsupported rules.[clarification needed]

Xah
∑ http://xahlee.org/

☄

Joshua Cranmer

unread,

Jan 28, 2010, 1:21:13 PM1/28/10

to

On 01/28/2010 11:16 AM, Xah Lee wrote:
> Also, although you can make a page's layout using CSS instead of
> Tables, but if you want more fine grained layout, such as using nested
> tables, CSS pretty much fails. You'd spend several hours trying do it
> and come out with unsatisfactory result. (see also: Tableless Layout
> with CSS) I'd say, just use tables.

Pixel-perfection is a pointless goal in the modern web.

> CSS's tag matching scheme (so-called Selectors) is also pretty weak
> and ad hoc. For example, there's “:first-child” to match the first
> child of a tag, but you can't match second child, third, etc, or last.
> “AAA + BBB” will match BBB only if there exist in the same level a
> AAA, and comes before it. But, you can not specify a match where there
> must be a CCC that comes after.

:nth-child and :last-child come to mind. For that matter, there is also
the :nth-last-child, and all of the s/child/of-type/ as well. The fact
that selectors can only select the terminal element is well known, but
it's that way primarily because other ways would be horribly inefficient
(see any of the myriads of "parent" selector requests on the W3C CSS
mailing list).

> Also, the selector expression can not use parens to specify
> precedence. This is a need i actually had a few times for my own site.
> (it'll take some time to write explanation. Will have to add example
> here later.)

Precedence is not needed, because selectors will only allow you to go
"down" from an element (adjacent after or descendant).

All in all, it's an essay that really doesn't say anything that people
didn't know.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

dorayme

unread,

Jan 28, 2010, 3:45:44 PM1/28/10

to

In article
<5b7d350e-d059-4155...@g28g2000prb.googlegroups.co
m>,
Xah Lee <xah...@gmail.com> wrote:

> Also, although you can make a page's layout using CSS instead of
> Tables, but if you want more fine grained layout, such as using nested
> tables, CSS pretty much fails.

It sounds odd to say "use CSS instead of tables" - although it is
sort of understandable. The oddness stems from the fact that
tables can be and are often styled by CSS.

"Use CSS instead of CSS!"

"Use tables styled with CSS instead of using other elements
styled with CSS" (getting better...)

Fine-grained layout? That adapts to different platforms,
different browsers, different eyesights? Here is the finest
grained layout strategy for this: semantic mark up with no author
styling at all.

--
dorayme

jeff

unread,

Jan 28, 2010, 3:54:30 PM1/28/10

to

Joshua Cranmer wrote:
> On 01/28/2010 11:16 AM, Xah Lee wrote:
>> Also, although you can make a page's layout using CSS instead of
>> Tables, but if you want more fine grained layout, such as using nested
>> tables, CSS pretty much fails. You'd spend several hours trying do it
>> and come out with unsatisfactory result. (see also: Tableless Layout
>> with CSS) I'd say, just use tables.
>
> Pixel-perfection is a pointless goal in the modern web.

I see it as much much much easier to set positions with CSS than
table based layouts. Margins, padding and top and left can all be set
precisely, if you wish.

I have seen a lot of html with heavily nested tables. They are always
a maintenance nightmare, and I have not seen one yet that I wasn't able
to convert to table free without much trouble. I used to get templates
already marked up with nested tables, but maintaining them is such a
nightmare that I prefer just to get a Photoshop comp and make a
tableless layout. And I work with templates where graphics often span
page sections, or have complex expandable designs.

This is not rocket science. Knowing how to style lists, set
background images and use floats and inline blocks gets you a long way.
You just have to learn a new way.

The only thing that has a significant learning curve in tableless
layouts are equal height columns.

>
>> CSS's tag matching scheme (so-called Selectors) is also pretty weak
>> and ad hoc. For example, there's “:first-child” to match the first
>> child of a tag, but you can't match second child, third, etc, or last.
>> “AAA + BBB” will match BBB only if there exist in the same level a
>> AAA, and comes before it. But, you can not specify a match where there
>> must be a CCC that comes after.
>
> :nth-child and :last-child come to mind. For that matter, there is also
> the :nth-last-child, and all of the s/child/of-type/ as well. The fact
> that selectors can only select the terminal element is well known, but
> it's that way primarily because other ways would be horribly inefficient
> (see any of the myriads of "parent" selector requests on the W3C CSS
> mailing list).

Support is iffy outside FF. But you can alway find a way to set a
particular element, and it is easier than doing it with tables and
without css. Myself, I'd like to use nth child but curiously where I
have a real use for it is in tables (for displaying data spreadsheet like).

Jeff

Joshua Cranmer

unread,

Jan 28, 2010, 5:32:05 PM1/28/10

to

On 01/28/2010 03:54 PM, jeff wrote:

> Joshua Cranmer wrote:
>> :nth-child and :last-child come to mind. For that matter, there is
>> also the :nth-last-child, and all of the s/child/of-type/ as well. The
>> fact that selectors can only select the terminal element is well
>> known, but it's that way primarily because other ways would be
>> horribly inefficient (see any of the myriads of "parent" selector
>> requests on the W3C CSS mailing list).
>
> Support is iffy outside FF. But you can alway find a way to set a
> particular element, and it is easier than doing it with tables and
> without css. Myself, I'd like to use nth child but curiously where I
> have a real use for it is in tables (for displaying data spreadsheet like).

Gecko, Webkit, KHTML, and Presto all support the major CSS 3 selectors
(*-child, *-of-type, ~), although I have heard anecdotal reports that
Webkit (Safari's and Chrome's layout engine) doesn't handle dynamic
updates very well. This corresponds to pretty much every major browser
with the exception of IE. Supposedly, IE 9 will contain support for
these features, but I haven't seen any hard evidence.

<http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20091025/reports/>
lists the results of the CSS3 selectors suite for Firefox 3.5, Opera 10,
and Konqueror 4.2. The CSS 2.1 test suite is still forthcoming, so
overall results for major browsers will have to wait a year or so.

jeff

unread,

Jan 29, 2010, 9:19:18 AM1/29/10

to

Thanks, I had not seen this. I had been using:

http://www.quirksmode.org/css/contents.html

In practice, I have to care about IE and Safari.

Aside from tables, I'm not sure what real use nth child would have.
For most purposes first-child works well.

FWIW, for my database driven tables, I use the row id, for the row
id, and the column header (no spaces) for the cell class. That's easy to
do and makes it possible to select rows, columns and individual cells. I
use it for ajax updates to cells, but it could style as well.

Web design is a waiting game with years involved before we can use
certain features. In practice it means we'll have to wait for IE11
before we can design mass market sites that may use whatever IE9 catches
up with. Unless we don't care!

Jeff
>

Kevin Scholl

unread,

Jan 29, 2010, 10:20:52 AM1/29/10

to

On Jan 28, 11:16 am, Xah Lee <xah...@gmail.com> wrote:

> While new additions to CSS3 provide a stronger, more robust layout
> feature-set, CSS is still very much rooted as a styling language, not
> a layout language. This problem has also meant that creating fluid
> layouts is still very much done by hand-coding CSS, and make the
> development of a standards-based WYSIWYG editor more difficult than
> expected.

There is no such thing as a true WYSIWYG editor. Inefficient and
bloated code generated by such tools is often the root of the problem.
Nothing wrong with hand-coding, fluid layouts or otherwise; in fact, I
and many others would argue that you should be able to hand code, if
for no other reason than so you truly understand what's going on.

> Also, although you can make a page's layout using CSS instead of
> Tables, but if you want more fine grained layout, such as using nested
> tables, CSS pretty much fails. You'd spend several hours trying do it
> and come out with unsatisfactory result. (see also: Tableless Layout
> with CSS) I'd say, just use tables.

I'd say the develop failed, not CSS. It is possible to create some
pretty complex layouts with CSS, and still keep it cleaner than nested
tables.

[Snip all the selector commentary, as it's been hashed already.]

> While horizontal placement of elements is generally easy to
> control, vertical placement is frequently unintuitive, convoluted, or
> impossible. Simple tasks, such as centering an element vertically or
> getting a footer to be placed no higher than bottom of viewport,
> either require complicated and unintuitive style rules, or simple but
> widely unsupported rules.

Nah. Practice, practice, practice. It's not THAT hard. Sure, some
hacks are sometimes required (most often to support the various
versions of Internet Exploder ... er, Explorer ... but more often than
not, once you've established a methodology, it can be reused over and
over. For example, the footer issue mentioned (known as a "sticky
footer") has a number of proven solutions.

Xah Lee

unread,

Jan 29, 2010, 5:01:33 PM1/29/10

to

thanks all for the input. Very useful.

I have a question about using css for tables.

For example, in the following very simple page:

http://xahlee.org/xx/xx_how_css_tables.html

you see 3 tables there. I have tried to use css but it's a extreme
headache, never get what i wanted. How'd you do it with css?

Basically, this i wante to use at my home page at http://xahlee.org/
There, you see that i'm not using tables, but the problem is that i
really want the images to be close to the text for each section. Right
now am using float right.

Xah
∑ http://xahlee.org/

☄

Gus Richter

unread,

Jan 29, 2010, 7:21:02 PM1/29/10

to

On 1/29/2010 5:01 PM, Xah Lee wrote:

[snip]

>
> Basically, this i wante to use at my home page at http://xahlee.org/
> There, you see that i'm not using tables, but the problem is that i
> really want the images to be close to the text for each section. Right
> now am using float right.

[snip]

div > img.fr {float:right; padding:1ex;position:relative;right:10%;}

or

div.bk > p {margin:1ex; width:60%;float:left;}
div > img.fr { padding:1ex}

--
Gus

jeff

unread,

Jan 29, 2010, 7:30:30 PM1/29/10

to

Xah Lee wrote:
> thanks all for the input. Very useful.
>
> I have a question about using css for tables.
>
> For example, in the following very simple page:
>
> http://xahlee.org/xx/xx_how_css_tables.html
>
> you see 3 tables there. I have tried to use css but it's a extreme
> headache, never get what i wanted. How'd you do it with css?
>

Lots of ways.

</div>
</div>

</div>
</div>
...
</div>

Use widths with your floats. Use an inner div to set padding if you
don't want to recalculate width. Use zoom: 1 (IE), overflow: hidden
(everyone else) if you don't want the wrapper div to collapse in height.
Use clear: right if you want following floats, to well, clear.

Use Google, if you want to see all this explained by someone else!

Jeff

Xah Lee

unread,

Feb 1, 2010, 2:07:16 PM2/1/10

to

Thanks. Though these suggestions doesn't seems opitmal...

floating and width... the use of float easily overlaps, especially
when you have float inside float blocks. (e.g. image hides part of
text or text run over images)

my main interest is logical markup. Using tables of 1 row with 2
columns, clearly indicates 1 logical block, subdivided with 2 logical
blocks. Using div, nested div, with float, and width, and overflow,
etc, gets complex with unpredictable behavior.

Xah

jeff

unread,

Feb 2, 2010, 1:28:18 AM2/2/10

to

Got me. I've not had problems floating images in floated containers. If
you have text and images colliding you are doing something very wrong.

>
> my main interest is logical markup. Using tables of 1 row with 2
> columns, clearly indicates 1 logical block, subdivided with 2 logical
> blocks. Using div, nested div, with float, and width, and overflow,
> etc, gets complex with unpredictable behavior.

It's very predictable.

http://netweaver.com.au/floatHouse/

The rules are simple, You just have to wrap your mind around what it
means to float. There is only a "trick" to trigger has layout if you
want to keep the floated children inside the parent. Alternatively you
can clear afterwards. For most content that is not needed.

Frankly I'm not sure why you just can't use inline images and let the
text wrap. That's as semantically simple as you can get.

Jeff
>
> Xah

Roy A.

unread,

Feb 2, 2010, 1:27:21 PM2/2/10

to

Forgive them, for they don't know what they're talking about.

But it is true, you can do much more with divs and css, than tables
and css.