nomster.bsky.social
Web platform engineer @ Chrome
110 posts
842 followers
657 following
Regular Contributor
Active Commenter
comment in response to
post
html.spec.whatwg.org/multipage/do... is the key. The body element needs to be null. Would be great to improve mdn there, mind opening an issue?
comment in response to
post
You can't add render-blocking scripts in the <body>, has to be in the <head> (per spec).
comment in response to
post
You can build paths in SVG but they're not responsive to the content, they are pixel-based and can scale.
This is explained in the spec:
drafts.csswg.org/css-shapes-2...
comment in response to
post
It's not "just" that, it also allows you to use all the CSS features like responsive units, custom properties and animation.
comment in response to
post
Not sure, but perhaps BrowserSync does other things that affect timing. I haven't tried the BrowserSync variant, only 11ty vs. a python HTTP server.
comment in response to
post
Opened issues.chromium.org/issues/41711...
comment in response to
post
An easy yet ugly workaround is to add an empty <script> after the stylesheet, because scripts are blocked by external CSS (per spec).
But to conclude, I believe this is a bug in the render-blocking mechanism, unblocking rendering too early in case the full HTML is parsed.
comment in response to
post
My hypothesis: 11ty makes this (very small) page too fast, creating a situation where often the HTML is fully downloaded before the external CSS.
Browsers have a heuristic to not render-block on external CSS forever, part of which cancels render-blocking at HTML end.
comment in response to
post
I can reproduce this, it seems like the dev server is fudging the order of things in such a way that the stylesheet is no longer render-blocking. Note that when converting this style to inline (inside <style>) everything works.
comment in response to
post
The common gotcha here is that there's a race condition with the first frame that the dev-enviroment masks somehow, which means that render-blocking is not properly set up.
A very common gotcha is putting a pagereveal event listener in an async script that's not render-blocking.
comment in response to
post
If you need assistance you know where to find it!
comment in response to
post
Can I haz?
comment in response to
post
Hopefully bundlers would decide when to keep it and when to remove it?
comment in response to
post
You can use the superellipse(parameter) function for all the values between square, notch, bevel, squircle etc. Squircle is merely a keyword meaning superellipse(2).
It's all in the spec :)
comment in response to
post
You can create different straight angles with border-radius and `corner-shape: bevel`
comment in response to
post
Not exactly, look at the spec: drafts.csswg.org/css-borders-...
comment in response to
post
You can try squircles in Chrome canary already (with experimental features turned on).
```
border-radius: 50%;
corner-shape: squircle;
```
comment in response to
post
Yea right now if you have other more lenient directives like `connect-src` you can fetch a style and apply it using CSSOM. That's described in developer.mozilla.org/en-US/docs/W...
comment in response to
post
How would that work? CSP takes effect when you fetch.
comment in response to
post
Oops, had a typo.
Thanks for reporting!
comment in response to
post
Working on this together with @smfr.bsky.social and with @fserb.com (who came up with a great solution for rendering something close enough to a superellipse half-corner using a cubic bezier curve)
comment in response to
post
It works together with border-radius, where the resulting corner is not necessarily exactly a square or rounded.
comment in response to
post
Nice! Working on a CfP
comment in response to
post
It's a forward compatibility thing about a future where you can have ::picker for many things and then *::picker() would have unintended consequences, e.g. your select ::picker() would suddenly style a color ::picker()
(Not defending this decision though, just reciting where the discussion went)
comment in response to
post
Our brains are still stuck in some visual rebase
comment in response to
post
Ha thanks! I'm not actually ready to act on this voice.
comment in response to
post
... I need to find time for a sequel article.
comment in response to
post
First, that's great to hear! Can you tell me more?
I still believe in the mindset of HTML-first, but some caveats (in a nutshell):
- too many CSS tricks can be a bad practice for accessibility and maintainability, sometimes JS is better and simpler.
- Be careful not to invent your own framework.
comment in response to
post
Ha thanks! Though I've learned a lot in the 3 years since I wrote this, a new post about this subject might look very different today.
comment in response to
post
Simon Fraser is @smfr.bsky.social
(He built the demo, I just put it on github pages)