Modernizr is a JavaScript library that detects HTML5 and CSS3 features in the user’s browser.

Let's use this ticket just to explore the ideaspace. Basically... is there a way to detect a mouse user?

just random notes on detection in this area:

touch evts & input exclusivity

Can't make assumptions about input anymore...

• Just because touch events are present doesn't mean the user is primarily using a touchscreen. Or that there is no mouse.
• Just because there are touch events supported doesn't mean :hover styles will never be triggered.
• Just because there is a mouse doesn't mean people can't also touch the screen.
• ~33% of iPad users with VoiceOver enabled use an attached keyboard. (@stevefaulkner said this, iirc)

http://www.html5rocks.com/en/mobile/touchandmouse/ by @cwilso is a must read for this space.

(and when this ticket says "mouse user" it means currently using a mouse but may mid-session switch to touch)

mousemove

• mousemove doesnt fire as a touch events user uses the page...
• however it does fire in this sequence when a user taps the screen
• so maybe we can test the difference between the two?
  • evt.isTrusted from DOM 4 events may be interesting. Implemented in FF, but not in Webkit. isTrusted is kinda untrusted right now though
    • hypothetically it could tell the diff between the simulated mousemove and real one
  • in my tests: evt.which was 0 in real mousemove and 1 in fake mousemove (part of the tap). Why? I have no idea.
  • the first time it fires, does mousedown fire <50ms after mousemove fired? (following the tap evt sequence) downsides galore: race condition. yucky detection, but .. might be worthwhile?

:hover

:hover styles are never triggered by a touch user except for a brief moment during a tap.

mouseenter / mouseleave

• They are not implemented in WebKit or FF
• they were in DOM3 events but not the dom4 events draft

cc @robcolburn @roblarsen

Anyone please add any notes here that aid in the pursuit of detection of mouse users. Differences in event objects, user behavior heuristics, etc.

We have experienced that custom, compressed modernizr builds crash IE8, resulting in showing this address in the addressbar: res://ieframe.dll/acr_error.html/#

This is not happening in the compat modes of IE7 or IE8 in IE9.

Unfortunately we can't really test this any further as we don't have a machine with IE8 installed. The machine we experienced this on, was a Windows XP machine of one of our partner companies.

Using the uncompressed development version does work without errors: http://www.modernizr.com/downloads/modernizr-2.0.6.js

OK, here we go!

I had a chance to go through the whole system. Cleaned up some unused files, reorganized, and rewrote the build system as promised.

This changes the API, which I'd like to get your feedback on. The cafe I'm working at is closing, so I'll expand a little on the benefits/reasoning tomorrow. Also, tests are currently broken but I'd like to nail down the API before I fix them.

The positive code is mostly comments, readme, and modularization. And the new CLI.

Can you explain what the use of generate-meta is? I've broken it a little and will fix up; knowing it's purpose will help with that.

Everything's documented in the readme.md. More tomorrow.

I have encountered a weird issue with Firefox 15.0.1 on Windows 7 64bit. Thankfully this is more of an annoyance and not as severe as the recent Safari bug that I read about, but I still think it is worth my reporting. Something changed between 2.6.1 and 2.6.2 that now results in the browser window jumping to the top of the page if you refresh/reload the page (whereas the correct behavior would be for the page to reload to the original scroll position). Going back to my copy of 2.6.1 fixes the issue in Firefox, so it is somehow related to a change in Modernizr (though that is not to say that it is definitely a bug). It appears that the problem does not appear in Chrome, Safari or IE9 (all on Win7).

I've done some experimenting and narrowed down the config that results in the above behavior to be the following: http://modernizr.com/download/#-touch-teststyles-prefixes

I believe the culprit is in the touch portion (or perhaps a combination of things) because I did a test with just http://modernizr.com/download/#-prefixes and that was fine, and had done another test that included teststyles which was also fine.

I also did a test on another installation of Firefox and also with Add-Ons Disabled to try to verify it wasn't just my particular setup.

As I said, this is more of an annoyance than an urgent thing, but it would be nice to have it fixed at some point.

Thanks! :)

I've removed android browsers until issue is resolved.

IE7 is throwing the infamous operation aborted error, I tried this in a saucelabs IE7 and didn't get it.

IE Mobile e.g. doesnt expose webkit touch events but is a touch device..

what exactly does Modernizr.touch imply? We should agree so we can document it.

IE 11 has recently made an error with Flexbox. It was / still is working fine in IE10, but the latest browser has made the CSS Feature unusable for those users.

What happens:

When an image is a child of a flex item, it doesn't resize the height to auto when specified, which doesn't keep the correct constraints when resizing for responsive elements.

Attached is an example of this:

Live example of the code in the screenshots: http://codepen.io/boostnewmedia/full/kvtoF

Phil Walton ( Solved by Flexbox ) said "philwalton: @themiketee the most annoying thing is I reported it well before IE11 shipped and it didn’t make it in. Months later, it’s still not fixed."

Known issue for Microsoft dating back to 10/1/2013: https://connect.microsoft.com/IE/feedback/details/802625/min-height-and-flexbox-flex-direction-column-dont-work-together-in-ie-10-11-preview#tabs

They have dropped the ball again.

With #486 taken care of we have individual files for all core detects. Now we have to declare dependencies. @SlexAxton suggested AMD and there seems to be consensus on that. He suggested cheating a lil' bit by assigning results directly to Modernizr global.

@paulirish asked Alex "for your AMD proposal, why wouldnt we return inside the modules and pull in the value as the dep?" And he said that's so we can ship the built version without any wrappers at all (almond or otherwise).

