IE5 ignores padding or margin for inline elements - workaround?

[Markus Ernst]

Hi

Does somebody know a workaround for the fact that IE5 does not apply margin
and padding to inline elements? I have a navigation with those styles:

ul#navigation {
border-top:1px #000000 solid;
border-bottom:1px #000000 solid;
list-style:none;
margin:0;
padding:0.2em 0 0.2em 2em;
white-space:nowrap;
}
ul#navigation li {
display:inline;
margin:0;
padding:0 2em 0 0;
font-weight:bold;
color:#000000;
}

Works nicely in standards browsers and IE6. Can this get fixed for IE5
without breaking other browsers, or even using deprecated HTML?

Thanks for a hint.

--
Markus

[Els]

Markus Ernst wrote:

Hi
Hello
Does somebody know a workaround for the fact that IE5 does not apply margin
and padding to inline elements?
I've only had succes with applying a height to them, but even a 1px
height will result in a higher height than I usually want.
I have a navigation with those styles:

ul#navigation {
border-top:1px #000000 solid;
border-bottom:1px #000000 solid;
list-style:none;
margin:0;
padding:0.2em 0 0.2em 2em;
white-space:nowrap;
}
ul#navigation li {
display:inline;
margin:0;
padding:0 2em 0 0;
font-weight:bold;
color:#000000;
}

Works nicely in standards browsers and IE6. Can this get fixed for IE5
without breaking other browsers, or even using deprecated HTML?
I forgot if I apply the height to the <li> element, or to the <a>
element inside, really, but the trick is in the height :-)
Thanks for a hint.

You're welcome.

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -
Now playing: Dirty White Boy - Badlands

[Markus Ernst]

Els wrote:

Does somebody know a workaround for the fact that IE5 does not apply
margin and padding to inline elements?

I've only had succes with applying a height to them, but even a 1px
height will result in a higher height than I usually want.

I forgot if I apply the height to the <li> element, or to the <a>
element inside, really, but the trick is in the height :-)

Ouf... height is one of those dimensions that are differently computed in
IE5, isn't it? I guess before adding Tantek hacks and adjusting heights for
different kinds of rendering engines... I will rather sniff IE5 with PHP and
add some &nbsp;s then...

Thanks a lot for your input and enjoy working on saturday ;-)

--
Markus

[Spartanicus]

"Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote:

Does somebody know a workaround for the fact that IE5 does not apply margin
and padding to inline elements? I have a navigation with those styles:

Unless you have an unusual high percentage of IE5.0 clients, I wouldn't
worry about it (IE5.5 does apply padding to inline elements).

--
Spartanicus

[Els]

Markus Ernst wrote:

Els wrote:

Does somebody know a workaround for the fact that IE5 does not apply
margin and padding to inline elements?
I've only had succes with applying a height to them, but even a 1px
height will result in a higher height than I usually want.

I forgot if I apply the height to the <li> element, or to the <a>
element inside, really, but the trick is in the height :-)

Ouf... height is one of those dimensions that are differently computed in
IE5, isn't it? I guess before adding Tantek hacks and adjusting heights for
different kinds of rendering engines... I will rather sniff IE5 with PHP and
add some &nbsp;s then...

Your choice.

But I now guess you only want to separate them horizontally? It helps
to have line-breaks in the code between the </li> and the next <li>.
Only gives a little space though, if you want more, than yes: height,
or &nbsp;.

But I take it you have something against hacks?
Thanks a lot for your input and enjoy working on saturday ;-)

I can see the wink, but I still don't get t - I'm not working atm if
that's what you think?

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -
Now playing: Chuck Berry - Maybelline

[Markus Ernst]

Spartanicus wrote:

"Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote:

Does somebody know a workaround for the fact that IE5 does not apply
margin and padding to inline elements? I have a navigation with
those styles:

Unless you have an unusual high percentage of IE5.0 clients, I
wouldn't worry about it (IE5.5 does apply padding to inline elements).

Oh that's good news, thank you!

--
Markus

[Markus Ernst]

Els wrote:

But I take it you have something against hacks?

I prefer server side hacks to client side ones, because I have more control
over the output.

