- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 24 Dec 2012 19:28:11 -0800
- To: David Bruant <bruant.d@gmail.com>
- CC: Anne van Kesteren <annevk@annevk.nl>, www-dom@w3.org, Cameron McCormack <cam@mcc.id.au>, Bobby Holley <bholley@mozilla.com>
On 12/24/12 5:42 PM, David Bruant wrote: > Chrome has a relevant market share, so testing in Chrome is never > pointless. I meant in terms of figuring out what the spec says t odo. > If a web browser with relevant proves that their non-spec compliant > behavior doesn't break the web, then the spec becomes questionable. Sure. I'm just saying that in my experience this particular behavior on Chrome's (more precisely WebKit's) part breaks things for a number of users. Of course so does the complete lack of history traversal handling across document.open in WebKit. >> It's pretty crucial last I checked. There are various things broken >> in Chrome because of its behavior here. > Do you have examples of webpages in the wild? > If they are broken, why don't they bother fixing it? Because none of their users use Chrome, because it doesn't work on those pages. Classic chicken and egg. Plus it's actually impossible to "fix" short of not using document.open at all, which means a complete rewrite. I'd have to query Bugzilla for examples, but you can do that as well as I can. > Why is it web-compatible enough for Chrome? Are you sure it is? > Do they have a different definition? Yes. > if so, how does it differ? It differs because they want to be compatible with the sites their users already use while we want to be compatible with the sites our users already use, if nothing else. This is why we were just fine with not having a global scope polluter in standards mode, but apparently WebKit was not, for example. -Boris
Received on Tuesday, 25 December 2012 03:28:47 UTC