Hi,

There is a little problem with the header on the page I recently
converted from frames to proper HTML+CSS. The top part with the
navigation used to be the top frame but is now included via SSI. On a
broad screen, it looks good, but if you make the viewport small, the
slogan text in the middle overlaps with the navigation buttons.

http://www.weltladen-tuebingen.de/

I experimented with the following:
- put the slogan line between the floats. This results in the right
float being pushed down
- instead of position:relative and top:1em (they belong together,
obviously, the one does nothing without the other), tried margin-top: 1
em, but that shifts the floats down as well.

So what I want is that the slogan is nicely centered between the floats,
both vertically and horizontally, but that it doesn’t overlap with the
line below if the viewport gets small. I do not really understand why
clear:both on the line doesn’t work as expected. float: center; would
be the solution, but this doesn’t exist.

Any hints most welcome.

H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

David Stone schreef:
> In article <gcne0g$so3$1@newsserv.zdv.uni-tuebingen.de>,
> Hendrik Maryns <gtw37bn02@sneakemail.com> wrote:
>
>> Hi,
>>
>> There is a little problem with the header on the page I recently
>> converted from frames to proper HTML+CSS. The top part with the
>> navigation used to be the top frame but is now included via SSI. On a
>> broad screen, it looks good, but if you make the viewport small, the
>> slogan text in the middle overlaps with the navigation buttons.
>>
>> http://www.weltladen-tuebingen.de/
>>
>> I experimented with the following:
>> - put the slogan line between the floats. This results in the right
>> float being pushed down
>> - instead of position:relative and top:1em (they belong together,
>> obviously, the one does nothing without the other), tried margin-top: 1
>> em, but that shifts the floats down as well.
>>
>> So what I want is that the slogan is nicely centered between the floats,
>> both vertically and horizontally, but that it doesn’t overlap with the
>> line below if the viewport gets small. I do not really understand why
>> clear:both on the line doesn’t work as expected. float: center; would
>> be the solution, but this doesn’t exist.
>
> You could set a min-width so that, if the viewport is shrunk, you
> don't observe the behaviour (the user gets a horizontal scroll-bar
> instead)

Sorry, but doesn’t work (a scroll-bar, yes, but the text is still wrapped).

