[Bug 15359] Make BOM trump HTTP

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15359

--- Comment #17 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2012-07-06 20:03:09 UTC ---
(In reply to comment #16)
> I'm PRO that the user can override just about anything. The web and the
> software exists for the user, not the other way around.

1st sentence doesn't always follow from 2nd. And for some reason your are not
PRO the same thing when it comes to XML. I wonder why.

> As soon as the user changes any configuration option - including 
> installing an extension - all bets are off, and the spec.  should
> not have to - or try to - account for such scenarios.

A plug-in or config that ignore/extend a spec, do ignore/extend that spec. 

WRT your test file <http://203.59.75.251/Bug15359>:
>> You have not documented that what the browsers do lead to any problems.
> 
> It will lead to problems when this happens: some browser - maybe a 
> current one, maybe a new one - begins to obey the spec., [...]

Specs, UAs, tools, authors etc need to stretch towards perfect unity. When
there are discrepancies, the question is who needs to change.

>> For instance, the test page you created above, works just fine.
> 
> It "works" with current major browsers.

It even works with the highly regarded xmllint (aka libxml2).

> Not all user agents are browsers. For example, many validators
> treat it according to the spec., which means a fatal error.

Validators are a special hybrid of user agents and authoring tools which of
course need to be strict.

> Also, at least some older versions of some browsers do produce an 
> error on this page. Specifically, Epiphany 2.30.6 [...] a
> Gecko-based browser

Firefox 1.0 does not have that issue.

> Also, it doesn't "work just fine", because in this case, I, the author,
> expected something different.

Something should adjust - the XML spec or the UAs. Make it an 'error' as
opposed to 'fatal error', is my proposal. The result of an 'error' is
undefined.

>> You have not even expressed any wish to override their encoding.
> 
> That is a different argument, and not in the original scope of this bug. You
> were the one to first mention how important compliance with the XML 
> spec. is;

Your page contains encoding related errors, and your argumet in favor of user
override was to help the user to (temporarily) fix errors. So it perplexes me
to hear that this is a "different argument".

But if that is how you think, then I see no point it discussing your page any
more - which is why this is my last comment regarding that page.

> where is the proof that users receive documents with BOMs, yet nevertheless cause havoc
> by manually changing the encoding settings of their browser without knowing exactly 
> what they are doing, or at least understanding that doing so makes only them responsible for
> "shooting themselves in the foot".

So many layers of if … As an author, I sometimes want prevent users from
overriding the encoding regardless of how conscious they are about violating my
intent.

There is evidence that users do override the encoding, manually. And that this
causes problems, especially in forms. To solve that problem, the Ruby community
has developed their own "BOM snowman":
<http://intertwingly.net/blog/2010/07/29/Rails-and-Snowmen> The HTML5 spec does
as well say that documents, and especially forms, are not guaranteed to work
unless the page is UTF-8 encoded.

-- 
Configure bugmail: https://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 Friday, 6 July 2012 20:03:11 UTC