- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 17 Nov 2011 12:05:02 +1300
- To: Brian Manthos <brianman@microsoft.com>
- CC: "www-style@w3.org" <www-style@w3.org>
On 11/17/11 11:06 AM, Brian Manthos wrote: > 1. Again, you're talking about cross-module. This is why I mentioned 27 and 28. My point is that *for an individual module* Level 3 vs. Level 4 has meaning. OK, agreed. > 3. Because people like to say "my v2011.11.16 browser supports selectors9 (which is at ED stage)" but they wouldn't find "my v2011.11.16 browser supports selectorsTotallyNotInteroperable" as fun to put in their advertising. Perhaps. I honestly couldn't care less about the difficulties UA vendors run into with advertising.... > 4. IMO, a responsible web developer should generally be using technology that is fully baked -- and intended to be interoperable -- rather than experimental. In practice, what web developers go with is "all UAs with sufficient market share implement it", which has nothing to do with unprefixing. And if a single UA has high enough market share, that stage is reached way before unprefixing, by the way. Yes, by your definition that makes them irresponsible. If we pretend otherwise, we're just setting ourselves up to fail. > At least for LOB sites. For hobbyist and exploratory stuff (csszengarden.com), different rules apply. It's quite common for what you call "LOB" sites to use all sorts of prefixed stuff right now; it's even commonly used incorrectly. Again, pretending that this doesn't happen is just setting us up to fail. > As such, having different levels for the "ready" and "not ready" portions of technology is important. I agree that we need a distinction between "ready" and "not ready". I'm not convinced that our current method of drawing this distinction is reasonable. > 5. I think you're making an argument for the ability for web authors to tag their markup such they can say, for example, "my page is written for selectors 3 and will break for selectors 4". Perhaps. No, I'm making the argument that the problem you seem to be worrying about already exists and none of the things being proposed make it worse. > 6. "CSSWG adds more values to a property" "The only way to prevent".... It's not the only way. Another way is to have the WG stop doing that. Well, sure. > 7. Closer, I hope. Same, I suspect not. I think close enough for now. At least we're talking about the same things now. ;) -Boris
Received on Wednesday, 16 November 2011 23:05:55 UTC