> As far as three things on the same line, you can have two left floats
> (#logo, #slogan) and leave the right content in the main flow.

Myes, but I’d like a big enough gap between the floats. And specifying
an explicit margin/padding will give similar problems with small viewports.

Thanks anyway, H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

Hendrik Maryns wrote:
>
> if you make the viewport small, the
> slogan text in the middle overlaps with the navigation buttons.
>
> http://www.weltladen-tuebingen.de/
>
> - instead of position:relative and top:1em (they belong together,
> obviously, the one does nothing without the other), tried margin-top: 1
> em, but that shifts the floats down as well.

Margins are subject to margin collapsing rules, which affects spacing of
elements around it. Margins and floats can be even trickier.

> I do not really understand why
> clear:both on the line doesn’t work as expected.

Relative positioning does not do what you probably think it does - it
offsets the element's position without affecting the other elements
around it. That's why the line doesn't shift down when the slogan line
wraps - it behaves as though slogan is staticly positioned.
http://brainjar.com/css/positioning/

Go back to static positioning on slogan, but try padding-top:1em instead
of margin-top, then you'll avoid the margin collapsing issues.

--
Berg

On Fri, 10 Oct 2008 15:19:43 +0200, Hendrik Maryns wrote:

> David Stone schreef:
>> In article <gcne0g$so3$1@newsserv.zdv.uni-tuebingen.de>,
>> Hendrik Maryns <gtw37bn02@sneakemail.com> wrote:
>>
>>> Hi,
>>>
>>> There is a little problem with the header on the page I recently
>>> converted from frames to proper HTML+CSS. The top part with the
>>> navigation used to be the top frame but is now included via SSI. On a
>>> broad screen, it looks good, but if you make the viewport small, the
>>> slogan text in the middle overlaps with the navigation buttons.
>>>
>>> http://www.weltladen-tuebingen.de/
>>>
>>> I experimented with the following:
>>> - put the slogan line between the floats. This results in the right
>>> float being pushed down
>>> - instead of position:relative and top:1em (they belong together,
>>> obviously, the one does nothing without the other), tried margin-top: 1
>>> em, but that shifts the floats down as well.
>>>
>>> So what I want is that the slogan is nicely centered between the floats,
>>> both vertically and horizontally, but that it doesn't overlap with the
>>> line below if the viewport gets small. I do not really understand why
>>> clear:both on the line doesn't work as expected. float: center;
>>> would be the solution, but this doesn't exist.
>>
>> You could set a min-width so that, if the viewport is shrunk, you don't
>> observe the behaviour (the user gets a horizontal scroll-bar instead)
>
> Sorry, but doesn't work (a scroll-bar, yes, but the text is still
> wrapped).
>
>> As far as three things on the same line, you can have two left floats
>> (#logo, #slogan) and leave the right content in the main flow.
>
> Myes, but I'd like a big enough gap between the floats. And
> specifying an explicit margin/padding will give similar problems with
> small viewports.
>
> Thanks anyway, H.

It looks like your min-width would have to be about 1100px to get it so
the title doesn't wrap - which is too wide for most people.

I would play with the position-top of #slogan so you are able to fit two
lines of text there, and then you can go with a min-width of about 900
(which is still too wide for many people). It's too bad your address has
such a long line in it - perhaps you can break that up into two?

Bergamot schreef:
> Hendrik Maryns wrote:
>> if you make the viewport small, the
>> slogan text in the middle overlaps with the navigation buttons.
>>
>> http://www.weltladen-tuebingen.de/
>>
>> - instead of position:relative and top:1em (they belong together,
>> obviously, the one does nothing without the other), tried margin-top: 1
>> em, but that shifts the floats down as well.
>
> Margins are subject to margin collapsing rules, which affects spacing of
> elements around it. Margins and floats can be even trickier.
>
>> I do not really understand why
>> clear:both on the line doesn’t work as expected.
>
> Relative positioning does not do what you probably think it does - it
> offsets the element's position without affecting the other elements
> around it. That's why the line doesn't shift down when the slogan line
> wraps - it behaves as though slogan is staticly positioned.
> http://brainjar.com/css/positioning/
>
> Go back to static positioning on slogan, but try padding-top:1em instead
> of margin-top, then you'll avoid the margin collapsing issues.

That’s a valuable suggestion. It starts looking stupid for a very small
viewport, but that is because then the last word is on a line /below/
the floats, and the centering is changed. A trick would be to make the
floats bigger, by splitting the first address line, as edgy suggested,
and putting some padding around the logo (I think I’ll try to scale it
up with Gimp, but that’s for later).

Thanks all, H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

Op 10-10-08 16:21 heeft Bergamot als volgt van zich laten horen:
> Hendrik Maryns wrote:
>> if you make the viewport small, the
>> slogan text in the middle overlaps with the navigation buttons.
>>
>> http://www.weltladen-tuebingen.de/
>>
>> - instead of position:relative and top:1em (they belong together,
>> obviously, the one does nothing without the other), tried margin-top: 1
>> em, but that shifts the floats down as well.
>
> Margins are subject to margin collapsing rules, which affects spacing of
> elements around it. Margins and floats can be even trickier.
>
>> I do not really understand why
>> clear:both on the line doesn’t work as expected.
>
> Relative positioning does not do what you probably think it does - it
> offsets the element's position without affecting the other elements
> around it. That's why the line doesn't shift down when the slogan line
> wraps - it behaves as though slogan is staticly positioned.
> http://brainjar.com/css/positioning/
>
> Go back to static positioning on slogan, but try padding-top:1em instead
> of margin-top, then you'll avoid the margin collapsing issues.

I’ve had a shot at it now, but there is still one problem: if the text
gets wrapped, the padding-top is no longer wanted. I want it to be
*vertically centered* between the two floats. Is there really no way to
achieve this?

H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
www.lieverleven.be
http://catb.org/~esr/faqs/smart-questions.html

On Sat, 11 Oct 2008 14:00:59 +0200 Hendrik Maryns <ialpjx302@sneakemail.com> wrote:

| I?ve had a shot at it now, but there is still one problem: if the text
| gets wrapped, the padding-top is no longer wanted. I want it to be
| *vertically centered* between the two floats. Is there really no way to
| achieve this?

You have taller things on one or the other side of something, or both, and
you want the shorter thing to be aligned vertically so the middle match up.
You can't just code some padding in a box because you don't know how tall
these things will be rendered in the browser.

I've seen quite a number of hacks on achieving this by many advocates who
(often strongly) urge people to avoid using markup tables to do layouts.
None of them work completely or correctly.

Layouts using tables is "wrong" but it still works. CSS2 has display modes
to mimic tables but this is not widely implemented (reportedly unsupported
in IE). Where I find I cannot achieve the desired layout in CSS, I revert
back to the old time hack of using tables.

--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

Op 23-11-08 21:59 heeft phil-news-nospam@ipal.net als volgt van zich
laten horen:
> On Sat, 11 Oct 2008 14:00:59 +0200 Hendrik Maryns <ialpjx302@sneakemail.com> wrote:
>
> | I?ve had a shot at it now, but there is still one problem: if the text
> | gets wrapped, the padding-top is no longer wanted. I want it to be
> | *vertically centered* between the two floats. Is there really no way to
> | achieve this?
>
> You have taller things on one or the other side of something, or both, and
> you want the shorter thing to be aligned vertically so the middle match up.
> You can't just code some padding in a box because you don't know how tall
> these things will be rendered in the browser.
>
> I've seen quite a number of hacks on achieving this by many advocates who
> (often strongly) urge people to avoid using markup tables to do layouts.
> None of them work completely or correctly.
>
> Layouts using tables is "wrong" but it still works. CSS2 has display modes
> to mimic tables but this is not widely implemented (reportedly unsupported
> in IE). Where I find I cannot achieve the desired layout in CSS, I revert
> back to the old time hack of using tables.

Hey, thanks for your input. I suppose this is something one should
complani about at w3c, isn’t it? But I can barely imagine they aren’t
aware of this deficit already.

H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
www.lieverleven.be
http://catb.org/~esr/faqs/smart-questions.html

phil-news-nospam@ipal.net wrote:
>
> CSS2 has display modes
> to mimic tables but this is not widely implemented

Actually, it *is* widely implemented - by the mozilla-based browsers,
Opera, and KHTML/Webkit - and has been for quite a while.

> (reportedly unsupported in IE).

Not reportedly - it's a fact. This may persuade you to avoid using
display:table, but I think it depends on the project. I'd just as soon
let IE use some fallback.

--
Berg

Hendrik Maryns schrieb:
> Op 23-11-08 21:59 heeft phil-news-nospam@ipal.net als volgt van zich
> laten horen:
>> Layouts using tables is "wrong" but it still works. CSS2 has display modes
>> to mimic tables but this is not widely implemented (reportedly unsupported
>> in IE). Where I find I cannot achieve the desired layout in CSS, I revert
>> back to the old time hack of using tables.
>
> Hey, thanks for your input. I suppose this is something one should
> complani about at w3c, isn’t it? But I can barely imagine they aren’t
> aware of this deficit already.

Why do you think that complaining at _W3C_ is the appropriate thing when
implementation support in _IE_ is missing?

--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

Hendrik Maryns wrote:
> Op 23-11-08 21:59 heeft phil-news-nospam@ipal.net als volgt van zich
> laten horen:
>
>> Where I find I cannot achieve the desired layout in CSS, I revert
>> back to the old time hack of using tables.
>>
> Hey, thanks for your input. I suppose this is something one should
> complani about at w3c, isn’t it? But I can barely imagine theyaren’t
> aware of this deficit already.
>

http://www.w3.org/Style/CSS/current-work#layout

Johannes Koch schreef:
> Hendrik Maryns schrieb:
>> Op 23-11-08 21:59 heeft phil-news-nospam@ipal.net als volgt van zich
>> laten horen:
>>> Layouts using tables is "wrong" but it still works. CSS2 has display
>>> modes
>>> to mimic tables but this is not widely implemented (reportedly
>>> unsupported
>>> in IE). Where I find I cannot achieve the desired layout in CSS, I
>>> revert
>>> back to the old time hack of using tables.
>>
>> Hey, thanks for your input. I suppose this is something one should
>> complani about at w3c, isn’t it? But I can barely imagine they aren’t
>> aware of this deficit already.
>
> Why do you think that complaining at _W3C_ is the appropriate thing when
> implementation support in _IE_ is missing?

I don’t. I suppose I misread the post and frankly, I do not care too
much about IE users. So where can I read up on this table mimicking CSS?

TIA, H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

dorayme schreef:
> In article <ggcg7k0ehe@news1.newsguy.com>, phil-news-nospam@ipal.net
> wrote:
>
>> On Sat, 11 Oct 2008 14:00:59 +0200 Hendrik Maryns <ialpjx302@sneakemail.com>
>> wrote:
>>
>> | I?ve had a shot at it now, but there is still one problem: if the text
>> | gets wrapped, the padding-top is no longer wanted. I want it to be
>> | *vertically centered* between the two floats. Is there really no way to
>> | achieve this?
>>
>> You have taller things on one or the other side of something, or both, and
>> you want the shorter thing to be aligned vertically so the middle match up.
>> You can't just code some padding in a box because you don't know how tall
>> these things will be rendered in the browser.
>>
>> I've seen quite a number of hacks on achieving this by many advocates who
>> (often strongly) urge people to avoid using markup tables to do layouts.
>> None of them work completely or correctly.
>>
>> Layouts using tables is "wrong" but it still works. CSS2 has display modes
>> to mimic tables but this is not widely implemented (reportedly unsupported
>> in IE). Where I find I cannot achieve the desired layout in CSS, I revert
>> back to the old time hack of using tables.
>
> Indeed. Sometimes though, where you cannot achieve what you want without
> tables, it can spur you to consider whether what you want to achieve is
> more worthwhile than something even better that does not have such
> demanding requirements.
>
> Just took a look at OP's site. He obviously wants to preserve an ability
> for the users browser to be quite narrow. But he should consider a
> min-width of 700 or 800px, not only because it eases the problem he is
> facing but because narrow browser widths with this design and bigger
> than average text is a fairly ugly result at the top banner...

The OP being me, I hope you can clear me up: by ‘bigger than average
text’, do you mean the slogan only, or the body text? AFAIR, I didn’t
specify a body text size (though my collaborator might have done so).

> Why not bite the bullet and make the slogan (is it just a slogan?) an
> image. The size of the image will be big enough to not cause
> inconvenience to people liking bigger text. It is not as if it is
> something anyone will be reading in a studied way.

True :-)

