@font-face multiple src-definition throws unwanted duplicate property warning

[jjanssen]

Since 1.2.0 the duplicate property rule got introduced. When using the @font-face declaration you it requires use of multiple src declarations if you want to support version prior to IE9. Like in the following example:

@font-face {
    font-family: 'custom-font';
    src: url('custom-font.eot?3q6lb2');
    src: url('custom-font.eot?#iefix3q6lb2') format('embedded-opentype'),
    url('custom-font.ttf') format('truetype'),
    url('custom-font.woff') format('woff'),
    url('custom-font.svg?#custom-font') format('svg');
    font-weight: normal;
    font-style: normal;
}

The output from this is:
4:5 warning Duplicate properties are not allowed within a block no-duplicate-properties

I am not sure whether to completely file this as a bug. In the future this could be fixed by disabling linter through via source (#70).

On the other hand, when validating for a DuplicateProperty through the Ruby SCSS Linter it validates without any warnings.

[DanPurdy]

Firstly I feel for you, having to support IE8, we're often in the same boat! Secondly that looks like it should fail in scss-lint too going on what they say their rule should be doing.

For me if you need to support older browsers then the duplicate property rule should probably be disabled as there's no clean way we can deduce the context of these 'hacks', definitely in the future allowing you to disable the linter via source will help with this though.

But maybe src is a special case that should be allowed?

@bgriffith @Snugug what do you think?

[bgriffith]

We could add an exclude: [] option where you could pass it either just the parameter src or maybe a selector and an array of parameters like the following?

'exclude': [
  'font-face': ['src']
]

Thoughts?

[jjanssen]

Could that also cover the scenario when you have old-skool background fallback?

For eg:

div {
   background: rgb(200, 54, 54); /* The Fallback */
   background: rgba(200, 54, 54, 0.5); 
}

Not necessarily asking too put much effort in it. I could disable the rule of course for the time being.
But maybe it is something to consider. But that is up to you guys 😉

[Snugug]

With @font-face specifically, I use the Fontspring Syntax which doesn't require a duplicate property (below) but I would be OK with an ignore property to specify duplicates that the property should ignore (in much the same way mixin-before-declaration works.

@font-face {
  font-family: 'Graublau Web';
  src: url('GraublauWeb.eot?') format('eot'), url('GraublauWeb.woff') format('woff'), url('GraublauWeb.ttf') format('truetype');
}

[bgriffith]

I'd be happy to implement the ignore functionality. I think the added flex would only enhance the rule.

[davegreenwp]

I was digging around grunt-contrib-cssmin the other day and found that clean-css (which it's a wrapper for) accepts a 'compatibility' option with values such as 'ie7', 'ie8' etc.

This might be the way to approach it? Treat it as a compatibility option?

I didn't want cssmin to remove duplicates from the final CSS as I wanted to retain my px fallbacks for rem sizes. It's not an apple for an apple, but it's fundamentally the same situation.

[DanPurdy]

Wouldn't the compatibility options just disable this rule effectively though? I don't think we really want to go down the road of browser compatibility versions as even within those peoples requirements will differ.

For example the rem / px example you gave, some people will absolutely want to declare rems and pixel fallbacks whereas others will be happy to use a gulp-plugin for example in their workflow to automatically pump an IE px fallback stylesheet out. Giving people the options to define their requirements rather than providing multiple defaults seems like the best way to achieve this.

Also on a related note, clean-css nearly caused me to throw my laptop out the window today when they for some reason started converting somepx values into pc or pt, in their latest version.. crazy.

[davegreenwp]

@DanPurdy On reflection I think you're right. In principle multiple defaults works in many cases but here it's probably best to give them a more granular level of control. Haha px to pc/pt sounds insane!