Restrict detects to unprefixed features #1082

Closed
ddprrt opened this Issue Oct 23, 2013 · 12 comments

Projects

None yet

4 participants

@ddprrt
Contributor
ddprrt commented Oct 23, 2013

Rad idea: I would love to see a Modernizr build option/release that just checks for unprefixed features.

Reasons behind that:

  • Major browser vendors (especially Google, Mozilla and Microsoft) follow the policy (see Blink Developer FAQ, Mozilla Statement in W3C lists) of just shipping unprefixed features in their browsers' stable releases. So 'unprefixed' became kind of a synonym for a stable feature. Prefixed features are in developer releases and just meant to fool play around and get a preview of things to come. Modernizr should also adopt this policy.
  • Current versions of major browsers already support plenty of CSS3 and HTML5 features unprefixed.
  • Older browsers, especially older mobile browsers, support modern features just prefixed, but in most cases they run crappy and have either huge performance issues, other implementation quirks or follow deprecated specifications. We should treat those browsers like old IEs and just give a presentation that they really can handle.

You can find a more elaborate (and maybe opinionated) statement here.

Anyhow, what do you think? Is Modernizr ready for that?

@patrickkettner
Member

I really love the spirit of the issue, but I can't imagine that ever being the case.

You are basically saying that if someone is using a device that supports a feature, but prefixed, that they should be forced to download a javascript polyfill in order to use the feature that they already support. That sounds a bit silly to me.

You are painting with very broad stokes when you say that older browsers "preform crappy" with prefixed things. Flexbox is still prefixed in chrome. Do you think that that should not be allowed?

I agree that prefix free is the future, but as a tool that people use to make-the-web-better :TM:, I think that this would do more harm than good.

@patrickkettner
Member

That being said, I am pretty sure you could quickly hack this by forking Modernizr and making prefixes.js return an empty array.

@stucox
Member
stucox commented Oct 23, 2013

The suggestion was for it to be a build option – which isn't completely infeasible.

The problem comes in cases where false-negatives (which is what you're asking for) cause problems… e.g. when loading a polyfill which then conflicts with the native implementation, or if a .no- class is used to provide a fallback but the feature-dependent code is allowed to be applied anyway.

Admittedly these should be few and far between for a developer who a) isn't using prefixes (or tools like Autoprefixer) or b) is diligent about ensuring they detect correctly before they use a feature, but still.

+1 for trying it on a fork and let us know how it goes!

@patrickkettner
Member

The suggestion was for it to be a build option

Ah! I apologize, I glazed over that option.

+1 for trying it on a fork and let us know how it goes!

consider that a +2. I'll be watching you blog for updates :]

@patrickkettner
Member

@ddprrt did you ever get a chance to dig into this?

@paulirish
Member

What result would you like?

  • console.warn() call if prefixed feature found?
  • return false if its only found prefixed?

cool ideas, but yeah i think this is a good experiment to try out first outside the library before baking in support for it.

@ddprrt
Contributor
ddprrt commented Dec 3, 2013

Sorry for the delay, kind of lost track of this one. Thanks for reminding me, @patrickkettner.
@paulirish actually console.warn would be a nice add-on, didn't think of that yet. I would've gone into the other direction and just return false if the feature isn't available unprefixed. And made available as an optional flag for custom builds. I would love to contribute to that one. Should it be a fork of the current master, or do you have some sort of experimental/developing branch?

@patrickkettner
Member

No problemo!
I think the best path forward for now would be for you to fork Modernizr and develop it on your own repo for now, with a pull once you have something you feel something solid.

@ddprrt
Contributor
ddprrt commented Jan 12, 2014

Hi everyone! I actually did something regarding that issue ;-)

It took me quite some time to figure out where to put that option. Or at least where it should be put best. Originally I wanted to have drop-in replacements for prefixes.js and cssomPrefixes.js, which are handled by the build. Then I figured out it would be a lot easier and more in tune with the rest of the library to just add another module which handles the configuration, this results in an build option called noPrefixes which is not set by default (see src/generate.js and lib/config-all.json), which includes noPrefixes.js, which in turn does all the configuration.

Anyway, you can actually watch my progress here. I won't do a pull request until I've thoroughly tested it and everyone agrees on the interface. (I was also jumping between a default usePrefixes flag and a non-default noPrefixes flag. Would be glad to hear some opinion on that)

I also did some (unit) tests, but I'm not quite sure how to integrate them with your qunit/nodeunit tests. If anyone can give me a lead where to integrate custom build tests, I'd be happy ;-)

@stucox
Member
stucox commented Jan 13, 2014

Looks like a sensible approach. By doing it at the prefixes.js level, Modernizr._prefixes in the resulting build will reflect that prefixes aren’t in use – which makes sense. Not sure if there might be cases where you would want to iterate through the prefixes though, and might want Modernizr._prefixes to be populated.

Given that expected behaviour would be for testAllProps() etc to test all the prefixes, a noPrefixes flag to disable this probably makes more sense than a usePrefixes flag to enable prefixes.

It’s also worth considering that currently testProp() doesn’t test prefixes but testAllProps() does – so this setting essentially means they’d both do the same thing. Not sure if that would be desirable/undesirable/confusing behaviour?

Re. unit tests – I think all of our tests operate off the same build config at the moment, which is something I’ve been meaning to address. Ultimately it’d be great if we could define a config as part of a test suite setup, and the suite then contains relevant tests. We’d need to ensure the teardown fully removes all trace of the current Modernizr build though, ready for the next suite to be run. Each suite (i.e. each set of tests requiring different config) should probably be separate files, with common functions/behaviour abstracted into shared/common files which can be reused.

@ddprrt
Contributor
ddprrt commented Jan 16, 2014

I looked into the unit test and tried to create a configured build in the browser, but ultimately failed on the qunit grunt task. I'd love to look into that topic even further and try some ideas if you like. But it's one hell of a task, and should be unrelated to this issue. Also interesting how issue #1184 turns out and might help with that.

For that one.. I'd be glad to have some input. Thinking of PRing my changes for in-depth discussion... are you ok with that?

@patrickkettner
Member

pr at any time, my friend

@ddprrt ddprrt added a commit to ddprrt/Modernizr that referenced this issue Jan 17, 2014
@ddprrt ddprrt adds "noPrefixes" build option to opt-out vendor prefixs #1082 6dc0594
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment