XHTML or HTML 4.01?

[Henri Sivonen]

Re: XHTML or HTML 4.01?

In article <3f2cba65.10491 9996@news.cis.d fn.de>,
jim@jibbering.c om (Jim Ley) wrote:
[color=blue][color=green]
> >Mozilla-based browsers support XHTML 1.x delivered as
> >application/xhtml+xml. However, they don't support incremental rendering
> >of application/xhtml+xml as the content arrives from the network.[/color][/color]
[color=blue]
> of course they claim they can't render
> it incrementally to be conformant to the XHTML spec[/color]

Who's "they"? Why would any of the XHTML specs forbid incremental
rendering?

AFAIK, it's just that Mozilla's XML content sink (the thing that
consumes data from the parser) can't deal with incremental loading.

http://bugzilla.mozilla.org/show_bug.cgi?id=18333

--
Henri Sivonen
hsivonen@iki.fi

http://www.iki.fi/hsivonen/

Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

[Jim Ley]

Re: XHTML or HTML 4.01?

On Sat, 09 Aug 2003 16:04:49 +0300, Henri Sivonen <hsivonen@iki.f i>
wrote:
[color=blue]
>In article <3f2cba65.10491 9996@news.cis.d fn.de>,
> jim@jibbering.c om (Jim Ley) wrote:
>[color=green][color=darkred]
>> >Mozilla-based browsers support XHTML 1.x delivered as
>> >application/xhtml+xml. However, they don't support incremental rendering
>> >of application/xhtml+xml as the content arrives from the network.[/color][/color]
>[color=green]
>> of course they claim they can't render
>> it incrementally to be conformant to the XHTML spec[/color]
>
>Who's "they"? Why would any of the XHTML specs forbid incremental
>rendering?[/color]

Because a parser must not pass non-well-formed elements to the
application for normal processing, and incremental rendering requires
that non-well-formed elements are processed by the application before
it can even know if it's well-formed (e.g. the root element is never
closed)

So given an XML document with the root element not closed, what should
be rendered?

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Headless]

Re: XHTML or HTML 4.01?

jim@jibbering.c om (Jim Ley) wrote:
[color=blue][color=green]
>>Who's "they"? Why would any of the XHTML specs forbid incremental
>>rendering?[/color]
>
>Because a parser must not pass non-well-formed elements to the
>application for normal processing, and incremental rendering requires
>that non-well-formed elements are processed by the application before
>it can even know if it's well-formed (e.g. the root element is never
>closed)[/color]

Why do you keep repeating this nonsense?

As I've told you before, the only requirement is that a parser throws a
parsing error when encountering malformed code, there is no requirement
not to process/display.

Opera 7 does incremental rendering of xhtml and it complies with the
requirement to throw a parsing error on encountering malformed code.

This is a non issue that XHTML haters apparently like to throw up, go
tell Mozilla to improve Gecko instead.


Headless

--
Email and usenet filter list: http://www.headless.dna.ie/usenet.htm

[Jim Ley]

Re: XHTML or HTML 4.01?

On Tue, 12 Aug 2003 07:51:25 +0100, Headless <invalid_addres s@dna.ie>
wrote:
[color=blue]
>jim@jibbering. com (Jim Ley) wrote:
>[color=green][color=darkred]
>>>Who's "they"? Why would any of the XHTML specs forbid incremental
>>>rendering?[/color]
>>
>>Because a parser must not pass non-well-formed elements to the
>>application for normal processing, and incremental rendering requires
>>that non-well-formed elements are processed by the application before
>>it can even know if it's well-formed (e.g. the root element is never
>>closed)[/color]
>
>Why do you keep repeating this nonsense?
>
>As I've told you before, the only requirement is that a parser throws a
>parsing error when encountering malformed code, there is no requirement
>not to process/display.[/color]

Yep, I agree, so a browser is doing nothing wrong by rendering invalid
XHTML documents, _GOOD_, a browser is free to render invalid
documents, that's good to hear, but I understood that wasn't one of
the oft trumped advantages of XHTML?

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Headless]

Re: XHTML or HTML 4.01?

jim@jibbering.c om (Jim Ley) wrote:
[color=blue][color=green][color=darkred]
>>>Because a parser must not pass non-well-formed elements to the
>>>applicatio n for normal processing, and incremental rendering requires
>>>that non-well-formed elements are processed by the application before
>>>it can even know if it's well-formed (e.g. the root element is never
>>>closed)[/color]
>>
>>Why do you keep repeating this nonsense?
>>
>>As I've told you before, the only requirement is that a parser throws a
>>parsing error when encountering malformed code, there is no requirement
>>not to process/display.[/color]
>
>Yep, I agree, so a browser is doing nothing wrong by rendering invalid
>XHTML documents, _GOOD_, a browser is free to render invalid
>documents, that's good to hear,[/color]

An XHTML renderer is required to throw a parsing error on _malformed_
code, invalid is something else entirely.
[color=blue]
>but I understood that wasn't one of
>the oft trumped advantages of XHTML?[/color]

Apparently you misunderstood, the requirement to throw a parser error on
encountering malformed code is an advantage.


Headless

--
Email and usenet filter list: http://www.headless.dna.ie/usenet.htm

[Henri Sivonen]

Re: XHTML or HTML 4.01?

In article <3f380dcd.16516 2951@news.cis.d fn.de>,
jim@jibbering.c om (Jim Ley) wrote:
[color=blue]
> Because a parser must not pass non-well-formed elements to the
> application for normal processing, and incremental rendering requires
> that non-well-formed elements are processed by the application before
> it can even know if it's well-formed (e.g. the root element is never
> closed)[/color]

No, the XML spec does not require the XML processor to check whether an
element is properly closed before passing information about the start of
the element to the application.

Quoting the XML spec (2nd ed.):
| fatal error
|
| [Definition: An error which a conforming XML processor must
| detect and report to the application. After encountering a
| fatal error, the processor may continue processing the data
| to search for further errors and may report such errors to
| the application. In order to support correction of errors,
| the processor may make unprocessed data from the document
| (with intermingled character data and markup) available to
| the application. Once a fatal error is detected, however,
| the processor must not continue normal processing (i.e.,
| it must not continue to pass character data and information
| about the document's logical structure to the application
| in the normal way).]

It says "after encountering a fatal error". That is, if an element is
not properly closed, the error would be encountered when the end tag of
the parent element is encountered or the end of the data streams is
encountered. Before that, it is OK to pass information about the
children of the unclosed element to the application.
[color=blue]
> So given an XML document with the root element not closed, what should
> be rendered?[/color]

Until the end of the data stream is reached, the entire document. When
the end of the data stream is seen and the error is detected, also
displaying an error message would be appropriate. I guess whether the
error message replaces the rendering of the document so far is an
implementation-dependent choice.

--
Henri Sivonen
hsivonen@iki.fi

http://www.iki.fi/hsivonen/

Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html