bramus

// 🗣 Text-to-Speech with the Web Speech API's SpeechSynthesis
// @link https://gist.github.com/bramus/e27fcb783f469b6585007a7453e1bb5a
// @ref https://developer.mozilla.org/en-US/docs/Web/API/SpeechSynthesis
((text) => {

    // Create an Utterance (= speech request)
    const utter = new SpeechSynthesisUtterance(text);

    // Set the voice
    utter.voice = window.speechSynthesis.getVoices()[0];

bramus

CSS sibling-count(), sibling-index(), and child-count() current workarounds

CSSWG Issue: w3c/csswg-drafts#4559

Demo: https://codepen.io/bramus/pen/oNVqZZq/546b6c9793668ad461329fb34732657f?editors=0110

sibling-index()

@property --sibling-index {

bramus

// Run this on https://developer.mozilla.org/en/docs/Web/HTML/Element
var tags = [], nodeList = document.querySelectorAll('td a code'); 
for (i in nodeList) {
    if ((nodeList[i].innerText) && (nodeList[i].innerText.indexOf('<') > -1)) {
        var tag = nodeList[i].innerText.replace('<','"').replace('>','"');
        if (tags.indexOf(tag) == -1) {
            tags.push(tag);
        }
    }
}

bramus

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [L]

bramus

An issue we’ve heard from authors is that they want to know what scrollbars are doing and respond to that.

There’s a bunch of issues that might go hand in hand to actually solve this:

1. [^1] Expose an env() variable that allows you to get the scrollbar-size. This is a fixed value, independent of whether a scrollbar is shown or not – it just gives you back the size
2. [^2] A way to query which type of scrollbars are being used on the page.
3. A container state query to be able to know if something is overflowing or not

If you combine these three, authors can do things like:

bramus

const extractLayersFromCssRules = (cssRules) => {
    if (!cssRules || !cssRules.length) return [];
	return [...cssRules].filter((cssRule) => {
			return (cssRule instanceof CSSStyleRule) || (cssRule instanceof CSSLayerBlockRule);
		})
		.flatMap((cssRule) => {
			if (cssRule instanceof CSSLayerBlockRule) {
				return [cssRule.name];
			} else {
                return extractLayersFromCssRules(cssRule.cssRules);

bramus

🚚 The bookmarklet has moved to https://github.com/bramus/mastodon-profile-redirect/

bramus

Bridging Native & React for iOS & Android

js -> native

• Simple Example
• Callbacks
• Promises
• Properties

native -> js

bramus

With Scroll-Driven Animations [^1] we have defined some new types of timelines which authors can use to run an animation on. Besides the existing DocumentTimeline, authors can now use a ScrollTimeline to animate based on a scroller’s scroll offset or ViewTimeline to animate as an element crosses its scrollport.

I’ve added this topic to get more ideas around new potential timelines. For example, one type of timeline we at Google discussed was a MediaPlaybackTimeline, where you could sync up animations to a media element – <audio> or <video> – play position.

video {
  timeline: --video;
}

bramus

This is a bit of controversial idea that has been lingering in the back of my mind. Basically, I’ve seen the need for authors to configure some things on a page, and it would be nice if they could do that from within CSS.

For example, MPA View Transitions we discussed yesterday, or other things that typically now go into a meta tag in the markup. Beyond VTs, I am thinking of the switch to control the viewport resizing behavior when the virtual keyboard gets shown (see https://drafts.csswg.org/css-viewport/#interactive-widget-section)

I haven’t thought this entirely through (insert chuckle by some of you here) but am thinking of an @config at-rule for that. In it you could put some things like the interactive-widget configuration.

@config {
  interactive-widget: resize-viewport;
}