4 ms·
I rather see this: @supports (vendor-prefix) then apply vendor prefixes to all css rules not understood by the browser. End of nightmare.
by Kilimanjaro 14y ago
I rather see this:
@supports (vendor-prefix)
then apply vendor prefixes to all css rules not understood by the browser.
End of nightmare.
- nathan_long 14y ago>> to all css rules not understood by the browser I don't get it. It seems like you're saying, "if it supports the -moz prefix, it's FireFox, therefore I know that it doesn't support X and needs -mox-X." But that requires you to separately know that the browser doesn't support X - the very thing this is trying to solve. It's much simpler to say "if it supports X, use it." If the browser releases a new version that supports X, you don't have to do anything for those users to get the benefit. Did I misunderstand you?
- harlanlewis 14y agoThe progressive enhancement approach you describe does not address cases where an alternative should be provided for less capable browsers. The closest analog in existing tools might be YepNope - "a conditional loader for your polyfills." http://yepnopejs.com/ http://yepnopejs.com/ There's an argument to be made that this is unnecessarily reducing maintainability and increasing development complexity by building redundant functionality to account for edge cases, but there are scenarios where it's appropriate. Building modern web apps with a support gradient more inclusive than latest Webkit/Gecko will appreciate the tools.