[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev question about blockquote

From: Michael Warner
Subject: Re: lynx-dev question about blockquote
Date: Thu, 16 Oct 2003 15:30:38 -0700 (PDT)

I'm probably a little confused ... was this thread about BLOCKQUOTE
wrapping behavior, or about BLOCKQUOTE inside PRE, or both together? 
I'm assuming here that it's BQ inside PRE, just 'cause that's what
first caught my attention :)

--- Miles O'Neal <address@hidden> wrote:

> Hoo, boy.  The w3c leaves a lot of wiggle room
> on PRE and BLOCKQUOTE, and doesn't explicitly
> address both (at least in the 4.,0,1 spec).

Presentation is largely up to the user agent, but nesting the two is,
explicitly, a No-No, near as I can tell.

PRE and BLOCKQUOTE are both block level elements:
ENTITY % block
     "P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
("%preformatted" expands to, surprise, "PRE")

and PRE can only contain inline content:

ELEMENT PRE - - (%inline;)* -(%pre.exclusion;) -- preformatted text
Start tag: required, End tag: required

so what to do with <PRE><BLOCKQUOTE></blockquote></pre>
falls under error recovery.  I see three recovery alternatives.

First, ignore the illegal BLOCKQUOTE and render the whole thing as
PRE (<PRE></pre>).  Users won't like that, I predict, since BQ
formatting will be lost.

Second, treat PRE as suggested for P:
ELEMENT P - O (%inline;)*            -- paragraph --
  %attrs;                              -- %coreattrs, %i18n, %events

Start tag: required, End tag: optional
(Note optional end tag--PRE's is required)

According to <>,
</p> is optional because the next block-level opening tag closes it
anyway.  Treating PRE the same gives <PRE></pre><BQ></BQ>, losing the
PRE formatting after the BQ.  Again, not ideal.

The third option would be to do what the author might have intended:
close the PRE tag at the start of the next block-level element, and
re-open it after the close of the block.
<PRE></pre><BQ></BQ><PRE></pre>.  That seems to cater to invalid html
too much for my taste, and I have no idea how hard to implement it
would be.  For all I know, it might even be the current behavior :)

As a confirmed curmudgeon, I vote for ignoring the invalid
BLOCKQUOTE, and rendering the whole chunk as PRE, at least as far as
SortaSGML goes.

Bye-the-bye, since:
ELEMENT BLOCKQUOTE - - (%block;|SCRIPT)+ -- long quotation --
, <BLOCKQUOTE><PRE></pre></blockquote> is legal, right?  Does the PRE
get formatted relative to the page margin or the BQ indent? Just
curious, haven't experimented yet with lynx.  Firebird uses the BQ
indent as the margin for PRE formatting.  And, FWIW, doesn't
word-wrap a BQ inside a PRE, nor a PRE inside a BQ.

> I'd say it's up to the browser implementer to decide.


> FWIW, my vote is, it's a bug.  It should indent, but
> not change the fact that PRE is in effect.

That would be option three above, then?  Or something else?

Michael Warner

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]