Now as it stands, this won’t work perfectly in all cases because the animation uses pixel values instead of percentages, so that it’s tied to an approximate text size.
By comparison, the CSS version can only be applied to text, and requires duplicating the text content at least once (the article duplicates it once in an attribute value, which is sufficient only for plain text; if you wanted any mixed formatting like bold or italics, you’d need to duplicate the element twice).
Also of glitch.svg: 6ßpx looks like an interesting number. Wonder if the error is intentional or not.
An observation for people that make websites: if you introduce multiple theme, you are now responsible for ensuring that your content works in all themes. Most of the time things will work tolerably enough (though you may want to tweak things on occasion, e.g. `filter: invert(0.9)` can work on black and white line art), but transparency especially is hazardous.
In this case, this means adding something like the following to glitch.css:
@media (prefers-color-scheme: dark) {
.glitch {
color: white;
}
.glitch:before, .glitch:after {
background: #1c1c1c;
}
/* and, unless you change the SVG one to use clipping or masking instead of a white flood fill, probably easiest to just give it a white background and be done with it: */
[alt="Svg glitch"] {
background: white;
}
}
It’s a very common theme for people to implement something that they personally don’t use, but with problems so that the end result for the people that do want to use it is worse than if they hadn’t done anything.
Accessibility is a good example of this, so that, for the web, the ARIA Practices document starts with a big warning, “no ARIA is better than bad ARIA”—because in general if you don’t touch ARIA stuff everything will still be there and usable, but it’s easy to mess everything up if you set things in the wrong way (but you can’t really put guard rails in without crippling the functionality for those cases where it is desired).
Dark modes can be added by browser extensions like Dark Reader, and it’s not frightfully uncommon for it to do a better job than the author—on this site, for example, Dark Reader would handle the code highlighting properly, where the author neglected to. (Would it have handled the glitch background thing? I haven’t tried it, but from past experience of how it works I think it would have caught at least the CSS one, but I’m not sure what it would have done with the SVG one at all.)
Hmm, I don't see how a bad optional stylesheet is worse than no stylesheet. Sure, the ARIA stuff might be, but those aren't optional. At worst, you can just not use the light stylesheet.
See the result in this page: dark mode users were presented something broken that completely ruined the main effect of the article, where it wasn’t immediately obvious why it was broken, and which they can’t easily switch away from; whereas if it had done nothing they would have received something admittedly inferior in an important way (light) but functional, by default, and if they use Dark Reader, something superior and functional.
Personally I prefer people to provide dark themes themselves. Dark Reader seemed to be CPU hungry last time I tried, and it would entirely crash some pages even.
The problem is that it's not just an optional stylesheet, it's enabled by default for everyone who uses dark mode on the OS level, with no easy way to opt back out except by changing a global system-wide setting—a casual user probably wouldn't even notice that there are two potential themes!
>An observation for people that make websites: if you introduce multiple theme, you are now responsible for ensuring that your content works in all themes
Am I missing something? This very site doesn't seem to offer theme/dark mode on my end.
I think I'm one of the few who doesn't prefer dark mode.
The reason is Apple no longer offer a non-super-glare screen on their laptops any more. I bought an MBP about 10 years ago, and the choice between a "matte" screen or "make everything more difficult to see in every environmental condition except inside the Apple Store" screen. Obviously I went for matte.
In their infinite marketing wisdom, Apple has removed the matte option.
I started on monochrome dark screens with white, green or orange phosphors. When I first started (briefly) using a Lisa in 1983 and then a Macintosh in 1984 I found that I really liked the paper-white look.
Eventually I decided that I preferred that the theme match the ambient lighting conditions. The recent operating system and browser features to provide adaptive behaviour is exactly what I sought. I now use light themes during the day–I am also a fan of natural light, and dark themes at night with reduced blue and lower colour saturation. I personally don't understand the preference for dark themes in bright ambient lighting. For me it seems to induce more eyestrain than relieving it.
It’s broken on Dark Mode. Needs an extra bit of CSS to determine whether it’s in dark mode or not.
The top example is just a GIF, so that's whatever - but the bottom example, which is actual text using this CSS trick, flickers white in a way that unfortunately ruins the illusion of the experience with a black background.
The code needs to use CSS's 'prefers-color-scheme' to differ between background colours for the effect.
This could also be used, for that matter; to auto-invert the 'text' colour. :)
I am mostly avoiding GUI stuff in my work, but from my experience
when you combine css animation with "infinite" then you get a constant CPU load, is it worth it? Are there more efficient way?
What is the correct way to check? I see 8% on a chrome thread and 2% on other chroem thread with only this page opened. A static page should use 0% . This percentages are per core.
The page regrettably is rendering animations in an SVG. In my experiments in the past, all browsers tended to optimise SVG animation, of all kinds, poorly. (CSS, animateMotion, JS - well, JS always performs badly obviously but..).
I think it'd be worth trying to translate this to CSS on text in a web page and see if the performance issues are still there. One can do it transparently these days with CSS filters. Or just draw against same colour as page background.
In fact, I think I'm going to give this a try. Will update here, but might take a while to get to it. I also wonder if it could be done more simply. this is basically just slices of offset text right? Also, those clip rects are pretty large. Wonder if that would impact browser texture allocation.
So my question is in general, animate infinite , is it a bad idea for a simple web page ? My experience was me having to put an emergency fix live because someone made such a css change that had for some reason very noticeable impact on OSX but not on Windows and Linux (though I could see the CPU usage in Linux there was no visible lag).
I also remember a big issue with a blinking cursor, so I am thinking why is such heavy animation APIs not coming with giant warnings.
It's really really really browser and hardware dependant.
https://m8y.org/tmp/testcase425.xhtml from 2018 is a simple effect with 2 translucent gradients. Was getting 200% (2 cores) CPU usage in Chrome on Windows, but like 15% in Firefox. Pretty much a case of hardware acceleration. OSX performed well in Safari but not Firefox and Chrome... Linux depended a lot on whether one force-enabled hardware acceleration which was off by default.
Overall I'd say if your web page doesn't need continuous animation, and you're worried about battery life or stutteriness or whatever, maybe don't use it?
It has gotten a lot better though. Not for SVG though, at least not last time I checked, and forget about SVG animated fonts unless you don't mind running CPU at 100% nonstop. :)
So in this case it triggers repaints, or maybe I am wrong
i opened only this page in Chrome, profiled it
then deleted the item and profiled it again
Also in my Process manager I see 2 chrome process with 5% and 7=8% usage witht he animated element and if I remove the elemtn I see only 1 process with 2% usage (weird static page still uses CPU, maybe there is still some other crap somewhere I had no adblocking on.
So far the only way I found to debug such performance issue was to start deleting elements until the CPU usage in Process manager drops I wish I knew a better way.
The blog briefly touches on it, but what does the data attribute 'data-text' enable?
I'm kinda confused, I do some data visualization work professionally and I understand how overlay patterns on SVGs work with the 'fill' property and IDs but lost with what the 'content' property is actually doing.
Why is it necessary to replace the h1 text with identical text? What does 'content' enable? It seems unnecessary to replace the text with the same text right?
The `data-text` attribute is used to set the `content` of the `before` and `after` pseudo-elements[0], effectively creating two "clones" of the original text. These get their own text shadows and clipping animations applied, which creates the effect. You can grab attributes from elements using `attr`[1], which they're using alongside `content`.
Thanks for the explanation, I've never seen the attr() property before. A lot of similar codepens I've seen in the past, that do fancy stylings, are suddenly making sense.
I always struggle to change my mental model about css to be more expressive, but now many wheels are starting to turn.
It's not replaced, it's in addition to the text. The HTML gives you one copy in black, then ::before & ::after are used to create copies in red and lime green. Partially showing those copies is what give you the glitch effect.
`::before & ::after` are pseudo-elements and a very common way of creating independently styleable elements when doing CSS effects like this
`content` is a property you can use to add text to those elements (he could have also just written `content: 'Artificial Truth';` if he preferred - having it as a data-attribute puts it right next to the "real" text and makes things easier to maintain)
`attr(data-text)` sets the value of content to the value of an attribute of the HTML. data-* is a common convention for creating value that aren't used for display. It is not possible, to my knowledge, to access the text contained within the `<h1>` with CSS only, hence the above choices.
That makes sense! Your explanation on why using the data attribute can enable more advance trickery just clicked multiple things in my brain when remembering other fancy codepens.
It shouldn't cause reflow by my understanding, the content never changes size, so the CPU hit should be minimal normally. It is going to consume unnecessary bandwidth and look messy if looking at it in a browser running remotes (via RDC, VNC, etc) but other methods like animated gifs will have that same effect too.
In any case, for an animation like this I'd set it to run through a few times, perhaps just once, then stop instead of bouncing around infinitely. Or have a long frame at then end of the sequence so that it only animates occasionally.
That too if off-screen animation is causing excess CPU use.
Though the loop than ends or only results in occasional animation has another rather nice benefit: less stuff jiggling around to drag my attention away from what I'm actually trying to look at. And using that will break the articles “with pure CSS” intent.
If something that shouldn't cause reflow and isn't animating a lot of content (or animating insanely fast) is eating bags of time on a modern CPU, I would suggest that is a browser bug not a problem with the idea.
Though do make sure you are understanding that 84% figure. Is it really that much of a full speed core or that much of one that is in a low power mode because none of the CPU needs to be at full speed ATM. CPU loading read from task manager apps and similar can be quite misleading these days.
By comparison, the CSS version can only be applied to text, and requires duplicating the text content at least once (the article duplicates it once in an attribute value, which is sufficient only for plain text; if you wanted any mixed formatting like bold or italics, you’d need to duplicate the element twice).
Also of glitch.svg: 6ßpx looks like an interesting number. Wonder if the error is intentional or not.