Every element in current Baseline
browsers
that would need a margin or padding removing in a reset stylesheet:
| Element | Chrome | Chrome for Android | Edge | Firefox | Firefox for Android | Safari | Safari for iOS |
|---|---|---|---|---|---|---|---|
body |
✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
h1 |
✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
Every element in current Baseline
browsers
that would need a margin or padding removing in a reset stylesheet:
| Element | Chrome | Chrome for Android | Edge | Firefox | Firefox for Android | Safari | Safari for iOS |
|---|---|---|---|---|---|---|---|
body |
✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
h1 |
✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
Nicolás Peña Moreno
Hongbo Song
Currently, developers can measure the latency of an event using the Event Timing API. Developers may query the duration, which returns the next paint after event handlers have run. Or they may compute the input delay, the delta between startTime (the event's timeStamp) and processingStart, which is a timestamp taken right before event is dispatched. But measuring event latency separately can’t help developers fully understand the user’s pain. When a user interacts with a web page, a user interaction (i.e. click/tap, press a key, drag) usually triggers a sequence of events. For example, when the user c
Github Actions is a CI/CD platform that gained a lot of popularity recently. I participated in building ⭐️ Lighthouse CI Action and was curious how well it performs.
But Github Marketplace UI shows no ranking information. Essentially, It's a search with random results; at least, I don't understand the order. I couldn't find ⭐️ Lighthouse CI Action in Continuous integration category after browsing 50 available pages (Each page shows 20 results, so it's possible to see only 1000 results, but CI category has 1469 😐).
I decided to build a custom script that crawls all categories and use Github Search (example query) to estimate usa
| input[type="search"]::-webkit-search-cancel-button { | |
| --size: 11px; | |
| --background: #7F7F7F; | |
| --icon: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI3IiBoZWlnaHQ9IjciIHZpZXdCb3g9IjAgMCAyNCAyNCIgZmlsbD0ibm9uZSIgc3Ryb2tlPSIjZmZmIiBzdHJva2Utd2lkdGg9IjMiIHN0cm9rZS1saW5lY2FwPSJyb3VuZCIgc3Ryb2tlLWxpbmVqb2luPSJyb3VuZCIgY2xhc3M9ImZlYXRoZXIgZmVhdGhlci14Ij48cGF0aCBkPSJNMTggNkw2IDE4TTYgNmwxMiAxMiIvPjwvc3ZnPgo="); | |
| -webkit-appearance: none; | |
| height: var(--size); | |
| width: var(--size); | |
| border-radius: 50%; | |
| background: var(--background) var(--icon) 50% 50% no-repeat; | |
| } |
🔍 see jay, yes! 🎉 / 👨🏻💻 see, JS! 👾 / ⚓️ sea JS ⛴
If you're publishing ES Modules, you need to also publish CommonJS versions of those modules.
This isn't to support old browsers or Node versions: even in Node 14, using require() to load a module won't work if it's only available as ESM.
cjyes is the bare minimum fix for this problem. You write ES Modules and fill out a valid package.json, and it'll generate the corresponding CommonJS files pretty much instantly. cjyes takes up 500kb of disk space including its two dependencies.
| export const h=(t,p,...c)=>({t,p,c,k:p&&p.key}) | |
| export const render=(e,d,t=d.t||(d.t={}),p,r,c,m,y)=> | |
| // arrays | |
| e.map?e.map((e,p)=>render(e,d,t.o&&t.o[p])): | |
| // components | |
| e.t.call?(e.i=render((render.c=e).t(Object.assign({children:e.c},e.p),e.s=t.s||{},t=> | |
| render(Object.assign(e.s,t)&&e,d,e)),t.i||d,t&&t.i||{}),d.t=t=e):( | |
| // create notes | |
| m=t.d||(e.t?document.createElement(e.t):new Text(e.p)), | |
| // diff props |
(10min demo at the performance.now() meetup, 20 November 2019, Amsterdam)
CrUX is the Chrome User Experience Report, a public dataset of performance and UX data from real Chrome users in the field.
Quick facts:
In this article, I would like to share three features of PageSpeed Insights (PSI), that is not easy to find in the official documentation. I discovered them while hacking on the Lighthouse plugin and integrating PSI to Treo.sh.
For a context, PSI is a simple yet powerful API by Google, that audits your page using Lighthouse and provides real-world users' data from Chrome UX Report (CrUX).
By default, PSI API returns only performance category. It's possible to pass ?category argument multiple times and get a report with many Lighthouse categories using one request (available categories: performance, accessibility, best-practices, seo, pwa).
curl -i "https://www.googleapis.com/pagespeffmeg as worker can be found at https://github.com/Kagami/ffmpeg.js/
Final build can be obtained via wget https://unpkg.com/ffmpeg.js@3.1.9001/ffmpeg-worker-mp4.js