- From: <bugzilla@jessica.w3.org>
- Date: Mon, 04 Oct 2010 06:56:03 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10954 --- Comment #4 from Henri Sivonen <hsivonen@iki.fi> 2010-10-04 06:56:03 UTC --- (In reply to comment #3) > (In reply to comment #2) > > What's the use case for serving format=flowed over HTTP? Wouldn't it make more > > The same as sending it per email, I guess. I think the IETF mindset of just copying the email stuff over to HTTP has been a mistake. (See CRLF line breaks and US-ASCII default for text/*, for one.) format=flowed exists because legacy email protocols wanted the payloads to have limited line lengths. HTTP has no such limitation, so it's OK to send long chunks of text between line breaks over HTTP. If you meant backwards-compatibility with UAs that don't soft-wrap long lines, I can see a potential use case there, but is there a reason to believe that Web authors who aren't IETF WG participants would use format=flowed over HTTP if UA supported it? > > sense not to put UA-removable line breaks in the text data and to make sure the > > styling of the pre allows the UA to wrap long lines? > > As far as I understand, that would be a change over what's being done today. A style change--not a DOM change. > > I worry that allowing something here without requiring it would expose a > > different DOM in different UAs. > > I'm not sure how the DOM exposed for something that hasn't got any support > today is really relevant. Suppose the spec said UAs are allowed but not required to implement a PLAINTEXT_flowed state alongside the PLAINTEXT state and could use PLAINTEXT_flowed for text/plain; format=flowed. The PLAINTEXT_flowed state removed line breaks preceded by a space. Now the DOM for text/plain; format=flowed resources would be different in UAs that do the allowed-but-not-required thing and UAs that don't. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 4 October 2010 06:56:05 UTC