Re: Coding by example?

Phil Kempster wrote:

The different doc types is a bit worrying though - but I don't know
enough about them yet, to worry too much. I'll try and stay with strict
html.

AIUI, IE does not really treat XHTML as XHTML. Rather it reverts to

quirks mode and treats the code as HTML Transitional.

--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

Jim Moe wrote:

The different doc types is a bit worrying though - but I don't know
enough about them yet, to worry too much. I'll try and stay with strict
html.

AIUI, IE does not really treat XHTML as XHTML. Rather it reverts to
quirks mode and treats the code as HTML Transitional.

Some misconceptions here.

1: XHTML vs HTML

In HTML mode browsers use tag soup slurpers to parse.
In XML mode browsers using XML parsers which, in theory are faster.

Given an XHTML document served as XHTML Mozilla based browsers will go in to
XML mode. This has a number of effects, including turning off incremental
rendering and support for document.write. Internet Explorer will, by
default, prompt the user to download the file and not render it at all.

Given an XHTML document served as HTML, most browsers will parse it just
like an HTML document and (thanks to bugs in *most* browsers) not render
">" characters after every XML-style self closing tag.

2: Strict Vs Quirks mode

Given a document served as HTML, many browsers will look at the Doctype and
use it to judge the author's CSS knowledge (yes, the HTML document used to
just the CSS knowledge - stupid or what?!).

An HTML 4.01 Transitional Doctype with NO URL will trigger Quirks mode in IE
6. This will cause it to intentionally make some mistakes with the CSS
parsing and rendering.

An XHTML Doctype will IF and ONLY if it is the first data in the document
(i.e. there is no XML prolog[1] or comment before the Doctype) will trigger
Standards mode (and cause IE to not intentionally make bugs (it will
exhibit some entirely new bugs though)).

If there is anything before the Doctype, or if the Doctype is HTML 4.01
Transitional with NO URL, then Quirks moed will be triggered.

Other DTDs trigger various different modes. Google will help you find
suitable documentation.

[1] You can't have one of these in an XHTML document served as text/html
anyway

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

On Mon, 20 Mar 2006, Jim Moe wrote:

AIUI, IE does not really treat XHTML as XHTML.

IE doesn't support real XHTML at all. Well, I did manage to configure
one IE installation to use Mozilla as its "helper application" for
opening real XHTML content-type (application/xhtml+xml), instead of
dumbly offering to download it.

If XHTML is delivered as text/html, then IE has a stab at treating it
as HTML. Since IE, like most other browsers, has the deliberate bug
on which this conjuring act depends, it gives the desired impression
of "working" (subject to the provisions of Appendix C, that is).

Rather it reverts to quirks mode

Not necessarily. See the usual references for details.

Inserting the <?xml... thingy at the head will sure throw IE into
quirks mode, but the <?xml... thingy is optional under certain
conditions, and those who aim for standards-based interpretation of
CSS are advised to leave it off, for that reason.

and treats the code as HTML Transitional.

MSIE treats all HTML as tag-soup. It has no real concept of the W3C
"HTML Transitional" specification, as such - but the same goes for
other browsers too. Considering that 95% of everything is crud, and
the so-called HTML that is found on the world-wild-web is no
exception, browsers can't afford to be so choosy.

And the same situation is developing for XHTML too, despite some
original claims that XML would cure the web of this mess.

David Dorward <dorward (AT) yahoo (DOT) com> wrote:

Given an XHTML document served as XHTML Mozilla based browsers will go in to
XML mode. This has a number of effects, including turning off incremental
rendering and support for document.write.

Neither are particular to Mozilla browsers.

2: Strict Vs Quirks mode

[...]

An XHTML Doctype will IF and ONLY if it is the first data in the document
(i.e. there is no XML prolog[1] or comment before the Doctype) will trigger
Standards mode (and cause IE to not intentionally make bugs (it will
exhibit some entirely new bugs though)).

If there is anything before the Doctype, or if the Doctype is HTML 4.01
Transitional with NO URL, then Quirks moed will be triggered.

Anything but whitespace preceding the doctype declaration triggering
quirks mode is particular to IE and some old Opera versions (O7.2 IIRC).

[1] You can't have one of these in an XHTML document served as text/html
anyway

Sure you can.

--
Spartanicus

Spartanicus wrote:

Anything but whitespace preceding the doctype declaration triggering
quirks mode is particular to IE and some old Opera versions (O7.2 IIRC).

