Is it just me (probably) or is Mozilla and the newer Firefox full of
CSS rendering bugs?

I ask, because some strange effects occur with Mozilla and Firefox
which don't happen in Opera and dare I say it, IE.

Like, for example, non-selection of a font-face for one style element,
even though it is selected okay for another element and the colour,
decoration and size are all rendered correctly!

Not recognising the 'border' parameter (eg: border: 1px solid black;)

Not rendering 'width' correctly (eg: width: 180px;)

Matt

--
If your encyclopaedia doesn't list "widget glass", you're reading the wrong 
encyclopaedia.
The Probert Encyclopaedia. Its not the same.
http://www.probertencyclopaedia.com

comments@probertencyclopaedia.com (Matt Probert) writes:
> Is it just me (probably) or is Mozilla and the newer Firefox full of
> CSS rendering bugs?

I expect it is. But the ones you list below seem unlikely.

> I ask, because some strange effects occur with Mozilla and Firefox
> which don't happen in Opera and dare I say it, IE.
>
> Like, for example, non-selection of a font-face for one style element,
> even though it is selected okay for another element and the colour,
> decoration and size are all rendered correctly!
>
> Not recognising the 'border' parameter (eg: border: 1px solid black;)
>
> Not rendering 'width' correctly (eg: width: 180px;)

This is where some test case URLs would be really useful. There could
be hundreds of reasons, only one a browser bug, why these don't do
what you expect.

--
Chris

"Matt Probert" <comments@probertencyclopaedia.com> wrote in message
news:40f69ca5.33574497@news.ntlworld.com...
> Is it just me (probably) or is Mozilla and the newer Firefox full of
> CSS rendering bugs?
>
> I ask, because some strange effects occur with Mozilla and Firefox
> which don't happen in Opera and dare I say it, IE.
>
> Like, for example, non-selection of a font-face for one style element,
> even though it is selected okay for another element and the colour,
> decoration and size are all rendered correctly!
>
> Not recognising the 'border' parameter (eg: border: 1px solid black;)
>
> Not rendering 'width' correctly (eg: width: 180px;)

Are you comparing apples with apples, e.g. by ensuring that a DOCTYPE is
used that triggers standards mode in all these browsers?

Examples would be nice.

On Thu, 15 Jul 2004 16:50:45 GMT "C A Upsdell"
<cupsdell0311XXX@-@-@XXXrogers.com> broke off from drinking a cup of
tea at  to write:

>Are you comparing apples with apples, e.g. by ensuring that a DOCTYPE is
>used that triggers standards mode in all these browsers?
>

No, which is why I'm asking! I had wondered if it was to do with
DOCTYPEs, which I shall now look into. Thanks for the suggestion - i
did ask if it was just me! <g>

Matt

--
If your encyclopaedia doesn't list "widget glass", you're reading the wrong 
encyclopaedia.
The Probert Encyclopaedia. Its not the same.
http://www.probertencyclopaedia.com

On Thu, 15 Jul 2004 18:46:33 GMT comments@probertencyclopaedia.com
(Matt Probert) broke off from drinking a cup of tea at The Probert
Encyclopaedia to write:

> On Thu, 15 Jul 2004 16:50:45 GMT "C A Upsdell"
><cupsdell0311XXX@-@-@XXXrogers.com> broke off from drinking a cup of
>tea at  to write:
> 

Pkay, it was a matter of DOCTYPES. Thanks for pointing me down that
road.

I thought CSS was fixed. There's CSS1 and CSS2 and they are defined,
but changing the DOCTYPE results in *very* different interpretations
of the CSS suggestions.

Perhaps I should wade through the incomprehensible brambles that are
the W3C specs <g>

Matt

--
If your encyclopaedia doesn't list "widget glass", you're reading the wrong 
encyclopaedia.
The Probert Encyclopaedia. Its not the same.
http://www.probertencyclopaedia.com

Matt Probert wrote:

> it was a matter of DOCTYPES.
>
> Perhaps I should wade through the incomprehensible brambles that
> are the W3C specs <g>

You'll find nothing on doctype switching afaik. Doctype switching was
an idea created by the browser makers, ostensibly to accomodate badly
authored pages but introducing a new set of problems. Some of the gory
details:

http://gutfeldt.ch/matthias/articles/doctypeswitch.html

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

On Fri, 16 Jul 2004, Matt Probert wrote:

> Pkay, it was a matter of DOCTYPES. Thanks for pointing me down that
> road.
>
> I thought CSS was fixed.

That's almost correct.  (Just teeny adjustments in CSS2.1, and a few
things taken out of CSS2 that it seemed nobody was going to implement
- but nothing remotely on the scale of the pratical differences
between CSS2 specification and actual browser behaviour).

> There's CSS1 and CSS2 and they are defined, but changing the DOCTYPE
> results in *very* different interpretations of the CSS suggestions.

Now you're confusing buggy client behaviour with differences in the
specifications.

> Perhaps I should wade through the incomprehensible brambles that are
> the W3C specs <g>

Not really.  Browser "quirks modes" are an attempt by the browser
makers to perpetrate their original bugs (so as not to upset those
foolish virgins who designed their pages "to" the browser bugs,
instead of staying within the specifications) - while still offering a
standards-conform-wards mode for properly made pages.

Once they'd taken that decision, they needed some kind of handle for
guesstimating whether a page was intended to be standards-conforming
or reliant on old bugs. Unfortunately, they seem to have hit upon a
rather unfortunatate choice of handle for that purpose, namely the
notorious "DOCTYPE switching".  The rest, as they say, is history.
But you won't really find any of this in W3C specifications.

Alan J. Flavell wrote:

> Browser "quirks modes" are an attempt by the browser makers to
> perpetrate their original bugs
>
> Once they'd taken that decision, they needed some kind of handle
> for guesstimating whether a page was intended to be
> standards-conforming or reliant on old bugs. Unfortunately, they
> seem to have hit upon a rather unfortunatate choice of handle for
> that purpose, namely the notorious "DOCTYPE switching".

Your posts hints that there might have been another (better) way. Was
there?

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

*Brian* <usenet3@julietremblay.com.invalid>:
> Alan J. Flavell wrote:
> 
>
> Your posts hints that there might have been another (better) way.

To use an *HTML* feature to switch *CSS* rendering behaviour, is really
strange. If they would at least parse the HTML differently, more correctly
in "standards conforming" mode!

> Was there?

If, I would have used the approach of using standard compliant mode by
default and as soon as an parse error occured, the rendition would restart
in quirks mode. This would of course make buggy pages take longer to load,
which is not such a bad thing IMO.

--
The penis mightier than the sword.

"Christoph Paeper" <christoph.paeper@nurfuerspam.de> wrote in message
news:opsa8mqrj6b8p244@crissov.heim4.tu-clausthal.de... 
>
> To use an *HTML* feature to switch *CSS* rendering behaviour, is really
> strange. If they would at least parse the HTML differently, more correctly
> in "standards conforming" mode!
> 
>
> If, I would have used the approach of using standard compliant mode by
> default and as soon as an parse error occured, the rendition would restart
> in quirks mode. This would of course make buggy pages take longer to load,
> which is not such a bad thing IMO.

The problem with this is that you can have a valid page that depends on
quirks mode.

I personally would have preferred it if a META tag had been used instead a
DOCTYPE to specify the mode.