Thanks a lot for your input and enjoy working on saturday ;-)

I can see the wink, but I still don't get t - I'm not working atm if
that's what you think?

Yes, wrong assumption of mine... so enjoy whatever you do!

--
Markus

[Els]

Markus Ernst wrote:

Els wrote:

But I take it you have something against hacks?

I prefer server side hacks to client side ones, because I have more control
over the output.

I prefer to use hacks based on what a browser is capable of, not based
on possibly wrongly sniffed UA strings.

Thanks a lot for your input and enjoy working on saturday ;-)

I can see the wink, but I still don't get t - I'm not working atm if
that's what you think?

Yes, wrong assumption of mine... so enjoy whatever you do!

Tnx ;-)

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -
Now playing: Deep Purple - Speed King

[Alan J. Flavell]

On Sat, 6 Aug 2005, Markus Ernst wrote:

Els wrote:

But I take it you have something against hacks?

I prefer server side hacks to client side ones, because I have more control
over the output.

Not necessarily. Think about cache servers. Think about a saved copy
of a web page, browsed with various browsers. And so on. And the
other more-obvious problems, of course, not limited to the widespread
phenomenon of web-compatible browsers having to pretend to be MSIE
because of so many proprietary "web" pages refusing to talk to them
unless they do so.

Sending your well-"controlled" output to the wrong browser is surely
worse than doing nothing?

[Eric B. Bednarz]

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

On Sat, 6 Aug 2005, Markus Ernst wrote:

I prefer server side hacks to client side ones, because I have
more control over the output.

Not necessarily. Think about cache servers. Think about a saved
copy of a web page, browsed with various browsers. And so on.

That's the problem, indeed. Of course *anybody* who negotiates
indicates that the outcome may vary. Nudge nudge, wink wink.
And the other more-obvious problems, of course, not limited to the
widespread phenomenon of web-compatible browsers having to pretend
to be MSIE because of so many proprietary "web" pages refusing to
talk to them unless they do so.

The UA string is particulary unreliable, but doublechecking against the
accept header server-side increases the odds to hit the right horse
remarkably for certain browsers of sorts. A request for text/html is
yet to be seen even in the OS-component-pre-releases de jour.

It's fun that even when using the inherently safer navigator object
client-side (well, if available) some people still seem to be inclined
to consult the easily spoofed userAgent instead of appName and
appVersion (fumbling with the registry apart, or local proxies that are
deliberately set up to be reasonably unreasonable :-).

But it would certainly be enlightening to figure out why it is so hard
to grasp that 'control over the output' is a matter of request instead
of response in this context (I *do* know everyday's our-cms-is-
basically-broken-and-I'm-not-authorized-to-fix-the-source-of-the-
problem situation, TfornotbringingthatupIA :-).
--
Goodbye and keep cold

[Alan J. Flavell]

On Tue, 9 Aug 2005, Eric B. Bednarz wrote:

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

On Sat, 6 Aug 2005, Markus Ernst wrote:

I prefer server side hacks to client side ones, because I have
more control over the output.

Not necessarily. Think about cache servers. Think about a saved
copy of a web page, browsed with various browsers. And so on.

That's the problem, indeed. Of course *anybody* who negotiates
indicates that the outcome may vary. Nudge nudge, wink wink.

Indeed. I have a couple of tutorial pages on server-side negotiation
topics, so you may take it that I've given the matter quire a bit of
thought. And I'm familiar with Mark Nottingham's excellent tutorial
on the significance of cacheing, and on how to make cache-friendly
pages - even when negotiation is involved.

Based on that background, I'm going to stick my neck out and say that
negotiating on the user agent string is just about the most
damned-fool dimension of negotiation that it's possible to conceive
of, in all except the most extreme situations.
The UA string is particulary unreliable, but doublechecking against
the accept header server-side increases the odds to hit the right
horse remarkably for certain browsers of sorts. A request for
text/html is yet to be seen even in the OS-component-pre-releases de
jour.
You've noticed that too? Yes, there's no way that MSIE would ever get
sent HTML, if I also had MS-Word, Powerpoint, Excel etc. variants of
the same content. Well, that's what IE says it wants - who am I to
argue with it? The interworking specification is very clear. Just
another symptom to add to the long list of symptoms that have caused
me to say over and over that "MSIE rules *itself* out as a web
browser". The only thing I consider it fit for is to run Windows
Update.

