Since autoprefixer changes intended CSS to actual CSS, I feel that it should also include https://github.com/luisrudge/postcss-flexbugs-fixes
Hm. Let's me think.
@luisrudge what do you think?
But we need to add Browserslist support to flexbugs-fixes.
I like the idea of merging, but I think adding browserslist support to flexbugs-fixes is way too much effort without too much of a gain
Aren't the flex bugs very specific to some browsers? So they can be hard
coded instead of using browser list?
On Wed, May 4, 2016, 19:01 Luís Rudge [email protected] wrote:
I like the idea of merging, but I think adding browserslist support to
flexbugs-fixes is way too much effort without too much of a gain—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/postcss/autoprefixer/issues/651#issuecomment-216932250
Wout.
(typed on mobile, excuse terseness)
Yes, they're very specific and well documented
So, why you din’t want to add Browserslist?
I feel it's too much of an effort without too much to gain, to be honest. Can you point me to an implementation of that, so I can check?
@luisrudge I can help you with Browserslist. Just add some machine readable data for all hacks about IE supported versions.
So I will use this versions in my PR to disable some rules according Browserslist.
The problem is that Autoprefixer uses Browserslist and all inner tools should use it too.
Can't you just apply the postcss-flexbugs-fixes plugin conditionally?
Nope, because people expect that Autoprefixer fixes thing only for needed browsers in browserslist config
Exactly my point. Can't you apply the plugin conditionally based on the browserslist config?
@luisrudge does all your fixes are for same IE versions?
Ouh, I don’t like this “mostly” ;). Maybe you add option to set a bug lists?
What do you mean by set a bug lists?
require('postcss-flexbugs-fixes')({ bugs: ['4', '8.1.a'] })
ok, that seems pretty straightforward
This feels like something that should stay as a separate plugin. Autoprefixer should do what it does brilliantly and just add prefixes where needed. It's trivial to add additional plugins to a PostCSS build when needed.
I agree that this is a bit beyond Autoprefixer's responsibility.
I would vote to mention this plugin in the doc (readme) of Autoprefixer, as it is a nice complement, instead. Simpler, more flexible for users.
I would also weight in favor of not including too much into Autoprefixer. So that it stays nice and predictable. It's really easy to pipe PostCSS plugins to our builds when needed, that keeps the "modular" idea.
On the other hand adding Browerslist support to postcss-flexbug-fixes seems like a good move.
Ok, fair enough, I'll change the issue title to be about linking to the plugin in the docs.
Actually, one of the flexbugs is that flex: 1 is interpreted differently by IE10, with the workaround being to expand to flex: 1 1 auto. Isn't that the same as the other browser-specific hacks for other things?
PR is welcome (anyway my English is bad)
PR for docs, flex: 1, or both? 😊
other browser-specific hacks for other things
Does Autoprefixer add hacks/fixes already? I thought it was just prefixing?
With regards to the flex shorthand, I'd vote for leaving it to the author. From the flexbugs repo:
If you have to support IE 10, the best solution is to always set an explicit
flex-shrinkvalue on all of your flex items, or to always use the longhand form (rather than the shorthand) in flex declarations to avoid the gotchas shown in the table above.
Seeing as there are two routes to fix the issue could it be too opinionated of Autoprefixer to always enforce one over the other? it might lead to some unexpected behaviour.
My vote is still to keep the flexbugs plugin an opt in feature.
Done a9c5c7e
Most helpful comment
I agree that this is a bit beyond Autoprefixer's responsibility.
I would vote to mention this plugin in the doc (readme) of Autoprefixer, as it is a nice complement, instead. Simpler, more flexible for users.