Re: Stylings only possible with Tables

David Woolley wrote:

> 
> James Elmore wrote:
> 
>> 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.
> 
> 
> The SS in CSS stands for style sheet.  Style sheets are documents that 
> define the layout rules for a whole family of documents and typically 
> define a house style.  In the original intended use of HTML, which 
> corresponds to white papers, user guides, and internal documents, not to 
> the glossy brochures that most web sites try to emulate,one wants to be 
> able to write simple and compact style sheets that will result in 
> correctly marked up text being rendered according to reasonably good 
> typographical practice.  That means putting a lot of simple document 
> typography into the CSS language definition.

I know this. When I first encountered CSS, about six or seven years ago, I 
thought to myself, 'what a GREAT idea!' I still think so. The original reason 
for CSS still exists and is just as valid as ever.

But, (you knew there would be a 'but,' didn't you?) But, people are using HTML 
and CSS for other things as well. (Or maybe not as well, but they are being 
used, and abused, for other things.)

What I suggested was not intended to allow designers to control margins on a 
per-pixel basis. (Although several people seemed to infer that from my proposal. 
Just guessing here, but I think there have been problems in CSS history from 
designers who want the type of layout features you mention below.) My thoughts 
were based on my experience as a tool maker and user. I see CSS as a powerful 
tool set. I also see that some of the wrenches and saw blades are missing from 
the set. That was the basis for my proposal -- the missing parts of the set 
bothered me, so I suggested adding a few of the missing parts to make the set 
more complete.

> 
> The demand for sophisticated layouts comes from people writing the 
> equivalent of glossy brochures, a rather different problem area.  Tools 
> for doing sophisticated but fixed layout, designs for these pre-date the 
> web; HTML made a very deliberate choice not to emulate them.

I suppose that some of my proposals can be used to produce more sophisticated 
layouts. The margin-collapse feature seems to be one such hot-button. Without 
much consideration for the ultimate uses, I suggested that a missing, and 
apparently obvious, feature might be added.

Now, I am not a designer and have no intentions (or ability) in that direction. 
I just recognize that HTML and CSS are powerful tools which have already far 
surpassed what their original designers intended in the ways they are used. My 
proposal, whatever finally happens to it, was merely intended to provide what I 
saw as missing parts of the tool set. With a more complete tool set, I would 
venture to guess that uses beyond either of our abilities to guess will appear.

Perhaps designers will become more intelligent in their use of CSS tools, just 
as the general population became more aware of fonts and their intricacies when 
computers finally became able to handle fonts on screen and printers. Maybe 
history will work backwards and whitepaper writers will become more aware of 
design principles and produce more artistic work. I don't know, and I don't even 
begin to guess. I only spotted what I perceived as a lack in CSS and attempted 
to have that lack addressed.

> 
> Personally I am not sure that many designers have the mathematical 
> skills to create rules for sophisticated fluid designs, and many work in 
> a very visual way.  For fixed layout, there are tools designed for 
> electronic brochures, like PDF (which even allows the presentational 
> design to be annotated with the semantic structure, even if this is 
> rarely done; you can extract the HTML from a properly constructed tagged 
>  PDF file.

I don't know if designers have the requisite mathematical skills or not. But 
perhaps making the ability to better control margins will provide the user 
population with a better understanding of this sophisticated subject. I remember 
the difference in the general population when fonts became available generally 
on computers. Some people still haven't a clue about fonts and leading, about 
how characters collapse against each other, and whether serifs are better or 
not. But the understanding of fonts, in general, has improved significantly. I 
expect something similar with respect to styles, once the tools are available.

On a side note -- before computers were able to handle fonts, font experts had 
to be both mathematicians and designers and font sets sold for tens of thousands 
of dollars. Only a very few people could design fonts. The number of people who 
understood and used fonts artistically (and in what was considered the 'proper' 
manner) was still a very small proportion of the population: probably near 1%.

Back to your comments. I was not aware of that feature of PDF. As I said, I am 
not a designer and I only use PDF for portability, not design. It seems as 
though the designers of PDF (Adobe?) gave it some valuable thought. Could styles 
be extracted from PDF as well? I mean, if an author was told by his/her boss to 
match the company style, given a PDF sample, could some sense of the correct 
style be extracted automatically? (Yes, I know from what you say that many 
features of PDF do not exist in CSS, different purposes, different tool sets.)

> 
> Although one might be able to use a model where the primary document is 
> semantics structured and there is a complex presentational overlay, I 
> think it will be difficult to do without presentational artifacts in the 
> semantics.  The existence of semantic artifacts in tagged PDF is less of 
> an issue, because semantic boundaries are always potential 
> presentational ones.

Sorry that I got up in my pulpit and started preaching. I know that the 
artifacts and complexities which exist in HTML / CSS will not go away. The tags 
with presentational capabilities will not magically disappear. The HTML/XTHML 
connections which are buried in CSS (because that was where it was first used) 
will be around a long time. Because of the number of times when I shot myself 
(metaphorically) in the foot by combining two different functions, I sometimes 
start preaching, trying to save the sinners from those sins I am already 
familiar with.

What I would like, simply, is to take tiny steps away from what we all know is 
causing complexity -- overlapping presentation and content -- so our lives will 
be simpler. None of the complexity will ever disappear completely, but I can try 
and make my life, and the lives of other XML / CSS users easier with these steps.

> 
> Note with regard to tables, I hope that you understand that 
> display:table is not restricted to table elements.  Also, at least at 
> one time, CSS3 would allow phantom containing elements to be generated 
> and styled.
> 

Yes, I know that any element can be declared as 'display: table' and the rules 
for adding unnamed elements should come into effect. What I am saying is that it 
should be possible to control some of the purely presentational features which 
exist only in tables using CSS in other elements.

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

Received on Thursday, 28 June 2007 17:46:47 UTC