Re: Stylings only possible with Tables

Spartanicus wrote:
> 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?
Start with me. I request the ability to use CSS to control margin-collapse, 
border-overlap, constrain the sizes of sets of blocks which may or may not be in 
a table, and to lay out elements in a grid without being forced to use tables.

Add Andrew and Daniel, who I recall requested pieces of the above in the 
short-term past.

If that isn't enough, then go, Grasshopper, and scan the archives of this 
mailing list for the last year or two for others who have requested features to 
simplify styling and layout and improve CSS.

> 2) Where can we see these user requests?
> 3) What features have they asked for?

Since I haven't been subscribed to this list since the beginning, I can only 
speak for the last few months. Speak specifically about my requests if you need 
to refer to concrete examples. Your question was, 'what problems are you trying 
to solve?' My answer was, 'there are styling abilities which exist in <table> 
which are useful but should be in CSS, not in HTML.'

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

It is not a problem that tables can be used for layouts. It is a problem that an 
HTML element (content) should be the ONLY way users can control styles 
(presentation), especially when they are not presenting tabular data.

> 5) What is this supposed table complexity that you are alluding to?

Tables are not inherently complex. But why should designers be forced to use 
tables when they really want presentation?

If a designer only wants to control the borders between blocks on a web site, 
why do they need to control those borders by surrounding the blocks with a 
table? CSS allows borders on block elements. Provide designers with a CSS 
mechanism to control border overlap, similar to that which exists in tables, but 
make it available for block elements in general.

When designers want to make block elements have identical sizes, excluding the 
designer hand-coding the sizes to make them match, the only way that can happen 
now is with tables. Put the elements in the same row or column and magically, 
they are the same size. What can designers do when the block elements need to be 
outside of the column or row? What if the block elements are not even tabular 
data and the table element itself is only used for presentation?

> 6) Where is the evidence that users are finding the use of tables for
> layout difficult?
> 
Read a book on HTML / XHTML page layout and design. Take a class in HTML. Read 
the CSS discussions online. Look at page source: even the simplest layouts 
require at least two nested tables, complex ones require 10 or more.

My point is not that using tables for layout is difficult, only that <table> 
(content) should be separate from margins, borders, alignment, size constraint 
of contained elements, and other style features, which are presentation. 
Presentation belongs in CSS. Content belongs in HTML or other document language.
> 
>>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?
> 
Again -- look back at the archives for this list. You are confusing the problem 
with the solution. You asked which problems I was trying to solve. Part of my 
answer was that developers said some proposed CSS features would be difficult to 
implement. (If you don't recall any implementors ever saying that about any 
proposed features, go back to the archives.)

I am proposing features which have already been implemented and proven to be 
implementable.
> 
>>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

Yes, I 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. 

Mostly, what I am saying is that the features I am proposing already exist, at 
least in part. People who attempt to implement them will have model code to copy 
which has already been developed and debugged.

Not that I am in the
> slightest bit convinced that most of what you want would serve any
> purpose.
> 
Can you see no practicality to allowing designers to control margin collapse? 
Are there no times when a web page would look better with borders overlapped, 
even when the blocks with the borders are not in a table? At least two other 
people proposed use cases for constraining block sizes outside of tables. 
Discussion about layout features are ongoing, my proposal is just to start 
simply, by separating (some styling and layout) abilities from the requirement 
that they only be used inside of tables.
> 
>>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.
> 
But much of that complexity is artificial!

If the rules for margin collapse were consistent for every block object, they 
would be much simpler to understand. Right now, there are different sets of 
rules for blocks in text flow, blocks which float, and blocks inside tables. 
Make one set of rules for margin collapse and allow designers to control when 
and how to apply them.

Similar discussion applies to border overlap.

Constraining block sizes is complex because it is exclusive to table elements. 
Make one set of rules and explain them, separate from the explanation about 
tables. Then, use those same rules when tables are discussed.

