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