more about #HTML5 mouse events.
on 02026-01-05This is apparently the #HTML5 thing to use to figure out the frame of reference within an element (such as a <canvas>) where a mouse or touch event is happening. Literally all of the element properties you can see in the DOM inspector are the wrong thing.
10 years ago Mozilla changed #IndexedDB to have non-durable #transactions by default, adding a “readwriteflush” mode for durable transactions. #HTML5
on 02025-12-27Disqus hasn’t yet lost Jonas Sicking’s comment about the synchronous API to #HTML5 #IndexedDB: “The reason we’re not permitting access to the sync version in the main thread, i.e. in Window environments, is that synchronous IO is terrible for performance. This would remain the same no matter what syntax is used, so would not be affected by a switch to a module based syntax.
However any environment that isn’t the main thread should be able to use the sync version. That isn’t affected by weather we use module syntax or not though. We could allow access to the synchronous API to any non-main thread environment. Currently the only such environment is web workers. If more are added in the future we might be able to add them there too, independent of if we use modules or not.” He also comments on how their #transactions work.
on 02025-12-27Jonas Sicking (an #HTML5 #IndexedDB spec author) explains how its #transactions work; normally they’re pretty transparent, and you can, like, read some data and then write some data in the callback when the reads succeed.
on 02025-12-27#HTML5 #IndexedDB #transactions commit implicitly when you return to the event loop without any pending requests, which seems error-prone
on 02025-12-27MDN explains that #HTML5 #IndexedDB only has an asynchronous API, although the section header may be a remnant from the draft when it had a synchronous one.
on 02025-12-27#HTML5 #IndexedDB no longer has a synchronous API
on 02025-12-27It seems like the #IndexedDB draft used to have a synchronous API for use in Web Workers which was eventually removed. #HTML5
on 02025-12-27#Tutorial documentation on the #HTML5 Fetch API.
on 02025-11-27It’s pretty easy to submit POST data with the #HTML5 Fetch API.
on 02025-11-27The #HTML5 Fetch API supports #CORS, so you can talk to third-party servers.
on 02025-11-27interesting, #HTML5 lets websites register URL protocol schemes that start with web+. web+wikipedia:? web+latlon:?
on 02023-02-07#Firefox #browsers consider localhost and file: URLs to be "secure contexts" for #HTML5 APIs like getUserMedia and service workers and custom protocol handlers
on 02023-02-07Mozilla’s official documentation for the #HTML5 #getUserMedia API for accessing cameras in #browsers; this has example code for things like front and back cameras. Apparently it’s deprecated, but I don’t know what alternatives exist.
on 02023-02-07how to use the #HTML5 #getUserMedia API for camera access in #browsers, step by step
on 02023-02-07the #HTML5 camera API #getUserMedia in #Firefox #browsers requires HTTPS (or localhost) since 02019; the about:config flag to allow otherwise is media.getusermedia.insecure.enabled
on 02023-02-07example code for #HTML5 camera API (#getUserMedia) to detect cameras (in this case for a #barcode #QR reader)
on 02023-02-07also in #Chromium #browsers, the #HTML5 camera API (#getUserMedia) can be blocked from a localhost port in chrome://settings/content/camera.
on 02023-02-07#Chromium #browsers allow access to the #HTML5 camera API #getUserMedia from localhost in JS, but not from file: URLs (even if you explicitly allow it yourself), though there's also chrome://flags/#unsafely-treat-insecure-origin-as-secure.
on 02023-02-07the #security of the #HTML5 clipboard API
on 02016-07-11the device orientation #HTML5 spec, which explains how browsers on cellphones expose accelerometer, gyro, and compass data to HTML applications.
on 02015-12-29the #performance of #HTML5 #localStorage.
on 02015-09-09