W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2007

[whatwg] Pre element question

From: Sam Ruby <rubys@intertwingly.net>
Date: Fri, 19 Jan 2007 18:29:11 -0500
Message-ID: <45B15447.4080701@intertwingly.net>
I've been running with html5lib as a sanitizer for syndication feeds now 
for several days, and things mostly look quite good, but I noticed one 
oddity.  People often code things like the following:

<pre>
one
two
three
</pre>

Visually, this ends up looking something like

+-------+
|       |
| one   |
| two   |
| three |
+-------+

with the following CSS rule:

pre { border: solid 1px #000; }

Going back to the original page I see no extra blank line at the top of 
th preformatted text.  Investigating further, Firefox indicates that 
that page is displayed in "Quirks mode".

Based on a quick scan of the references[1], I can find obvious wrong 
with Firefox's "standards mode" interpretation of this input.  Which in 
my mind turns this into a standards question, namely will this behavior 
inhibit the adoption of HTML5?

As one possible alternative, the parsing rules for HTML5 could specify 
any  whitespace following a <pre> tag up to, and including, the first 
newline are to be ignored (or alternatively, hoisted outside of the 
<pre> to become a preceding sibling DOM element).  Those that wish to 
retain the visual appearance of a blank line would be encouraged to 
insert a <samp> or <code> tag.

This would potentially penalize the set of those who (a) are currently 
triggering a standards mode interpretation, (b) are NOT including a 
<code> or <samp> tag, and (C) actually wish for an initial blank line to 
be present.

I'm not sure what is right -- other than the desire to reduce 
impediments / excuses for people indicating that their documents are 
intended to be interpreted as standards compliant HTML5.

- Sam Ruby

[1] References:

http://www.whatwg.org/specs/web-apps/current-work/#the-pre
http://www.w3.org/TR/CSS21/text.html#white-space-prop
Received on Friday, 19 January 2007 15:29:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:31 UTC