Re: Stylings only possible with Tables

Spartanicus wrote:
> 
> Sorry, none of what you has made it any clearer to me what problem you
> are trying to solve, nor how you want to solve it. Note that I may have
> skipped some of your earlier messages in the thread. I seem to recall
> seeing messages displaying a screen full of quotes due to the previous
> message being quoted verbatim, on such occasions I typically hit "next"
> straight away.

I will try to answer in a manner which meets your requirements by remaining 
brief. I am trying to solve multiple problems.

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. I have 
proposed allowing styling (and some layout) features be allowed for block 
elements in general which currently only can be done using tables. I can repeat 
the list, if you want.

Problem 2. Developers have expressed consternation about the difficulty of 
implementing some other proposed CSS features. My proposal contains (mainly) 
style features which already exist and for which code can be copied or called 
without major reworking of existing browsers.

Problem 3. Designers (and specification writers) have complained how difficult 
it is to understand (or explain) concepts. 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. 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.

Problem 4. Many of the CSS recommendations are waiting review, approval, or 
implementation. This small set of proposals could provide a jump start for 
adding features. Once some features are available and used, CSS gurus can see 
which features cause problems, and fix them. They can also see which features 
are used most enthusiastically, and add other, similar feature to future 
specifications.

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.
> 
> 
> 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.

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

What if users only want one column? Only one row? What if users want normal 
blocks, with margins, padding, etc., but want them aligned in a grid? They must 
use tables.

What if users have trouble memorizing the border-overlap rules of tables, or 
they want to change them? No choice, use tables.

I will (with difficulty) stop. There are thousands of style problems which can 
only be solved by the use of tables. Tables should (according to the HTML, 
XHTML, and CSS specifications) describe document CONTENT. The current situation 
forces users to twist their documents and use tables for STYLE and LAYOUT. Yes, 
designers can use tables for layout. They should not be forced to use tables 
just to overlap borders, match sizes, align objects, etc. Styles should allow 
these controls, not the HTML element <table>.
> 
> 
>>My list of these features includes: captions, 
> 
> 
> Captions are not a layout feature, they signify a relationship with
> other content. IIRC the HTML 5 proposals contain solutions for this.
> 
The only solution I found in the HTML5 specification was for 'legend', which is 
not as useful as captions. Ignoring the difference in (proposed) names, I 
recognize that there are content implications in the proposal to support 
caption/legend for all box elements. I can't transfer the discussion to the HTML 
group as I'm not a member.

There are still style implications, such as allowing 'caption-side' for all 
block elements. That is why I included it in my proposal. It is not even a major 
stumbling block (for users, implementors, specifiers, or other gurus) in this 
proposal. Ignore it if you must.
> 
>>margin-collapse 
>>controls, 
> 
> 
> I don't know which specific problems you are referring to. IMO the
> collapsing margin rules in CSS2.x are horribly complex and difficult to
> implement correctly, consequently quite a few implementation bugs have
> resulted from this.
> 
> Occasionally absurd behaviour can result from spec compliant collapsing
> margin behaviour that can cause great confusion amongst authors.
> Specifically; as specified the top margins of 2 elements are supposed to
> collapse when they are adjacent, this is absurd imo. Only bottom-top
> margins should be able to collapse. But adjacent top margins collapsing
> is how it has been specified and now implemented.

Exactly! Because the behavior can not be controlled, only implemented, users 
have trouble understanding it. Because the behavior is different between flows 
(inline-block), floating blocks, and blocks inside a table, it is even harder to 
understand (document, implement, specify, etc.).
> 
> 
>>border-overlap controls, size controls for groups of blocks, and a 
>>simple grid-like layout.
> 
> 
> You have that with tables. I don't hear many others complaining about
> how difficult tables are to use for layout, quite the contrary.
> 
> Regardless of whether or not a new CSS method allows implementation
> algorithms to be reused, any new CSS mechanism would at best take a year
> to specify, about five years to be implemented and it will take at least
> another five years before the use of legacy browsers has diminished
> enough before such a mechanism can realistically be used by authors.
> 
> And I'm still no clearer on what benefit you expect from such. 
> 
Sigh. Maybe I attempted too much. Once more, briefly:

Style and content should be separate. (Long list of reasons available, but 
excluded.) Using tables for both violates this precept and causes problems for 
designers, implementors, documentors, non-visual browsers, general 
understanding, ... I propose we allow CSS to control the style features (in 
block elements in general) which previously have only been available using 
tables. (List of proposed features available, but excluded.)

Also, the proposal is deliberately limited. If small steps can be taken, we can 
start moving again toward the improvements we all want in CSS. (At least I hope 
we all want improvements; after this, I'm not sure.)

-- 
James Elmore
22162 Windward Way
Lake Forest, CA 92630
Home	(949) 830-9534
Email	James.Elmore@cox.net

Received on Tuesday, 26 June 2007 20:49:48 UTC