CSS layout frustration

[Diane Wilson]

I'm trying (once again) to figure out how to make a robust
CSS layout style that can replace tables. I'd like to be able
to do a basic two-column layout, with a one-column header,
a two column body, and a two-column footer.

The problem, and one that always sends me back to using tables,
is that word "robust." Absolute positioning gets squirrelly,
because it takes the positioned elements completely out of the
float scheme, and stuff starts overprinting. Nor does there
seem to be a reliable way to specify absolute positioning
when there are multiple elements to be juggled both vertically
and horizontally.

I'm currently trying to use just float positioning (left and
right) with percentage widths, and it *almost* works. (Meaning
that it's *almost* robust, which is why I always quit using
CSS for layout.) The current problem is that if the window
width shrinks to some arbitrary point, the floating elements
are no longer side by side; one drops below the other, while
still remaining "floated" to the left or right. There seems
to be no reason at all for this; the floated elements use
percentage width so that they should always have don't take
the entire page width.

The page is at http://www.firelily.com/test/test3.html with
the styles embedded for easier debugging. Here's the key
part of the stylesheet that seems to need fixing:

#content {
width: 100%;
}

#content #main {
margin: 0 .5em;
float: right;
width: 75%;
}

#content #leftNav {
margin: 0 .5em;
float: left;
width: 20%;
}

The footer is set up the same way, and has the same problems.

The other problem that I can't figure out on this page is the
top margin on the right callout box, which should behave like
the quoted text box just up the page, but doesn't. This is minor,
although if someone can spot what the difference is, I'd love
to hear about it.

The problem occurs with both current IE and back-level Firefox
on WinXP.

Thanks for any suggestions on fixing this page!

Diane

[Beauregard T. Shagnasty]

Diane Wilson wrote:

I'm trying (once again) to figure out how to make a robust CSS
layout style that can replace tables. I'd like to be able to do a
basic two-column layout, with a one-column header, a two column
body, and a two-column footer.
Possibly one of Ben's templates will give you clues:

http://benmeadowcroft.com/webdev/css...s/spider1.html
The page is at http://www.firelily.com/test/test3.html with the

Please don't assign a text size smaller than my default. Very hard to
read. IOW, assign 100% to the body element, and then only assign
different (larger) percentages for things like <hx> and possibly
(smaller, but not less than 85%) for copywrite/legalese.

Oh, in your CSS there is a lot of extra stuff. Remember, the C in CSS
is Cascading.

--
-bts
-This space intentionally left blank.

[Spartanicus]

Diane Wilson <di***@firelily.com> wrote:

I'm trying (once again) to figure out how to make a robust
CSS layout style that can replace tables. I'd like to be able
to do a basic two-column layout, with a one-column header,
a two column body, and a two-column footer.

The problem, and one that always sends me back to using tables,
is that word "robust."

Alas some of the semi enlightened are trying to convince others that
they should not use tables for layout. Although theoretically correct,
the use of floats for creating a "layout" is fundamentally inappropriate
and an awful hack. In practice the method introduces many problems, both
for the author and (worse) for the user.

Unless you are truly skilled in creating a "CSS layout", you'd do your
visitors a favour by using a table for layout. CSS support in IE isn't
good enough to easily create CSS layouts that are as robust as HTML
tables.

Many "CSS layouts" using floats or absolute positioning are of the very
basic variety, or they introduce all sorts of problems that a comparable
table layout would not suffer from.

--
Spartanicus

[Diane Wilson]

In article <2L*****************@twister.nyroc.rr.com>,
a.*********@example.invalid says...

Diane Wilson wrote:

I'm trying (once again) to figure out how to make a robust CSS
layout style that can replace tables. I'd like to be able to do a
basic two-column layout, with a one-column header, a two column
body, and a two-column footer.
Possibly one of Ben's templates will give you clues:

http://benmeadowcroft.com/webdev/css...s/spider1.html

Doesn't do nearly enough. For one thing, there's no separate page header,
which means that once the header is added, his absolute positioning
trick for the left and right columns is going to be a serious problem.
He also sidesteps the issue of doing columns within the footer.

The page is at http://www.firelily.com/test/test3.html with the

Please don't assign a text size smaller than my default. Very hard to
read. IOW, assign 100% to the body element, and then only assign
different (larger) percentages for things like <hx> and possibly
(smaller, but not less than 85%) for copywrite/legalese.

This text size is a little smaller than I would normally use; this
is an experimental page with a lot of test stuff going on relative
to styles. I needed to be able to fit a lot of stuff in view to see
how things interact.

At least the text sizing is completely responsive to the text size
option in the browser.
Oh, in your CSS there is a lot of extra stuff. Remember, the C in CSS
is Cascading.

Could you vague that up for me, please?

Diane

[Diane Wilson]

In article
<pt********************************@news.spartanic us.utvinternet.ie>,
in*****@invalid.invalid says...

Diane Wilson <di***@firelily.com> wrote:

I'm trying (once again) to figure out how to make a robust
CSS layout style that can replace tables. I'd like to be able
to do a basic two-column layout, with a one-column header,
a two column body, and a two-column footer.

