Re: [selectors] Reconsider to not drop whole selector list containing an invalid selector

On Sat, Jan 10, 2015 at 2:05 AM, François REMY
<francois.remy.dev@outlook.com> wrote:
> ± > Dropping whole selector list containing an invalid selector would lead
> ± > to many future errors.
> ± >
> ± > * Why not just to ignore the invalid selector styling?
> ± > * What is the benefit of dropping whole selector list? The performance?
> ± >
> ± > Today's vendor prefixes leaded problem:
> ± > @-webkit-keyframes,@keyframes{} is be shorter then to repeat whole
> ± > style list again and again. And repeating same thing leads to maintenance
> ± and performance problems.
> ±
> ± This is indeed a legacy mistake that we wish we could change, but can't.  Lots
> ± of people use this as a "feature" to do browser-targetting, by putting in a
> ± selector with a browser-specific pseudoclass that doesn't match anything; in
> ± other browsers, it'll force the entire rule to be dropped.  If we changed it,
> ± we'd suddenly break a bunch of pages by applying styles that weren't
> ± intended to apply.
> ±
> ± So, unfortunately, this has to stay the way it is.
> ±
> ± ~TJ
>
> Though I think the "repeat-with-various-prefixes" issue would have been eased if the group did adopt the "vendor-tag/vendor-bang" proposal which was made quite a while ago [1]. I'm still not sure why it wasn't pursued further, this is so much better than the statu quo. Duplicating @keyframes or @supports rules is a complete madness we could have avoided with this proposal.

All water under the bridge, since we don't recommend using any sort of
vendor-indicating anyway anymore.  (That's why that proposal wasn't
pursued, as well - it was made when we were coming around to the idea
that prefixes were an antipattern, and we went with "well, just don't
vendor-indicate at all" instead of trying to find a better way to
vendor-indicate.)

~TJ

Received on Monday, 12 January 2015 17:37:41 UTC