I was discussing IE in particular there, although rereading it, I see I
didn't make it very clear.

[1] You can't have one of these in an XHTML document served as text/html
anyway

Sure you can.

http://www.w3.org/TR/xhtml1/#C_1

It's debatable. You have to follow Appendix C before serving as text/html,
but Appendix C is amazingly fuzzy in some places. (Yet another reason to
stick to HTML).

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

David Dorward <dorward (AT) yahoo (DOT) com> wrote:

[1] You can't have one of these in an XHTML document served as text/html
anyway

Sure you can.

http://www.w3.org/TR/xhtml1/#C_1

It's debatable.

There may be pragmatic reasons to avoid it, but that's a far cry from
what "can't have one of these" implies. Gazillions of XHTML pages served
as text/html on the web use an XML declaration.

You have to follow Appendix C before serving as text/html,
but Appendix C is amazingly fuzzy in some places. (Yet another reason to
stick to HTML).

Sure.

--
Spartanicus

Spartanicus wrote:

It's debatable.

There may be pragmatic reasons to avoid it

My comment was more "Forbidden by spec" then "Not a good idea".


--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

David Dorward <dorward (AT) yahoo (DOT) com> wrote:

It's debatable.

There may be pragmatic reasons to avoid it

My comment was more "Forbidden by spec" then "Not a good idea".

Then kindly provide a normative reference to this.

--
Spartanicus

On Tue, 21 Mar 2006, David Dorward wrote:

Spartanicus wrote:

It's debatable.

There may be pragmatic reasons to avoid it

My comment was more "Forbidden by spec" then "Not a good idea".

You might take B.3.3 "We recommend that authors avoid using all of
these features" in conjunction with B.3.6
( http://www.w3.org/TR/REC-html40/appe...tes.html#h-B.3 ) , but
those are only recommendations in the HTML spec, they aren't normative
prohibitions.

This is another case where W3C somewhat contradicts itself in
concurrently-valid recommendations, since XHTML/1.0 Appendix C quite
recommends the idea, whereas the above-cited appendix says "avoid".

My conclusion is that if the character encoding needs to be specified
(i.e is not one of those accepted by default in XML) then the best
move is to advertise it in the HTTP header, and not mess around with
in-document crud - neither the <?xml thingy nor meta...http-equiv.

But I'm aware that this isn't everyone's opinion, and, in particular,
one would have to take care when browsing a document from file, if its
correct encoding is only known via HTTP.

Spartanicus wrote:

David Dorward <dorward (AT) yahoo (DOT) com> wrote:

It's debatable.

There may be pragmatic reasons to avoid it

My comment was more "Forbidden by spec" then "Not a good idea".

Then kindly provide a normative reference to this.

As I said - It's debatable.

Section 5.1 of the XHTML 1.0 spec says:
XHTML Documents which follow the guidelines set forth in Appendix C, "HTML
Compatibility Guidelines" may be labeled with the Internet Media
Type "text/html" [RFC2854], as they are compatible with most HTML
browsers. Those documents, and any other document conforming to this
specification, may also be labeled with the Internet Media
Type "application/xhtml+xml" as defined in [RFC3236]. For further
information on using media types with XHTML, see the informative note
[XHTMLMIME].

It doesn't say that documents which don't conform to Appendix C may be
served as text/html.

But then we get to Appendix C itself, which is marked as informative. So a
normative section requires conformace to an information section!

Then we have RFC 2854 which says:
In addition, XHTML1 defines a profile of use of XHTML which is compatible
with HTML 4.01 and which may also be labeled as text/html.

While not making it clear if the "profile" it means is the subset of XHTML
1.0 that conforms to Appendix C.

And the XHTML media types note (http://www.w3.org/TR/xhtml-media-types/)
clarifies this as:
The use of 'text/html' for XHTML SHOULD be limited for the purpose of
rendering on existing HTML user agents, and SHOULD be limited to [XHTML1]
documents which follow the HTML Compatibility Guidelines.

But it says "SHOULD" and not "MUST"!

Going back to the XHTML 1.0 spec and section C.1. it says:
"you may want to avoid"

Not "SHOULD" or "MAY" or any other RFC 2119ism.

And that ignores the whole issue of depending on user agents not
understanding what <br /> et al mean in HTML.

So the entire issue of XHTML as text/html is a complete mess (hence why I
avoid XHTML as text/html entirely these days).


--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is