But, realistically, as a web *author* I need to accept that far too
many people still imagine it to be the only web browser in existence,
and I have to live in that alice-in-wonderland world somehow.
Fortunately it's not totally incapable of browsing properly made web
pages, provided one makes a few concessions for its oddities.

Anyway, to get back to the specific issue you raised. Fortunately I
don't offer MS-Word variants of my HTML pages, so I haven't had to
address that directly myself, although I do discuss it. Let's see,
where was it again? ... ah, this would be it:
http://ppewww.ph.gla.ac.uk/~flavell/...ype.html#unsuc

(the rest of the page may be of interest, but a bit off-topic for the
present group).

As I say there, and I stand by this:

In practice, client agents may or may not give the user the ability
to express their personal wishes for different content types via the
Accept header. So, in general it would be a bad idea to use content
negotiation as the sole means of choosing between different content
formats: it's pretty much essential to offer an alternative route via
a menu of available variants.

and that, indirectly, could address the problem with MSIE also.
It's fun that even when using the inherently safer navigator object
client-side (well, if available) some people still seem to be
inclined to consult the easily spoofed userAgent instead of appName
and appVersion (fumbling with the registry apart, or local proxies
that are deliberately set up to be reasonably unreasonable :-).

If and when MSIE needs special attention, I'd strongly recommend the
use of their proprietary "conditional comments". Provided that care
is taken with the syntax (i.e don't just blindly copy the defective
examples in MS's own tutorial, which one could be forgiven for
guessing were formulated by their dirty tricks department in the
interests of de-railing web-compatible browsers) it's going to be
completely harmless to web-compatible browsers: it's completely
transparent to negotiation, caches, disabled jscript, and so on. It
even works from a saved copy of the HTML. Of course this has to be
done in the HTML, not in the CSS, so if you're trying to even-out a
difference in the CSS implementation then you have to be a bit
resourceful, but in all other respects it seems to me to be the killer
solution to the operating systems component that thinks it's a web
browser.

hope that's useful.

Oh yes, for those who haven't seen the citation yet,
http://www.mnot.net/cache_docs/ is the cach(e)ing tutorial, and don't
miss the same author's cach(e)ability engine, a useful resource.

[Eric B. Bednarz]

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

On Tue, 9 Aug 2005, Eric B. Bednarz wrote:

A request for text/html is yet to be seen even in the
OS-component-pre-releases de jour.

You've noticed that too?

My bad, actually:

User-AgentMozilla/2.0
(compatible; MSIE 3.0; Windows 3.1)

Accept
*/*,q=0.300,
application/x-x509-ca-cert,
audio/x-aiff,
audio/basic,
image/x-xbitmap,
image/jpeg,
image/gif,
multipart/mixed,
multipart/x-mixed-replace,
text/plain,
text/html

:)
Yes, there's no way that MSIE would ever
get sent HTML, if I also had MS-Word, Powerpoint, Excel etc.
variants of the same content.
I don't have Office installed, so I wouldn't be bothered by those
variants at all.
If and when MSIE needs special attention, I'd strongly recommend
the use of their proprietary "conditional comments".
Certainly; in healthy symbiosis with quirksmode, of course, as M$
quite frankly suggests for fixed and forwardscompatible content. Soon
the 'webstandards' kids can play with the version vector for their
legacy stuff to meet partly adjusted behaviour until the cows come
home. :)
Of course this has to be done in the HTML, not in the CSS, so if
you're trying to even-out a difference in the CSS implementation
then you have to be a bit resourceful, but in all other respects
it seems to me to be the killer solution to the operating systems
component that thinks it's a web browser.

A real(-life) problem would be no write permissions.

OTOH, getting 'layout' in a neutral way with the 'zoom' property
actually fixes most of the severe (e.g. page reflow) bugs. That
doesn't even require any special treatment since it should just be
ignored by others UAs, but a dedicated style sheet inbetween CCs is
certainly safer.
--
Goodbye and keep cold