- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Tue, 26 Jun 2012 22:34:27 +0000
- To: Brad Kemper <brad.kemper@gmail.com>
- CC: Florian Rivoal <florianr@opera.com>, "www-style@w3.org" <www-style@w3.org>
[Brad Kemper:] > > > > > > Speaking for ourselves I think we have established we are willing to > > drop features to the extent there is a standard equivalent e.g. see > > the legacy IE filter property in > > IE10 [1]. I cannot say whether or when we would flip this particular > > switch at the Moment but in principle we have no opposition to > > dropping support for legacy features given solid interoperable standard > alternatives. > > I think webkit never drops anything though. I suspect that would cause them > drag down the advancement of logical sides in background-position (start, > end, head, foot), unless a way can be found for them to peacefully coexist > with background-position-x and background-position-y. Past/current WebKit policies should not really be a decision factor. The reason we suspect WebKit folks might object should be though: a large amount of existing content. If a new proposal were to extend the syntax that is already supported in a backward-compatible manner - i.e. existing content remains valid and renders the same - I don't see why anyone should object. Now, if the proposal involves a compat-breaking syntax makeover I suspect I would agree with such objections. But if we do need to break compatibility - e.g. because there is no good way to align the feature with current CSS requirements - then, as fantasai and Tab noted, why not address the use-case properly? Either we do not want to leave content behind and we must be backward-compatible. Or we want a long-term standard solution to spriting and we should not shoe-horn ourselves into background-position hacking. Wouldn't spriting be useful in non-background scenarios?
Received on Tuesday, 26 June 2012 22:35:07 UTC