> Something like:
>
> <div id="header">
> <div id="logo"><img src="bild/logo.png" alt="Logo" height="105"
> width="157"></div>
> <div id="adresse"><strong>Hier finden Sie uns:</strong><br>
> Aktionszentrum Arme Welt e.V.<br>
> Weltladen <br>
> Lange Gasse 64<br>
> 72070 Tübingen<br>
> Tel.: 07071/23062</div>
> <div id="slogan"><img src="bild/slogan.png" alt="Ein Stück Welt von
> Morgen" height="105" width="300"></div>
> <div id="linie-oben">
> <hr>
>
> and
>
> #logo {
> float: left;
> }
>
> #adresse {
> float: right;
> text-align: right;
> }
>
> #slogan {
> font-weight: bold;
> font-style: italic;
> text-align: center;
>
> }

I suppose you leave this in for the case the alt text is shown?

Thanks, H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

Hendrik Maryns schrieb:
> So where can I read up on this table mimicking CSS?

In the CSS 2.1 spec, section 17.

--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

Johannes Koch schreef:
> Hendrik Maryns schrieb:
>> So where can I read up on this table mimicking CSS?
>
> In the CSS 2.1 spec, section 17.

Right. I was hoping for more of a cookbook-like page, but if nothing
s, I’ll have to fight through that text.

