Browser error correction mechanisms

[DU]

Hi!

I really need to understand what is so-called browser error correction
mechanisms. Can you explain this?
I read somewhere (and I no longer can find where I read that) that
browsers try to render as best as they can elements (and/or attribute
too? can't remember) that they ignore.
e.g.: I know that fieldset will be rendered as a block level element in
NS 4.7+, almost just like div.

But in a mozilla.org document about upgrading webpages (and I commited
myself into upgrading such document), it is said "standards-based
browsers typically ignore non-compliant elements altogether." Is that
true? Why standards-based browsers should not try to render (instead of
ignoring) an unknown element?
Mozilla supports <embed> and a few other non-HTML4-spec elements IIRC.

DU

[Jim Dabell]

Re: Browser error correction mechanisms

DU wrote:
[color=blue]
> I really need to understand what is so-called browser error correction
> mechanisms. Can you explain this?[/color]

The code that most websites use is out-of-spec (in other words, contains
errors). Browsers have historically attempted to understand such documents
in the name of providing a better user experience. However, it has
resulted in authors and authoring tools routinely producing code that
contains many errors. Browser vendors are stuck with having to maintain
numerous bug workarounds, because otherwise they would be accused of
"breaking things" when popular websites with errors stopped working.
Developers of new user-agents have to reverse-engineer their popular
competitors to figure out how they should handle error conditions in order
to compete. This error handling is for the most part undocumented and not
fixed into a specification that we can read or compare implementations
against.

Naturally, this isn't very helpful, and when XML was developed, parsers were
required by the specification to throw fatal errors (in other words, stop
parsing the document) when syntax errors occurred. XHTML, building on XML,
also has this requirement. However, many people serve it as text/html for
browsers like Internet Explorer that haven't caught up to the XHTML 1.0
specification yet (the specification co-authored by Microsoft and published
over four years ago). Therefore, this XML parsing mode is rarely
encountered, and browser vendors still have to go to great lengths to
counteract author ignorance.

From this point, I'll assume you are talking about the SGML-based HTML and
not the XML-based XHTML.

[color=blue]
> I read somewhere (and I no longer can find where I read that) that
> browsers try to render as best as they can elements (and/or attribute
> too? can't remember) that they ignore.
> e.g.: I know that fieldset will be rendered as a block level element in
> NS 4.7+, almost just like div.[/color]

This principle is mentioned in the HTML 4.01 specification:

<URL:http://www.w3.org/TR/html401/appendix/notes.html#h-B.1>

However, this bit is especially important:

"Since user agents may vary in how they handle error conditions, authors and
users must not rely on specific error recovery behavior."

Writing crap code and assuming browsers will fix it for you is no substitute
for writing correct code to begin with. Even if every user-agent
understands your code today (you cannot be sure of this), the very next
version could break, and I don't see how you could possibly test in
browsers that haven't been developed yet.

[color=blue]
> But in a mozilla.org document about upgrading webpages (and I commited
> myself into upgrading such document), it is said "standards-based
> browsers typically ignore non-compliant elements altogether." Is that
> true?[/color]

As far as I know, yes, unless the element is a proprietary extension that
the browser recognises.

[color=blue]
> Why standards-based browsers should not try to render (instead of
> ignoring) an unknown element?[/color]

The mozilla.org statement you quoted was an observation, not an opinion on
how things should be. There is arguably no incorrect behaviour in the face
of errors in an HTML document, at least from the HTML specification's point
of view. In the end, it boils down to a judgement call by the browser
developers.

[color=blue]
> Mozilla supports <embed> and a few other non-HTML4-spec elements IIRC.[/color]

Those would be the proprietary extensions I mentioned earlier. It's
important to note that browsers vendors can and do drop support for these
from time to time (layers, for example).

In my opinion, documents that are syntactically correct, but use unknown
attributes and element types are more robust than documents that are not
syntactically correct, as long as you don't assume the unknown elements and
attributes will be acted upon. For example, <nobr> is safer than unquoted
attribute values that should have been quoted or misnested tags.


--
Jim Dabell

[C A Upsdell]

Re: Browser error correction mechanisms

"DU" <drunclear@hotW IPETHISmail.com > wrote in message
news:c4s63o$7ft $1@news.eusc.in ter.net...[color=blue]
>
> I really need to understand what is so-called browser error correction
> mechanisms. Can you explain this?
> I read somewhere (and I no longer can find where I read that) that
> browsers try to render as best as they can elements (and/or attribute
> too? can't remember) that they ignore.
> e.g.: I know that fieldset will be rendered as a block level element in
> NS 4.7+, almost just like div.
>
> But in a mozilla.org document about upgrading webpages (and I commited
> myself into upgrading such document), it is said "standards-based
> browsers typically ignore non-compliant elements altogether." Is that
> true? Why standards-based browsers should not try to render (instead of
> ignoring) an unknown element?
> Mozilla supports <embed> and a few other non-HTML4-spec elements IIRC.[/color]

The HTML specs do not say how a user agent should deal with invalid code.
Assuming any particular behaviour is therefore risky.

The CSS specs say that a user agent should ignore code that it does not
understand, though IE3 and NN4 don't always do so, sometimes with
catastrophic effects.

[DU]

Re: Browser error correction mechanisms

C A Upsdell wrote:[color=blue]
> "DU" <drunclear@hotW IPETHISmail.com > wrote in message
> news:c4s63o$7ft $1@news.eusc.in ter.net...
>[color=green]
>>I really need to understand what is so-called browser error correction
>>mechanisms. Can you explain this?
>>I read somewhere (and I no longer can find where I read that) that
>>browsers try to render as best as they can elements (and/or attribute
>>too? can't remember) that they ignore.
>>e.g.: I know that fieldset will be rendered as a block level element in
>>NS 4.7+, almost just like div.
>>
>>But in a mozilla.org document about upgrading webpages (and I commited
>>myself into upgrading such document), it is said "standards-based
>>browsers typically ignore non-compliant elements altogether." Is that
>>true? Why standards-based browsers should not try to render (instead of
>>ignoring) an unknown element?
>>Mozilla supports <embed> and a few other non-HTML4-spec elements IIRC.[/color]
>
>
> The HTML specs do not say how a user agent should deal with invalid code.[/color]

I found it!
4.1 Definitions

http://www.w3.org/TR/html401/conform.html#conformance

also, B.1 Notes on invalid documents

http://www.w3.org/TR/html401/appendix/notes.html#notes-invalid-docs

[color=blue]
> Assuming any particular behaviour is therefore risky.
>[/color]

Noted. That is most probably why it's so important to validate documents
and stick to compliant code.
[color=blue]
> The CSS specs say that a user agent should ignore code that it does not
> understand[/color]

Yes. That is
3.3 Error conditions

http://www.w3.org/TR/CSS2/conform.html#q3

and
4.2 Rules for handling parsing errors

http://www.w3.org/TR/CSS2/syndata.html#parsing-errors

CSS is more predictable. For instance, if I go
p {-moz-border-radius: 10px; border: 2px solid blue;}
Mozilla 1.1+ based browsers will render both declarations while Opera
7.x will only render the last declarations.

DU

, though IE3 and NN4 don't always do so, sometimes with[color=blue]
> catastrophic effects.
>
>[/color]

[DU]

Re: Browser error correction mechanisms

Jim Dabell wrote:
[color=blue]
> DU wrote:
>
>[color=green]
>>I really need to understand what is so-called browser error correction
>>mechanisms. Can you explain this?[/color]
>
>
> The code that most websites use is out-of-spec (in other words, contains
> errors). Browsers have historically attempted to understand such documents
> in the name of providing a better user experience. However, it has
> resulted in authors and authoring tools routinely producing code that
> contains many errors. Browser vendors are stuck with having to maintain
> numerous bug workarounds, because otherwise they would be accused of
> "breaking things" when popular websites with errors stopped working.
> Developers of new user-agents have to reverse-engineer their popular
> competitors to figure out how they should handle error conditions in order
> to compete. This error handling is for the most part undocumented and not
> fixed into a specification that we can read or compare implementations
> against.
>
> Naturally, this isn't very helpful, and when XML was developed, parsers were
> required by the specification to throw fatal errors (in other words, stop
> parsing the document) when syntax errors occurred. XHTML, building on XML,
> also has this requirement. However, many people serve it as text/html for
> browsers like Internet Explorer that haven't caught up to the XHTML 1.0
> specification yet (the specification co-authored by Microsoft and published
> over four years ago). Therefore, this XML parsing mode is rarely
> encountered, and browser vendors still have to go to great lengths to
> counteract author ignorance.
>[/color]

This is really well said.
[color=blue]
> From this point, I'll assume you are talking about the SGML-based HTML and
> not the XML-based XHTML.
>[/color]

Yes, precisely.[color=blue]
>
>[color=green]
>>I read somewhere (and I no longer can find where I read that) that
>>browsers try to render as best as they can elements (and/or attribute
>>too? can't remember) that they ignore.
>>e.g.: I know that fieldset will be rendered as a block level element in
>>NS 4.7+, almost just like div.[/color]
>
>
> This principle is mentioned in the HTML 4.01 specification:
>
> <URL:http://www.w3.org/TR/html401/appendix/notes.html#h-B.1>
>
> However, this bit is especially important:
>
> "Since user agents may vary in how they handle error conditions, authors and
> users must not rely on specific error recovery behavior."
>
> Writing crap code and assuming browsers will fix it for you is no substitute
> for writing correct code to begin with. Even if every user-agent
> understands your code today (you cannot be sure of this), the very next
> version could break, and I don't see how you could possibly test in
> browsers that haven't been developed yet.
>
>
>[color=green]
>>But in a mozilla.org document about upgrading webpages (and I commited
>>myself into upgrading such document), it is said "standards-based
>>browsers typically ignore non-compliant elements altogether." Is that
>>true?[/color]
>
>
> As far as I know, yes, unless the element is a proprietary extension that
> the browser recognises.
>[/color]

But the specs also *suggests* to render the content of such unknown
element. So, on 1 hand:

<asdf ghjk="qwer">Con tent of the unknown element</asdf>

will have the content rendered in MSIE 6, Mozilla 1.7b and Opera 7.5 (I
tested this) but the content won't have any kind of formating or
modification while on the other hand:

<asdf ghjk="qwer"></asdf>

won't be rendered at all. Absolutely nothing. This is what I did not
understand.
[color=blue]
>
>[color=green]
>>Why standards-based browsers should not try to render (instead of
>>ignoring) an unknown element?[/color]
>
>
> The mozilla.org statement you quoted was an observation, not an opinion on
> how things should be. There is arguably no incorrect behaviour in the face
> of errors in an HTML document, at least from the HTML specification's point
> of view. In the end, it boils down to a judgement call by the browser
> developers.
>[/color]

Ok, so this is why <embed> is rendered in Mozilla-based browsers while
<layer>, <ilayer> are ignored.
[color=blue]
>
>[color=green]
>>Mozilla supports <embed> and a few other non-HTML4-spec elements IIRC.[/color]
>
>
> Those would be the proprietary extensions I mentioned earlier. It's
> important to note that browsers vendors can and do drop support for these
> from time to time (layers, for example).
>
> In my opinion, documents that are syntactically correct, but use unknown
> attributes and element types are more robust than documents that are not
> syntactically correct, as long as you don't assume the unknown elements and
> attributes will be acted upon. For example, <nobr> is safer than unquoted
> attribute values that should have been quoted or misnested tags.
>
>[/color]

Thank you very much for your well worded reply and for the time you took
to edit this complete answer. Your reply helped me and is greatly
appreciated.

DU
P.S.: Are you by any chance using Konqueror 3.2? If so, I might have a
favor to ask you about Konqueror's support for CSS3 opacity property...

[Mark Parnell]

Re: Browser error correction mechanisms

On Mon, 05 Apr 2004 13:47:32 -0400, DU <drunclear@hotW IPETHISmail.com >
declared in comp.infosystem s.www.authoring.html,alt.html:
[color=blue]
> Hi![/color]

G'day.
[color=blue]
> I really need to understand what is so-called browser error correction
> mechanisms. Can you explain this?[/color]

That term is often used with regards to the browsers guessing what the
author meant when the author was too lazy to write their code properly
(AKA Tag Soup).

E.g. if you put in your page:

<table><tr>blah </tr></table>

Browsers may display it as intended[1], despite the fact that you
omitted the <td> (or <th>) that the <tr> is required to contain.

In the specs, though, it seems to refer to what you are talking about -
how they handle unknown elements or attributes.
[color=blue]
> I read somewhere (and I no longer can find where I read that) that
> browsers try to render as best as they can elements (and/or attribute
> too? can't remember) that they ignore.[/color]

Try to render elements they ignore? That's somewhat of an oxymoron.

Try to render elements they don't recognise? They should just try and
render the contents of the element (if there are any), but not apply any
styling etc to the element itself. Unknown attributes should be ignored.

http://www.w3.org/TR/html4/appendix/notes.html#h-B.1

[color=blue]
> e.g.: I know that fieldset will be rendered as a block level element in
> NS 4.7+, almost just like div.[/color]

And why not? Fieldset _is_ a block level element.
[color=blue]
> But in a mozilla.org document about upgrading webpages (and I commited
> myself into upgrading such document), it is said "standards-based
> browsers typically ignore non-compliant elements altogether."[/color]

I wonder exactly what they mean by "non-compliant"? As you say below,
most (all?) browsers support non-standard elements.
[color=blue]
> Is that true?[/color]

Depends what you mean by ignore, I guess. They generally follow the
specs - they try to render the content, but they ignore the element
itself.
[color=blue]
> Mozilla supports <embed> and a few other non-HTML4-spec elements IIRC.[/color]

As I said above, that's a different issue. All the major browsers
support various additional elements, but there are few (if any) elements
that are supported by _all_ those browsers. What you were asking about
before is what they do when they encounter one that they _don't_
support.

[1] OK, so they didn't in that particular example when I tried it (the
text was displayed before the table, although that was in Standards mode
- Quirks mode may be different), but you get the point.

--
Mark Parnell

http://www.clarkecomputers.com.au