- 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>
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 
 and 
 where appropriate, use , where necessary (these should not be converted to spaces). Chris
Received on Monday, 3 March 2008 18:35:43 UTC