The forced combining of border overlap, margin collapse, block sizing, and grid 
layout makes each of them more complex.
> 
>>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.
> 
My original proposal was that CSS be extended to provide styles controlling 
margin collapse, border overlap, block size constraints, simple grid layout, and 
captions for all block elements. If there are styles for each of these, the 
designer has the option of not using them, of turning them off. This is not 
currently possible -- users either use tables, where some of these things are 
possible, or they don't use tables, and have no control at all over these 
presentation issues.
> 
>>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.
> 
I am not proposing to disable the entire collapsing margin mechanism. I am 
proposing that some designers, at some times, might find it useful to have some 
control over when and how margins collapse.

Similar words apply to border overlap, block size constraints, grid layouts, and 
captions.

Before anybody says anything: Yes, I know some will misunderstand the margin 
collapse mechanism and some will misuse it. Border overlap will be abused by 
some. At some point, alignment and sizing issues will make some pages load 
slowly because a designer overused those abilities. This does not mean that CSS 
should not provide these features.

The main point I was trying to make was that the interactions between blocks are 
not (well) considered in CSS currently. What happens when two blocks are next to 
each other? How does a designer control margins, borders, size differences, and 
alignment? When working with text within CSS, leading, font sizes, wrapping 
behaviors, etc. are defined and controllable. Why are there no similar controls 
for blocks -- to control margin overlap, border overlap, alignment, and sizes?
> 
>>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.
> 
> 
Where did I say that I wanted CSS2 rewritten? What I have said all along is that 
I wanted a small set of features considered for addition to CSS. If the CSS 
group considers some of these features worthy, then add them. I personally would 
like to see a small modification to an already implemented specification so 
there would be less work to get the specification approved and implemented, but 
   I never said anything about the process.

Many others have commented about the delays in getting CSS features written, 
reviewed, approved, and implemented. My proposal was deliberately small, to see 
if incremental changes work faster than complete rewrites. But that was only in 
my mind, not an explicitly stated goal.

>>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).
> 
It is not possible to overlap borders of adjacent objects. There is no way to 
code this, except using tables. And using tables adds layers of HTML which have 
nothing to do with PRESENTATION. This is my use case.

Besides, this is the wrong mail list to discuss difficulties in coding. We are 
supposed to be discussing proposed improvements to CSS.
> 
>>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).
> 
Use cases and examples were already provided when this was discussed about a 
month ago. My point, again, just in case you missed it, is that this is 
impossible in CSS and can only be done using tables
> 
>>What if users only want one column?
> 
> 
> div{width:20em}
> <div>foo</div>

This isn't a column, this is an element. I want a column of blocks on the left 
side of my screen, a column of text in the middle, and a column of images on the 
right. Over my three columns, I would like a header. Underneath, a footer. I 
want to use CSS to control positioning, alignment, borders, margins, and 
captions of all elements in my columns. Yes, I know I can fudge things and make 
nested tables to handle this situation, but I want to use CSS, not HTML! I want 
to use CSS for presentation. The layout is not related to the content and should 
not require a table, or multiple tables to do.
> 
>>Only one row?
> 
> 
> <div>foo</div>

A row: <div>A</div><div>B</div><div>C</div>

If A, B, and C are images, I can't declare them inline-block, they might wrap. I 
must use a table. Why? Please extend CSS to let me position blocks horizontally, 
without forcing me to use CONTENT specifiers (table) for PRESENTATION (style).
> 
>>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.
> 
I am not whining that it is too hard to use tables as presentation. I am arguing 
that presentation is simpler to use, simpler to explain, simpler to understand, 
simpler to implement when it is separate from content specifiers.
> 
>>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.

But why does changing BLOCK borders, especially overlapping BLOCK borders 
require the use of tables? Many objects have borders. CSS needs to provide a 
mechanism to allow designers to overlap those borders. Currently, only the HTML 
element <table> allows border overlap.
> 
> 
>>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.
> 
Which is why I am requesting that CSS have my proposed additions. Isn't this the 
group where people discuss proposals for additions and improvements to CSS? I 
understood that the group to discuss actual uses was elsewhere.
> 
>>Style and content should be separate. (Long list of reasons available, but 
>>excluded.)
> 
> 
> See above.
> 
So, you are saying that CSS2.1 is the last CSS there will ever be and anyone who 
thinks differently is wrong? Who died and left you in charge?

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

Received on Wednesday, 27 June 2007 14:58:52 UTC