H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

On Mon, 24 Nov 2008 15:07:20 +0100 Hendrik Maryns <gtw37bn02@sneakemail.com> wrote:
| Johannes Koch schreef:
|> Hendrik Maryns schrieb:
|>> So where can I read up on this table mimicking CSS?
|>
|> In the CSS 2.1 spec, section 17.
|
| Right. I was hoping for more of a cookbook-like page, but if nothing
| s, I?ll have to fight through that text.

Actually, I find the spec easier to read than most of the online material out
there. One exception is this reference: http://xhtml.com/en/css/reference/
I use it because it is well organized. But it lacks detail and I sill need to
access the spec for genuine semantics. I find tutorials and how-to guides to
be the worst, mostly because their examples don't really include layout issues
I encounter (what they do include are the simpler things I can figure out).

--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

On Sun, 23 Nov 2008 16:06:20 -0600 Bergamot <bergamot@visi.com> wrote:
|
| phil-news-nospam@ipal.net wrote:
|>
|> CSS2 has display modes
|> to mimic tables but this is not widely implemented
|
| Actually, it *is* widely implemented - by the mozilla-based browsers,
| Opera, and KHTML/Webkit - and has been for quite a while.

If you figure it by count of implementations, then the majority has it.
If you figure it by count of users with implementations in hand, then the
majority is slim at best, and likely not quite a majority. For websites
targeted to the open source community, I'd use the display:table* styles.
For websites targeted to the general population masses, I would not, and
thus for many layout issues I would have to revert to markup tables.


