newbie: header spanning two columns with left- and right-alignment

Els wrote:

ironcorona wrote:

HTML rule: inline elements (and a couple of block elements like h1 and
p) can't hold block elements.
CSS practice: assign inline or block to any block or inline element
and get away with it ;-)
Okay, I think I'm with you now. I assumed that if you had something like

p><span></span></p

and you set

span {display:block;}

that the browser would treat it exactly as if it were something like

p><div></div></p

and thus illegal because <p> contains a block element.

But that's not how it works?

Indeed :-)

Eureka!


--
Brian O'Connor (ironcorona)

Els wrote:

ironcorona wrote:
Els wrote:

so I think maybe Firefox is assuming a missing </h1> tag and then
putting the span on the next line (because <h1> is block).
No, in HTML, <span> is inline, so there is no </h1> missing.
But didn't you just set #Header span {display: block; float: right;} or
am I not keeping up?

That is CSS. You assign display:block to an inline element. A browser
will only assume closing tags missing if the HTML is wrong.
HTML rule: inline elements (and a couple of block elements like h1 and
p) can't hold block elements.
CSS practice: assign inline or block to any block or inline element
and get away with it ;-)

[snip]

Not correct according to the CSS2.1 specs afaics, and it seems only
Opera gets it right. (that is, of the 3 browsers I tested it in)
Damned Opera and their sticking to the standard

g

My experience is somewhat different to these observations. I am using
IE, Firefox and Opera (as Opera)

The reason that the floated h2 is not on the same line as h1 (as in
<h1><h2 style="float:right;">right text</h2>left text</h1> seems to have
to do with cumulating margins. Declaring margin-top:0 on <h2> renders
the two texts on the same line in all browsers.

Mozilla however removes the font-sizing and bolding of the <h1>

The rendering of a floated span inside a <p> or <h> element seems to be
the same in all three browsers. In all browsers, the span content is
inherently font sized and bolded as its parent element

The theory that is illegal for a block element to be contained in
certain block elements such as <p> and <h>, I understand, but what then
of the <img> element. This is an inline element but unless it can be
floated how is the image to be displayed part way down a para of length.

Louise

boclair wrote:

Els wrote:
ironcorona wrote:
Els wrote:

so I think maybe Firefox is assuming a missing </h1> tag and then
putting the span on the next line (because <h1> is block).
No, in HTML, <span> is inline, so there is no </h1> missing.
But didn't you just set #Header span {display: block; float: right;} or
am I not keeping up?

That is CSS. You assign display:block to an inline element. A browser
will only assume closing tags missing if the HTML is wrong.
HTML rule: inline elements (and a couple of block elements like h1 and
p) can't hold block elements.
CSS practice: assign inline or block to any block or inline element
and get away with it ;-)

[snip]

Not correct according to the CSS2.1 specs afaics, and it seems only
Opera gets it right. (that is, of the 3 browsers I tested it in)
Damned Opera and their sticking to the standard

g

My experience is somewhat different to these observations. I am using
IE, Firefox and Opera (as Opera)