The problem, and one that always sends me back to using tables,
is that word "robust."

Alas some of the semi enlightened are trying to convince others that
they should not use tables for layout. Although theoretically correct,
the use of floats for creating a "layout" is fundamentally inappropriate
and an awful hack. In practice the method introduces many problems, both
for the author and (worse) for the user.

Unless you are truly skilled in creating a "CSS layout", you'd do your
visitors a favour by using a table for layout. CSS support in IE isn't
good enough to easily create CSS layouts that are as robust as HTML
tables.

Many "CSS layouts" using floats or absolute positioning are of the very
basic variety, or they introduce all sorts of problems that a comparable
table layout would not suffer from.

Whic is pretty much why I continue to use tables for layout. They're
versatile, flexible, robust, and mostly bug-free, which is a lot more than
anyone can say about CSS.

I got bugged by all this again when I happened to notice that one of
the local web design firms put "using CSS for page layout" as a
job skill requirement. Unfortunately, their own web site is full
of the same hacks and limitations that everything else I've seen using
CSS is prey to.

I understand about all the bugs and incompatibilities in various
browser implementations and display models, but the W3C CSS standards
must take a large share of the blame as well. The ability to put
together a robust and predictable grid structure is the foundation
of any good visual structure. I know that some people have put
together some very interesting pages with CSS, but they all seem to
work around structual weaknesses and omissions in the CSS standard.

Diane

[Spartanicus]

Diane Wilson <di***@firelily.com> wrote:

I understand about all the bugs and incompatibilities in various
browser implementations and display models, but the W3C CSS standards
must take a large share of the blame as well. The ability to put
together a robust and predictable grid structure is the foundation
of any good visual structure. I know that some people have put
together some very interesting pages with CSS, but they all seem to
work around structual weaknesses and omissions in the CSS standard.

CSS 2.x does contain a method that can replace HTML tables used for
layout in most situations, but it's not supported by IE, so few people
know about it. But this method (CSS tables) suffers from all the same
problems that HTML tables suffer from, minus the semantic problem.

CSS 2.x contains no good methods for creating a layout. Although there
is a proposed "layout" module for CSS 3, it isn't public so whether any
work has been done on it, and if so, if it promises some long awaited
progress on this front is anyone's guess.

--
Spartanicus

[Alan J. Flavell]

On Mon, 22 Aug 2005, Diane Wilson wrote:

I'm trying (once again) to figure out how to make a robust
CSS layout style that can replace tables. I'd like to be able
to do a basic two-column layout, with a one-column header,
a two column body, and a two-column footer.

The problem, and one that always sends me back to using tables,
is that word "robust."

The problem with (mis)using tables for layout is that they are far *too*
"robust". They tend to force their grid construction on the user through
thick and thin, no matter how far their browsing situation differs from
the one that the author had in mind. While it's true that a skilled
author can avoid some of the excesses that are usual in the mass of
"commercial" table-based designs (typical symptoms being pixel-sized text,
pixel-sized table cells, pixel-sized tables, the whole thing becoming
unusable when the reader has to zoom the text in order to read it! - some
even become unusable if the user selected one of the available text sizes
other than the default in their browser!!) - authors with more skill allow
their tables at least *some* flexibility towards the user's situation.
But I prefer techniques that adapt themselves more effectively to a wide
range of situations - for example, if necessary floating marginal material
to the top or foot of the page if the browsing width is insufficient to
accommodate it.

As such, anyone who's struggling to use CSS to mimic the kind of robust
grid that they were hankering for with their previous table designs has,
IMHO, missed the point: they might as well have stuck with their (mis)use
of tables. CSS seems best at doing what tables couldn't do: achieving
flexibility of presentation across a much wider range of browsing
situations (not excluding that the page should look reasonably close to
what the author would like, in the presentation situation which the author
had in mind!), whereas tables are much too "robust" for that, even in the
hands of a skilled author.

IMHO, anyway. I won't claim to be good at it yet myself, but I do think I
can recognise web pages where it's working.

[Beauregard T. Shagnasty]

Diane Wilson wrote:

In article <2L*****************@twister.nyroc.rr.com>,
a.*********@example.invalid says...

Diane Wilson wrote:

I'm trying (once again) to figure out how to make a robust CSS
layout style that can replace tables. I'd like to be able to
do a basic two-column layout, with a one-column header, a two
column body, and a two-column footer.
Possibly one of Ben's templates will give you clues:

http://benmeadowcroft.com/webdev/css...s/spider1.html

Doesn't do nearly enough. For one thing, there's no separate page
header,

http://benmeadowcroft.com/webdev/css...ft-column.html
He calls it ".title"

<div class="title">
<h1>Left Column Layout</h1>
</div>
which means that once the header is added, his absolute
positioning trick for the left and right columns is going to be a
serious problem. He also sidesteps the issue of doing columns
within the footer.

They are samples. Feel free to modify. Put two divs in the footer, and
align one left and one right.