|> (reportedly unsupported in IE).
|
| Not reportedly - it's a fact. This may persuade you to avoid using
| display:table, but I think it depends on the project. I'd just as soon
| let IE use some fallback.

What I loath even more than using markup tables is using browser detection
to modify content. If I'm going to have tables in there for some browsers,
it saves my time just to go ahead and leave it that way for all, since they
do work.

There is the principle of that which is style should be specified as style,
and that which is content should be specified as content. This principle
would avoid doing any layout or style in HTML. The sad fact is that CSS 2.1
is simply NOT mature enough to achieve this lofty goal. There are still many
cases where desired layout and style cannot be achieved without adding extra
<div> or <span> elements to the HTML. A simplistic example is a rainbow of
border colors. You need extra <div> elements nested to do that, and style
each with a different color. Once CSS has a means to let style do anything
that could be done with as many elements, and apply it to exactly one element
via one ID or one class, then we may have something. But then this would be
a box model that can contain an infinite number of layers, instead of the fixed
set of margin, border, padding. CSS is still weak, and has not kept up with
the imaginations of web designers.

--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

On 2008-11-25, phil-news-nospam@ipal.net <phil-news-nospam@ipal.net> wrote:
[...]
> There is the principle of that which is style should be specified as
> style, and that which is content should be specified as content. This
> principle would avoid doing any layout or style in HTML. The sad fact
> is that CSS 2.1 is simply NOT mature enough to achieve this lofty
> goal. There are still many cases where desired layout and style cannot
> be achieved without adding extra <div> or <span> elements to the HTML.
> A simplistic example is a rainbow of border colors. You need extra
> <div> elements nested to do that, and style each with a different
> color. Once CSS has a means to let style do anything that could be
> done with as many elements, and apply it to exactly one element via
> one ID or one class, then we may have something.

But to do that would bloat CSS unacceptably.

