@bramus@front-end.social
@bramus@front-end.social avatar

bramus

@bramus@front-end.social

Chrome Developer Relations at Google (CSS + Web UI + DevTools). CSSWG Member. PADI Divemaster. Blogs at bram.us

This profile is from a federated server and may be incomplete. Browse more on the original instance.

ppk, (edited ) to random
@ppk@front-end.social avatar

I'm now at day 8 of not smoking.

If it continues like this, I'm going to succeed in quitting smoking permanently. Though I thank the stars for bits of nicotine chewing gum when I really need it.

Meanwhile, a funny story is attached to my quitting ...

bramus,
@bramus@front-end.social avatar

@ppk Keep it going! 💪

bramus, (edited ) to random
@bramus@front-end.social avatar

Hey all! Quick heads up that I’m working on a free video course that teaches you all there is to know about Scroll-Driven Animations in CSS and JavaScript.

https://youtube.com/shorts/W1la5yV3PcQ

Expect the full series to drop later this month 🤩

bramus,
@bramus@front-end.social avatar

@iamdtms the autostart would require a tad of extra JS, but in general: YES.

bramus,
@bramus@front-end.social avatar

@ydaniv https://brm.us/css-scroll-velocity

bramus,
@bramus@front-end.social avatar

@ydaniv Thanks! 😊

jpzwarte, to random
@jpzwarte@fosstodon.org avatar

@bramus So anchor positioning is in Chrome 125 beta, but not in dev? Una's http://anchor-tool.com/ doesn't work in 125.0.6420.4 (dev build).

Devtools sees things like inset-area as valid, but the element isn't positioned correctly.

bramus,
@bramus@front-end.social avatar

@jpzwarte @dbaron There was a recent crashfix wrt anchorpos in Canary. Can take a while before that goes into Dev.

If it happens in Canary too, could you report the crash from chrome://crashes? It should be listed there.

After uploading the report, you can use that same screen to file a bug that refers that crashreport.

matuzo, to random
@matuzo@front-end.social avatar

People often ask me for recommendations for front-end development conferences. Picking my Top 3 would be challenging, but I know that @btconf in Germany is one of them!

https://matuzo.at/blog/2024/beyond-tellerand?t

bramus,
@bramus@front-end.social avatar

@matuzo @btconf BT is on my list of “Conferences I need to attend but never have”.

Never made it to it as there’s always something else going on at the same time (this year: Google I/O in May; A planned vacation in November).

One day …

DavidDarnes, to random
@DavidDarnes@mastodon.design avatar

Idea: Web Component which uses the CSS Highlight API to highlight code blocks

bramus,
@bramus@front-end.social avatar

@DavidDarnes @Jbasoo This would make a nice Web Component indeed: https://www.bram.us/2024/02/18/custom-highlight-api-for-syntax-highlighting/#highlighting-contenteditable

bramus,
@bramus@front-end.social avatar

@DavidDarnes @Jbasoo 🎯

stephaniewalter, to random
@stephaniewalter@front-end.social avatar

What if you had real control over Light Mode / Dark Mode on a per-site basis? Let the user decide which color-scheme they want on a per-site basis and store that. This is a very nice proof of concept by @bramus here.

https://www.bram.us/2024/04/13/what-if-you-had-real-control-over-light-mode-dark-mode-on-a-per-site-basis/
https://www.bram.us/2024/04/13/what-if-you-had-real-control-over-light-mode-dark-mode-on-a-per-site-basis/

bramus,
@bramus@front-end.social avatar

@oldmanspidey @stephaniewalter Key difference is that my extension taps into the native browser features instead of relying on hacks and workarounds to achieve a Dark Mode.

I address this in more detail the FAQ: https://github.com/bramus/chrome-dark-mode-toggle#how-does-this-extension-differ-from-other-dark-mode-extensions

bramus,
@bramus@front-end.social avatar

@oldmanspidey @stephaniewalter Also note that my extension is a POC.

If this feature were to land in the browser you’d see no “FART” at all (which something my extension and the others can have).

bramus, to random
@bramus@front-end.social avatar

Chrome Dark Mode Toggle is here! 🎉

> It’s an extension to override the value of prefers-color-scheme on a per-origin basis. That way, if a site uses prefers-color-scheme in their stylesheet, you can keep your OS in Light Mode while watching a site in Dark Mode (or vice versa).

Chrome Web Store: https://chromewebstore.google.com/detail/chrome-dark-mode-toggle/idnbggfpadjhjicgjmhlpeilafaplnhd

Readme + FAQ: https://github.com/bramus/chrome-dark-mode-toggle

Backstory: https://www.bram.us/2024/04/13/what-if-you-had-real-control-over-light-mode-dark-mode-on-a-per-site-basis/

(Remember: this is an experimental POC. You need to flip a Chrome Flag to be able to use this …)

Teaser of what this extension can do.

bramus,
@bramus@front-end.social avatar

(And TBF: I wouldn’t recommend flipping the flag in Chrome Stable as you typically want to keep that browser in line with what regular Chrome users are using. Try it in Beta, Dev, or Canary)

bramus,
@bramus@front-end.social avatar

@meduz I hope this POC can be used to get the ball rolling and see if folks from UX et al not are keen on having it or not … ;)

j9t, to CSS
@j9t@mas.to avatar

Today I learned about the table column combinator ||: https://www.w3.org/TR/selectors-4/#the-column-combinator

—and also that it’s (still?) at risk: https://www.w3.org/TR/selectors-4/#:~:text=The%20following%20features%20are%20at%2Drisk

#css #til

bramus,
@bramus@front-end.social avatar

@j9t which reminds me: I have a whole thread prepared on that one that I still need to publish.

bramus, to random
@bramus@front-end.social avatar

🌞 vs 🌑

If you’ve been following me for a while here you most likely know that I think that Dark Mode Toggle Buttons should be a browser feature:

Let the user decide which color-scheme they want on a per-site basis and store that.

https://brm.us/dark-mode-override

bramus,
@bramus@front-end.social avatar

@rdela @jensimmons

Having a way to override light/dark on a per-origin basis holds no privacy issue. That bit of data is already exposed today, as reported by your OS. Best case, being able to override this preference on a per-origin basis is adding some noise to the data.

The privacy concerns Jen is referring to have to do with the Web Preferences API. You can read https://github.com/WICG/web-preferences-api/issues/16 and https://github.com/WICG/web-preferences-api/issues/30#issuecomment-1839318117 if you want to know more.

bramus,
@bramus@front-end.social avatar

@rdela @jensimmons And yes, I did use the Web Preferences API to build this POC extension, but that’s because it was the thing that allowed me to build it.

If browsers offered this as a built-in, they can do so without the Web Preferences API.

However, with the Web Preferences API, websites can integrate with that setting nicely, instead of having to roll their own implementation using localstorage and class-overrides.

bramus,
@bramus@front-end.social avatar

@rdela @jensimmons As for the 4 options you listed:

  1. Yes.
  2. This to offer users the option to divert from the OS setting (in my original proposal https://www.bram.us/2022/05/25/dark-mode-toggles-should-be-a-browser-feature/ I also mention a browser-level override)
  3. That is not user exposed. Only (some) devs are aware of that.
  4. Having this browser-level toggle can result in less browsers needing such a button, as now the browser can offer it. That way, users no longer need to search if a website has such a toggle and where it is.
bramus,
@bramus@front-end.social avatar

@rdela @jensimmons Did you really read https://www.bram.us/2022/05/25/dark-mode-toggles-should-be-a-browser-feature/?

I Iiterally say “Think of a button that is part of the browser's UI that you could click. Something like the button Chrome DevTools already sports, but then part of the browser UI, available for all users”

IIUC the thing you see different is that a click applies to all sites, something I also cover: “To not force users to set the value for every new site they visit, there would also be a setting at the browser level.”

bramus,
@bramus@front-end.social avatar

@rdela @jensimmons

> I am with you until you want it to remember individual site settings, which opens up fingerprinting possibilities no matter how you implement it

If Service A from company X sees you as prefers-color-scheme: light from the UA, and Service B from that same company sees prefers-color-scheme: dark then that’s less tracking, no? One bit of identifying data got flipped.

(I am talking about the browser overriding the value directly here, not the Web Preferences API)

bramus,
@bramus@front-end.social avatar

@rdela @jensimmons

> Also people typically would want that to apply across the sites they visit for a given range of time.

You’re making a feature request here? :)

> interface challenges […], that I am near certain browser vendors would fail to rise to

I agree that this must be executed correctly and will be difficult to get right, but having these fears upfront doesn’t mean the proposal has no value.

bramus,
@bramus@front-end.social avatar

@rdela @jensimmons

> it needlessly complicates the primary use case in service of the edge case who wants a different arbitrary color-scheme

Setting a specific light/dark preference on a website is not an edge case but a common thing.

Proof: the many dark mode toggle buttons in the wild.

> within short browsing sessions on different sites.

This is not short lived. By persisting the value, the override applies to the current and future visits to that origin.

bramus,
@bramus@front-end.social avatar

@rdela @jensimmons This could be a problem for the Web Preferences API when implemented without the proper safeguards, but not for the browser itself.

The browser itself doesn’t leak whether you are overriding the value or not. It only reports “this is the value and it’s none of your business where that came from”

(And yes, I did use the Web Preferences API in my extension as that’s what was needed to create the POC. A browser can implement this natively, without needing the WP API).

bramus,
@bramus@front-end.social avatar

@rdela @jensimmons And that‘s exactly where this browser feature comes into play.

The existing button can’t be pulled out of DevTools and put into Chrome as DevTools is its own app that communicates with Chrome through the Chrome DevTools Protocol to manipulate the page’s appearance.

bramus,
@bramus@front-end.social avatar

@rdela @jensimmons

> I am not sure “the many dark mode toggle buttons in the wild” prove anything since many of them do not respond to prefers-color-scheme on load or value change.

You are underlining why exactly we need this as a browser feature.

By putting the feature into the browser, we can get rid of all these (often incorrectly implemented) custom dark mode buttons.

> short-lived,” yes, but that persistence might not be preferable.

Seems like a preference to be set in the feature :)

bramus,
@bramus@front-end.social avatar

@rdela @jensimmons But that would require you to have logged in to those services already … so they already know it's you.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • megavids
  • InstantRegret
  • magazineikmin
  • thenastyranch
  • modclub
  • everett
  • rosin
  • Youngstown
  • slotface
  • ethstaker
  • mdbf
  • kavyap
  • osvaldo12
  • DreamBathrooms
  • anitta
  • Durango
  • ngwrru68w68
  • tester
  • khanakhh
  • love
  • tacticalgear
  • cubers
  • GTA5RPClips
  • Leos
  • normalnudes
  • provamag3
  • cisconetworking
  • JUstTest
  • All magazines
    •