--
-bts
-This space intentionally left blank.

[Diane Wilson]

In article <Pine.WNT.4.63.0508221946240.852@ZORIN>,
fl*****@physics.gla.ac.uk says...

On Mon, 22 Aug 2005, Diane Wilson wrote:

I'm trying (once again) to figure out how to make a robust
CSS layout style that can replace tables. I'd like to be able
to do a basic two-column layout, with a one-column header,
a two column body, and a two-column footer.

The problem, and one that always sends me back to using tables,
is that word "robust."
The problem with (mis)using tables for layout is that they are far *too*
"robust". They tend to force their grid construction on the user through
thick and thin, no matter how far their browsing situation differs from
the one that the author had in mind. While it's true that a skilled
author can avoid some of the excesses that are usual in the mass of
"commercial" table-based designs (typical symptoms being pixel-sized text,
pixel-sized table cells, pixel-sized tables, the whole thing becoming
unusable when the reader has to zoom the text in order to read it! - some
even become unusable if the user selected one of the available text sizes
other than the default in their browser!!) - authors with more skill allow
their tables at least *some* flexibility towards the user's situation.
But I prefer techniques that adapt themselves more effectively to a wide
range of situations - for example, if necessary floating marginal material
to the top or foot of the page if the browsing width is insufficient to
accommodate it.

Well-constructed layout tables have none of the defects you refer to,
and allow for a fair amount of "float" as well. If (and so far, that's
still a big IF) the web ever makes much headway on mobile devices, the
world will have to change, but so far CSS hasn't blzed that trail well
enough to be a true replacement for tables.
As such, anyone who's struggling to use CSS to mimic the kind of robust
grid that they were hankering for with their previous table designs has,
IMHO, missed the point: they might as well have stuck with their (mis)use
of tables. CSS seems best at doing what tables couldn't do: achieving
flexibility of presentation across a much wider range of browsing
situations (not excluding that the page should look reasonably close to
what the author would like, in the presentation situation which the author
had in mind!), whereas tables are much too "robust" for that, even in the
hands of a skilled author.
That kind of misses the point, and underscores one of my basic complaints
about CSS. There are *centuries* of experience with text layout and
visual design. Much of it translates very well to flexible media like
the web. However, CSS was seemingly designed in deliberate contempt of that
body of experience. It's not just the CSS layout problems; it's part of the
basic vocabulary and capability of fundamentals like text and paragraph
typography controls.

CSS has also perpetuated some of the worst aspects of the things it
was designed to replace. As much as I hate <font> tags, the average
user has a lot more flexibility to deal with under-sized type if a
page is written using <font size="small"> than if the page is written
with <span style="font-size: 8px;"> (or equivalent with proper external
style sheets). One resizes automatically when I select larger type
size from IE's menu bar; the other doesn't. The web would be a much
friendlier environment if CSS had not supported absolute type sizes,
especially in pixels or points. (Inline style definitions are another
hot button, but I'll stay off that one for today.)

Font-sizing rants aside, the basics of visual design and visual
structure don't change so much from one medium to another. Things
like running headings and running footings are extremely useful in
print, and have their functional equivalent in page headers and footers
on the web. It's something that's easy with tables and very difficult
with CSS.
IMHO, anyway. I won't claim to be good at it yet myself, but I do think I
can recognise web pages where it's working.

Alan, I know you've been doing web pages longer than most of us, and the
fact that neither you nor many other talented people have become "good
at it" yet is indicative of the problems inherent in CSS.

When I do see attractive pages in CSS (such as Zen Garden), I can almost
hear the sigh of relief from the designer along the lines of "ahhh,
another page where I've avoided the necessity of complex headers and
footers!". The problems don't show up until you try to translate those
techniques to a different visual structure. CSS isn't just limiting;
it's constricting.

Diane

[Spartanicus]

Diane Wilson <di***@firelily.com> wrote:

CSS has also perpetuated some of the worst aspects of the things it
was designed to replace. As much as I hate <font> tags, the average
user has a lot more flexibility to deal with under-sized type if a
page is written using <font size="small"> than if the page is written
with <span style="font-size: 8px;"> (or equivalent with proper external
style sheets). One resizes automatically when I select larger type
size from IE's menu bar; the other doesn't. The web would be a much
friendlier environment if CSS had not supported absolute type sizes,
especially in pixels or points.

CSS does not support non resizable font sizes, the issue you are
referring to is one of the many CSS defects in IE. This one is simple to
avoid, don't use px sized text.

--
Spartanicus

[Alan J. Flavell]

On Mon, 22 Aug 2005, Diane Wilson wrote:

That kind of misses the point, and underscores one of my basic complaints
about CSS. There are *centuries* of experience with text layout and
visual design.
Indeed there are - on a canvas of known size, proportion, and visual
properties. And usually in a collective viewing situation (everyone has
to look at the same picture, or are offered the same book - if someone
needs a large print book, they have to find one first, and buy it).

Then there's the web. With its canvas of, in general, unknown size,
unknown proportions, uncertain visual properties, and with the "large
print book" built-in (if only the author doesn't contrive to defeat the
possibility).
Much of it translates very well to flexible media like the web.
A pity that the mass of commercial authors hasn't yet discovered which
parts belong to that "much" of which you are speaking.
CSS has also perpetuated some of the worst aspects of the things it
was designed to replace. As much as I hate <font> tags, the average
user has a lot more flexibility to deal with under-sized type if a
page is written using <font size="small"> than if the page is written
with <span style="font-size: 8px;">
Erm, CSS offers a wide range of units, some of which might be suitable for
specialised situations, but only a few of which are suitable for general
web use. I think it's fair to say that the balance of opinion here is that
the only *text size* units fit for general web use are em units and
percentages. Some of the other units may be arguably usable for specific
purposes.
One resizes automatically when I select larger type
size from IE's menu bar; the other doesn't.
px units are pretty clearly defined, as are pt (and mm, inches etc.).
They're *not* *supposed* to change at the user's whim - they're supposed
to obey the CSS size unit definitions. That's why they're only for
specialised use (e.g pt for a print-only stylesheet - CSS px units
arguably for a projection situation), and unfit for use in a general web
context.

