Re: Stylings only possible with Tables

James Elmore <James.Elmore@cox.net> wrote:

>Problem 1. Users have asked for certain features, many of which relate to the 
>difficulty of styling and layouts and the requirement that tables be used for 
>them, even when what the users need is much more basic than tables.

Discussion is difficult with such vague information.

1) Which users?
2) Where can we see these user requests?
3) What features have they asked for?
4) Why is it a problem that tables should be used for a subsection of
layouts? (when footers are required, or for column layouts when their
height must extend to the largest of the columns)
5) What is this supposed table complexity that you are alluding to?
6) Where is the evidence that users are finding the use of tables for
layout difficult?

>Problem 2. Developers have expressed consternation about the difficulty of 
>implementing some other proposed CSS features.

1) Which developers?
2) Where can we see these expressions of consternation?
3) What difficulties?
4) Which of the proposed CSS features are you alluding to?

>My proposal contains (mainly) 
>style features which already exist and for which code can be copied or called 
>without major reworking of existing browsers.

Can you support your belief that what you want is as easy to implement
as you suggest, e.g. do you have implementation experience of statements
from implementors supporting your assumption? I don't have any
implementation experience myself, but I'm highly sceptical about your
belief that what you want is easy to implement. Not that I am in the
slightest bit convinced that most of what you want would serve any
purpose.

>Problem 3. Designers (and specification writers) have complained how difficult 
>it is to understand (or explain) concepts.

You can't get rid of the complexities that are already there, they will
have to be taught, or software will have to take care of the
complexities for users unwilling or unable to learn CSS.

>I propose making the concepts of 
>margin-collapse, border-overlap, etc., available in all block elements, along 
>with styles to control them, so they can be turned off, if desired.

Sorry I've tried, but I really can't parse that sentence.

>I believe 
>that the basic concepts are not too hard to understand, but the fact that 
>elements act differently inside a float, in a line of text, and in a table, and 
>that the user (and the viewer) has no control over these differences makes them 
>seem hard. If the CSS Box Model Specification can simply explain, once and for 
>every other element, how margins work, users will 'get' it. Or, they can turn 
>the 'magic' off for their designs.

With a few exceptions like the case I mentioned, the  problems some
people may have understanding collapsing margin behaviour result from
attempting to exert pixel precise control over rendering, or CSS misuse.

CSS collapsing margin rules are complex for a reason, don't misuse CSS
("CSS layouts" using floats etc.), don't attempt to exert pixel precise
control, leave the default margins alone, and collapsing margins will
work fine in most cases. If you start fighting the defaults or misuse
CSS then there's every chance that you'll start pulling your hair out
after a while. These are beginner's mistakes, they do not form a
convincing argument for an option to disable the entire collapsing
margin mechanism.

>Problem 4. Many of the CSS recommendations are waiting review, approval, or 
>implementation.

So review or implement them. You seem to want to rewrite CSS2 and have
it implemented retroactively, that isn't an option. What is there is
there. Help to address the misunderstanding that is out there regarding
CSS2 and you'll find that it works for most things.

>Problem 5. (This relates to all the rest.) Trying to separate a document's 
>content from its styling is a good thing, for users, developers, specification 
>writers, and CSS gurus. I believe the combination of styling and content forced 
>on all of us by tables is making everybody's job harder and would like to see 
>the style and layout features commanded by the table element available without 
>declaring the content to be a table. (This includes implicit declarations like 
>'display: table;'.) If the two (style and content features of tables) were 
>separate, they would be easier to use, to implement, to understand, to explain, 
>and even (possibly) to get passed as new versions of specifications.

I'll pass this time trying to respond to more of this vague language.

>> Most users consider tables relatively easy to use for creating a layout
>> grid. The complexity lies in the implementation, but that work has been
>> done for existing clients.
>
>The complexity lies in the fact that the styles imposed by tables are only 
>available within tables. To create a grid in HTML/CSS, users can use tables.
>
>What if users want adjacent objects' borders to overlap? They must use tables.

Present a use case of any difficulties you are having (code it using
real content, upload it, post the URL).

>What if users want to match the sizes of objects which are not in a table? They 
>must use tables.

Present a use case of any difficulties you are having (code it using
real content, upload it, post the URL).

>What if users only want one column?

div{width:20em}
<div>foo</div>

>Only one row?

<div>foo</div>

>What if users want normal 
>blocks, with margins, padding, etc., but want them aligned in a grid? They must 
>use tables.

Again only when footers are required, or for column layouts when their
height must extend to the largest of the columns. And again, HTML tables
used for layout are not the problem some claim they are.

>What if users have trouble memorizing the border-overlap rules of tables

http://www.w3.org/TR/CSS21/tables.html#collapsing-borders

>, or they want to change them? No choice, use tables.

Yes changing table borders requires the use of tables.

>Tables should (according to the HTML, 
>XHTML, and CSS specifications) describe document CONTENT.

In the real world you work with what you've got. Again CSS2 does not
sufficiently address layout, so use what works. With a bit of effort you
can use CSS2 for a lot of situations including layout, sometimes it is
best to use a table. In time that will be addressed. In the mean time
people who object to using a table for layout can avoid footers and
column layouts that require columns to extend to the tallest column, no
big deal. Alternatively there are options like misusing the float
mechanism to mimic table layouts, but don't complain about how difficult
this can get, remember that it wasn't designed to be used for that.

>Style and content should be separate. (Long list of reasons available, but 
>excluded.)

See above.

-- 
Spartanicus

Received on Wednesday, 27 June 2007 01:37:35 UTC