Height of Horizontal Menu

[Lachlan Hunt]

Hi,
In the "Firefox 5 Minute Challenge" [1] that I'm trying to write the
stylesheet for, the height of language bar needs controlled by the
height of the content, so that if the window is not wide enough, and the
menu items wrap around to the next line, the height of the <ul>
increases, and thus the background stays behind the list items.

The height has been set using min-height for for those that support it
and 'height' for IE only. It works the way I want it in IE and Opera.
But, it does not work in Firefox. I'm not sure whether Firefox's or
Opera's rendering is correct (I know IE's isn't, because I had to add
the hack for it), but does anyone know how I can get it to work in
Firefox also?

[1] http://lachy.id.au/dev/mozilla/firef...nute/challenge

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://SpreadFirefox.com/ Igniting the Web

[Lauri Raittila]

in comp.infosystem s.www.authoring.stylesheets, Lachlan Hunt wrote:

[floats in container, container has background]

The height has been set using min-height for for those that support it
and 'height' for IE only. It works the way I want it in IE and Opera.
Not on Opera either, at least 7.6p2
but does anyone know how I can get it to work in Firefox also?
1) #language li, #language a { display: inline; } /* instead current */
Sort out problem with PDF image differently. Would be easy with
display:inline-block or inline-table, but FF dont support them. You could
float the pdf thing, and use inline for others.
2)
Set background for body, instead of ul. Then set background for
#conteiner. This has side effect of overriding users default background.
3) ul:after {display:block; content:"";clea r:both}
Most likely don't work on FF, does in Opera.
4) wrap ul in div, have <div style="clear:bo th">&nbsp;</div> under ul.
(there is bug in Gecko that it don't get empty elements)
5)
Add additional, empty list item, that will have clear:both etc. Not good
idea.
There might be other ways too, but I think one of these should do.
[1] http://lachy.id.au/dev/mozilla/firef...nute/challenge

Well, the problem with wrapping language bar background is very minor
compared to other, extreamily serious problems, when looking it in narrow
eaboug window to get lan bar wrap. At least I have my text zoom at
smallest (11px).

Only tested stuff in Opera.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[Lachlan Hunt]

Lauri Raittila wrote:

in comp.infosystem s.www.authoring.stylesheets, Lachlan Hunt wrote:

[floats in container, container has background]

The height has been set using min-height for for those that support it
and 'height' for IE only. It works the way I want it in IE and Opera.

Not on Opera either, at least 7.6p2

I tested it in Opera 7.54 and it works. I couldn't find where to get
7.6p2, but it's obviously an upgrade and maybe they've fixed a bug with
it, which would mean Opera 7.54's current behaviour is likely to be
incorrect. I had a feeling it was, but wasn't totally sure.

but does anyone know how I can get it to work in Firefox also?

1) #language li, #language a { display: inline; } /* instead current */
Sort out problem with PDF image differently. Would be easy with
display:inline-block or inline-table, but FF dont support them. You could
float the pdf thing, and use inline for others.

Yes, I wanted to use inline-block. I knew it would be perfect, but had
to face reality when I realised neither IE or firefox has implemented it.

I considered using inline, but then it's there's spaces between each
<li> which get rendered as a single space. I used the floats to avoid
that problem, so there is no gap.
2)
Set background for body, instead of ul. Then set background for
#container. This has side effect of overriding users default background.
That may be the best option, I'll think about that.
3) ul:after {display:block; content:"";clea r:both}
Most likely don't work on FF, does in Opera.
Definately won't work in IE, and I'd prefer to have very few, if any,
user-agent specific CSS. Ideally, I would be able to remove the 1 hack
that's in there at the moment and use the same CSS for all.
4) wrap ul in div, have <div style="clear:bo th">&nbsp;</div> under ul.
(there is bug in Gecko that it don't get empty elements)

I prefer to avoid extraneous elements.

[1] http://lachy.id.au/dev/mozilla/firef...nute/challenge

Well, the problem with wrapping language bar background is very minor
compared to other, extreamily serious problems, when looking it in narrow
eaboug window to get lan bar wrap. At least I have my text zoom at
smallest (11px).

Yes, I know it's minor at the moment, but if I get more translations,
and therefore it doesn't require such a small window to wrap, then it
will. But you're right, compared with the other issues I'm still yet to
work on, it is fairly minor.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://SpreadFirefox.com/ Igniting the Web

[Lauri Raittila]

in comp.infosystem s.www.authoring.stylesheets, Lachlan Hunt wrote:

Lauri Raittila wrote:

in comp.infosystem s.www.authoring.stylesheets, Lachlan Hunt wrote:

[floats in container, container has background]

I couldn't find where to get [Opera] 7.6p2,
http://www.google.com/search?q=7.6p2+opera
but it's obviously an upgrade and maybe they've fixed a bug with
it, which would mean Opera 7.54's current behaviour is likely to be
incorrect. I had a feeling it was, but wasn't totally sure.
I had not seen the bug on 7.54, and it can be only temporary bug, as this
has worked correctly in 7 series...

but does anyone know how I can get it to work in Firefox also?

1) #language li, #language a { display: inline; } /* instead current */
Sort out problem with PDF image differently. Would be easy with
display:inline-block or inline-table,

