`to()` conflicts with CSS3 linear-gradient syntax (and nib)
bryanforbes opened this issue · comments
I'm currently doing something along these lines:
@require 'nib';
@require 'rupture';
.some-thing {
background: linear-gradient(to bottom, #F8F8F8, #F4F4F4);
}
/* later on I use rupture, so I require it for a reason */This ends up generating the following:
.some-thing {
background: -webkit-linear-gradient(to(scale-point, anti-overlap, density, orientation, use-device-width) bottom, #f8f8f8, #f4f4f4);
background: -moz-linear-gradient(to(scale-point, anti-overlap, density, orientation, use-device-width) bottom, #f8f8f8, #f4f4f4);
background: -o-linear-gradient(to(scale-point, anti-overlap, density, orientation, use-device-width) bottom, #f8f8f8, #f4f4f4);
background: -ms-linear-gradient(to(scale-point, anti-overlap, density, orientation, use-device-width) bottom, #f8f8f8, #f4f4f4);
background: linear-gradient(to(scale-point, anti-overlap, density, orientation, use-device-width) bottom, #f8f8f8, #f4f4f4);
}One workaround I've used is to change to bottom to unquote('to bottom'), but that's not really in the spirit of nib. I haven't thought about it much, but it seems like the only solution aside from using unquote() is to change the name of to() and/or prefix all rupture functions with something to avoid conflicts with CSS features.
Ah man, this is really unfortunate. It makes rupture so much less clean to prefix everything, but this is definitely not an issue that we can live with. I wonder if maybe something like a "no conflict mode" like jquery has is a possibility, where you could turn it on if needed? I feel like the gradient to keyword is somewhat rare (especially seeing as this library has been in heavy use for quite a long time and this hasn't come up until now), and I'd hate to force everyone into more obtuse syntax even when they don't need it...
The to keyword is going to become more and more common since it has become the formal syntax for linear-gradient. I agree that prefixing the calls sucks and I was disappointed that this was happening. Another option might be to suffix the calls: to-width, from-width, between-widths. Something like that. The no conflict mode might be OK, but with to becoming more prevalent and being a standard CSS3 keyword, it's less appealing.
Hmm, rough times over here in rupture-land. Good call on the width postfix, this is a good idea. Would be curious to hear what @declandewet and @Coobaha think about this as well before making any moves.
well, we cant use object namespace in css blocks, like rupture.to right?
then 👍 for postfix, *-scale(s) seems more intuitive and close to settings. but we can have aliases like *-width(s) :)
Would really love to hear @declandewet weigh in on this one before moving forward!
from / to are already aliased as above / below - so we could just do away with from and to. I find the above / below syntax makes more grammatical sense anyway.
@declandewet That's an OK solution, except that I chose to use from() and to() because when I'm thinking about layout and CSS, the terms "above" and "below" are a bit ambiguous as global function calls: they could relate to z-index ("the menu needs to be above the content") or position on the screen ("the footer needs to be below the content"). I'd rather have an API that is less ambiguous and that I can hand to someone who isn't quite as familiar with stylus or rupture and they can figure out kind of what is going on.
Hmm, you raise a valid point there. Then perhaps the most optimal solution would be to change the names to to-width, from-width, etc. It is a breaking change, but it could suit well to prepare us for #38 (vertical scale) if we ever find a use-case - so it could be to-height / above-height, etc.
This sounds like a decent compromise. We can keep above and below as the main syntax, but also offer from-width and to-width as alternatives for people who prefer this. If anyone wants to tackle this and PR it in (@bryanforbes maybe?) that would be sweet. If not I'll make it happen later this week.
Also the docs site is due for an update although I know the readme is up to date, so that will be coming soon as well.
If I get a chance, I'll take a stab at it. I can't promise anything, though.
Hah, ok. I'll come back here in a week and finish it out if you can't make it happen.
But think of all the glory and community involvement happiness you'll get if you do 😉
I just realized exactly what needed to happen when I cloned the repo... I'll get you a PR hopefully by tomorrow.
magical ✨
btw, below and above is used in box-reflect
Oh man, for real? This is super unfortunate... I've never thought this before but as they add more and more to stylus I'm afraid it's ambiguity may be too much...
yeah, anyway this mixin renames is not a future bulletproof fix.. maybe we should open an issue on stylus for namespacing mixins? so stylus will be aware of rupture.to syntax and wont parse it like a selector?
Yeah might be worth doing. It's not definitely something they can fix, but probably worth making them aware of it at least. Want to open this up @Coobaha?
Thanks for fixing this (at least for now). Could you tag v0.4.1?
Hey @teohhanhui --sorry for the delay, just published this as 0.5.0, since this is a breaking change. It should be on npm now and ready to roll!