The reason that the floated h2 is not on the same line as h1 (as in
h1><h2 style="float:right;">right text</h2>left text</h1> seems to have

Eh... <h2> inside <h1> ??
That's like... illegal :-)

I'll assume you meant our example of <h1>left text <span
style="float:right;">right text</span></h1>

to do with cumulating margins. Declaring margin-top:0 on <h2> renders

But we're talking about spans, not illegally nested h2 elements.

the two texts on the same line in all browsers.

Of course they do. You've put the floated block before the rest of the
text. That works. Our investigated example had the right floated text
after the regular text inside a <h1>.

--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/

Now playing: System Of A Down - Peephole

Els wrote:

boclair wrote:

Els wrote:
ironcorona wrote:
Els wrote:

Eh... <h2> inside <h1> ??
That's like... illegal :-)

Of course it is but see further for my point.

I'll assume you meant our example of <h1>left text <span
style="float:right;">right text</span></h1
You've put the floated block before the rest of the
text. That works.

Or something like
<h1>Some text long enough here <span style="float:right;">right
text</span> and some more text</h1>

Our investigated example had the right floated text
after the regular text inside a <h1>.

I got that and sorry for not making myself clear. I was moving along
was addressing the fact that the browsers do indeed handle all floated
elements in much the same way. This leaves me with the question is a
construct such as

<p>...<div style="float:right;">floated content</div> ........</p>

illegal in the same way as

<p>...<div>NOT floated</div> ........</p>

The reason I ask is because as soon as an element is floated it is
certainly interpreted as as a block element BUT **all floated elements
are out of the flow**.

One asks what is the difference between a block element (hn, p, div)
being floated and an inline element (span , img) being floated (now
being block). Is it consistent that they should be considered
differently? (I know what the validators say in html terms).

The same question applies to position absolute.

The browsers considered appear to interpret them the same, not that this
proves anything. Who knows how compliance will play out in future browsers.

In practical terms I cannot see the purpose of such constructs but
perhaps there is a point here in the general css context.

(Setting aside the caveat that css may not be enabled)

Louise

Hi Els, and others
thanks for your thoughts on all of this. I've taken your
suggestions and created a page which correctly does the left- and
right- alignment.

However there seems to be a problem with Internet Explorer (V6). I've
put a stripped-down page demonstrating the problem here:

http://www.nicorp.f9.co.uk/testleftright.html

What I see in IE6 is the following:

- the text in the 'banner' ('left-aligned txt/right-aligned text')
appears to be 'cut-off' at the top and botton edges. This displays
correctly in Firefox & Opera.

- The menu at the left encroaches the banner box - it's too high. This
may be connected with the fact that the box holding the banner seems
rather taller in IE6 than in the other browsers.

Can you give me any pointers to what's happening here and how I might
make this IE6-compatible?

Thanks very much
Jon N

jkn wrote:

- the text in the 'banner' ('left-aligned txt/right-aligned text')
appears to be 'cut-off' at the top and botton edges. This displays
correctly in Firefox & Opera.

Just remove the #Banner {line-height:14px;}, reduce the padding-top and
increase the padding-bottom to compensate. [something like 13px and 5px,
respectively, seems to be about right] I think this has something to do
with the IE box model.

- The menu at the left encroaches the banner box - it's too high.

You can remove the absolute padding from #Menu unless you need it for
some other reason. Put the <div id="menu"> before <div id="content">
and set both divs to float:left; In order for the two divs to line up
side by side you have to give them width values [because the default is
100% of the screen size] I suggest setting #Content {width:77%;
padding:2%;} and #Menu {width:16%; padding:1%;} [though you may need to
jigger this around to suit your own needs], all of which adds up to 99%
[remember that padding applies to both sides so in the case of #Content
the 2% padding is 4% overall. Taking into account padding-left and
padding-right] because there's issues with rounding or something that
doesn't allow 100%.

Hope it works for you

ps. you in the menu div you have two widths set; width:160px; and
width:172px;

--
Brian O'Connor (ironcorona)

ironcorona wrote:

You can remove the absolute padding from #Menu unless you need it for
some other reason. Put the <div id="menu"> before <div id="content"
and set both divs to float:left; In order for the two divs to line up
side by side you have to give them width values [because the default is
100% of the screen size] I suggest setting #Content {width:77%;
padding:2%;} and #Menu {width:16%; padding:1%;} [though you may need to
jigger this around to suit your own needs], all of which adds up to 99%
[remember that padding applies to both sides so in the case of #Content
the 2% padding is 4% overall. Taking into account padding-left and
padding-right] because there's issues with rounding or something that
doesn't allow 100%.

Ha, I forgot why I was telling you to do all that. This is so the menu
and content boxes line up. You can set their distance from the banner
by using the banner's margin-bottom.


--
Brian O'Connor (ironcorona)

Hi Brian
Thanks for this - I spotted the line-height thing and removed it
shortly after my posting. I still haven't found reference to the
specific characteristic of the IE box model that relates to what I'm
seeing, but life's too short...

I followed some of your other suggestions as well - putting the menu
div before the content div etc. I ended up changing most of my
dimensions to percents (ie. in the non-cut-down version of my page).
There are a few things I could tweak further but for my purposes it's a
case of diminishing returns...

One thing I wondered about relating to the line-height thing; Is there
any stated behaviour which should occur if the line-height is less than
the font-size?

Thanks again
Jon N

jkn wrote:

One thing I wondered about relating to the line-height thing; Is there
any stated behaviour which should occur if the line-height is less than
the font-size?

I don't know of any explicitly stated behaviour but from testing it out
it looks like the text just gets pushed out of it's containing box
[created by line height]. I guess it's the same thing that happens if
you set the child element to be bigger than it's parent element; it just
pushes it's way out. Like giving birth to an alien.


--
Brian O'Connor (ironcorona)