Repository navigation
[v13 beta] Consider Safari verison baseline for v13 vs CSS injection change #9876
Description
Check for duplicates
- I have searched for similar issues before opening a new one.
Description
v13 beta changes the browser baseline in two ways that I can see:
- :has CSS pulled in from the keyboard navigation plugin, this is expected and was discussed last year (requires Safari 15.4), it's possible there are more involved ways to the same end. No strong view from me but would be good to cover in release notes.
- Constructable stylesheets + adoptedStylesheets call added on feat!: Allow using Blockly in web components/shadow DOM #9611, this requires Safari 16.4 which is an unexpected baseline raise for us that will affect MakeCode's supported versions and require raising minimum versions for apps. This is also a start-up crash rather than degrade.
Is it viable to fall back to the old approach for #9611 with feature detection / error handling? I can take a look at a PR for this if that's an acceptable path forward.
Reproduction steps
- Use Safari 15, e.g. via browserstack
- Load v13 branch playground
- Note no workspace and logged error.
Priority
I think this is pretty straightforward to address if there's the willingness to maintain a fallback path.
It's possible you could push apps to use a polyfill instead. I haven't tested any with this scenario.
Stack trace
[Error] TypeError: Illegal constructor
CSSStyleSheet (blockly_compressed.js:134:245)
register$$module$build$src$core$css (blockly_compressed.js:134:245)
(anonymous function) (blockly_compressed.js:1422:482)
(anonymous function) (blockly_compressed.js:10)
Global Code (blockly_compressed.js:12)Screenshots
I tested Safari desktop but more worried about edu iPads in practice.
Browsers
Safari desktop
Activity
maribethb commentedon May 18, 2026
I think a fallback approach here rather than requiring a polyfill is agood call. We'll review a PR for that if you are able to make one.
For the 15.4
:hasaddition we've discussed and willing to accept that and will call it out in the release notes.microbit-matt-hillsdon commentedon May 19, 2026
One additional complication: moving to adoptStylesheets has changed the cascade:
Before: Injects a <style id="blockly-renderer-style-..."> element prepended to the start of . Application styles loaded later in the document come after it and can naturally override styles (due to source order).
After: Inserts into document.adoptedStyleSheets. Adopted stylesheets are applied after the document's
<link>/<style>rules in the cascade. On a same-specificity tie, Blockly now wins so MakeCode needs higher specificity or !important hackery. I've ended up adding "body" to a bunch of CSS to win.It might be possible to address this in Blockly by wrapping Blockly's styles in
@layer(which is in Safari 15.4). If not I think this needs documenting clearly in release notes as it's a subtle breakage.Edit: spotted Rob noted this on #9611 (comment)
fix: Inject Blockly CSS via <style> elements instead of adoptedStyleS…
fix: CSS back to <style> for Safari/cascade reasons
fix: CSS back to <style> for Safari/cascade reasons
fix: CSS back to <style> for Safari/cascade reasons (#9908)