- From: Domenic Denicola <d@domenic.me>
- Date: Fri, 21 Nov 2014 22:32:07 +0000
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: whatWG <whatwg@whatwg.org>
From: Sam Ruby [mailto:rubys@intertwingly.net] > I guess I didn't make the point clearly before. This is not a waterfall process where somebody writes down a spec and expects implementations to eventually catch up. That line of thinking sometimes leads to browsers closing issues as WONTFIX. For example: > > https://code.google.com/p/chromium/issues/detail?id=257354 > > Instead I hope that the spec is open to change (and, actually, the list of open bug reports is clear evidence that this is the case), and that implies that "differing from the spec" isn't isomorphically equal to "problematic case". More precisely: it may be the spec that needs to change. For sure! But, I would like to see where the spec differs from implementations, so that I can see what parts of the spec needs to be changed. Right now, when I read "user agents with differences: testdata chrome firefox ie" versus one that reads "user agents with differences: ie safari", I can't tell which user agents are aligned with the spec and which aren't. So I can't tell if the spec needs to change, or if it doesn't. I'd prefer some kind of view where it said "user agents with differences from the spec: x, y, z". Then if the answer was "chrome, firefox, ie" clearly the spec needs to change; if the answer was "chrome" then clearly Chrome needs to change and we can leave the spec alone. I'm gathering this is very different from the data the table is currently showing, but it seems I don't actually understand what the table is currently showing anyway, so I don't understand how I could use the table's current data to guide spec changes.
Received on Friday, 21 November 2014 22:32:35 UTC