A few simple styling rules PLUS being able to change the document tree
is very powerful. If you can't touch the tree there is always going to
be much less you can do with the stylesheets. You can keep adding
properties to CSS to do different individual things, to try to keep up
with the imaginations of designers, but that would quickly get out of
hand (although that doesn't stop people suggesting it).

More powerful stylesheet languages can transform the tree so the problem
disappears. But those were rejected for CSS because they make
progressive rendering much harder. You can read about this in Hakon Wium
Lie's thesis (http://people.opera.com/howcome/2006/phd/).

> But then this would be a box model that can contain an infinite number
> of layers, instead of the fixed set of margin, border, padding. CSS
> is still weak, and has not kept up with the imaginations of web
> designers.

CSS _is_ weak compared to a transformation language. This means you can
either (in rough order of preference):

1. Compromise the design.
2. Use extra divs and spans anyway.
3. Use Flash or something equally horrible.
4. Add hundreds of fabulous new properties to CSS until it can do
everything you can think of.

Somewhere between 1 and 2 is usually the best advice. A couple of extra
divs aren't going to hurt anyone, and fancy overconstrained designs
usually create a lot of other problems anyway.

On Tue, 25 Nov 2008 17:01:30 -0600 Ben C <spamspam@spam.eggs> wrote:

| On 2008-11-25, phil-news-nospam@ipal.net <phil-news-nospam@ipal.net> wrote:
| [...]
|> There is the principle of that which is style should be specified as
|> style, and that which is content should be specified as content. This
|> principle would avoid doing any layout or style in HTML. The sad fact
|> is that CSS 2.1 is simply NOT mature enough to achieve this lofty
|> goal. There are still many cases where desired layout and style cannot
|> be achieved without adding extra <div> or <span> elements to the HTML.
|> A simplistic example is a rainbow of border colors. You need extra
|> <div> elements nested to do that, and style each with a different
|> color. Once CSS has a means to let style do anything that could be
|> done with as many elements, and apply it to exactly one element via
|> one ID or one class, then we may have something.
|
| But to do that would bloat CSS unacceptably.

The bloat would only be if you use such a feature to create an excess of
layers. If you want to create 200 layers of borders, each with a unique
color, of course you have to provide 200 colors, in the correct order.
Doing this without an integral feature in CSS means you have to create
200 CSS selectors AND 200 nested elements in HTML. That's MORE bloat.

If you want to argue that 200 layers of borders is bloat, I would agree.
But I don't see making CSS know how to handle this is bloat.


| A few simple styling rules PLUS being able to change the document tree
| is very powerful. If you can't touch the tree there is always going to
| be much less you can do with the stylesheets. You can keep adding
| properties to CSS to do different individual things, to try to keep up
| with the imaginations of designers, but that would quickly get out of
| hand (although that doesn't stop people suggesting it).

IMHO, the document tree should not be changed, and ideally need not be
changed.

One component of extending CSS would be to provide for multiple borders.
For example:

..rainbowborder {
border: 4px solid #f00, 4px solid #0f0, 4px solid #00f;
}

This would simply imply 3 borders on one element. No document tree change
is needed. The total border size is 12. And this is merely a simple and
convenient change. The same should be done with other rules where it would
accomplish something.


| More powerful stylesheet languages can transform the tree so the problem
| disappears. But those were rejected for CSS because they make
| progressive rendering much harder. You can read about this in Hakon Wium
| Lie's thesis (http://people.opera.com/howcome/2006/phd/).

NOT doing so makes web development harder.

NOT doing so leads people to making layouts in the markup (whether that is
by using table elements, or by adding more and more elements).

NOT doing so keeps us from reaching the point where style and markup are
truly separate.


|> But then this would be a box model that can contain an infinite number
|> of layers, instead of the fixed set of margin, border, padding. CSS
|> is still weak, and has not kept up with the imaginations of web
|> designers.
|
| CSS _is_ weak compared to a transformation language. This means you can
| either (in rough order of preference):
|
| 1. Compromise the design.

Unacceptable.

| 2. Use extra divs and spans anyway.

Unacceptable.

| 3. Use Flash or something equally horrible.

Unacceptable. Any form of client side programming/scripting is unacceptable.

| 4. Add hundreds of fabulous new properties to CSS until it can do
| everything you can think of.

Not what I suggested. I suggest a few (generalized) ideas, not hundreds.
I suggest some extensions on some existing rules (see border example above).

A generalized approach would be a virtual document tree. This would be an
expression in CSS that specifies an extension of the document tree branch to
which the rules apply. The document tree itself would be unchanged in terms
of its delivery by HTML/XHTML/XML/etc or construction by ECMAScript/JavaScript.
An implementation (of a browser) may choose to actually reconstruct the tree
internally, or choose to refer to a separate branch extension that includes a
back reference (where the branch extension ends, it refers back to the part
of the tree that referred to it, much like a function call).

The rule applied to the selected elements would add virtual elements, which
can then be styled in place, or styled separately by element or class selection.

Here is an example. The syntax here is ad-hoc and NOT specifically what I am
suggesting. Focus on the semantics. The whole idea is open to tweaking and
other changes, including how the syntax should be done.

..mybox {
inside-div: {
position: relative;
top: 4px;
left: 4px;
background-color: #cccccc;
}
inside-div: {
position: relative;
top: 0px;
left: 0px;
border: 1px solid #000000;
background-color: #eeee00;
}
}

A generalized form of rules would be:
before-(element-name)
inside-(element-name)
after-(element-name)
These rules can then specify their own set of rules like show above, or can
specify a referenced class to use another selector elsewhere, or both.
In the above example 2 divs are added inside the selected element, but not
inside each other. To make 2 divs inside each other, nest them:

..myclass {
...
inside-div: {
...
inside-div: {
...
}
...
}
...
}

The form of implied element rules that begin with "before" and "after" would
place the implied elements before the selected element, or after it, in the
order given if more than one.

Cascading multiple selectors means using the implied elements only from ONE
of the rules, in the same order as other rules are overridden.


| Somewhere between 1 and 2 is usually the best advice. A couple of extra
| divs aren't going to hurt anyone, and fancy overconstrained designs
| usually create a lot of other problems anyway.

I strongly disagree.

What the extra divs will hurt is the proper separation of markup and style.
Proper separation will allow markup to be created entire oblivious to what
the style will be. Proper separation will allow style to be changed to any
design without having to make any change whatsoever to the document.

I will continue to tell people to go ahead and use table elements in document
markup until such time as the definition of separation of markup and style is
complete (e.g. that CSS can do what would otherwise require adding elements to
the document to do). As long as I have to tell people to "add a div" then I
know the separation of markup and style is not complete, and thus will have no
qualms about _also_ telling them "go ahead and use table elements in markup"
because both suggestions are essentiall the same violation of the principle
(that is not yet realized).

--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

On 2008-11-28, phil-news-nospam@ipal.net <phil-news-nospam@ipal.net> wrote:
> On Tue, 25 Nov 2008 17:01:30 -0600 Ben C <spamspam@spam.eggs> wrote:
>
>| On 2008-11-25, phil-news-nospam@ipal.net <phil-news-nospam@ipal.net> wrote:
>| [...]
>|> There is the principle of that which is style should be specified as
>|> style, and that which is content should be specified as content. This
>|> principle would avoid doing any layout or style in HTML. The sad fact
>|> is that CSS 2.1 is simply NOT mature enough to achieve this lofty
>|> goal. There are still many cases where desired layout and style cannot
>|> be achieved without adding extra <div> or <span> elements to the HTML.
>|> A simplistic example is a rainbow of border colors. You need extra
>|> <div> elements nested to do that, and style each with a different
>|> color. Once CSS has a means to let style do anything that could be
>|> done with as many elements, and apply it to exactly one element via
>|> one ID or one class, then we may have something.
>|
>| But to do that would bloat CSS unacceptably.
>
> The bloat would only be if you use such a feature to create an excess of
> layers. If you want to create 200 layers of borders, each with a unique
> color, of course you have to provide 200 colors, in the correct order.
> Doing this without an integral feature in CSS means you have to create
> 200 CSS selectors AND 200 nested elements in HTML. That's MORE bloat.
>
> If you want to argue that 200 layers of borders is bloat, I would agree.
> But I don't see making CSS know how to handle this is bloat.

For this example you have a point, and if there were much demand for
rainbow borders, they might be worth putting in CSS3. (In fact they
probably have been).

Curved borders are something you can do with CSS2.1 and extra elements.
But you might need up to 8 extra elements and it's a lot of trouble for
a popular feature. So those are a good addition to CSS3 (and already
partially implemented in Firefox).

But if something's easy to do with just one or two extra divs and isn't
also seriously popular then I don't think it should be added to CSS3
because that will make CSS3 too big.

A document bloated by a few extra elements is bad, but not as bad as a
specification bloated by hundreds of extra rules to make up for its
inherent lack of combinative power.

>| A few simple styling rules PLUS being able to change the document tree
>| is very powerful. If you can't touch the tree there is always going to
>| be much less you can do with the stylesheets. You can keep adding
>| properties to CSS to do different individual things, to try to keep up
>| with the imaginations of designers, but that would quickly get out of
>| hand (although that doesn't stop people suggesting it).
>
> IMHO, the document tree should not be changed, and ideally need not be
> changed.

Well, OK, but you have to think about where that would end. Today you
can think of rainbow borders, but if you added properties so that you
could do anything anybody could reasonably want to do without changing
the tree, how many properties would you need?

Assume for this experiment that you cannot change CSS into a
"transformation-based language". All you can do is stuff in more
properties.

> One component of extending CSS would be to provide for multiple borders.
> For example:
>
> .rainbowborder {
> border: 4px solid #f00, 4px solid #0f0, 4px solid #00f;
> }
>
> This would simply imply 3 borders on one element. No document tree change
> is needed. The total border size is 12. And this is merely a simple and
> convenient change. The same should be done with other rules where it would
> accomplish something.

They are proposing exactly that for background-image in CSS3. You can
have as many background images as you like, clip and position them all
differently, and they all sit on top of each other.

And yes, that would be a fine way to do rainbow borders in CSS. Check
the spec-- they may already be there in CSS3.

>| More powerful stylesheet languages can transform the tree so the problem
>| disappears. But those were rejected for CSS because they make
>| progressive rendering much harder. You can read about this in Hakon Wium
>| Lie's thesis (http://people.opera.com/howcome/2006/phd/).
>
> NOT doing so makes web development harder.
>
> NOT doing so leads people to making layouts in the markup (whether that is
> by using table elements, or by adding more and more elements).
>
> NOT doing so keeps us from reaching the point where style and markup are
> truly separate.

I agree with all three of those things.

>|> But then this would be a box model that can contain an infinite number
>|> of layers, instead of the fixed set of margin, border, padding. CSS
>|> is still weak, and has not kept up with the imaginations of web
>|> designers.
>|
>| CSS _is_ weak compared to a transformation language. This means you can
>| either (in rough order of preference):
>|
>| 1. Compromise the design.
>
> Unacceptable.
>
>| 2. Use extra divs and spans anyway.
>
> Unacceptable.
>
>| 3. Use Flash or something equally horrible.
>
> Unacceptable. Any form of client side programming/scripting is unacceptable.
>
>| 4. Add hundreds of fabulous new properties to CSS until it can do
>| everything you can think of.
>
> Not what I suggested. I suggest a few (generalized) ideas, not hundreds.
> I suggest some extensions on some existing rules (see border example above).
>
> A generalized approach would be a virtual document tree. This would be an
> expression in CSS that specifies an extension of the document tree branch to
> which the rules apply. The document tree itself would be unchanged in terms
> of its delivery by HTML/XHTML/XML/etc or construction by ECMAScript/JavaScript.

Yes, with that you could do everything, and that approach would have
many advantages.

But it was rejected because of the progressive rendering problem. All
the same I don't find that perfectly convincing-- you could still do
some progressive rendering, and even as things stand today, progressive
rendering already consists of complete reflow in a lot of cases.

> An implementation (of a browser) may choose to actually reconstruct the tree
> internally, or choose to refer to a separate branch extension that includes a
> back reference (where the branch extension ends, it refers back to the part
> of the tree that referred to it, much like a function call).
>
> The rule applied to the selected elements would add virtual elements, which
> can then be styled in place, or styled separately by element or class selection.
>
> Here is an example. The syntax here is ad-hoc and NOT specifically what I am
> suggesting. Focus on the semantics. The whole idea is open to tweaking and
> other changes, including how the syntax should be done.
>
> .mybox {
> inside-div: {
> position: relative;
> top: 4px;
> left: 4px;
> background-color: #cccccc;
> }
> inside-div: {
> position: relative;
> top: 0px;
> left: 0px;
> border: 1px solid #000000;
> background-color: #eeee00;
> }
> }
>
> A generalized form of rules would be:
> before-(element-name)
> inside-(element-name)
> after-(element-name)
> These rules can then specify their own set of rules like show above, or can
> specify a referenced class to use another selector elsewhere, or both.
> In the above example 2 divs are added inside the selected element, but not
> inside each other. To make 2 divs inside each other, nest them:
>
> .myclass {
> ...
> inside-div: {
> ...
> inside-div: {
> ...
> }
> ...
> }
> ...
> }
>
> The form of implied element rules that begin with "before" and "after" would
> place the implied elements before the selected element, or after it, in the
> order given if more than one.

A limited form of that does already exist with the :before and :after
pseudo-elements (CSS2.1). We also have anonymous blocks and table boxes
which add boxes to the box-tree for layout purposes without affecting
the DOM tree.

But what you are describing is what Lie calls a "transformation-based
style sheet language" and which he says he didn't want to use for CSS.

The most interesting thing about the thesis though is the survey of
other stylesheet languages.

> Cascading multiple selectors means using the implied elements only
> from ONE of the rules, in the same order as other rules are
> overridden.
>
>
>| Somewhere between 1 and 2 is usually the best advice. A couple of
>extra | divs aren't going to hurt anyone, and fancy overconstrained
>designs | usually create a lot of other problems anyway.
>
> I strongly disagree.
>
> What the extra divs will hurt is the proper separation of markup and
> style. Proper separation will allow markup to be created entire
> oblivious to what the style will be. Proper separation will allow
> style to be changed to any design without having to make any change
> whatsoever to the document.

I can't argue with the principle but the tools we've got just aren't
suited to that job. It's like trying to build a wall out of icing sugar.

That's why I say accept the compromise. If CSS were transformation-based
there would be no compromise.

> I will continue to tell people to go ahead and use table elements in
> document markup until such time as the definition of separation of
> markup and style is complete (e.g. that CSS can do what would
> otherwise require adding elements to the document to do). As long as
> I have to tell people to "add a div" then I know the separation of
> markup and style is not complete, and thus will have no qualms about
> _also_ telling them "go ahead and use table elements in markup"
> because both suggestions are essentiall the same violation of the
> principle (that is not yet realized).

Yes I'd go along with that. Although for me it's a matter of degree not
of principle. The real harm is not in breaking a rule, but in breaking
it _badly_. For me a couple of extra divs is OK, but nested tables and
<font>s everywhere isn't.