Autoprefixer: Support "appearance"?

[tobiastom]

I see that appearance is not supported equally through different browsers, but maybe at least some

appearance: none
-webkit-appearance: none
-moz-appearance: none

support would be nice?

[ai]

There are 2 problem with appearance:

1. It is non-standard vendor specific property. There is no any current W3C reccomendation about this property.
2. There is no Can I Use page.

I think that not there is no appearance, only vendors -webkit-appearance and -moz-appearance. Like non-standard webkit-tap-highlight-color or -webkit-touch-callout. So I prefer just write:

-webkit-appearance: none
-moz-appearance: none

What do you think about this property?

[tobiastom]

Yeah, as I mentioned I'm at least aware of your first point. The second point makes it even worse…

Not sure. I though implementing only appearance: none and translating it to the related rules would be ok. Now I'm not really sure anymore.

There is an issue in caniuse itself (Fyrd/caniuse#42), also without much activity.

[ai]

We now have updater.all, so we can implement it without Can I Use support. I reopen issue.

[ai]

But is -moz-appearance is really used now?

[porada]

To answer @ai’s question, Normalize.css uses the property a few times.

I wouldn’t allow appearance to be autoprefixed because:

1. There is no such thing as unprefixed appearance, and there probably won’t be. Converting appearance to -moz-appearance and -webkit-appearance makes it a mixin—a mixin that you can create yourself.
2. The same values for both properties might mean different things for the two browsers. And most of the times, you just target one (e.g. in a vendor prefixed pseudo-element that doesn’t have to be applied for the second browser).

[ai]

Agree. Close again :-).

[Grawl]

I just figured that Safari and Chrome in iOS 6 doesn't render inset box-shadow on inputs until -webkit-appearance: none is specified. What situation in Firefox Mobile?

[porada]

Still not a case for autoprefixing.

[Grawl]

Okay. But there is W3C Recommendation about appearance.

[ai]

@Grawl it is outdated spec, new revision doesn‘t contain appearance.

As I understand, in FF you can remove box-shadow by box-shadow CSS. So in your case it is only -webkit-appearance: none is needed.

[Grawl]

@ai I don't need to remove box-shadow. I need to apply it to input.

[ai]

@Grawl idea is same, as I understand FF doesn’t need appearance hack to it.

[jasonkuhrt]

@ai There appears to be data available now at Can I Use: http://caniuse.com/#feat=css-appearance

Since it is non-standard I think what we should do is let users enter this:

.foo { appearance: none; }

Which autoprefixer will convert into:

.foo { -webkit-appearance: none; -moz-appearance: none; }

We might even have a CLI flag such as --non-standard which would prevent autoprefixer from throwing warnings, otherwise autoprefixer would complain like so:

Warning: Used known non-standard property "appearance". See postcss/issues/43 for more information. If you want to use this property use the `--non-standard` flag.

OR... we could be opt-out instead of opt-in using a flag like --strict-standards

[jasonkuhrt]

Whoops, prematurely entered the comment above, make sure to re-read if you were reading in email client. Sorry!

[jasonkuhrt]

To be clear, I think if the data is available in Can I Use, we should support it. People _will_ benefit from it, and if the sticking point is "non-standard" then we just need to correctly _frame_/_communicate_ the feature; its an _interface_ issue. Saying "nope, we're not going to support this" is dumb if the underlaying data is available and _people are already using this anyways_.

[ai]

@jasonkuhrt create a PostCSS plugin for this non-standard cases, like @yisibl created CSS Grace for IE hacks.

I want to add this property too. But I can’t do it. Becuase after few years there will be no prefixes. And right now Autoprefixer works in that case, that you will remove it after few years.

If your CSS will contains appearance: none, it will be broken without Authoprefixer.

Of course, we can add warnings and extra options. But right now Autoprefixer is the slowest PostCSS plugin because of many extra non-standard cases. Autoprefixer’s code base is complicated, so only I maintain it. Extra option for this non-standard cases make it more complicated. And we have no really reasons for this victims.

You can really write PostCSS plugin for appearance by few lines of code:

module.exports = function (css) {
    css.eachDecl('appearance', function (decl) {
        if ( decl.value != 'none' ) return;
        decl.cloneBefore({ prop: '-webkit-appearance' });
        decl.cloneBefore({ prop: '-moz-appearance' });
        decl.removeSelf();
    });
};

Thats all! You need only README.md and tests. You can use postcss-size plugin a boilerplate.

[jasonkuhrt]

@ai Yeah that's all fair.

[ai]

@jasonkuhrt Do you want to release and maintain postcss-appearance plugin by snippet above?

[jasonkuhrt]

@ai Nope ; ) Which probably means its not important enough. If I change my mind I will let you know.

[ai]

@jasonkuhrt why not? it is about 30 minutes. Same time that you spend in this issue :).

[jasonkuhrt]

@ai Sort of, but it turns out we don't need this property anymore (right now). If the use-case comes back, maybe! : )

[yisibl]

CSS Grace maybe support its.

[ai]

@yisibl It will be nice.

[simevidas]

Update: https://github.com/postcss/autoprefixer-core/issues/14#issuecomment-93640159

[ai]

Becuase appearance with auto and none became a standard again, Autoprefixer 5.2 will have appearance support.

[ai]

Done https://github.com/postcss/autoprefixer-core/commit/dfc98f4cc873970518e897dfaf6e23771074d748