The fact that some of them are capable of being rescaled in some browsers
might be rated as a bug, just as it would be a bug in the general store if
the owner could re-scale the weights to suit her mood. If that's not the
behaviour that's wanted, then THOSE UNITS SHOULD NOT BE USED. It's as
simple as that. Browsers of course must have option(s) to override the
author's inappropriate presentation proposals - that should go without
saying. But as long as the author's styles are in effect, they ought to
be taken seriously, or CSS is not being implemented to specification.
The web would be a much friendlier environment if CSS had not supported
absolute type sizes, especially in pixels or points.
Gosh. I suppose that would be one alternative to author education, and/or
pointing readers to their browser's disable-CSS functionality.
When I do see attractive pages in CSS (such as Zen Garden), I can almost
hear the sigh of relief from the designer along the lines of "ahhh,
another page where I've avoided the necessity of complex headers and
footers!".

As I've said before: the zen garden is a spectacular demonstration of what
-can- be achieved with CSS, and valuable for that reason - but in no way
suitable as a role model for real-world web page design.

[kchayka]

Diane Wilson wrote:

I'm currently trying to use just float positioning (left and
right) with percentage widths, and it *almost* works.

The page is at http://www.firelily.com/test/test3.html

It only "almost" works because:
1. You appear to be using IE's broken box model, rather than the W3C
standard. In the header and footer:
non-zero left/right-padding + width:100% = wider than the viewport

The width property sets content width, not box width. See
<URL:http://www.w3.org/TR/CSS21/box.html>

2. You are mixing units with the 2 columns:
margins:2em (.5em * 4) + width:20% + width:75% != 100%

With my larger-than-average default text size, those margins can easily
make it wider than 100% and the left column slides under the right. With
a small enough text size, the 2 columns stay side-by-side, but then it's
too small for my reading comfort. Use % for margins instead of ems and
you should avoid this problem.

Be warned, though...IE's broken default overflow behavior will
automatically expand the width if needed to hold the content. That might
easily happen with the very narrow (too narrow, perhaps) left column if
there is a long word in there, especially in a smallish window or with
larger text sizes. Widen the left column some to reduce the risk.

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.

[Christoph Päper]

Spartanicus:

CSS does not support non resizable font sizes, the issue you are
referring to is one of the many CSS defects in IE.
Actually IE's interpretation of the standard in this case can be
considered correct, despite being user-unfriendly. CSS is a more
powerful tool than presentational HTML. Users of more powerful tools
tend to harm themselves and others more often. Therefore they have to be
instructed properly or be willing to learn themselves before using the
tool in public.
This one is simple to avoid, don't use px sized text.

Sure, and none of the (real) absolute units either.

[C A Upsdell]

Christoph Päper wrote:

CSS does not support non resizable font sizes, the issue you are
referring to is one of the many CSS defects in IE.

Actually IE's interpretation of the standard in this case can be
considered correct, despite being user-unfriendly. CSS is a more
powerful tool than presentational HTML. Users of more powerful tools
tend to harm themselves and others more often. Therefore they have to be
instructed properly or be willing to learn themselves before using the
tool in public.

Hmmm. I could argue that other browsers are implementing the standards
correctly inasmuch as, without user intervention, fonts specified in
absolute units will be rendered in absolute units. It is only when the
user intervenes that the font sizes are overridden, and this is as it
should be to meet the overriding imperative of usability. Remember too
in this context that CSS does not specify: it suggests.

[Spartanicus]

Christoph Päper <ch**************@nurfuerspam.de> wrote:

CSS does not support non resizable font sizes, the issue you are
referring to is one of the many CSS defects in IE.
Actually IE's interpretation of the standard in this case can be
considered correct

Regarding user font zooming there is nothing in the specs that justifies
treating px sized fonts any different to other units.
CSS is a more powerful tool than presentational HTML.

Really? What would we do if we didn't have you to enlighten us.

--
Spartanicus

