should not alphabetically sort -#{vendor}- properties.

[sds]

should not alphabetically sort -#{vendor}- properties.

[sds]

In general, manually coding vendor properties is probably a smell. You should be using a framework like https://github.com/chriseppstein/compass so that you never need to think in terms of vendor-specific prefixes. Writing something like

@include border-radius(10px);

Is so much nicer than the alternative boilerplate multi-line declaration.

Having said that, you may have very good reasons for needing to manually write vendor prefixes. It sounds like the underlying problem is you are writing SCSS properties with interpolated names, e.g.

-#{$some-prefix}-#{$stuff}: $some-value;

It seems reasonable to me to simply ignore the sorting of properties that contain interpolated Sass script, since their names are dynamically evaluated.

Any thoughts?

[lifeiscontent]

I totally agree with you there,

some parts of our site us the -ms-filter and filter properties though, to support specific things in IE.

[sds]

Perhaps I'm misunderstanding (or just lacking context), but is there a strong reason you can't use Compass' cross-browser filter implementation? http://compass-style.org/reference/compass/css3/filter/

We don't make significant use of that particular mixin, so I'm not sure of valid situations where you really need to manually write vendor-prefixed properties, but in general it feels like you should always use a Compass mixin where possible.

Sorry if I seem to be hammering the same point, I just want to make sure there's a real need here. Thanks for keeping the dialog going.

[zakiwarfel]

There's also this
http://leaverou.github.io/prefixfree/

Todd Zaki Warfel
[email protected]
[phone]

On Jun 6, 2013, at 5:34 PM, Shane da Silva [email protected] wrote:

Perhaps I'm misunderstanding (or just lacking context), but is there a strong reason you can't use Compass' cross-browser filter implementation? http://compass-style.org/reference/compass/css3/filter/

We don't make significant use of that particular mixin, so I'm not sure of valid situations where you really need to manually write vendor-prefixed properties, but in general it feels like you should always use a Compass mixin where possible.

Sorry if I seem to be hammering the same point, I just want to make sure there's a real need here. Thanks for keeping the dialog going.

—
Reply to this email directly or view it on GitHub.

[lifeiscontent]

@zakiwarfel prefixfree doesn't isn't related in this context, I'm talking about the very specific IE filter properties.

[lifeiscontent]

@sds that isn't the same thing. that is for supporting the new CSS3 filter features.

[lifeiscontent]

@sds I am really interested in using scss-lint full time, for all of my code, and I think the reason I've been hitting so many edge cases is because I truly use almost, if not all the features scss allows.

I really like what you guys are doing, and I will continue to submit bug reports as they come across.

you guys have been very awesome with response time as well. so 🍻 for you guys.

[sds]

After talking this over with a few members of the team, including our in-house CSS expert, we'll probably end up implementing something different than a straight-up ignore of vendor-specific properties.

Instead, what we felt was possibly worth implementing was a lint that enforces that all vendor-specific prefixes come before their non-prefixed form, sorted in alphabetical order of the prefix. For example, we'll enforce the following order:

border: 0;
-moz-border-radius: 3px;
-o-border-radius: 3px;
-webkit-border-radius: 3px;
border-radius: 3px;
color: #ccc;

...where we do the regular alphabetical ordering of properties, but when the property is vendor-specific we'll make sure that the final non-prefixed property is the last in the list.

@lifeiscontent, does this seem reasonable to you?

[lifeiscontent]

@sds this is exactly the solution I would invision, great call 👍