Fix failing tests 4

[cvle]

With this PR our CI passes except for flex and IE + Edge issues.

• Support filter property for webkit/blink browsers
• Exclude font-variant-ligatures due to lack of caniuse data
• Exclude column-fill from browsers with no support
• Exclude mask-border-* props from browsers with no support
• Exclude image-rendering when not supported
• Exclude unsupported logical props from older firefox

Related PRs:

• https://github.com/Fyrd/caniuse/pull/3213
• https://github.com/Fyrd/caniuse/pull/3205
• https://github.com/Fyrd/caniuse/pull/3204
• https://github.com/Fyrd/caniuse/pull/3203
• https://github.com/Fyrd/caniuse/pull/3198
• https://github.com/postcss/autoprefixer/pull/795

[kof]

nice

[cvle]

I actually started implementing flexbox spec from 2009 but we cannot do it with the current API

[kof]

I actually started implementing flexbox spec from 2009 but we cannot do it with the current API

Maybe we also don't need to, we should see the browser usage for that old spec.

[kof]

merged

[cvle]

I looked through the statistics. Flexbox spec 2009 is used in 0,9% of browsers excluding the UC browser. Including the UC browser it's almost 10% (mostly india, china and indonesia).

[kof]

UC?

[cvle]

Though UC Browser is a pain in the ass to feature detect. I'd say lets proceed with current API and implement flexbox spec 2012 for IE & Edge.

[cvle]

It's a browser from china that is gaining world wide popularity but especially in emerging markets like India, China and Indonesia

[kof]

Wow, never heard of it. But yeah lets skip it for now.

[kof]

Does autoprefixer support that spec?

[cvle]

Yes and inline-style-prefixer too. The issue with our API is that to support the old spec we need to split flew-flow into two longhand props. We can't do that with our current API.

Though to really support the UC Browser a few hacks will probably necessary because they messed up stuff and made it hard to feature detect.

I will look into whether the 2012 spec for IE is compatible with our current API.

[kof]

Maybe we don't need to feature detect that stuff after all, but just resort for static map for the flexbox.

[cvle]

feature detection is easy, only the UC Browser is a bit tricky e.g. it accepts a flex-wrap property even though it does not support it xD but I believe there is a way to detect the UC browser too.

[kof]

feature detection is easy, only the UC Browser is a bit tricky e.g. it accepts a flex-wrap property even though it does not support i

Thats why feature detection can't be used there…

[kof]

I mean in a useful way

[kof]

so maybe we can have a static map for this case, if a prop is not there, we start feature detection.

[cvle]

As long as it does not affect others browsers, sure.

[cvle]

I still hope that at one point they will update to a newer Chromium version and then this would be a non issue. At least it is an evergreen browser.

[kof]

Yep, for this reason we should keep this logic in a separate file we can simply remove when this happens.

[cvle]

Are you in favor of changing the API to support the old flexbox spec?

[kof]

I am not sure what the changes are, but they are internal, right?

[cvle]

So currently we have this:

cssVendor.supportedProperty('animation')  // -webkit-animation
cssVendor.supportedValue('display', 'flex') // -webkit-flex

But we would need this

cssVendor.supported('flex-flow', 'row-reverse')  

{
  -webkit-box-orient: 'horizontal',
  -webkit-box-direction: 'reverse',
}

[kof]

https://developer.mozilla.org/en-US/docs/Web/API/CSS/supports

it returns just a boolean though.

[kof]

So in your example it returns an object, are you expecting that the user applies all returned properties/values?

[cvle]

Exactly, both need to be set in order to support the old spec. That's what came in my mind first. What are your thoughts?

[cvle]

Though it was more of an example to show you what is the problematic than an actual well-thought solution :-)

[cvle]

This would be closer to our current architecture, easier to implement and probably faster:

const prop = cssVendor.supportedProperty('flex-flow')  // ['-webkit-box-orient', '-webkit-box-direction']
if (Array.isArray(prop)) {
  prop.forEach(
    p => cssVendor.supportedValue(p, 'row-reverse'),
  )
} 
else {
  cssVendor.supportedValue(prop, 'row-reverse')
}

[kof]

Yeah this one looks a bit better, though its a breaking change. What if we introduce a supportedProperties(prop1, prop2, …) function which expect a number of properties and returns an array always. This method will be used by those who cares about legacy browsers and at some point it can be removed.

This way we keep supportedProperty interface as it was before, you pass a prop, you receive a prop. Same for supportedProperties, you pass a number of props, you receive a number of props.

Also it could be supportedProperties([prop1, prop2, …])

[cvle]

There is an issue with your proposal because when I have this supportedProperties('height', 'flex-flow', 'width') and I get ['height', '-webkit-box-orient', '-webkit-box-direction', 'width'], I wouldn't know how the new properties relate to the one I passed.

We could use supportedProperties(prop) that only accepts one prop and always returns an array and we keep supportedProperty for backwards compatibility.

[kof]

True. Another idea supportedProperty(prop, supportMultiple). This way we don't have to return always an array and it is explicit. My previous suggestion would lead to actually generating arrays always, even if there is no need. Now if supportMultiple is true, the return might be an array if needed.

[cvle]

That's good. Do you agree with the following?

supportedProperty(prop, {multiple: true})

[kof]

yeah, that is even better for the future

[kof]

by default multiple should be false