[Alan J. Flavell]

On Tue, 23 Aug 2005, Spartanicus wrote:

Regarding user font zooming there is nothing in the specs that justifies
treating px sized fonts any different to other units.

Which "other units" do you have in mind? pt units are absolute, and (once
the display has been calibrated against an absolute standard of length,
e.g a ruler) the only way to "zoom" pt units is to break the client
agent's conformance with the CSS specification (or disable the author
style sheet in the interests of accessibility).

em units, on the other hand, are defined to behave quite differently in
response to user preferences, entirely within the CSS specification and
without anything needing to be overriden nor specification conformance
needing to be broken.

If there's ever a client agent which conforms with the CSS specification
of the px unit, then it will need some kind of facility to calibrate the
unit in terms of parameters which the client agent does not know (the
displayed dpi, and the anticipated viewing distance). This kind of
calibration should not however be confused with arbitrary user-preference
zoom factors.

I say again, if authors do not want inappropriate size units, they SHOULD
NOT ASK FOR THEM, on penalty of risking getting what they asked for - and
causing the inconvenienced user to override their requests altogether.

And I'd put the CSS px unit into much the same class in *that* regard:
even though it's not an absolute length unit in the way that the pt unit
is, it is nevertheless pretty clearly defined in the CSS specification in
terms of absolute length units (dpi and viewing distance), and anyone who
uses it must take the risk that there could be client agents out there
which implement it to specification - even if I don't currently know of
one.

[Spartanicus]

"Alan J. Flavell" <fl*****@physics.gla.ac.uk> wrote:

Regarding user font zooming there is nothing in the specs that justifies
treating px sized fonts any different to other units.
Which "other units" do you have in mind?

Any.
pt units are absolute, and (once
the display has been calibrated against an absolute standard of length,
e.g a ruler) the only way to "zoom" pt units is to break the client
agent's conformance with the CSS specification

"absolute" has no relation to the various user override mechanisms
provided by a browser such as settings for minimum font size, font zoom,
page zoom, or changing the font size through a user stylesheet.

--
Spartanicus

[junk]

Diane Wilson wrote:

I'm trying (once again) to figure out how to make a robust
CSS layout style that can replace tables.

have a look at http://webhost.bridgew.edu/etribou/layouts/index.html
several layouts and well commented.

[Alan J. Flavell]

On Tue, 23 Aug 2005, Spartanicus wrote:

"absolute" has no relation to the various user override mechanisms
"absolute" length units in CSS mean that a ruler can be used on the
display to test for conformance.

Override mechanisms will, in general, break CSS conformance: that's
what they are for. And maybe in different ways on different browsers,
since overrides are outside of what the applicable specifications
cover. But one should not pretend that the result has much to do with
CSS!

I don't understand why this seems to be causing such an argument: it
seems to me to be a plain statement of the facts.
provided by a browser such as settings for minimum font size,
...which breaks CSS conformance, and means that texts which should have
appeared at different sizes can appear at the same size. Yes, I use
that feature myself, as a defence against misguided authors who
specify microfonts: but I'm under no illusions about what it does to
the browser's CSS conformance, and the fact that the result - in the
interests of being useful to myself - is neither what the author
intended NOR what the CSS specification intended.
font zoom, page zoom,
If a page contains texts specified in a mixture of units, then changes
in the user's preferences should (on a conforming CSS specification)
affect text sizes in *different* proportions. E.g doubling the user's
preferred font size should result in 1.0em text being twice as big,
while 10pt text should still be measureably 10pt in size (i.e
unchanged). If this behaviour isn't what the author wants, then s/he
should not have asked for it. If it isn't what the reader wants, then
they need to overrule the author's specification - breaking CSS
conformance.

So: if the browser's font zoom affects both units equally, as you
appear to want, then the specification conformance will be broken. You
might consider this to be a preferable behaviour in the interests of
accessibility - but it doesn't change the fact that the browser then
*no longer conforms* with the CSS specification. Of course,
ultimately the user is free to disable the author's style
specification, maybe even to apply their own instead, but that is a
different principle.
or changing the font size through a user stylesheet.

If you mean via the specified cascading rules, then fine: that doesn't
have to mean breaking CSS conformance. Or if you mean disabling the
author stylesheet and applying a user stylesheet instead, then that's
OK too - in the interests of accessibility. Neither of these involve,
for example, redefining absolute length units at the user's whim.

[Spartanicus]

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

"absolute" has no relation to the various user override mechanisms

"absolute" length units in CSS mean that a ruler can be used on the
display to test for conformance.

Override mechanisms will, in general, break CSS conformance: that's
what they are for.

You are thoroughly confused about CSS conformance. CSS conformance does
not imply that author style suggestions will be rendered as intended by
the author, the user has the final say. On the CSS level there is the
provision of user stylesheets, but it doesn't stop there, a browser is
fully entitled to trump that by applying user preferences set outside
the CSS model without this having any effect on CSS conformance.

--
Spartanicus

[Alan J. Flavell]

On Tue, 23 Aug 2005, Spartanicus wrote:

