- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 16 Nov 2010 13:46:49 +0100
- To: Anne van Kesteren <annevk@opera.com>
- CC: Maciej Stachowiak <mjs@apple.com>, "public-html@w3.org" <public-html@w3.org>
On 16.11.2010 13:41, Anne van Kesteren wrote: > On Sun, 14 Nov 2010 12:38:30 +0100, Julian Reschke > <julian.reschke@gmx.de> wrote: >> On 14.11.2010 12:35, Anne van Kesteren wrote: >>> On Sun, 14 Nov 2010 12:17:56 +0100, Julian Reschke >>> <julian.reschke@gmx.de> wrote: >>>> On 13.11.2010 22:49, Maciej Stachowiak wrote: >>>>> I don't have strong data on the compatibility impact of this specific >>>>> change, but when we diverge from both Firefox and IE, it is rarely on >>>>> purpose, and matching them has almost always fixed bugs, even if we >>>>> didn't know it at the time. >>>> >>>> I'm confident that it really doesn't matter in practice, in which case >>>> we should default on being consistent with the base specs. >>> >>> Because you are confident? Specifications are at the bottom of the >>> priority of constituencies. Better safe than sorry in my opinion. >> >> But how do you know it's safer when UAs currently do not agree on >> processing, and seem to get away with it? > > As Maciej indicated, they are starting to converge. Well, it's not clear that they *need* to converge (on a spec violation), and also not whether what they converge on is the right thing to do. >> Sometimes it *really* doesn't matter, in which case considerations >> like consistency and re-usability of code should be taken into account. > > It is funny that you say that while also advocating having separate URL > processors throughout the code. Do I? If you're referring to the URI-in-HTML permathread: my point of view is that we're confusing an pre-processing step with the actual parsing. Best regards, Julian
Received on Tuesday, 16 November 2010 12:54:08 UTC