Yes, I wanted to use inline-block. I knew it would be perfect, but had
to face reality when I realised neither IE or firefox has implemented it.

In IE it works on inline stuff (don't ask why), so
display:inline; display:inline-block;display:i nline-table;

Would give quite good results, as it would only look a bit different
in FF...
I considered using inline, but then it's there's spaces between each
<li> which get rendered as a single space. I used the floats to avoid
that problem, so there is no gap.
What harm does that gap do? You need some white space between the links
anyway. And you can of course get rid of that whitespace. Just remove all
spaces and tabs between tags. (you can leave linebreaks)

3) ul:after {display:block; content:"";clea r:both}
Most likely don't work on FF, does in Opera.

Definately won't work in IE, and I'd prefer to have very few, if any,
user-agent specific CSS.

It is not user agent specific. Some browsers just don't support it...

That is what cascading is all about.
Ideally, I would be able to remove the 1 hack
that's in there at the moment and use the same CSS for all.

Tricker quirks mode, and hope there is nothing that will broke? (IE had
bug that does what you want...)

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[Lachlan Hunt]

Lauri Raittila wrote:

In IE it works on inline stuff (don't ask why), so
display:inline; display:inline-block;display:i nline-table;
That could be a good idea because it uses a fallback mechansim, rather
than a specific browser hack. I'll think about using something like that.

I considered using inline, but then it's there's spaces between each
<li> which get rendered as a single space. I used the floats to avoid
that problem, so there is no gap.

What harm does that gap do?

It creates non-clickable regions between the links, which I dislike in
navigation bars.
You need some white space between the links anyway.
No, there just needs to be sufficient padding to make the links large
enough to be easily targetted with the cursor
And you can of course get rid of that whitespace. Just remove all
spaces and tabs between tags. (you can leave linebreaks)

That won't work since all white space characters in HTML including
spaces tabs and line breaks are collapsed to a single space.

...I'd prefer to have very few, if any, user-agent specific CSS.

It is not user agent specific. Some browsers just don't support it...

I didn't mean user agent specific as being proprietary, I just meant
user agent specific, in that hacks, although they're valid, are usually
written for just one browser. There's a difference between writing a
hack and using a fallback mechanism, which is acceptable.

Ideally, I would be able to remove the 1 hack
that's in there at the moment and use the same CSS for all.

Tricker quirks mode, and hope there is nothing that will broke? (IE had
bug that does what you want...)

I definately will not trigger quirks mode in any browser, it must be
done with standards or not at all. I don't understand why you even
suggested that, considering that it would just be a different kind of
hack, which I said I want to avoid.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://SpreadFirefox.com/ Igniting the Web

[Lauri Raittila]

in comp.infosystem s.www.authoring.stylesheets, Lachlan Hunt wrote:

Lauri Raittila wrote:

In IE it works on inline stuff (don't ask why), so
display:inline; display:inline-block;display:i nline-table;

That could be a good idea because it uses a fallback mechansim, rather
than a specific browser hack. I'll think about using something like that.

I considered using inline, but then it's there's spaces between each
<li> which get rendered as a single space. I used the floats to avoid
that problem, so there is no gap.

What harm does that gap do?

It creates non-clickable regions between the links, which I dislike in
navigation bars.

It is good to have non-clickable regions between links. If there aren't,
it is hard to know which link you are clicking. (assume :hover is
forbidden for example)

There should be non-link printable characters between links
http://www.w3.org/TR/WCAG10/#tech-divide-links
Remeber screen readers that use IE. Not having anything between links is
even worse, I assume. I have not tested such things, so I can say
anything by experiance.

You need some white space between the links anyway.

No, there just needs to be sufficient padding to make the links large
enough to be easily targetted with the cursor

The problem is that space between links needs something that is not link,
so that user knows which is link and which is other.

And you can of course get rid of that whitespace. Just remove all
spaces and tabs between tags. (you can leave linebreaks)

That won't work since all white space characters in HTML including
spaces tabs and line breaks are collapsed to a single space.

You are right, I was remembering wrong. You could do
<ul>
<li>fi
</li><li>se
</li>
</ul>

though.
http://www.w3.org/TR/REC-html40/appe...es-line-breaks

Ideally, I would be able to remove the 1 hack
that's in there at the moment and use the same CSS for all.

Tricker quirks mode, and hope there is nothing that will broke? (IE had
bug that does what you want...)

I definately will not trigger quirks mode in any browser, it must be
done with standards or not at all. I don't understand why you even
suggested that, considering that it would just be a different kind of
hack, which I said I want to avoid.

If you don't want to use quirks mode, you have already done some decision
on grounds of supporting specific browsers. In reality, something else
must be done than just give correct CSS to all browsers, if you aren't
willing to do lots of compromises on how things will look.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[Lachlan Hunt]

Lauri Raittila wrote:

in comp.infosystem s.www.authoring.stylesheets, Lachlan Hunt wrote:

It creates non-clickable regions between the links, which I dislike in
navigation bars.
It is good to have non-clickable regions between links. If there aren't,
it is hard to know which link you are clicking. (assume :hover is
forbidden for example)

Not when the links are large enough, and visual feedback is given
appropriately. In my experience, having a space between a link makes
targetting and clicking a link harder as it is too easy to slip off the
link into that gap.
There should be non-link printable characters between links
http://www.w3.org/TR/WCAG10/#tech-divide-links
That refers to having space between links in the markup. Whether or not
those spaces are dispalyed visually on the screen (depending on how they
are removed) is irrelevant. In this instance because the li are floated
which effectively removes the spaces visually, it doesn't hurt.
You could do
<ul>
<li>fi
</li><li>se
</li>
</ul>
Ha? That would violate Guidline 10.5! Why would you tell me about it
and then suggest a solution that violates it?

I definately will not trigger quirks mode in any browser, it must be
done with standards or not at all. I don't understand why you even
suggested that, considering that it would just be a different kind of
hack, which I said I want to avoid.

If you don't want to use quirks mode, you have already done some decision
on grounds of supporting specific browsers.

Now that's the most ridiculous statement I've read in a while. Choosing
to support *standards* rather than undefined quirks mode behaviours of
proprietary browsers is the exact opposite of supporting specific
browsers. Not only that, given the content, and the fact that part of
the reason for spreading Firefox is to support *standards*, it would be
extremely hypocritical to trigger quirks mode.
In reality, something else
must be done than just give correct CSS to all browsers, if you aren't
willing to do lots of compromises on how things will look.

I am far more willing to compromise on presentation than I am to
compromise on the markup, especially when it comes to a decision as
insane as choosing quirks mode over standards mode.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://SpreadFirefox.com/ Igniting the Web

[Lauri Raittila]

in comp.infosystem s.www.authoring.stylesheets, Lachlan Hunt wrote:

Lauri Raittila wrote:

in comp.infosystem s.www.authoring.stylesheets, Lachlan Hunt wrote:

It creates non-clickable regions between the links, which I dislike in
navigation bars.
It is good to have non-clickable regions between links. If there aren't,
it is hard to know which link you are clicking. (assume :hover is
forbidden for example)

Not when the links are large enough, and visual feedback is given
appropriately.

There was nothing but whitespace between those links. When hovered, there
was slight color change, IIRC. That is not much visual feedback.
In my experience, having a space between a link makes
targetting and clicking a link harder as it is too easy to slip off the
link into that gap.
But, at least it is better than slip to wrong link. Gap doesn't need to
be big gap. (hint: ul {font-size:50%;} li {font-size:200%})

There should be non-link printable characters between links
http://www.w3.org/TR/WCAG10/#tech-divide-links

That refers to having space between links in the markup. Whether or not
those spaces are dispalyed visually on the screen (depending on how they
are removed) is irrelevant.

Is it really. Have you made a study?
In this instance because the li are floated
which effectively removes the spaces visually,
In case of display:inline, the stuff is no more floated, BTW.
it doesn't hurt.
Screen readers often work on visual browsers, like MSIE. Of course, user
might have had sence to turn of CSS.

I definately will not trigger quirks mode in any browser, it must be
done with standards or not at all. I don't understand why you even
suggested that,

It was not serious suggestion...
If you don't want to use quirks mode, you have already done some decision
on grounds of supporting specific browsers. Now that's the most ridiculous statement I've read in a while.
Think about it again. Quirks vs. Standards modes are not defined by any
spec, and don't follow any specific rules. Rules are in fact bit
different for every browser.
Choosing
to support *standards* rather than undefined quirks mode behaviours of
proprietary browsers is the exact opposite of supporting specific
browsers.
But it is. You could use any of about 8 official (X)HTML strict doctypes,
but you need choose between the ones that tricker standards in browsers.
Not only that, given the content, and the fact that part of
the reason for spreading Firefox is to support *standards*, it would be
extremely hypocritical to trigger quirks mode.
Yes, but if you did choose doctype that will tricker standards becuase it
trickers standard, and not some other reason, you have made desision to
aim for certain browsers. The decision is of course very good, but shows
that you need to do compromises, as world is not ready.
In reality, something else
must be done than just give correct CSS to all browsers, if you aren't
willing to do lots of compromises on how things will look.

I am far more willing to compromise on presentation than I am to
compromise on the markup,

There is absolutely no need to compromise on markup, when trickering
quirks or standards...
especially when it comes to a decision as
insane as choosing quirks mode over standards mode.

Markup has nothing to do with that. Remember, there is standard doctype
that does tricker quirks. Nobody uses it. (Well practically nobody uses
the standard doctype that trickers standards either... ,-)
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>