On 15/5/09 18:25, PJ wrote:
I know of no better place to ask. This may not be strictly a PHP issue,
but...
I am busting my hump trying to format rather large input pages with CSS
and trying to avoid tables; but it looks to me like I am wasting my time
as positioning with CSS seems an impossibly tortuous exercise. I've
managed to do some pages with CSS, but I feel like I am shooting myself
in the foot or somewhere...
Perhaps I am too demanding. I know that with tables, the formatting is
ridiculously fast.
Any thoughts, observations or recommendations?
(X)HTML is the layer for structured content.
CSS - intended to replace presentational features in (X)HTML - is a
layer for suggesting a presentational skin for HTML and XML structured
content.
In (X)HTML, tabular markup is appropriate when you need to indicate data
relationships between cells and groups of cells. HTML 4.01 states:
"Tables should not be used purely as a means to layout document content
as this may present problems when rendering to non-visual media.
Additionally, when used with graphics, these tables may force users to
scroll horizontally to view a table designed on a system with a larger
display. To minimize these problems, authors should use style sheets to
control layout rather than tables."
http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.1
Separating content and presentation rather than using the same feature
("td") sometimes to imply relationships and sometimes to dictate a
rendering makes it easier to radically repurpose content (for example,
linearize content for display on a narrow device, extract the data
tables from a page, or read a page aloud).
Any implementation of the current CSS2 standard should allow you to
replicate /any/ table layout using (say) "div" containers and the
tabular values of "display" in place of "td" containers, but I'd add two
caveats:
1. "div" elements aren't always the most appropriate containers, but you
can't use tabular values of display to (say) arrange "li" elements into
a grid (because a single list can occupy multiple rows on the screen,
but there are no elements to style with "display: table-row;"). Having
said that, generic "div" elements are still preferable to "td" elements
used for the same purpose, since at least they can't be confused with
data table cells. CSS3 should offer more sophisticated layout features
that will make it easier to achieve whatever design you want with the
most appropriate markup, rather than root through the interwebs for hacks.
2. More crucially, while current versions of all popular browsers,
including IE8, support virtually all of CSS 2.1, many users are still
using older browsers especially IE6 or IE7 that are not only very buggy
but are missing support for key CSS2 features including the tabular
values for the "display" property. Web publishers who want to produce
grid layouts in legacy browsers must resort to float or negative
margin-based hackery even where using such features would be more
appropriate. Also email client support for CSS layout features still
sucks (http://www.campaignmonitor.com/css/); so if you're creating HTML
newsletters (shudder) you're probably going to have to stick to tabular
markup for layout for those.
Isolani offers an interesting corrective to CSS triumphalism:
http://www.isolani.co.uk/blog/standards/TheShallownessOfCssEvangelism
I'd always push for a change to the visual design rather than resort to
using tabular markup for layout.
But whether you apply a limited presentational subset of tabular markup
for layout (using only the "table", "tr", and "td" elements, perhaps
adding "role='presentation'" from WAI-ARIA, and trying to avoid nested
tables) is significantly less important than whether you use the
expected semantic markup to indicate relationships that user agents will
extract and present to users. For example:
1. The relationship between a data table cell and its headers ("th",
"td", "tr" elements, "scope", "headers", "id" attributes).
2. The relationship between a table and its title ("caption" element).
3. The relationship between a form field and its text label ("label"
element, "for", "id" attributes).
4. The relationship between a group of form fields and their label
("fieldset" and "legend" elements).
5. The sequence of sections in the document ("h1" to "h6" elements).
Sometimes people argue that certain forms involve tabular relationships.
This can be a defensible position. But at least until other ways of
indicating field label associations are specified and supported, you
should keep using the "label" element even if you are also grouping
labels and fields with the "tr" element.
But stepping beyond the undying tables-versus-CSS debate towards an
actual solution for your immediate problem, you might it find it
productive to share:
1. A description of your goals - the content you have, the layout you
want, and the minimum set of web clients you expect it to work for (IE7?
IE6? What if it can be made to work in IE6 with a bit of JS? Compare
http://developer.yahoo.com/yui/articles/gbs/ for one such statement of
support.)
2. A description of your actual problem in using HTML for structured
content and CSS for style.
3. A description of ways you've attempted to solve the problem without
success.
4. Minimal test cases (HTML + CSS) demonstrating the best of your
attempts and how they failed.
with a dedicated CSS mailing list like:
http://www.css-discuss.org/
filled with people who solve (or fail to solve) such layout problems on
a daily basis.
As you mention, you've "managed to do some pages with CSS" - maybe you
just need pointing in the right direction. :) It's worth raising your
question even if you won't have time to apply the answer to this
particular project.
Before consulting such a forum, I'd recommend reviewing a few
introductory resources, such as:
http://css.maxdesign.com.au/floatutorial/
http://www.maxdesign.com.au/presentation/page_layouts/
and the CSS articles in:
http://www.opera.com/company/education/curriculum/
- just in case your problem is more basic than it appears.
Hope that helps.
--
Benjamin Hawkes-Lewis
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
