- From: <bugzilla@jessica.w3.org>
- Date: Tue, 27 Nov 2012 14:15:48 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15359 --- Comment #28 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> --- (In reply to comment #27) > (In reply to comment #22) > > Has anyone actually discussed Anne's > > proposal with the CSS and XML people? > > CSS Level 3 gives the BOM precedence (implemented in WebKit, Presto and > Gecko). Test case: > http://hsivonen.iki.fi/test/moz/bom/no-charset-attribute.html1251 > > For JS, Gecko experienced incompatibility with deployed content when not > giving the BOM the precedence in the case of JS, so I fixed Gecko to give > the BOM the precedence in the JS case. > > Frankly, XML should just follow HTML, CSS and JS behavior for consistency. > The worst that can happen is that previously ill-formed docs become > well-formed. If someone has a problem with that, I suggest they fight the > 5th edition first. > > I think this bug should go back into the resolved state without spec changes. CSS- and JavaScript-files are comparable to external entities in XML, for which XML 1.0 requires the use of the BOM, even for UTF-8 texts, if the replacement text of the external entity is to begin with U+FEFF. Clearly, the justification for that special rule, is a realization of the fact that when a zero with no-break space character occurs as the first character in a plain-text text, then, in a markup language that is biased towoards Unicode/UTF-8/UTF-16, then - in a conforming parser, the first such character *will* be interpreted as a byte order mark. Thus it isn't necessarily HTML that invented the wheel, here ... -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 27 November 2012 14:15:54 UTC