You are thoroughly confused about CSS conformance.
I don't believe so. If I am, then so it seems were those writing the
specification!
CSS conformance does not imply that author style suggestions will be
rendered as intended by the author, the user has the final say. On
the CSS level there is the provision of user stylesheets,
I have already agreed that the cascading of a user style sheet is
regulated by the CSS specification, so there is no need to keep on
about that.
but it doesn't stop there, a browser is fully entitled to trump that
by applying user preferences set outside the CSS model
Yes, it is, but, as you say yourself, the result is then "outside the
CSS model", i.e it does not conform to the CSS specification.
without this having any effect on CSS conformance.

Since you haven't cited anything in the specifications, we're left to
guess what you're relying on, which isn't very helpful.

You'll note that in 3.2 it says in relation to conformance that
"Values may be approximated when required by the user agent".

I wouldn't say that "multiplying or dividing by arbitrary factors at
the user's behest" could be interpreted as "approximated".

It also says "Additionally, UAs may offer other means to specify user
preferences, for example through a GUI". Does this mean that users
are allowed to "prefer" different values for the size of a pt unit,
and still be specification-conforming, even though the specification
already unambiguously specified it as 1/72nd of an inch? I say "no":
if they want to change the size of such a text (without using the
cascade to overrule the author) then the resulting display no longer
conforms to the CSS specification. That may well make it more useful
- but being useful is one thing, while conforming to the specification
(particularly if inappropriate values/units have been specified in the
first place) is something else.

Anyway, unless you care to cite some chapter and verse which supports
your position and which leads to useful further discussion, I've done
my best - I think I'll draw a line under this now.

[Spartanicus]

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

It also says "Additionally, UAs may offer other means to specify user
preferences, for example through a GUI".

Clear enough English to me.

--
Spartanicus

[Christoph Päper]

Spartanicus schrieb:

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

"absolute" length units in CSS mean that a ruler can be used on the
display to test for conformance.
I agree, although I would not consider Opera's zoom feature non-conformant.
Override mechanisms will, in general, break CSS conformance: that's
what they are for.
You are thoroughly confused about CSS conformance. CSS conformance does
not imply that author style suggestions will be rendered as intended by
the author, the user has the final say.

Something like

* {min-font-size: 12px !important}

or, until that property exists in CSS, rather

* {-vendor-min-font-size: 12px !important}

in the /user stylesheet/ would indeed conformantly enforce a minimum
font size. One can argue whether the current browser implementations do
just that. IMVHO, which is not set in stone, the settings in the browser
GUI are to be considered adjustments to the /user agent stylesheet/.
The origin-importance cascading order is (ascending):

1. user agent
2. user normal
3. author normal
4. author important
5. user important

Therefore it's not conformantly possible to enforce a minimum font size
with UA (quasi) CSS.
a browser is fully entitled to trump that by applying user preferences
set outside the CSS model without this having any effect on CSS conformance.

From 3.2 Conformance (current 2.1 revision):

| - A user agent that renders a document with associated style sheets
| must respect points 1-5 and render the document according to the
| media-specific requirements set forth in this specification. Values
| may be approximated when required by the user agent.

It's not approximation.

| The inability of a user agent to implement part of this specification
| due to the limitations of a particular device (e.g., a user agent
| cannot render colors on a monochrome monitor or page) does not imply
| non-conformance.

It's not technical limitations either.

| UAs must allow users to specify a file that contains the user style
| sheet. (...) Additionally, UAs may offer other means to specify user
| preferences, for example through a GUI.

That final sentence may be it, but it's IMHO underspecified. It seems to
allow pretty much anything without any interaction with CSS, although it
should be done with a (pseudo) user stylesheet using vendor specific
properties or values if necessary.
I just posted a question on www-style regarding this.

[Christoph Päper]

Spartanicus:

Christoph Päper <ch**************@nurfuerspam.de> wrote:

CSS does not support non resizable font sizes, the issue you are
referring to is one of the many CSS defects in IE.

Actually IE's interpretation of the standard in this case can be
considered correct

Regarding user font zooming there is nothing in the specs that justifies
treating px sized fonts any different to other units.

That depends how font zooming is implemented, which the CSS
specification does not define. In IE it's simply a change of the default
font size of the root element, resulting in dependent relative font
sizes (i.e. such set with 'em', 'ex' or '%', or keywords) changing
accordingly. Mozillas (and I think KHTML) scale all font sizes by some
factor, Operas all lengths. All approaches are justifiable, but
Mozilla's is closest to the edge of CSS conformance, although many may
consider it the most user-friendly solution.

CSS is a more powerful tool than presentational HTML.

Really? What would we do if we didn't have you to enlighten us.

That was directed more at Diane than you. If I remember her text
correctly, she seemed to believe CSS should not allow anything that
could be used to the malefit of the user.

[Spartanicus]

Christoph Päper <ch**************@nurfuerspam.de> wrote:

IMVHO, which is not set in stone, the settings in the browser
GUI are to be considered adjustments to the /user agent stylesheet/.

