better legacy omega support? (E:first-child + E pattern as fallback for nth-child?) #118

Closed
tbredin opened this Issue Oct 1, 2012 · 3 comments

Projects

None yet

2 participants

@tbredin

moving into about my 4th site using susy having to support IE7 (and even sometimes limited support for IE6), and to support these browsers I've noticed I'm often using a pattern similar to the following:

li:first-child + li + li { @include omega; }

or

li:first-child + li + li,
li:first-child + li + li + li + li + li { @include omega; }

For modern browsers I can just use nth-child(3n) or similar, but to avoid polyfills (which I prefer to do) this solution allows omega to function in ie7 & 8. Being reasonably new to coding programmatically in sass I'm not feeling particularly confident about coding this up however, I might make a mess.. :(

I am aware that the E + E selector (technical term) isn't the most efficient but I'd assume it's still preferable to most javascript alternatives.

You might also say that we can soon drop these browsers (as google plans to soon with IE8..) but unfortunately here in New Zealand (and probably many similar countries) it typically takes a little while for national clients to catch up with the rest of the world in terms of browser adoption, so we certainly can't look at dropping support on these older browsers for a while yet.. (I expect to be supporting IE7 for at least another year >__< if not 2)

Thoughts?

@tbredin

One issue I see with replicating (for example) :nth-child(3n) as the E:first-child + E is that you'd have to find a way to set a sensible top limit on how many n's it will output up to, or you risk massively bloating your output - with a css selector that is generally considered to be pretty slow, no less.

I'm thinking a global variable or a mixin parameter could perhaps control this, $ie-n-ceiling or something..

Would probably need a global variable to toggle this output off as well, considering the potential it'd have to bloat output if not used sparingly - and I think it might be helpful to document it with a "to be used sparingly to avoid bloating output!" warning too.

@tbredin

I've also noticed that the current legacy ie hack (from the omega mixin) is still applied when you're using nth-omega, which (correct me if I'm wrong) seems like a waste of code since ie can't interpret nth-child anyway.

It is only one line - but on big projects this is exactly the sort of redundancy I'd try to keep to a minimum.

This considered, in the interest of cutting down unnecessary code, it might be wise for us to think about finding a way to skip the legacy output on nth-omega calls (which might mean duplicating the omega mixin code into the nth-omega mixin, but leaving out the ie fallback?)

I'm just a little unsure if I might have missed something here - perhaps the hack is needed in some edge cases?

@mirisuzanne
OddBird member

The nth-omega mixin handles all the possible css3 selectors (nth, nth-last, nth-of-type, last, first, etc). There is no good way that we could create fallbacks for everything here, and I would rather not lead people to expect bloated ie-fallback selectors where they are using CSS3. If you want to propose a specific mixin for building fake-nth-child selectors, I would consider including it as an optional mixin of it's own.

In the meantime, I fixed the legacy-hacks being output inside the css3 selectors. Good catch. Thanks for the help!

cbf7291

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment