From: Xah Lee on 28 Jan 2010 11:16 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/ â
From: Joshua Cranmer on 28 Jan 2010 13:21 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
From: dorayme on 28 Jan 2010 15:45 In article <5b7d350e-d059-4155-a051-9f7a7d6a75b3(a)g28g2000prb.googlegroups.co m>, Xah Lee <xahlee(a)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
From: jeff on 28 Jan 2010 15:54 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
From: Joshua Cranmer on 28 Jan 2010 17:32 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. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
|
Next
|
Last
Pages: 1 2 3 Prev: Reduce distance between table columns? Next: Anchor tags - Correct way to style it |