Whilst I don't agree that browser pref settings should be made to
participate in the CSS cascade, or that the issue is conformance
related, if viewed that way, then user prefs are "user important" in the
cascade, not a "user agent" stylesheet.

A user agent stylesheet is an entirely different thing.

--
Spartanicus

[Stan Brown]

On Mon, 22 Aug 2005 19:53:43 GMT, Diane Wilson <di***@firelily.com>
wrote:

As much as I hate <font> tags, the average
user has a lot more flexibility to deal with under-sized type if a
page is written using <font size="small"> than if the page is written
with <span style="font-size: 8px;"> (or equivalent with proper external
style sheets). One resizes automatically when I select larger type
size from IE's menu bar; the other doesn't.

That's a completely false dichotomy. Leaving aside the issue of
classes versus inline styles, why not <span style="font-size:80%"> ?

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

[Quasimido CSS]

snip all

my own .02 centavos...

i've been doing heavy css in last few weeks.

but i decided to avoid relearning tables.

at this point. i think (partly intuitively) that advantages of css outweigh those of tables.

to the OP: i've had good results with full horizontal divs. top and bottom (which i ahvne't
used on any of my real pages)

teh intervening horiz divs are full iwdth "wrappers".

within *some of* those divs, i have inserted more divs! and inset a few divs into one of
those inserted divs. ha!
yep, much like nesting tabels.

but eventually i run into the real truth. html is not layout (eg, quark) or desktop
publishing (eg, word). (admittedly those don't produce 'fluid' layout, but their layout
details are much quicker to adjust)

html has no layout-editing flex.

so i also agree with those who say that teh much-vaunted css showcase pages work
due to simplicity and evasion:
huge (wasted white space) margins, lots of flowable content (wrapped text, but few large
images)

------
by good results with my pages, i mean that i can drag the edges of window rather
small (30% of maximiazed width), and content behaves decently fluidly.

how do i do it with so many images?
overflow attribute.

also as at least one person here mentoined: I use em and % to size things. and watch
the arithmetic. here and there tweaking with px makes sense (such as locating targets
or borders relative to images.)

unfortunately, my layout expectatoins have caused me greif... i've had to do so much
tweaking when i decide to reword text. and the connectoins within the content cannot fit
into 2 dimensions.

-------
one other layout thing. IE can't seem to handle more than one 100% hor wrapper. so i
just stack rows of divs. layout of Html file:
'header' hor100
wrapper100[
div50 div25 div25
div50 div50
div30 div30 div 35
]end wrapper100
optional 'footer' hor100

all divs are float left class
leftmost divs are clear left class
divs containing only images are overflow:hidden; class
my css has list of divs by % width
like this

..div3 {width:29.5%;}
..div35 {width:34.5%;}
#wrapper100 {width:99.5%;}

etc

note, one must be careful about "reusing" .divs! otherwise, use the once-only id type
divs:
#div35 {width:35%}

if you need multiple 35% that cannot have clear left (or magrin tweaks) in common?
then use
#a-div35, #b-div35 {width:35%}

then in style sectoin of html file, i list whichever divs need clear left
and second list of divs that need overflow hidden

then individual divs that need individual margin and padding tweaks. and..

I'm trying to develop some standard methods for flexible visual dividers. HR is not
reliably stylable. and i've used nbsp with some lines of H3 ("blank lines") to force
dividers.
(but i'm trying to kill my need for precise visual layout!)
---------
and i've got indents i can't overrride in some divs. i assume one of the outer wrapper divs
has caused the indent (margin, padding) Yet specifying margin and padding in the
particular inner div has no effect. (of course, complelty killing all styles removes all
indenting :-) )

-------

on my current luxury wishlist, is hi % opcatiy on a non scrolling {position:fixed; }
pagename div, but i'd like the div to slip under a scrolling menu (regular div) at top. yet,
z-index doesn't work.

regarding silly w3 standards?
1 not allowing block elements inside a href

how else are we to incorporate an img and caption into the same link!?!? this is
necessary for hover behavior. maybe i haven't stumbled across the solutoin.

2 excessive wordiness class="blah" style="border-style-top:whatever"
3 strong? b is faster.

[Leonard Blaisdell]

> regarding silly w3 standards?

1 not allowing block elements inside a href

how else are we to incorporate an img and caption into the same link!?!? this
is
necessary for hover behavior. maybe i haven't stumbled across the solutoin.
Use the title attribute in your HTML. Or I misunderstand you.
2 excessive wordiness class="blah" style="border-style-top:whatever"
Put the style in a rule that defines the class in a separate stylesheet.
Your markup will be dramatically shorter.
3 strong? b is faster.

Yes it is. But <b> is a stylistic element. <strong> is supposed to
convey another linguistic meaning to speech browsers now, and perhaps
other forms of browsers in the future (or maybe now).

leo

--
<http://web0.greatbasin.net/~leo/

[Matt Silberstein]

