Duplicate property when using star-hack #306

Closed
Francisc opened this Issue Sep 22, 2012 · 10 comments

Comments

Projects
None yet
3 participants

Hello.

CSS Lint says Duplicate property '*display' found. for this bit of CSS:

display:inline-block;*zoom:1;*display:inline;

Which "polyfills" inline-blocks for oldIE.

Is there anyway around that?

Contributor

stubbornella commented Sep 25, 2012

display:inline;display:inline-block;*zoom:1;

Will work the same and not cause an error isn CSS lint.

Ah, thank you.
Still, the linter shouldn't warn about that even with the star-hack, I'd say.

Contributor

stubbornella commented Sep 25, 2012

As long as the two properties are next to each other, it shouldn't warn... It is warning you because zoom is between the two display, so it looks like a mistake.

If you get a warning for using the star hack with the two displays next to each other please do reopen the bug.

When they are next to each other, there is no warning.

I don't want to be stubborn (that's your nickname!), but even so, I still think the linter shouldn't warn about that.
Proximity of rules shouldn't be "something".

Thanks, Nicole.

Contributor

stubbornella commented Sep 26, 2012

You might be right in the case of * and _ hacks, since they are obviously targeting a specific browser.

On the other hand, if we don't have any way of knowing if someone did it intentionally, we can't really have a rule that checks for duplicate properties.

@nzakas what do you think?

The linter pointing out duplicates is very useful, but I'm thinking that if someone uses an asterisk or an underscore before a CSS rule, they are intentionally trying to target an IE version.

When looking for duplicates I'd differentiate between hacked and non-hacked attributes.
So *display, _display and display would not conflict, even if they are a few rules apart. (One might consider fixing IE at the end of the rules or at the start.)

But, for example, *display should be seen as a duplicate if used twice (so with the asterisk twice) in the same selector.

I know this isn't crucial though and in time it might even be irrelevant and obsolete as we slowly move away from old technology.

Contributor

nzakas commented Sep 26, 2012

I like the way the rule currently works. Basically, when duplicate selectors appear right next to each other, you know that it's intentional and it will be hard to miss if not. The concern with having to of the same selectors at different places in the rule is that it could be in error and if so you are far more likely to miss it because it's not located next to the other one. Since the star and underscore hacks effectively create duplicate property definitions, I think the way it works still makes the most sense. Yes, we are kind of saying that duplicate properties should be grouped together in order for us to know that you're not making a mistake, but I think that's a good trade-off.

Just my $0.02.

Hmm, this doesn't get any warnings though:

.selector{
    background-color:#000000;
    font-family:'hello slicknet',monospace;
    background-color:rgba(0,0,0,0.8);
}

It's up to you, but I would consider *property (and any hacked property) and property as separate properties just like font-weight and border-size are different because they do different things.

Contributor

nzakas commented Sep 26, 2012

@Francisc What version are you using? I just tried it on the live site and I get a warning for the second background-color.

Ah, I'm sorry.
I am using Sublime Text 2's SublimeLinter which has v0.9.8 I think.

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