Xah Lee
2010-01-28 16:16:54 UTC
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/
☄
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/
☄