I am currently working on a complex web page where the layout is quite
uncertain. I have a series of elements A*, B*, and C* and we don't
know how we want to arrange them on the page. (Any of the current
thoughts are effectively tabular.) With tables I have to decide now
what to do with them and have to do an extensive re-write to alter the
layout. With CSS I can change the layout with a few keystrokes. This
allows me the freedom to show my customer variations and let them
easily pick (and change their mind). We can even provide end users
different versions and decide on a final form at the very last minute.
--
Matt Silberstein

Do in order to understand.

[Alan J. Flavell]

On Tue, 23 Aug 2005, Christoph Päper wrote:

Spartanicus schrieb:

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

Override mechanisms will, in general, break CSS conformance:
that's what they are for.

You are thoroughly confused about CSS conformance. CSS conformance
does not imply that author style suggestions will be rendered as
intended by the author,

Certainly not. We're talking about the user agent's rendering of the
*final* stylesheet, after the CSS-specified cascade has been actioned.
This will in general contain contributions from the user stylesheet,
some of which can override the author's contributions, of course.
There's never been any disagreement from me about *that*, no matter
how many times folks have tried to teach me what I was already taking
for granted about it.

But what I thought we were trying to discuss was the application of
any /user preferences/ implemented in the browser /outside/ of the
scope of the CSS specification.
Something like

* {min-font-size: 12px !important}

or, until that property exists in CSS, rather

* {-vendor-min-font-size: 12px !important}

in the /user stylesheet/ would indeed conformantly enforce a minimum
font size. One can argue whether the current browser implementations
do just that.
That's an interesting way of looking at that. I think I could live
with that interpretation.

What's still worrying me is the idea, which I seem to deduce from what
Spartanicus previously posted, that if some perverse user decided to
use the terms of "Additionally, UAs may offer other means to specify
user preferences" to redefine the pt unit as an inch, the inch unit
as a mm, to turn the colour wheel inside out and upside down,
interchange right and left, and suchlike extreme preferences, we are
meant to accept that the rendering would *still* be conformant to the
CSS specification, since it's only doing something which the CSS
specification said was allowed, and we have been lectured that it's:

|Clear enough English to me.

I find that deuced hard to swallow - if it were indeed so, then one
wonders why they'd have bothered to make those rather mild remarks
about "approximation" and "technical limitations" not being in
themselves grounds for non-compliance, if user preferences are meant
to have the ability to *completely redefine* the meaning of units, and
maybe even of properties, and still be within the scope of the
specification!
IMVHO, which is not set in stone, the settings in the browser GUI
are to be considered adjustments to the /user agent stylesheet/.
If that's all that they are, then, as you rightly deduce, those can't
have the last word - and so, in order to fulfil the accessibility
requirements, the user agent will need /additional/ override features,
which really will have the last word.

But normally, I think it's accepted that to satisfy this kind of
accessibility requirement, the ability to *disable* features of CSS is
sufficient - whereas, here, there seems to be discussion of
user-last-word preferences that would not just /disable/, but
/completely redefine/ the rules of CSS - the specific case here being
turning an absolute length unit, which should a fixed length as
determined by a ruler, into something relative and zoomable, and thus
in general no longer of the fixed length laid down by the
specification, and yet it's claimed that the result is still
specification-conformant. This is what has got me at a loss.
I just posted a question on www-style regarding this.

Would this be Message-ID: <43**************@tu-clausthal.de>
http://lists.w3.org/Archives/Public/...5Aug/0174.html ?

If so, then it's a bit low-key compared to the issue that I had with
the contribution by Spartanicus. Can a "user preference" cause a unit
(e.g pt) which the CSS specification says is an absolute length unit,
to *change* to something relative and zoom-able, and still claim to be
conformant to the CSS specification?

If it can do that, then maybe a user preference can say that the CSS
colour specification can be re-interpreted as I hinted above; or a
user preference can say that the text size property doesn't control
text size at all, but audio loudness. And a user preference can say
that the box model is the one that quirks mode implemented, instead of
the one that the CSS specification laid down - all of those
possibilities and *still* be CSS conformant, merely because of that
clause that said there can be user preferences? Boggle. Sorry, I find
that hard to grasp.

all the best

[david m wicker]

On Mon, 22 Aug 2005 17:47:27 GMT, Spartanicus
<in*****@invalid.invalid> wrote:

Alas some of the semi enlightened are trying to convince others that
they should not use tables for layout. Although theoretically correct,
the use of floats for creating a "layout" is fundamentally inappropriate
and an awful hack. In practice the method introduces many problems, both
for the author and (worse) for the user.

Unless you are truly skilled in creating a "CSS layout", you'd do your
visitors a favour by using a table for layout. CSS support in IE isn't
good enough to easily create CSS layouts that are as robust as HTML
tables.

Many "CSS layouts" using floats or absolute positioning are of the very
basic variety, or they introduce all sorts of problems that a comparable
table layout would not suffer from.

--
Spartanicus

For us css layout newbie's, where would you say there is a good layout
to start with, bearing in mind all the browser hacks etc that are
required in this 'art'?

__________________
Regards

David M Wicker
www.atf-uk.co.uk
__________________