Re: [CSS21] properties for table-column (In HTML: COL) & table-column-group (In HTML: COLGROUP) items.

On 6/30/05, David Woolley <david@djwhome.demon.co.uk> wrote:
> 
> > They are in my mind two different beasts and should be treated as
> > such. I find immense pain anytime I want to come up with a layout for
> > CSS. I find it's just not very good at layout. But I attribute that to
> > the mechanism for choosing properties and the box model.
> 
> There may be a market for this split, but it is such a radical leap
> from CSS that it really is a new language.

Probably yeah, but that's because as I see it, the way CSS specifies
rules for layout is flipped. Layout's define their contents, not the
other way around.
 
> > They do not think of them the same way. And the processes usually end
> > up being separated. Layout can be done on a napkin - created in rough
> > fashion and shown to a colleague. Presentation cannot.
> 
> Where there is a strong layout, they will probably decide on the content
> last, and fit the content to the layout.  As well as conflicting with
> the idea of HTML as a semantic structure language, it only really works
> for a known rendering environment.  It's a continuance of old technology
> in which the final rendering is fixed on paper before the user sees it.
> It doesn't work well were the user can control media size, font size,
> etc., etc.

Excpet that would be the responsibility of the device. The benefit,
the major benefit of all this, is the ability to move layout to the
device where it is most critical. Layout as content actually fixes
this problem. A problem not _easily_ solved any other way.

> > One of the key benefits of this separation beyond the tuning of the
> > language towards the mental models of the users of that language is
> > that the organization of space can be seen simply looking at the file.
> 
> Yes for a desktop publishing system producing final form output, but
> not so obviously the case for extremely reflowable content.

It can be reflowable (hence the use of percentages) and it can be
based on viewport size and not pixel lengths.

> > Language is used to communicate and the model the language presents to
> > its user should match very closely the model the user uses themselves.
> 
> User in CSS normally represents the viewer.  Here you mean the graphic
> designer.
> 
> > This is one of the core tenants of usability. Currently, I find that
> > CSS layout doesn't accomplish this.
> 
> Usability issues for the designer can be handled by their authoring tools.
> Usability in web terms normally refers to the consumer, not the producer.

As and Human-Computer Interaction (HCI) specialist, this statement
frustrates me to no end because it ignored the fact that authors do in
fact write using the language directly. They also read using the
language directly. The job of the spec includes looking at the reality
of the language consumers as well as the hardware and algorithms.
Moving off usability requirements to the authoring tools just doesn't
cut it.

> > Tagged PDF isn't a solution to any problem in the web for so many
> > other reasons. PDF is a source of frustration to a large number of
> > people on the web. Fortunately it's primary problem - slow load times
> > - seems to have been fixed in 7.
> 
> One of the reasons that PDF files are slow to download is that authoring
> tools try to take too much control over the layout, i.e. they try
> and produce too much pixel perfection.  If you compare the PDF from
> PostScript generated by MS Word (or most other Windows programs) with
> that generated by groff, you will see that the former is much bigger.
> That's essentially because instead of output whole lines of text,
> with possible spacing adjustment arrays, each character is output as
> separately positioned graphic element.

No, one of the reasons it's so slow is because the software was slow;
something they fixed in 7. It runs quite quickly now.

> > Another aside is the solution I proposed above doesn't break
> > incremental rendering. Since the layout is specified beforehand, as
> 
> As I pointed out, you will get overflows or big gaps if you fix the
> layout in sufficient detail for that before actually seeing the
> content.

Yeah, but only in situations where you would now using percentages and
table layouts. If a section is set to use 30% of the viewport which
ends up being 200px and you want to display a 300px picture in there,
there's going to be overflow. As far as gaps are concerned, you'll
only see them where you'ld see them now. I'm not quite sure where you
got the idea that this will be a problem.

> > As an aside if HTML were willing to actually promote the five largest
> > div types to actual elements (a benefit being increased usability),
> 
> XHTML2 does add some of these and provides a role attribute for encoding
> the others.  However, my take on this is that most of these components
> are logically separate documents and should be linked to with
> link elements.  Unfortunately that won't happen, as it will remove the
> ability to apply branding to the layout of such features if the browser
> took responsibility.  It would be much more usable, though, as the
> browser would enforce consistency.

Yeah, once they're standard elements they can be given their own
content models, be moved off into other documents and given their own
specs, but I was trying to forcast _all_ my moves.

> > As far as your coment about a specific page, the example presented
> > before you would apply to all documents that use a particular layout
> > and not just one. It would also allow for the easy separation of
> 
> The problem is that it only seems to allow the top level structure
> to be defined as a pattern.  You can't, for example, define generic
> rules for the structure of a document section or for a real (data)
> table.

I fail to see why I can't? I got ~90% of comercial sites I visit by
having a layout that tackled the 5 biggest zones. I never said layout
documents couldn't be mixed with the author specifying how the
overarching layout is handled and the content author providing how
internal content is handled. However, once the big 5 are handled there
isn't that much laying out anyways. At that point it tends to be
either simple block, float or inline content. But again these should
be handled by the content author.

> > To me it's just a simpler model that's easier to work with. The layout
> > algorithm is easier to work with and it makes reading and writing
> > layout code easier. If you noticed the excessive use the of the word
> > easier, then maybe you'll get what I'm after.
> 
> Doing global layout is OK for desktop publishing, where the author sees
> the result and fixes it into final form before distribution.  It is
> a much more difficult problem when the layout needs to remain fluid
> at the destination.

Yeah... um, no. Device layout would finally fix the largest problem
with unknown destination today, by moving the problem to the device
allowing authors to simply work without having to worry about the
sizes and dimensions of the devices they work on (at least too much).
They'll still have to worry about color depth, but that's a lot less
to worry about and can be fixed in other ways.

Orion Adrian

Received on Thursday, 30 June 2005 11:09:26 UTC