Couple examples:

define('canvastext', ['canvas'], function () {
  var ret;
  if (Modernizr.canvas){
    ret = document.createElement('canvas').getContext('2d').fillText == 'function';
  }
  Modernizr.canvastext = !!ret;
});

or CJS-style

define(function (require) {
  require('canvas');

  var ret;
  if (Modernizr.canvas){
    ret = document.createElement('canvas').getContext('2d').fillText == 'function';
  }
  Modernizr.addTest('canvastext', ret);
});

@SlexAxton @paulirish @ryanseddon @patrickkettner @joecritch

Hi folks, thought we could do with a final decision on this.

We’ve agreed that v3 won’t distinguish between “core” and “community” detects. So, what goes in the development version?

• Do we still have a dev version, or encourage people to use a custom build (or grunt-modernizr) from the start?
• If we do have a dev version, do we put every detect in the dev version? This would be ~60kB min’d (and growing), taking about 300ms (including async tests) on my MBA

Obviously the concern is that some may deploy a heavy dev version to production… then we’ve contributed to someone having a bit of a shit experience on the web.

Also worth considering what kind of build we’d expect HTML5 Boilerplate to include, as that’s probably an easy way to accidentally end up with a heavy Modernizr dev build in production.

Hi,

In my example on IE10 Modernizr.flexbox return true but looks like IE10 it doesn't understand flexbox css. Or maybe I'm doing something wrong?

Please take a look: http://jsfiddle.net/wGBL8/5/

(On safari Modernizr.flexbox return false, but everything looks fine)

We’ve mentioned this a bit in the past, so let’s look at it properly.

It’d be supercoolandawesome if devs can take advantage of our internal AMD structure to specify individual detects as module dependencies, e.g.:

define(['modernizr/websockets'], function () {
    if (Modernizr.websockets) {
        // Do something with websockets
    }
});

One option would be a custom RequireJS plugin. But it feels like we should be able to do it without that too.

What would be involved in making this work?

Bumps qs from 6.7.0 to 6.11.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps decode-uri-component from 0.2.0 to 0.2.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Type of bug Modernizr adds an empty prefix class to the <html> tag when using Add CSS classes option with prefix.

How to Reproduce

1. Select the Webp under the DOWNLOAD tab.
2. Goto OPTIONS and select minify then in the input box for Add CSS classes add has-
3. Download the build file.
4. Include the modernizr-custom.js in the head section of the website.

Expected behavior Expected classes in the <html> tag has-webp has-webp-alpha has-webp-animation has-webp-lossless

Actual behavior Classes added to the <html> tag has- has-webp has-webp-alpha has-webp-animation has-webp-lossless

Which feature do you want to detect? Support for animated AVIF images, a.k.a. AVIF image sequences.

Which browsers do support this feature? https://caniuse.com/avif

Although all major browsers support AVIF for still images, only Chrome supports animated AVIF. Per @jensimmons’s tweet, Safari will support animated AVIF in Safari 16.1 (scheduled for release in October 2022).

Until all browsers advertising AVIF support also support animations, this poses an interoperability problem where developers cannot rely on the browser to do format selection by using <picture> + <source>. A JavaScript feature test would help bridge this unfortunate gap.

How could it be implemented? There’s existing tests for animated image formats:

• Animated PNG: https://github.com/Modernizr/Modernizr/blob/master/feature-detects/img/apng.js
• Animated WebP: https://github.com/Modernizr/Modernizr/blob/master/feature-detects/img/webp-animation.js

I suspect we could follow these examples.

Additional context A feature test for (static) AVIF support was added in #2539.

I'm trying to compile modernizr using npm and a json file. I've added "canvas/canvas" as feature-detct, as reported in the configuration provided in the documentation,

However, I obtain the error "no such file or directory" when I try to compile the library. The missing file is 'feature-detects/canvas/canvas.js' which is not shipped with the npm installation of modernizr but is present on the github repository.

I'm using 3.12.0 version (latest on npm)

Question

Can a specific test be created to check if a browser can be triggered/forced to store user data permanently?

Description

There is a Persistence permission in browsers to flag data for being persisted permanently in the users' browser.

In, e.g., Firefox https://developer.mozilla.org/en-US/docs/web/api/storagemanager#browser_compatibility, one can use the StorageManager to ask for that permission.

From what I see, there is currently no specific test in Modernizr that can be queried to get info if this is available on the user's browser.

From what I've read, it uses the StorageAPI and refers to a "box modes". This mode can either be "best-effort" or "persistent".

"best-effort" means that the data could be removed if the user runs low on disk space. "persistent" won't wipe that data, even if disk space is low.

All I found atm is

• "quotamanagement", which is not sufficient enough to judge if data can be persisted
• "indexeddb", which on its own can be both "best-effort" or "persistent"

Problem

• Firefox will ask the user for permission if he wants to store data permanently.
• Brave will also ask, but in addition will ask for how long the data shall be stored.
• Chrome, however is a little bit intransparent on this. It will determine if it's allowed based on the user activity. While it's not clear to me what this means in detail. But if e.g., the user has given an allowance for 'notification', Chrome will also allow persisting data.
• For mobile browsers I haven't tested it with all browser/os combinations, but e.g. on Safari iOS it's not possible at all.

References

https://storage.spec.whatwg.org/#persistence

https://caniuse.com/mdn-api_permissions_persistent-storage_permission

https://web.dev/persistent-storage/