W3C home > Mailing lists > Public > public-html@w3.org > March 2008

Re: [whatwg] several messages about the HTML syntax

From: Krzysztof Żelechowski <giecrilj@stegny.2a.pl>
Date: Mon, 03 Mar 2008 19:20:40 +0100
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg@whatwg.org, "public-html@w3.org WG" <public-html@w3.org>
Message-Id: <1204568441.6878.21.camel@a1dmin.vola.spe.com.pl>

Dnia 02-03-2008, N o godzinie 23:02 +0000, Ian Hickson pisze:

> On Tue, 31 Jul 2007, Simon Pieters wrote:
> > 
> > Aha. I didn't think of testing attributes.
> > 
> > Safari preserves CRs in attribute values, both real and NCRs. CRLF 
> > pairs, LFCR pairs, CRs and LFs cause a single linebreak in the tooltip. 
> > In data, CRs don't cause linebreaks.
> > 
> > For title="", IE preserves CRs in attribute values, both real and NCRs. 
> > CRLF pairs, CRs and LFs in the DOM gets rendered as a signle linebreak 
> > in the tooltip. For value="", all types of linebreaks are converted to 
> > CRLF pairs. In data, only CRs cause linebreaks and LFs are rendered as 
> > spaces.
> > 
> > Firefox preserves CRs in attribute values, both real and NCRs. CRs are 
> > ignored and LFs are rendered as spaces in the tooltip. In data, CRs 
> > don't cause linebreaks.
> > 
> > For title="", Opera drops LFs in attribute values, both real and NCRs, 
> > and converts CRs (both real and NCRs) to spaces. For value="", CRs and 
> > LFs are preserved as written, both real and NCRs.
> > 
> > Personally, I think attribute values should be parsed the same way as 
> > data is parsed wrt linebreaks.
> 
> I agree.

I oppose.  

When I want to define a paragraph-style tool-tip, 
I am left with the following choice: 
either make the source code unreadable 
by making an excessively long line 
(this is also true for URI attributes 
but they are not expected to be readable)
or make the tool-tip ugly by inserting line breaks.  
(It cannot be done in an portable way 
because the width of the tool-tip window 
and the fount metrics at the viewer's UI are unknown).

I recommend: 
convert line feeds to spaces,
use &#8232; and &#8233; where appropriate,
use &#10;, &#13; where necessary 
(these should not be converted to spaces).

Chris
Received on Monday, 3 March 2008 18:35:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:13 GMT