Doesn't properly generate input placeholder rules

[necolas]

source:

input::placeholder { color: black; }
input::-webkit-input-placeholder { line-height: 16px; /* fix chrome bug */ }

output:

input::-moz-placeholder { color: black; }
input:-ms-input-placeholder { color: black; }
input::placeholder { color: black; }
input::-webkit-input-placeholder { line-height: 16px; /* fix chrome bug */ }

expected:

input::-moz-placeholder { color: black; }
input:-ms-input-placeholder { color: black; }
input::-webkit-input-placeholder { color: black; }
input::placeholder { color: black; }
input::-webkit-input-placeholder { line-height: 16px; /* fix chrome bug */ }

I'd expect to be able to "extend" the generated webkit rule (in the example), rather than have it completely omitted by AP.

[ai]

I understand, but you want Autoprefixer to be too smart and understand does vendor hack (like input::-webkit-input-placeholder here) append rules or override rules ;).

Current logick is simple. If you write vendor hack, Autoprefixer will not add own.

We can add more code, try to look inside rules. But I think, it will be bad for code climate and overengineering :).

But I open for PR :).

[necolas]

I think that makes sense for properties, but not for pseudo-elements.

[ai]

I understand, that you have some point, but them come another user and say, that he want different logic ;).

[necolas]

It's the CSS language logic.

[ai]

I mean, that somebody may need miss some property in hack selector. How do I know, that you need color for webkit in your example?

[ai]

Or maybe we should remove too smart logic and not detect hacks for selectors?

Main problems is when browsers well start support placeholders and will read both prefixed and unprefixed rules.

[necolas]

How do I know, that you need color for webkit in your example?

What I'm thinking is that you don't need to; you pretend like it isn't there and generate the full set of rules.

Main problems is when browsers well start support placeholders and will read both prefixed and unprefixed rules.

How would that be different than having them apply 2 separate vendor-prefixed rules (see my desired output example)?

[lydell]

Could ::placeholder:not(::-webkit-input-placeholder) {} work, perhaps?

[ai]

I will change logic for selectors only in 1.1, because it will broke current API.

[necolas]

OK sounds good. Might be something to get wider feedback on before a public release too. Thanks for considering it :)

[necolas]

Yep, this is not working properly for us at Twitter. Say I have 2 files. One uses prefixed placeholders (or has them generated in place), the other uses ::placeholder to override them. If they are concatenated and then passed to AP, AP doesn't generate any new placeholder prefixes because it finds prefixes used in existing selectors, so the resulting "override" CSS is not as expected.

[necolas]

Or even the same file. You might ask "why", but this is what a bundle looks like when you append override rules for experiments.

Source:

/* from default.css */

input::placeholder { color: gray; }

/* from override.css */

input::placeholder { color: black; }

Output:

/* from default.css */

input::-moz-placeholder { color: gray; }
input:-ms-input-placeholder { color: gray; }
input::-webkit-input-placeholder { color: gray; }
input::placeholder { color: gray; }

/* from override.css */

input::placeholder { color: black; }

Clearly, if you expect the unprefixed ::placeholder to override due to the CSS cascade, then AP should be generating the prefixed selectors again. Or de-duping and putting the prefixed versions next to the last instance of the selector.

[ai]

Hmmm, really I totally forget about this. Moving property logic to selectors is a bad idea :).

[ai]

There will not be hotfix today :(. We need more smarter check to prevent adding prefixed selector again, when in some cases we call autoprefixer again.

But I can use logic from properties, where we view for prefixed selectors only on upper unprefixed one (also it will be faster).

For hostfix today you can put next placeholder in any at-rule to create new context, like:

@media all {
  input::placeholder { color: black; }
}

I will fix it on this or next week and them you can remove your hack.

[necolas]

We need more smarter check to prevent adding prefixed selector again, when in some cases we call autoprefixer again.

Yeah that definitely adds to the difficulty.

Thanks for the hack! That works for now.

[ai]

Done 42a6539

• Now Autoprefixer try to group selectors (prefixed can be directly before unprefixed) and remove outdated selector only if it in group.
• Don’t prefix selector only if prefixed is in group, not in all CSS.
• Prefix selector even if directy after unprefixed selector will be prefixed hack.

[ai]

I try to release 1.1 with this fix at Monday.

[necolas]

Thanks so much for this!

[ai]

Version 1.1 with this fix was released today.

[hoIIer]

tldr: what do I use for placeholder? ::placeholder?

[ai]

@erichonkanen ::placeholder

[hoIIer]

@ai thanks

[nikuideveloper]

reduce the padding in textbox. i am able to get the placeholder in firefox