- From: <bugzilla@jessica.w3.org>
- Date: Mon, 21 Jun 2010 14:17:55 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9965 --- Comment #4 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2010-06-21 14:17:55 --- (In reply to comment #3) > > class=" class1 class2 > > class3 " > > > > as [o]pposed to this: > > > > class="class1 class2 class3" > > Those parse to the same DOM in XML but to different DOMs in text/html. The Did you *mean* "DOMs" in plural about 'text/html'? For what it is worth, there *does* seem to be differences with regard to how text/html browsr treat white space: IE8 in IE8/edge mode seems to handle the first example above more and less as XML parsers do (that is: if I can trust Live DOM viewer). Wheras IE8 in IE7 mode takes care of all space characers, but convert the linebreak to a space (if I can trust Live DOM Viewer). Trusting Live DOM Viewer here, seems risky, though. In Opera, Firebug, Safari, then Dragonfly, Firebug, WebInspector showed that linebreaks were preserved, in text/HTML mode. > first case is not polyglot, since there's an observable DOM difference between > HTML and XML. I probably agree, when it comes to tabs, line feeds and carriage returns. As you said in Comment #1: > The correct thing to say here is: > Tabs, line feeds and carriage returns in attribute values must be encoded as > numeric character references. But I question what you said about consecutive spaces: > At least every second of consecutive spaces in > attribute values must be encoded as numeric character references (so that there > are no consecutive literal spaces in attribute values). This is because XML > parsing doesn't preserve unescaped tabs, line feeds, carriage returns or > consecutive spaces in attribute values. When I consulted Dragonfly, Firebug and Webinspector, then spaces *were* taken care of in both XML and text/HTML. So what is this claim based on? -- 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, 21 June 2010 14:17:58 UTC