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