This is a valid RSS feed.
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
line 91, column 0: (10 occurrences) [help]
<a href="https://meyerweb.com/eric/thoughts/wp-content/uploads/infinity-text ...
line 92, column 0: (2 occurrences) [help]
<figcaption aria-hidden="true">Consistency across Firefox, Chrome, and Safar ...
... 2025%22">email Eric directly</a>.</p>]]></content:encoded>
^
<figure><a href="https://www.sarawb.com/design-for-real-life"><img fetchprio ...
<style>#ghload {border: 1px solid; padding: 0.75em; background: #FED3; borde ...
<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
>
<channel>
<title>Thoughts From Eric</title>
<atom:link href="http://meyerweb.com/eric/thoughts/feed/?scope=summary" rel="self" type="application/rss+xml" />
<link>https://meyerweb.com/eric/thoughts</link>
<description>Things that Eric A. Meyer, CSS expert, writes about on his personal Web site; it's largely Web standards and Web technology, but also various bits of culture, politics, personal observations, and other miscellaneous stuff</description>
<lastBuildDate>Fri, 22 Aug 2025 16:22:39 +0000</lastBuildDate>
<language>en-US</language>
<sy:updatePeriod>
hourly </sy:updatePeriod>
<sy:updateFrequency>
1 </sy:updateFrequency>
<item>
<title>No, Google Did Not Unilaterally Decide to Kill XSLT</title>
<link>https://meyerweb.com/eric/thoughts/2025/08/22/no-google-did-not-unilaterally-decide-to-kill-xslt/</link>
<comments>https://meyerweb.com/eric/thoughts/2025/08/22/no-google-did-not-unilaterally-decide-to-kill-xslt/#comments</comments>
<dc:creator><![CDATA[Eric Meyer]]></dc:creator>
<pubDate>Fri, 22 Aug 2025 16:22:39 +0000</pubDate>
<category><![CDATA[Browsers]]></category>
<category><![CDATA[Commentary]]></category>
<category><![CDATA[XSLT]]></category>
<guid isPermaLink="false">https://meyerweb.com/eric/thoughts/?p=5635</guid>
<description><![CDATA[The Web Discourse has been spicy of late, and XSLT is to blame. Well, sort of. It’s complicated.]]></description>
<content:encoded><![CDATA[<p>It’s uncommon, but not unheard of, for a GitHub issue to spark an uproar. That happened over the past month or so as the WHATWG (Web Hypertext Application Technology Working Group, which I still say should have called themselves a Task Force instead) issue “<a href="https://github.com/WHATWG/html/issues/11523">Should we remove XSLT from the web platform?</a>” was opened, debated, and eventually locked once the comment thread started spiraling into personal attacks. Other discussions have since opened, such as <a href="https://github.com/whatwg/html/issues/11578"> a counterproposal to update XSLT in the web platform</a>, thankfully with (thus far) much less heat.</p>
<p>If you’re new to the term, XSLT (Extensible Stylesheet Language Transformations) is an XML language that lets you transform one document tree structure into another. If you’ve ever heard of people styling their RSS and/or Atom feeds to look nice in the browser, they were using some amount of XSLT to turn the RSS/Atom into HTML, which they could then CSS into prettiness.</p>
<p>This is not the only use case for XSLT, not by a long shot, but it does illustrate the sort of thing XSLT is good for. So why remove it, and who got this flame train rolling in the first place?</p>
<p>Before I start, I want to note that in this post, I won’t be commenting on whether or not XSLT support should be dropped from browsers or not. I’m also not going to be systematically addressing the various reactions I’ve seen to all this. I have my own biases around this — some of them in direct conflict with each other! — but my focus here will be on what’s happened so far and what might lie ahead.</p>
<p>Also, <a href="https://bkardell.com">Brian</a> and I <a href="https://www.igalia.com/chats/xslt-liam"> talked with Liam Quin</a> about all this, if you’d rather hear a conversation than read a blog post.</p>
<p>As a very quick background, various people have proposed removing XSLT support from browsers a few times over the quarter-century-plus since support first landed. It was discussed in both the early and mid-2010s, for example. At this point, browsers all more or less support<a href="https://www.w3.org/TR/xslt-10/">XSLT 1.0</a>, whereas the latest version of XSLT is <a href="https://www.w3.org/TR/xslt-30/">3.0</a>. I believe they all do so with C++ code, which is therefore not memory-safe, that is baked into the code base rather than supported via some kind of plugged-in library, like Firefox using <a href="https://github.com/mozilla/pdf.js"> PDF.js</a> to support PDFs in the browser.</p>
<p>Anyway, back on August 1st, Mason Freed of Google opened <a href="https://github.com/WHATWG/html/issues/11523">issue #11523</a> on WHATWG’s HTML repository, asking if XSLT should be removed from browsers and giving a condensed set of reasons why it might be a good idea. He also included a WASM-based polyfill he’d written to provide XSLT support, should browsers remove it, and opened “<a href="https://issues.chromium.org/issues/435623334"> Investigate deprecation and removal of XSLT</a>” in the Chromium bug tracker.</p>
<p>“So it’s already been decided and we just have to bend over and take the changes our Googlish overlords have decreed!” many people shouted. It’s not hard to see where they got that impression, given some of the things Google has done over the years, but that’s <strong>not</strong> what’s happening here. Not at this point. I’d like to set some records straight, as an outside observer of both Google and the issue itself.</p>
<p>First of all, while Mason was the one to open the issue, this was done because the idea was raised in a periodic WHATNOT meeting (call), where someone at Mozilla was actually the one to bring it up, after it had come up in various conversations over the previous few months. After Mason opened the issue, members of the Mozilla and WebKit teams expressed (tentative, mostly) support for the idea of exploring this removal. Basically, <em>none</em> of the vendors are particularly keen on keeping native XSLT support in their codebases, particularly after <a href="https://www.neowin.net/news/google-project-zero-exposes-security-flaw-in-libxslt-library-used-in-gnome-applications/"> security flaws were found</a> in XSLT implementations.</p>
<p>This isn’t the first time they’ve all agreed it might be nice to slim their codebases down a little by removing something that doesn’t get a lot of use (relatively speaking), and it won’t be the last. I bet they’ve all talked at some point about how nice it would be to remove <a href="https://en.wikipedia.org/wiki/BMP_file_format">BMP</a> support.</p>
<p>Mason mentioned that they didn’t have resources to put toward updating their XSLT code, and got widely derided for it. “Google has trillions of dollars!” people hooted. <em>Google</em> has trillions of dollars. The Chrome team very much does not. They probably get, at best, a tiny fraction of one percent of those dollars. Whether Google should give the Chrome team more money is essentially irrelevant, because that’s not in the Chrome team’s control. They have what they have, in terms of head count and time, and have to decide how those entirely finite resources are best spent.</p>
<p>(I will once again invoke my late-1900s formulation of <a href="https://en.wikipedia.org/wiki/Hanlon's_razor">Hanlon’s Razor</a>: <em> Never attribute to malice that which can be more adequately explained by resource constraints.</em>)</p>
<p>Second of all, the issue was opened to start a discussion and gather feedback as the first stage of a multi-step process, one that could easily run for years. Google, as I assume is true for other browser makers, has a pretty comprehensive method for working out whether removing a given feature is tenable or not. <a href="https://bkardell.com">Brian</a> and I <a href="https://www.igalia.com/chats/unshipping"> talked with Rick Byers about it</a> a while back, and I was impressed by both how many things<em> have</em> been removed, and what they do to make sure they’re removing the right things.</p>
<p>Here’s one (by no means the only!) way they could go about this:</p>
<ol type="1">
<li>Set up a switch that allows XSLT to be disabled.</li>
<li>In the next release of Chrome, use the switch to disable XSLT in one percent of all Chrome downloads.</li>
<li>See if any bug reports come in about it. If so, investigate further and adjust as necessary if the problems are not actually about XSLT.</li>
<li>If not, up the percentage of XSLT-disabled downloads a little bit at a time over a number of releases. If no bugs are reported as the percentage of XSLT-disabled users trends toward 100%, then prepare to remove it entirely.</li>
<li>If, on the other hand, it becomes clear that removing XSLT will be a widely breaking change  —  where “widely” can still mean a very tiny portion of their total user base — then XSLT can be re-enabled for all users as soon as possible, and the discussion taken back up with this new information in hand.</li>
</ol>
<p>Again, that is just one of several approaches Google could take, and it’s a lot simpler than what they would most likely actually do, but it’s roughly what they default to, as I understand it. The process is slow and deliberate, building up a picture of actual use and user experience.</p>
<p>Third of all, opening a bug that includes a pull request of code changes isn’t a declaration of countdown to merge, it’s a way of making crystal clear (to those who can read the codebase) exactly what the proposal would entail. It’s basically a requirement for the process of making a decision to start, because it sets the exact parameters of what’s being decided on.</p>
<p>That said, as a result of all this, I now strongly believe that every proposed-removal issue should point to the process and where the issue stands in it. (And write down the process if it hasn’t been already.) This isn’t for the issue’s intended audience, which was other people within WHATWG who are familiar with the usual process and each other, but for cases of context escape, like happened here. If a removal discussion is going to be held in public, then it should assume the general public will see it and provide enough context for the general public to understand the actual nature of the discussion. In the absence of that context, the nature of the discussion will be assumed, and every assumption will be different.</p>
<p>There is one thing that we should all keep in mind, which is that “remove from the web platform” really means “remove from browsers”. Even if this proposal goes through, XSLT could still be used server-side. You could use libraries that support XSLT versions more recent than 1.0, even! Thus, XML could still be turned into HTML, just not in the client via native support, though JS or WASM polyfills, or even add-on extensions, would still be an option. Is that good or bad? Like everything else in our field, the answer is “it depends”.</p>
<p>Just in case your eyes glazed over and you quickly skimmed to see if there was a TL;DR, here it is:</p>
<p><em>The discussion was opened by a Google employee in response to interest from multiple browser vendors in removing built-in XSLT, following a process that is opaque to most outsiders. It’s a first step in a multi-step evaluation process that can take years to complete, and whose outcome is not predetermined. Tempers flared and the initial discussion was locked; the conversation continues elsewhere. There are good reasons to drop native XSLT support in browsers, and also good reasons to keep or update it, but XSLT is not itself at risk.</em></p>
<hr><p>Have something to say to all that? You can <a href="https://meyerweb.com/eric/thoughts/2025/08/22/no-google-did-not-unilaterally-decide-to-kill-xslt/#commentform">add a comment to the post</a>, or <a href="mailto:eric@meyerweb.com?subject=In%20reply%20to%20%22No,%20Google%20Did%20Not%20Unilaterally%20Decide%20to%20Kill%20XSLT%22">email Eric directly</a>.</p>]]></content:encoded>
<wfw:commentRss>https://meyerweb.com/eric/thoughts/2025/08/22/no-google-did-not-unilaterally-decide-to-kill-xslt/feed/</wfw:commentRss>
<slash:comments>3</slash:comments>
</item>
<item>
<title>To Infinity… But Not Beyond!</title>
<link>https://meyerweb.com/eric/thoughts/2025/08/20/to-infinity-but-not-beyond/</link>
<comments>https://meyerweb.com/eric/thoughts/2025/08/20/to-infinity-but-not-beyond/#comments</comments>
<dc:creator><![CDATA[Eric Meyer]]></dc:creator>
<pubDate>Wed, 20 Aug 2025 14:49:31 +0000</pubDate>
<category><![CDATA[Browsers]]></category>
<category><![CDATA[CSS]]></category>
<guid isPermaLink="false">https://meyerweb.com/eric/thoughts/?p=5606</guid>
<description><![CDATA[More explorations of ways to abuse the CSS `infinity` keyword, this time with more than just lengths.]]></description>
<content:encoded><![CDATA[<p><a href="https://meyerweb.com/eric/thoughts/2025/08/07/infinite-pixels/">Previously on meyerweb</a>, I explored ways to do strange things with <a href="https://www.w3.org/TR/css-values-4/#calc-error-constants">the <code>infinity</code> keyword</a> in CSS calculation functions. There were some great comments on that post, by the way; you should definitely go give them a read. Anyway, in this post, I’ll be doing the same thing, but with different properties!</p>
<p>When last we met, I’d just finished up messing with font sizes and line heights, and that made me think about other text properties that accept lengths, like those that indent text or increase the space between words and letters. You know, like these:</p>
<pre class="css"><code>div:nth-of-type(1) {text-indent: calc(infinity * 1ch);}
div:nth-of-type(2) {word-spacing: calc(infinity * 1ch);}
div:nth-of-type(3) {letter-spacing: calc(infinity * 1ch);}
</code></pre><pre class="html"><code><div>I have some text and I cannot lie!</div>
<div>I have some text and I cannot lie!</div>
<div>I have some text and I cannot lie!</div></code></pre>
<p>According to Frederic Goudy, I am now the sort of man who would steal a infinite number of sheep. Which is untrue, because, I mean, where would I put them?</p>
<figure class="standalone">
<a href="https://meyerweb.com/eric/thoughts/wp-content/uploads/infinity-text.png"><img decoding="async" src="https://meyerweb.com/eric/thoughts/wp-content/uploads/infinity-text.png" alt="" /></a>
<figcaption aria-hidden="true">Consistency across Firefox, Chrome, and Safari</figcaption>
</figure>
<p>Visually, these all came to exactly the same result, textually speaking, with just very small (probably line-height-related) variances in element height. All get very large horizontal overflow scrolling, yet scrolling out to the end of that overflow reveals no letterforms at all; I assume they’re sat just offscreen when you reach the end of the scroll region. I particularly like how the “I” in the first <code><div></code> disappears because the first line has been indented a few million (or a few hundred undecillion) pixels, and then the rest of the text is wrapped onto the second line. And in the third <code><div></code>, we can check for line-leading <a href="http://wikipedia.org/wiki/Steganography">steganography</a>!</p>
<p>When you ask for the computed values, though, that’s when things get weird.</p>
<table class="data">
<caption>Text property results</caption>
<thead>
<tr>
<th></th>
<th colspan="3">Computed value for…</th>
</tr>
<tr>
<th>Browser</th>
<th><code>text-indent</code></th>
<th><code>word-spacing</code></th>
<th><code>letter-spacing</code></th>
</tr>
</thead>
<tbody>
<tr>
<td>Safari</td>
<td>33554428px</td>
<td>33554428px</td>
<td>33554428px</td>
</tr>
<tr>
<td>Chrome</td>
<td>33554400px</td>
<td>3.40282e+38px</td>
<td>33554400px</td>
</tr>
<tr>
<td>Firefox (Nightly)</td>
<td>3.40282e+38px</td>
<td>3.40282e+38px</td>
<td>3.40282e+38px</td>
</tr>
</tbody>
</table>
<p>Safari and Firefox are at least internally consistent, if many orders of magnitude apart from each other. Chrome… I don’t even know what to say. Maybe pick a lane?</p>
<p>I have to admit that by this point in my experimentation, I was getting a little bored of infinite pixel lengths. What about infinite unitless numbers, like <code>line-height</code> or  —  even better  —  <code>z-index</code>?</p>
<pre class="css"><code>div {
position: absolute;
}
div:nth-of-type(1) {
top: 10%;
left: 1em;
z-index: calc(infinity + 1);
}
div:nth-of-type(2) {
top: 20%;
left: 2em;
z-index: calc(infinity);
}
div:nth-of-type(3) {
top: 30%;
left: 3em;
z-index: 32767;
}</code></pre>
<pre class="html"><code><div>I’m really high!</div>
<div>I’m really high!</div>
<div>I’m really high!</div></code></pre>
<figure>
<a href="https://meyerweb.com/eric/thoughts/wp-content/uploads/infinity-zindex.png"><img decoding="async" src="https://meyerweb.com/eric/thoughts/wp-content/uploads/infinity-zindex.png" alt="" class="" /></a>
<figcaption aria-hidden="true">The result you get in any of Firefox, Chrome, or Safari</figcaption>
</figure>
<p>It turns out that in CSS you can go to infinity, but <em>not</em> beyond, because the computed values were the same regardless of whether the <code>calc()</code> value was <code>infinity</code> or <code>infinity + 1</code>.</p>
<table class="data">
<caption>z-index values</caption>
<thead>
<tr>
<th>Browser</th>
<th>Computed value</th>
</tr>
</thead>
<tbody>
<tr>
<td>Safari</td>
<td>2147483647</td>
</tr>
<tr>
<td>Chrome</td>
<td>2147483647</td>
</tr>
<tr>
<td>Firefox (Nightly)</td>
<td>2147483647</td>
</tr>
</tbody>
</table>
<p>Thus, the first two <code><div></code> s were a long way above the third, but were themselves drawn with the later-painted <code><div></code> on top of the first. This is because in positioning, if overlapping elements have the same <code>z-index</code> value, the one that comes later in the DOM gets painted over top any that come before it.</p>
<p>This does also mean you can have a finite value beat infinity. If you change the previous CSS like so:</p>
<pre class="css"><code>div:nth-of-type(3) {
top: 30%;
left: 3em;
z-index: 2147483647;
}</code></pre>
<p>…then the third <code><div></code> is painted atop the other two, because they all have the same computed value. And no, increasing the finite value to a value equal to 2,147,483,648 or higher doesn’t change things, because the computed value of anything in that range is still <code>2147483647</code>.</p>
<p>The results here led me to an assumption that browsers (or at least the coding languages used to write them) use a system where any “infinity” that has multiplication, addition, or subtraction done to it just returns “infinite”. So if you try to double <code>Infinity</code>, you get back <code> Infinity</code> (or <code>Infinite</code> or <code>Inf</code> or whatever symbol is being used to represent the concept of the infinite). Maybe that’s entry-level knowledge for your average computer science major, but I was only one of those briefly and I don’t think it was covered in the assembler course that convinced me to find another major.</p>
<p>Looking across all those years back to my time in university got me thinking about infinite spans of time, so I decided to see just how long I could get an animation to run.</p>
<pre class="css"><code>div {
animation-name: shift;
animation-duration: calc(infinity * 1s);
}
@keyframes shift {
from {
transform: translateX(0px);
}
to {
transform: translateX(100px);
}
}</code></pre>
<pre class="html"><code><div>I’m timely!</div></code></pre>
<p>The results were truly something to behold, at least in the cases where beholding was possible. Here’s what I got for the computed <code>animation-duration</code> value in each browser’s web inspector Computed Values tab or subtab:</p>
<table class="data">
<caption>animation-duration values</caption>
<thead>
<tr>
<th>Browser</th>
<th>Computed value</th>
<th>As years</th>
</tr>
</thead>
<tbody>
<tr>
<td>Safari</td>
<td colspan="2">🤷🏽</td>
</tr>
<tr>
<td>Chrome</td>
<td>1.79769e+308s</td>
<td>5.7004376e+300</td>
</tr>
<tr>
<td>Firefox (Nightly)</td>
<td>3.40282e+38s</td>
<td>1.07902714e+31</td>
</tr>
</tbody>
</table>
<p>Those are… <em>very</em> long durations. In Firefox, the <code><div></code> will finish the animation in just a tiny bit over ten nonillion (ten quadrillion quadrillion) <em> years</em>. That’s roughly ten times as long as it will take for nearly all the matter in the known Universe to have been swallowed by supermassive galactic black holes.</p>
<p>In Chrome, on the other hand, completing the animation will take <del datetime="2025-08-21T16:18:36+00:00">approximately half again as long as</del><ins datetime="2025-08-21T16:18:36+00:00">an incomprehensibly longer amount of time than</ins> our current highest estimate for the amount of time it will take for all the protons and neutrons in the observable Universe to decay into radiation, assuming protons actually decay. (Source: Wikipedia’s <a href="https://en.wikipedia.org/wiki/Timeline_of_the_far_future">Timeline of the far future</a>.)</p>
<p>“Okay, but what about Safari?” you may be asking. Well, there’s no way as yet to find out, because while Safari loads and renders the page like usual, the page then becomes essentially unresponsive. Not the browser, just the page itself. This includes not redrawing or moving the scrollbar gutters when the window is resized, or showing useful information in the Web Inspector. I’ve already <a href="https://bugs.webkit.org/show_bug.cgi?id=297596">filed a bug</a>, so hopefully one day we’ll find out whether its temporal limitations are the same as Chrome’s or not.</p>
<p>It should also be noted that it doesn’t matter whether you supply <code>1s</code> or <code>1ms</code> as the thing to multiply with <code>infinity</code>: you get the same result either way. This makes some sense, because any finite number times infinity is still infinity. Well, sort of. But also yes.</p>
<p>So what happens if you divide a finite amount by infinity? In browsers, you very consistently get <strong>nothing</strong>!</p>
<pre class="css"><code>div {
animation-name: shift;
animation-duration: calc(100000000000000000000000s / infinity);
}</code></pre>
<p>(Any finite number could be used there, so I decided to type 1 and then hold the 0 key for a second or two, and use the resulting large number.)</p>
<table class="data">
<caption>Division-by-infinity results</caption>
<thead>
<tr>
<th>Browser</th>
<th>Computed value</th>
</tr>
</thead>
<tbody>
<tr>
<td>Safari</td>
<td>0</td>
</tr>
<tr>
<td>Chrome</td>
<td>0</td>
</tr>
<tr>
<td>Firefox (Nightly)</td>
<td>0</td>
</tr>
</tbody>
</table>
<p>Honestly, seeing that kind of cross-browser harmony… that was soothing.</p>
<p>And so we come full circle, from something that yielded consistent results to something else that yields consistent results. Sometimes, it’s the little wins that count the most.</p>
<p>Just not infinitely.</p>
<hr><p>Have something to say to all that? You can <a href="https://meyerweb.com/eric/thoughts/2025/08/20/to-infinity-but-not-beyond/#commentform">add a comment to the post</a>, or <a href="mailto:eric@meyerweb.com?subject=In%20reply%20to%20%22To%20Infinity…%20But%20Not%20Beyond!%22">email Eric directly</a>.</p>]]></content:encoded>
<wfw:commentRss>https://meyerweb.com/eric/thoughts/2025/08/20/to-infinity-but-not-beyond/feed/</wfw:commentRss>
<slash:comments>2</slash:comments>
</item>
<item>
<title>Infinite Pixels</title>
<link>https://meyerweb.com/eric/thoughts/2025/08/07/infinite-pixels/</link>
<comments>https://meyerweb.com/eric/thoughts/2025/08/07/infinite-pixels/#comments</comments>
<dc:creator><![CDATA[Eric Meyer]]></dc:creator>
<pubDate>Thu, 07 Aug 2025 11:30:55 +0000</pubDate>
<category><![CDATA[Browsers]]></category>
<category><![CDATA[CSS]]></category>
<guid isPermaLink="false">https://meyerweb.com/eric/thoughts/?p=5596</guid>
<description><![CDATA[In which I push browser engines to their finite limits using infinite values.]]></description>
<content:encoded><![CDATA[<p>I was on one of my rounds of social media trawling, just seeing what was floating through the aether, when I came across <a href="https://mastodon.art/@otterlove/114971594534242993">a toot by Andy P</a> that said:</p>
<blockquote>
<p>Fun #css trick:<br />
<br />
width: calc(infinity * 1px);<br />
height: calc(infinity * 1px);</p>
</blockquote>
<p>…and I immediately thought, <em>This is a perfect outer-limits probe!</em> By which I mean, if I hand a browser values that are effectively infinite by way of <a href="https://www.w3.org/TR/css-values-4/#calc-error-constants"> the<code>infinity</code> keyword</a>, it will necessarily end up clamping to something finite, thus revealing how far it’s able or willing to go for that property.</p>
<p>The first thing I did was exactly what Andy proposed, with a few extras to zero out box model extras:</p>
<pre class="css"><code>div {
width: calc(infinity * 1px);
height: calc(infinity * 1px);
margin: 0;
padding: 0; }</code></pre>
<pre class="html"><code><body>
<div>I’m huge!</div>
</body></code></pre>
<p>Then I loaded the (fully valid HTML 5) test page in Firefox Nightly, Chrome stable, and Safari stable, all on macOS, and things pretty immediately got weird:</p>
<table class="data">
<caption>Element Size Results</caption>
<thead>
<tr>
<th>Browser</th>
<th>Computed value</th>
<th>Layout value</th>
</tr>
</thead>
<tbody>
<tr>
<td>Safari</td>
<td>33,554,428</td>
<td>33,554,428</td>
</tr>
<tr>
<td>Chrome</td>
<td>33,554,400</td>
<td>33,554,400</td>
</tr>
<tr>
<td>Firefox (Nightly)</td>
<td>19.2 / 17,895,700</td>
<td>19.2 / 8,947,840 †</td>
</tr>
</tbody>
</table>
<p class="fnote"><em>† height / width</em></p>
<p>Chrome and Safari both get <em>very</em> close to 2<sup>25</sup>-1 (33,554,431), with Safari backing off from that by just 3 pixels, and Chrome by 31. I can’t even hazard a guess as to why this sort of value would be limited in that way; if there was a period of time where 24-bit values were in vogue, I must have missed it. I assume this is somehow rooted in the pre-Blink-fork codebase, but who knows. (Seriously, who knows? I want to talk to you.)</p>
<p>But the faint whiff of oddness there has <em>nothing</em> on what’s happening in Firefox. First off, the computed height is<code>19.2px</code>, which is the height of a line of text at default font size and line height. If I explicitly gave it<code> line-height: 1</code>, the height of the <code><div></code> changes to 16px. All this is despite my assigning a height of infinite pixels! Which, to be fair, is not really possible to do, but does it make sense to just drop it on the floor rather than clamp to an upper bound?</p>
<p>Even if that can somehow be said to make sense, it <em>only</em> happens with height. The computed width value is, as indicated, nearly 17.9 million, which is not the content width and is also nowhere close to any power of two. But the actual layout width, according to the diagram in the Layout tab, is just over 8.9 million pixels; or, put another way, one-half of 17,895,700 <em> minus 10</em>.</p>
<p>This frankly makes my brain hurt. I would truly love to understand the reasons for any of these oddities. If you know from whence they arise, please, please leave a comment! The more detail, the better. I also accept trackbacks from blog posts if you want to get extra-detailed.</p>
<p>For the sake of my aching skullmeats, I almost called a halt there, but I decided to see what happened with font sizes.</p>
<pre class="css"><code>div {
width: calc(infinity * 1px);
height: calc(infinity * 1px);
margin: 0;
padding: 0;
font-size: calc(infinity * 1px); }</code></pre>
<p>My skullmeats did not thank me for this, because once again, things got… interesting.</p>
<table class="data">
<caption>Font Size Results</caption>
<thead>
<tr>
<th>Browser</th>
<th>Computed value</th>
<th>Layout value</th>
</tr>
</thead>
<tbody>
<tr>
<td>Safari</td>
<td>100,000</td>
<td>100,000</td>
</tr>
<tr>
<td>Chrome</td>
<td>10,000</td>
<td>10,000</td>
</tr>
<tr>
<td>Firefox (Nightly)</td>
<td>3.40282e38</td>
<td>2,400 / 17,895,700 †</td>
</tr>
</tbody>
</table>
<p class="fnote"><em>† line height values of <code>normal</code> /<code>1</code></em></p>
<p>Safari and Chrome have pretty clearly set hard limits, with Safari’s an order of magnitude larger than Chrome’s. I get it: what are the odds of someone wanting their text to be any larger than, say, a viewport height, let alone ten or 100 times that height? What intrigues me is the nature of the limits, which are so clearly base-ten numbers that someone typed in at some point, rather than being limited by setting a register size or variable length or something that would have coughed up a power of two.</p>
<p>And speaking of powers of two… ah, Firefox. Your idiosyncrasy continues. The computed value is a 32-bit <a href="https://en.wikipedia.org/wiki/Single-precision_floating-point_format">single-precision floating-point</a> number. It doesn’t get used in any of the actual rendering, but that’s what it is. Instead, the actual font size of the text, as judged by the Box Model diagram on the Layout tab, is… 2,400 pixels.</p>
<p>Except, I can’t say that’s the <em>actual</em> actual font size being used: I suspect the actual value is 2,000 with a line height of 1.2, which is generally what <code> normal</code> line heights are in browsers. “So why didn’t you just set <code> line-height: 1</code> to verify that, genius?” I hear you asking. I did! And that’s when the layout height of the <code><div></code> bloomed to just over 8.9 million pixels, like it probably should have in the previous test! And all the same stuff happened when I moved the styles from the<code><div></code> to the <code><body></code>!</p>
<p>I’ve started writing at least three different hypotheses for why this happens, and stopped halfway through each because each hypothesis self-evidently fell apart as I was writing it. Maybe if I give my whimpering neurons a rest, I could come up with something. Maybe not. All I know is, I’d be much happier if someone just explained it to me; bonus points if their name is Clarissa.</p>
<p>Since setting line heights opened the door to madness in font sizing, I thought I’d try setting <code>line-height</code> to infinite pixels and see what came out. This time, things were (relatively speaking) more sane.</p>
<table class="data">
<caption>Line Height Results</caption>
<thead>
<tr>
<th>Browser</th>
<th>Computed value</th>
<th>Layout value</th>
</tr>
</thead>
<tbody>
<tr>
<td>Safari</td>
<td>33,554,428</td>
<td>33,554,428</td>
</tr>
<tr>
<td>Chrome</td>
<td>33,554,400</td>
<td>33,554,400</td>
</tr>
<tr>
<td>Firefox (Nightly)</td>
<td>17,895,700</td>
<td>8,947,840</td>
</tr>
</tbody>
</table>
<p>Essentially, the results were the same as what happened with element widths in the first example: Safari and Chrome were very close to 2<sup>25</sup>-1, and Firefox had its thing of a strange computed value and a rendering size not <em> quite</em> half the computed value.</p>
<p>I’m sure there’s a fair bit more to investigate about infinite-pixel values, or about infinite values in general, but I’m going to leave this here because my gray matter needs a rest and possibly a pressure washing. Still, if you have ideas for infinitely fun things to jam into browser engines and see what comes out, let me know. I’m already wondering what kind of shenanigans, other than in <code>z-index</code>, I can get up to with <code> calc(-infinity)</code>…</p>
<hr><p>Have something to say to all that? You can <a href="https://meyerweb.com/eric/thoughts/2025/08/07/infinite-pixels/#commentform">add a comment to the post</a>, or <a href="mailto:eric@meyerweb.com?subject=In%20reply%20to%20%22Infinite%20Pixels%22">email Eric directly</a>.</p>]]></content:encoded>
<wfw:commentRss>https://meyerweb.com/eric/thoughts/2025/08/07/infinite-pixels/feed/</wfw:commentRss>
<slash:comments>10</slash:comments>
</item>
<item>
<title>Masonry, Item Flow, and… GULP?</title>
<link>https://meyerweb.com/eric/thoughts/2025/05/21/masonry-item-flow-and-gulp/</link>
<comments>https://meyerweb.com/eric/thoughts/2025/05/21/masonry-item-flow-and-gulp/#comments</comments>
<dc:creator><![CDATA[Eric Meyer]]></dc:creator>
<pubDate>Wed, 21 May 2025 16:07:00 +0000</pubDate>
<category><![CDATA[CSS]]></category>
<guid isPermaLink="false">https://meyerweb.com/eric/thoughts/?p=5577</guid>
<description><![CDATA[Masonry layout is a difficult thing to do with CSS at present. Item Flow could make it easy.]]></description>
<content:encoded><![CDATA[<p>There’s a layout type that web designers have been using for a long time now, and yet can’t be easily done with CSS: “masonry” layout, sometimes called “you know, like Pinterest does it” layout. Masonry sits sort of halfway between flexbox and grid layout, which is a big part of why it’s been so hard to formalize. There are those who think of it as an extension of flexbox, and others who think it’s an extension of grid, and both schools of thought have pretty solid cases.</p>
<p>So that’s been a lot of the discussion, which led to competing blog posts from Google (<a href="https://developer.chrome.com/blog/masonry-syntax">“Feedback needed: How should we define CSS masonry?”</a>) and Apple (<a href="https://webkit.org/blog/16026/css-masonry-syntax/">“Help us choose the final syntax for Masonry in CSS”</a>). <a href="https://bkardell.com/"> Brian</a> and I, with special guest star <a href="https://rachelandrew.co.uk">Rachel Andrew</a>, did <a href="https://www.igalia.com/chats/masonry"> an Igalia Chats episode</a> about the debate, which I think is a decent exploration of the pros and cons of each approach for anyone interested.</p>
<p>But then, maybe you don’t actually <em>need</em> to explore the two sides of the debate, because there’s a new proposal in town. It’s currently being called Item Flow (which I can’t stop hearing sung by <a href="https://en.wikipedia.org/wiki/Eddie_Vedder">Eddie Vedder</a>, please send help) and is explained in some detail in <a href="https://webkit.org/blog/16587/item-flow-part-1-a-new-unified-concept-for-layout/">a blog post from the WebKit team</a>. The short summary is that it takes the flow and packing capabilities from flex and grid and puts them into their own set of properties, along with some new capabilities.</p>
<p>As an example, here’s a thing you can currently do with flexbox:</p>
<pre class="css"><code>display: flex;
flex-wrap: wrap;
flex-direction: column;</code>
</pre>
<p>If the current Item Flow proposals are taken as-is, you could get the same behavior with:</p>
<pre class="css?"><code>display: flex;
item-wrap: wrap;
item-direction: column;</code>
</pre>
<p>…or, you could more compactly write it as:</p>
<pre><code>display: flex;
item-flow: wrap column;</code>
</pre>
<p>Now you might be thinking, okay, this just renames some flex properties to talk about items instead and you also get a shorthand property; big deal. It actually <em>is</em> a big deal, though, because these <code>item-*</code> properties would apply in grid settingsas well. In other words, you would be able to say:</p>
<pre><code>display: grid;
item-flow: wrap column;</code>
</pre>
<p>Hold up. Item wrapping… in <em>grid</em>?!? Isn’t that just the same as what grid already does? Which is an excellent question, and not one that’s actually settled.</p>
<p>However, let’s invert the wrapping in grid contexts to consider an example given in the WebKit article linked earlier, which is that you could specify a single row of grid items that equally divide up the row’s width to size themselves, like so:</p>
<pre><code>display: grid;
grid-auto-columns: 1fr;
item-wrap: nowrap;</code>
</pre>
<p>In that case, a row of five items would size each item to be one-fifth the width of the row, whereas a row of three items would have each item be one-third the row’s width. That’s a new thing, and quite interesting to ponder.</p>
<p>The proposal includes the properties <code>item-pack</code> and <code>item-slack</code>, the latter of which makes me grin a little like J.R. “Bob” Dobbs but the former of which I find a lot more interesting. Consider:</p>
<pre><code>display: flex;
item-wrap: wrap;
item-pack: balance;</code>
</pre>
<p>This would act with flex items much the way <a href="https://developer.chrome.com/docs/css-ui/css-text-wrap-balance">
<code>text-wrap: balance</code> acts with words</a>. If you have six flex items of roughly equal size, they’ll balance between two rows to three-and-three rather than five-and-one. Even if your flex items are of very different sizes, <code> item-pack: balance</code> would do always automatically its best to get the row lengths as close to equal as possible, whether that’s two rows, three rows, four rows, or however many rows. Or columns! This works just as well either way.</p>
<p>There are still debates to be had and details to be worked out, but this new direction does feel fairly promising to me. It covers all of the current behaviors that flex and grid flowing already permit, plus it solves some longstanding gripes about each layout approach and while also opening some new doors.</p>
<p>The prime example of a new door is the aforementioned masonry layout. In fact, the previous code example is essentially a true masonry layout (because it resembles the way irregular bricks are laid in a wall). If we wanted that same behavior, only vertically like Pinterest does it, we could try:</p>
<pre><code>display: flex;
item-direction: column; /* could also be `flex-direction` */
item-wrap: wrap; /* could also be `flex-wrap` */
item-pack: balance;</code>
</pre>
<p>That would be harder to manage, though, since for most writing modes on the web, the width is constrained and the height is not. In other words, to make that work with flexbox, we’d have to set an explicit height. We also wouldn’t be able to nail down the number of columns. Furthermore, that would cause the source order to flow down columns and then jump back to the top of the next column. So, instead, maybe we’d be able to say:</p>
<pre><code>display: grid;
grid-template-columns: repeat(3,1fr);
item-direction: row;
item-pack: dense balance;</code>
</pre>
<p>If I’ve read the WebKit article correctly, that would allow Pinterest-style layout with the items actually going across the columns in terms of source order, but being laid out in packed columns (sometimes called “waterfall” layout, which is to say, “masonry” but rotated 90 degrees).</p>
<p>That said, it’s possible I’m wrong in some of the particulars here, and even if I’m not, the proposal is still very much in flux. Even the property names could change, so values and behaviors are definitely up for debate.</p>
<p>As I pondered that last example, the waterfall/Pinterest layout, I thought: isn’t this visual result essentially what multicolumn layout does? Not in terms of source order, since multicolumn elements run down one column before starting again at the top of the next. But that seems an easy enough thing to recreate like so:</p>
<pre><code>display: grid;
grid-template-columns: repeat(3,1fr);
item-direction: column;
item-pack: dense balance;</code>
</pre>
<p>That’s a balanced set of three equally wide columns, just like in multicol. I can use <code>gap</code> for the column gaps, so that’s handled. I wouldn’t be able to set up column rules — at least, not right now, though that may be coming thanks to the Edge team’s <a href="https://blogs.windows.com/msedgedev/2025/03/19/minding-the-gaps-a-new-way-to-draw-separators-in-css/">gap decorations proposal</a>. But what I <em> would</em> be able to do, that I can’t now, is vary the width of my multiple columns. Thus:</p>
<pre><code>display: grid;
grid-template-columns: 60% 40%; /* or 3fr 2fr, idc */
item-direction: column;
item-pack: dense balance;</code>
</pre>
<p>Is that useful? I dunno! It’s certainly not a thing we can do in CSS now, though, and if there’s one thing I’ve learned in the past almost three decades, it’s that a lot of great new ideas come out of adding new layout capabilities.</p>
<p>So, if you’ve made it this far, thanks for reading and I strongly encourage you to go read <a href="https://webkit.org/blog/16587/item-flow-part-1-a-new-unified-concept-for-layout/">the WebKit team’s post</a> if you haven’t already (it has more detail and a lovely summary matrix near the end) and think about what this could do for you, or what it looks like it might fall short of making possible for you.</p>
<p>As I’ve said, this feels promising to me, as it enables what we thought was a third layout mode (masonry/waterfall) by enriching and extending the layout modes we already have (flex/grid). It also feels like this could eventually lead to a Grand Unified Layout Platform — a GULP, if you will — where we don’t even have to say whether a given layout’s <code>display</code> is <code>flex</code> or <code>grid</code>, but instead specify the exact behaviors we want using various <code> item-*</code> properties to get just the right ratio of flexible and grid-like qualities for a given situation.</p>
<p>…or, maybe, it’s already there. It almost feels like it is, but I haven’t thought about it in enough detail yet to know if there are things it’s missing, and if so, what those might be. All I can say is, my Web-Sense is tingling, so I’m definitely going to be digging more at this to see what might turn up. I’d love to hear from all y’all in the comments about what you think!</p>
<hr><p>Have something to say to all that? You can <a href="https://meyerweb.com/eric/thoughts/2025/05/21/masonry-item-flow-and-gulp/#commentform">add a comment to the post</a>, or <a href="mailto:eric@meyerweb.com?subject=In%20reply%20to%20%22Masonry,%20Item%20Flow,%20and…%20GULP?%22">email Eric directly</a>.</p>]]></content:encoded>
<wfw:commentRss>https://meyerweb.com/eric/thoughts/2025/05/21/masonry-item-flow-and-gulp/feed/</wfw:commentRss>
<slash:comments>5</slash:comments>
</item>
<item>
<title>CSS Naked Day 2025</title>
<link>https://meyerweb.com/eric/thoughts/2025/04/09/css-naked-day-2025/</link>
<comments>https://meyerweb.com/eric/thoughts/2025/04/09/css-naked-day-2025/#comments</comments>
<dc:creator><![CDATA[Eric Meyer]]></dc:creator>
<pubDate>Wed, 09 Apr 2025 17:22:46 +0000</pubDate>
<category><![CDATA[CSS]]></category>
<category><![CDATA[Design]]></category>
<category><![CDATA[Web]]></category>
<guid isPermaLink="false">https://meyerweb.com/eric/thoughts/?p=5568</guid>
<description><![CDATA[meyerweb.com goes au naturel, mostly, in observance of the annual CSS Naked Day.]]></description>
<content:encoded><![CDATA[<p>I’m a little (okay, a lot) late to it, but meyerweb is now participating in <a href="https://css-naked-day.org/">CSS Naked Day</a>  —  I’ve removed the site’s styles, except in cases where pages have embedded CSS, which I’m not going to do a find-and-replace to try to suppress. So if I embedded a one-off CSS Grid layout, like on <a href="/eric/tools/">the Toolbox page</a>, that will still be in force. Also, cached files with CSS links could take a little time to clear out. Otherwise, you should get 1990-style HTML. Enjoy!</p>
<p>(The site’s design will return tomorrow, or whenever I remember [or am prodded] to restore it.)</p>
<hr><p>Have something to say to all that? You can <a href="https://meyerweb.com/eric/thoughts/2025/04/09/css-naked-day-2025/#commentform">add a comment to the post</a>, or <a href="mailto:eric@meyerweb.com?subject=In%20reply%20to%20%22CSS%20Naked%20Day%202025%22">email Eric directly</a>.</p>]]></content:encoded>
<wfw:commentRss>https://meyerweb.com/eric/thoughts/2025/04/09/css-naked-day-2025/feed/</wfw:commentRss>
<slash:comments>1</slash:comments>
</item>
<item>
<title>CSS Wish List 2025</title>
<link>https://meyerweb.com/eric/thoughts/2025/01/08/css-wish-list-2025/</link>
<comments>https://meyerweb.com/eric/thoughts/2025/01/08/css-wish-list-2025/#comments</comments>
<dc:creator><![CDATA[Eric Meyer]]></dc:creator>
<pubDate>Wed, 08 Jan 2025 12:45:06 +0000</pubDate>
<category><![CDATA[CSS]]></category>
<guid isPermaLink="false">https://meyerweb.com/eric/thoughts/?p=5560</guid>
<description><![CDATA[Back in 2023, I belatedly jumped on the bandwagon of people posting their CSS wish lists for the coming year. This year I’m doing all that again, less belatedly! (I didn’t do it last year because I couldn’t even. Get it?) I started this post by looking at what I wished for a couple of […]]]></description>
<content:encoded><![CDATA[<p>Back in 2023, I <a href="https://meyerweb.com/eric/thoughts/2023/02/08/css-wish-list-2023/">belatedly jumped on the bandwagon</a> of people posting their CSS wish lists for the coming year. This year I’m doing all that again, less belatedly! (I didn’t do it last year because I couldn’t even. Get it?)</p>
<p>I started this post by looking at what I wished for a couple of years ago, and a small handful of my wishes came true:</p>
<ul>
<li><a href="https://drafts.csswg.org/css-grid/#subgrids">Subgrid</a> support</li>
<li><a href="https://drafts.csswg.org/css-nesting-1/">Nested selectors</a>
</li>
<li>Color shading and blending (thanks to <a href="https://drafts.csswg.org/css-color-5/#color-mix"><code>color-mix()</code></a>)</li>
<li>More and better <code>:has()</code> use</li>
</ul>
<p>Note that by “came true”, I mean “reached at least Baseline Newly Available”, not “reached Baseline Universal”; that latter status comes over time. And more <code>:has()</code> isn’t really a feature you can track, but I do see more people sharing cool <code>:has()</code> tricks and techniques these days, so I’ll take that as a positive signal.</p>
<p>A couple more of my 2023 wishes are on the cusp of coming true:</p>
<ul>
<li>Element transitions, a.k.a. <a href="https://drafts.csswg.org/css-view-transitions-1/">view transitions</a></li>
<li><a href="https://drafts.csswg.org/css-anchor-position-1/">Anchor positioning</a>
</li>
</ul>
<p>Those are both in the process of rolling out, and look set to reach Baseline Newly Available before the year is done. I hope.</p>
<p>That leaves the other half of the 2023 list, none of which has seen much movement. So those will be the basis of this year’s list, with some new additions.</p>
<h3 id="hanging-punctuation">Hanging punctuation</h3>
<p>WebKit has been the sole implementor of this <a href="https://drafts.csswg.org/css-text/#hanging-punctuation-property">very nice typographic touch</a> for almost a decade now. The lack of any support by Blink and Gecko is now starting to verge on feeling faintly ridiculous.</p>
<h3 id="margin-and-line-box-trimming">Margin and line box trimming</h3>
<p>Trim off the leading block margin on the first child in an element, or the trailing block margin of the last child, so they don’t stick out of the element and mess with margin collapsing. Same thing with block margins on the first and last line boxes in an element. And then, be able to do similar things with the inline margins of elements and line boxes! All these things could be ours.</p>
<h3 id="stroked-text">Stroked text</h3>
<p>We can already fake text stroking with <code>text-shadow</code> and <code>paint-order</code>, at least in SVG. I’d love to have a <code> text-stroke</code> property that can be applied to HTML, SVG, and MathML text. And XML text and any text that CSS is able to style. It should be at least as powerful as SVG stroking, if not more so.</p>
<h3 id="expanded-attr-support">Expanded <code>attr()</code> support</h3>
<p>This has seen some movement specification-wise, but last I checked, no implementation promises or immediate plans. Here’s what I want to be able to do:</p>
<pre><code>td {width: attr(data-size em, 1px));
<td data-size="5">…</td></code>
</pre>
<p>The <a href="https://drafts.csswg.org/css-values-5/#attr-notation">latest Values and Units module describes this</a>, so fingers crossed it starts to gain some momentum.</p>
<h3 id="exclusions">Exclusions</h3>
<p>Yes, I still want <a href="https://drafts.csswg.org/css-exclusions/">CSS Exclusions</a>, a <em> lot</em>. They would make some layout hacks a lot less hacky, and open the door for really cool new hacks, by letting you just mark an element as creating a flow exclusions for the content of other elements. Position an image across two columns of text and set it to exclude, and the text of those columns will flow around or past it like it was a float. This remains one of the big missing pieces of CSS layout, in my view. Linked flow regions is another.</p>
<h3 id="masonry-layout">Masonry layout</h3>
<p>This one is a bit stalled because the basic approach still hasn’t been decided. <a href="https://webkit.org/blog/16026/css-masonry-syntax/">Is it part of CSS Grid</a> or <a href="https://developer.chrome.com/blog/masonry-syntax">its own display type</a>? It’s a tough call. There are persuasive arguments for both. I myself keep flip-flopping on which one I prefer.</p>
<p>Designers want this. Implementors want this. In some ways, that’s what makes it so difficult to pick the final syntax and approach: because everyone wants this, everyone wants to make the exactly perfect right choices for now, for the future, and for ease of teaching new developers. That’s very, <em>very</em> hard.</p>
<h3 id="grid-track-and-gap-styles">Grid track and gap styles</h3>
<p>Yeah, I still want a Grid equivalent of <code>column-rule</code>, except more full-featured and powerful. Ideally this would be combined with a way to select individual grid tracks, something like:</p>
<pre><code>.gallery {display: grid;}
.gallery:col-track(4) {gap-rule: 2px solid red;}</code>
</pre>
<p>…in order to just put a gap rule on that particular column. I say that would be ideal because then I could push for a way to set the <code>gap</code> value for individual tracks, something like:</p>
<pre><code>.gallery {gap: 1em 2em;}
.gallery:row-track(2) {gap: 2em 0.5em;}</code>
</pre>
<p>…to change the leading and trailing gaps on just that row.</p>
<h3 id="custom-media-queries">Custom media queries</h3>
<p>This was listed as “Media query variables” in 2023. With these, you could define a breakpoint set like so:</p>
<pre>
<code>@custom-media --sm (inline-size <= 25rem);
@custom-media --md (25rem < inline-size <= 50rem);
@custom-media --lg (50rem < inline-size);
body {margin-inline: auto;}
@media (--sm) {body {inline-size: auto;}}
@media (--md) {body {inline-size: min(90vw, 40em);}
@media (--lg) {body {inline-size: min(90vw, 55em);}</code>
</pre>
<p>In other words, you can use custom media queries as much as you want throughout your CSS, but change their definitions in just one place. It’s CSS variables, but for media queries! Let’s do it.</p>
<h3 id="unprefix-all-the-things">Unprefix all the things</h3>
<p>Since we decided to abandon vendor prefixing in favor of feature flags, I want to see anything that’s still prefixed get unprefixed, in all browsers. Keep the support for the prefixed versions, sure, I don’t care, just let us write the property and value names without the prefixes, please and thank you.</p>
<h3 id="grab-bag">Grab bag</h3>
<p>I still would like a way to indicate when a shorthand property is meant for logical rather than physical directions, a way to apply a style sheet to a single element, the ability to add or subtract values from a shorthand without having to rewrite the whole thing, and styles that cross resource boudnaries. They’re all in <a href="https://meyerweb.com/eric/thoughts/2023/02/08/css-wish-list-2023/">the 2023 post</a>.</p>
<p>Okay, that’s my list. What’s yours?</p>
<hr><p>Have something to say to all that? You can <a href="https://meyerweb.com/eric/thoughts/2025/01/08/css-wish-list-2025/#commentform">add a comment to the post</a>, or <a href="mailto:eric@meyerweb.com?subject=In%20reply%20to%20%22CSS%20Wish%20List%202025%22">email Eric directly</a>.</p>]]></content:encoded>
<wfw:commentRss>https://meyerweb.com/eric/thoughts/2025/01/08/css-wish-list-2025/feed/</wfw:commentRss>
<slash:comments>5</slash:comments>
</item>
<item>
<title>Design for Real Life: Online for Free AND On Sale for Money</title>
<link>https://meyerweb.com/eric/thoughts/2024/10/10/design-for-real-life-online-for-free-and-on-sale-for-money/</link>
<comments>https://meyerweb.com/eric/thoughts/2024/10/10/design-for-real-life-online-for-free-and-on-sale-for-money/#comments</comments>
<dc:creator><![CDATA[Eric Meyer]]></dc:creator>
<pubDate>Thu, 10 Oct 2024 20:27:01 +0000</pubDate>
<category><![CDATA[Books]]></category>
<category><![CDATA[Design]]></category>
<category><![CDATA[Writing]]></category>
<guid isPermaLink="false">https://meyerweb.com/eric/thoughts/?p=5549</guid>
<description><![CDATA[Design for Real Life is now available, for free, in its entirety, at dfrlbook.com. And is also for sale!]]></description>
<content:encoded><![CDATA[<figure><a href="https://meyerweb.com/eric/thoughts/wp-content/uploads/dfrl-cover.png"><img decoding="async" src="https://meyerweb.com/eric/thoughts/wp-content/uploads/dfrl-cover.png" alt="" width="" height="" class="" /></a></figure>
<p><a href="https://dfrlbook.com"><cite>Design for Real Life</cite> is now available, for free</a>, in its entirety, at <code> <a href="https://dfrlbook.com">dfrlbook.com</a></code>. If you like what you read and want a personal copy, or just to support Sara and me, <a href="https://dfrlbook.com/page/buy-the-book/"> print-on-demand and ePub versions are also available</a> from a number of sources. There are some countries where the book is not yet available, which we hope will be fixed soon. We’ll update the “Buy the book” page as appropriate.</p>
<p><a href="https://dfrlbook.com">The booksite</a> contains the entire content of the book, with no paywalls or premium tiers or whatever gimmicks late-stage capitalism/early-stage infoconomy is forcing online publishers to try this month. So if you want to read it for nothing more than some of your time, or share it with people who you think might benefit from the free resource, go for it! Spread the word far and wide! Please and thank you.</p>
<p>To those who already own a copy of the book, the only real differences between that text and the one we have now is: we removed all the A Book Apart (ABA) branding and contact information, and made a couple of URL updates. We also had to switch to fonts for which we had licensing. Thus, if you have the ABA version, this is essentially the same thing. You do <strong>not</strong> need to buy this new printing. You certainly <em>can</em> buy it, if you want, but the content won’t be different in any meaningful way.</p>
<p>A project like this does not happen individually, and some thanks are in order.</p>
<p>First, so very many thanks to my co-author, <a href="https://sarawb.com">Sara Wachter-Boettcher</a>. Not just for writing it with me almost a decade ago, but also for her tireless work on the tedious minutia of transferring ownership of publisher accounts, obtaining a new ISBN, organizing the work that needed to be done, et cetera, et cetera. Basically, project managed the whole thing. It would have taken forever to get done if I’d been in charge, so the credit for it being live goes entirely to her.</p>
<p>Second, many thanks to <a href="https://eaton.fyi/">Jeff Eaton</a>, who wrote a converter called <a href="https://github.com/eaton/dq"> Dancing Queen</a> that takes in an ABA ePub file and spits out Markdown files containing all the text and images of the figures. Then he gave it to us all for free.</p>
<p>Third, we were able to get the book up for free thanks to the generosity of fellow ABA author and union man <a href="https://hire.wil.to/">Mat Marquis</a>, who wrote <a href="https://github.com/Wilto/a-book-departs"> some code</a> to take the output of Dancing Queen and import it into an <a href="https://11ty.dev/">11ty</a> install. He did free tech support and lent a helping hand to us whenever we ran into snags. He was also an integral part of the process that led to all the ABA authors reclaiming full ownership of their books. He’ll deny every word of it, but dude is a mensch. You should hire him to do cool stuff for you.</p>
<p>Speaking of all the ABA authors, the community we formed to help each other through the reclamation process has been a real blessing. So many tips and tricks and expressions of support and celebrations of progress have flowed through the team over the past few months. None of us had to do any of this alone. Collective action, community support, <em>works</em>.</p>
<p>The conversion to ePub was handled by the entirely capable Ron Bilodeau, who leveraged his experience doing that work for ABA to do it for us. Thank you, Ron!</p>
<p>And certainly not least, thank you to everyone at A Book Apart for publishing the book in the first place, for being great partners in its creation, and for releasing the books back to us when it was time to close up shop. It’s hard to imagine it would have existed at all without ABA, so thank you, one and all.</p>
<hr><p>Have something to say to all that? You can <a href="https://meyerweb.com/eric/thoughts/2024/10/10/design-for-real-life-online-for-free-and-on-sale-for-money/#commentform">add a comment to the post</a>, or <a href="mailto:eric@meyerweb.com?subject=In%20reply%20to%20%22Design%20for%20Real%20Life:%20Online%20for%20Free%20AND%20On%20Sale%20for%20Money%22">email Eric directly</a>.</p>]]></content:encoded>
<wfw:commentRss>https://meyerweb.com/eric/thoughts/2024/10/10/design-for-real-life-online-for-free-and-on-sale-for-money/feed/</wfw:commentRss>
<slash:comments>1</slash:comments>
</item>
<item>
<title>Announcing BCD Watch</title>
<link>https://meyerweb.com/eric/thoughts/2024/09/23/announcing-bcd-watch/</link>
<comments>https://meyerweb.com/eric/thoughts/2024/09/23/announcing-bcd-watch/#comments</comments>
<dc:creator><![CDATA[Eric Meyer]]></dc:creator>
<pubDate>Mon, 23 Sep 2024 15:54:33 +0000</pubDate>
<category><![CDATA[Browsers]]></category>
<category><![CDATA[Tools]]></category>
<category><![CDATA[Web]]></category>
<guid isPermaLink="false">https://meyerweb.com/eric/thoughts/?p=5539</guid>
<description><![CDATA[A new service to help you keep up to date with changes in browser support.]]></description>
<content:encoded><![CDATA[<figure class="standalone">
<a href="https://meyerweb.com/eric/thoughts/wp-content/uploads/bcd-watch-01.png"><img decoding="async" src="https://meyerweb.com/eric/thoughts/wp-content/uploads/bcd-watch-01.png" alt="" /></a>
</figure>
<p>
One of the things I think we all struggle with is keeping up to date with changes in web development. You might hear about a super cool new CSS feature or JavaScript API, but it’s never supported by all the browsers when you hear about it, right? So you think “I’ll have to make sure check in on that again later” and quickly forget about it. Then some time down the road you hear about it again, talked about like it’s been best practice for years.
</p>
<p>
To help address this, <a href="https://bkardell.com">Brian Kardell</a> and I have built <strong>a service called <a href="https://bcd-watch.igalia.com">BCD Watch</a></strong>, with a nicely sleek design by <a href="https://stephaniestimac.com/">Stephanie Stimac</a>. It’s <strong>free for all to use</strong> thanks to the generous support of <a href="https://igalia.com">Igalia</a> in terms of our time and hosting the service.
</p>
<p>
What BCD Watch does is, it grabs releases of the <a href="https://github.com/mdn/browser-compat-data">Browser Compatibility Data (BCD) repository</a> that underpins the support tables on <a href="https://developer.mozilla.org">MDN</a> and services like <a href="https://caniuse.com">caniuse.com</a>. It then analyzes what’s changed since the previous release.
</p>
<p>
Every Monday, BCD Watch produces two reports. <a href="https://bcd-watch.igalia.com/weekly/">The Weekly Changes Report</a> lists all the changes to BCD that happened in the previous week — what’s been added, removed, or renamed in the whole of BCD. It also tells you which of the Big Three browsers newly support (or dropped support for) each listed feature, along with a progress bar showing how close the feature is to attaining Baseline status.</p>
<p>
<a href="https://bcd-watch.igalia.com/weekly-completed/">The Weekly Baselines Report</a> is essentially a filter of the first report: instead of all the changes, it lists only changes to <a href="https://web.dev/baseline">Baseline</a> status, noting which features are newly Baseline. <a href="https://bcd-watch.igalia.com/weekly-completed/2024-09-09.html">Some weeks</a>, it will have nothing to report. <a href="https://bcd-watch.igalia.com/weekly-completed/2024-06-24.html">Other weeks</a>, it will list everything that’s reached Baseline’s “Newly Available” tier.
</p>
<p>
Both reports are available as standalone RSS, Atom, and JSON feeds, which are linked at the bottom of each report. So while you <em>can</em> drop in on the site every week to bask in the visual design if you want (and that’s fine!), you can also get a post or two in your feed reader every Monday that will get you up to date on what’s been happening in the world of web development.
</p>
<p>
If you want to look back at older reports, the home page has a details/summary collapsed list of weekly reports going back to the beginning of 2022, which we generated by downloading all the BCD releases back that far, and running the report script against them.
</p>
<p>
If you encounter any problems with BCD Watch or have suggestions for improvements, please feel free to open an issue in <a href="https://github.com/bkardell/bcd-watch">the repository</a>, or submit suggested changes via pull request if you like. We do expect the service to evolve over time, perhaps adding a report for things that have hit Baseline Widely Available status (30 months after hitting all three engines) or reports that look at more than just the Big Three engines. Hard to say! Always in motion, the future is.
</p>
<p>
Whatever we may add, though, we’ll keep BCD Watch centered on the idea of keeping you better up to date on web dev changes, once a week, every week. We really hope this is useful and interesting for you! We’ve definitely appreciated having the weekly updates as we built and tested this, and we think a lot of you will, too.
</p>
<hr><p>Have something to say to all that? You can <a href="https://meyerweb.com/eric/thoughts/2024/09/23/announcing-bcd-watch/#commentform">add a comment to the post</a>, or <a href="mailto:eric@meyerweb.com?subject=In%20reply%20to%20%22Announcing%20BCD%20Watch%22">email Eric directly</a>.</p>]]></content:encoded>
<wfw:commentRss>https://meyerweb.com/eric/thoughts/2024/09/23/announcing-bcd-watch/feed/</wfw:commentRss>
<slash:comments>6</slash:comments>
</item>
<item>
<title>Design for Real Life News!</title>
<link>https://meyerweb.com/eric/thoughts/2024/07/22/design-for-real-life-news/</link>
<comments>https://meyerweb.com/eric/thoughts/2024/07/22/design-for-real-life-news/#comments</comments>
<dc:creator><![CDATA[Eric Meyer]]></dc:creator>
<pubDate>Mon, 22 Jul 2024 15:22:01 +0000</pubDate>
<category><![CDATA[Web]]></category>
<category><![CDATA[Writing]]></category>
<guid isPermaLink="false">https://meyerweb.com/eric/thoughts/?p=5521</guid>
<description><![CDATA[Design for Real Life’s rights have been returned to Sara and me, and we’ve cut the price by about half (or more in some regions).]]></description>
<content:encoded><![CDATA[<p>If you’re reading this, odds are you’ve at least heard of A Book Apart (ABA), who published <cite>Design for Real Life</cite>, which I co-wrote with <a href="https://sarawb.com">Sara Wachter-Boettcher</a> back in 2016. What you may not have heard is that <a href="https://abookapart.com/pages/about">ABA has closed up shop</a>. There won’t be any more new ABA titles, nor will ABA continue to sell the books in their catalog.</p>
<p>That’s the bad news. The great news is that ABA has transferred the rights for all of its books to their respective authors! (Not every ex-publisher does this, and not every book contract demands it, so thanks to ABA.) We’re all figuring out what to do with our books, and everyone will make their own choices. One of the things Sara and I have decided to do is to eventually put the entire text online for free, as a booksite. That isn’t ready yet, but it should be coming somewhere down the road.</p>
<figure><a href="https://www.sarawb.com/design-for-real-life"><img fetchpriority="high" decoding="async" src="https://meyerweb.com/eric/books/external/dfrl.png" width="300" height="464" class="book cover"/></a></figure>
<p>In the meantime, we’ve decided to cut the price of print and e-book copies available through Ingram. <cite title="Design for Real Life">DfRL</cite> was the eighteenth book ABA put out, so we’ve decided to make the price of both the print and e-book $18, regardless of whether those dollars are American, Canadian, or Australian. Also €18 and £18. Basically, in all five currencies we can define, the price is 18 of those.</p>
<p>…unless you buy it through Apple Books; then it’s 17.99 of every currency, because the system forces us to make it cheaper than the list price and also have the amount end in <code>.99</code>. Obversely, if you’re buying a copy (or copies) for a library, the price has to be <em> more</em> than the list price and also end in <code>.99</code>, so the library cost is 18.99 currency units. Yeah, I dunno either.
</p>
<p>At any rate, compared to its old price, this is a significant price cut, and in some cases (yes, Australia, we’re looking at you) it’s a <em> huge</em> discount. Or, at least, it <em>will</em> be at a discount once online shops catch up. The US-based shops seem to be up to date, and Apple Books as well, but some of the “foreign” (non-U.S.) sources are still at their old prices. In those cases, maybe wishlist or bookmark or something and keep an eye out for the drop. We hope it will become global by the end of the week. And hey, as I write this, a couple of places have the ebook version for like 22% less than our listed price.</p>
<p>So! If you’ve always thought about buying a copy but never got around to it, now’s a good time to get a great deal. Ditto if you’ve never heard of the book but it sounds interesting, or you want it in ABA branding, or really for any other reason you have to <a href="https://www.sarawb.com/design-for-real-life">buy a copy now</a>.</p>
<p>I suppose the real question is, <em>should</em> you buy a copy? We’ll grant that some parts of it are a little dated, for sure. But the concepts and approaches we introduced can be seen in a lot of work done even today. It made significant inroads into government design practices in the UK and elsewhere, for example, and we still hear from people who say it really changed how they think about design and UX. We’re still very proud of it, and we think anyone who takes the job of serving their users seriously should give it a read. But then, I guess we would, or else we’d never have written it in the first place.</p>
<p>And that’s the story so far. I’ll blog again when the freebook is online, and if anything else changes as we go through the process. Got questions? Leave a comment or drop me a line.</p>
<hr><p>Have something to say to all that? You can <a href="https://meyerweb.com/eric/thoughts/2024/07/22/design-for-real-life-news/#commentform">add a comment to the post</a>, or <a href="mailto:eric@meyerweb.com?subject=In%20reply%20to%20%22Design%20for%20Real%20Life%20News!%22">email Eric directly</a>.</p>]]></content:encoded>
<wfw:commentRss>https://meyerweb.com/eric/thoughts/2024/07/22/design-for-real-life-news/feed/</wfw:commentRss>
<slash:comments>2</slash:comments>
</item>
<item>
<title>A Decade Later, A Decade Lost</title>
<link>https://meyerweb.com/eric/thoughts/2024/06/07/a-decade-later-a-decade-lost/</link>
<comments>https://meyerweb.com/eric/thoughts/2024/06/07/a-decade-later-a-decade-lost/#comments</comments>
<dc:creator><![CDATA[Eric Meyer]]></dc:creator>
<pubDate>Fri, 07 Jun 2024 22:00:03 +0000</pubDate>
<category><![CDATA[Rebecca]]></category>
<guid isPermaLink="false">https://meyerweb.com/eric/thoughts/?p=5513</guid>
<description><![CDATA[I woke up this morning about an hour ahead of my alarm, the sky already light, birds calling. ]]></description>
<content:encoded><![CDATA[<p>I woke up this morning about an hour ahead of my alarm, the sky already light, birds calling. After a few minutes, a brief patter of rain swept across the roof and moved on.</p>
<p>I just lay there, not really thinking. Feeling. Remembering.</p>
<p>Almost sixteen years to the minute before I awoke, my second daughter was born. Almost ten years to the same minute before, she’d turned six years old, already semi-unconscious, and died not quite twelve hours later.</p>
<p>So she won’t be taking her first solo car drive today. She won’t be celebrating with dinner at her favorite restaurant in the whole world. She won’t kiss her niece good night or affectionately rag on her siblings.</p>
<p>Or maybe she wouldn’t have done any of those things anyway, after a decade of growth and changes and paths taken. What would she really be like, at sixteen?</p>
<p>We will never know. We can’t even guess. All of that, everything she might have been, is lost.</p>
<p>This afternoon, we’ll visit Rebecca’s grave, and then go to hear her name read in remembrance at one of her very happiest places, <a href="https://en.wikipedia.org/wiki/Anshe_Chesed_Fairmount_Temple">Anshe Chesed Fairmount Temple</a>, for the last time. At the end of the month, the temple will close as part of a merger. Another loss.</p>
<p>A decade ago, I said that I felt the weight of all the years she would never have, and that they might crush me. Over time, I have come to realize all the things she never saw or did adds to that weight. Even though it seems like it should be the same weight. Somehow, it isn’t.</p>
<p>I was talking about all of this with a therapist a few days ago, about the time and the losses and their accumulated weight. I said, “I don’t know how to be okay when I failed my child in the most fundamental way possible.”</p>
<p>“You didn’t fail her,” they said gently.</p>
<p>“I know that,” I replied. “But I don’t feel it.”</p>
<p>A decade, it turns out, does not change that. I’m not sure now that any stretch of time ever could.</p>
<hr><p>Have something to say to all that? You can <a href="https://meyerweb.com/eric/thoughts/2024/06/07/a-decade-later-a-decade-lost/#commentform">add a comment to the post</a>, or <a href="mailto:eric@meyerweb.com?subject=In%20reply%20to%20%22A%20Decade%20Later,%20A%20Decade%20Lost%22">email Eric directly</a>.</p>]]></content:encoded>
<wfw:commentRss>https://meyerweb.com/eric/thoughts/2024/06/07/a-decade-later-a-decade-lost/feed/</wfw:commentRss>
<slash:comments>30</slash:comments>
</item>
<item>
<title>Bookmarklet: Load All GitHub Comments</title>
<link>https://meyerweb.com/eric/thoughts/2024/02/05/bookmarklet-load-all-github-comments/</link>
<comments>https://meyerweb.com/eric/thoughts/2024/02/05/bookmarklet-load-all-github-comments/#comments</comments>
<dc:creator><![CDATA[Eric Meyer]]></dc:creator>
<pubDate>Mon, 05 Feb 2024 14:49:46 +0000</pubDate>
<category><![CDATA[Hacks]]></category>
<category><![CDATA[JavaScript]]></category>
<category><![CDATA[Tools]]></category>
<category><![CDATA[Web]]></category>
<guid isPermaLink="false">https://meyerweb.com/eric/thoughts/?p=5497</guid>
<description><![CDATA[A quick way to load all the comments on a GitHub issue.]]></description>
<content:encoded><![CDATA[<p>What happened was, <a href="https://bkardell.com/" rel="acquaintance colleague co-worker met">Brian</a> and I were chatting about W3C GitHub issues and Brian mentioned how really long issues are annoying to search and read, because GitHub has this thing where if there are too many comments on an issue, it snips out the middle with a “Load more…” button that’s very tastefully designed and pretty easy to miss if you’re quick-scrolling to try to catch up. The squiggle-line would be a good marker, if it weren’t so tasteful as to blend into the background in a way that makes the Baby WCAG cry.</p>
<p>And what’s worse, from this perspective, is that if the issue has been discussed to a very particular kind of death, the “Load more…” button can have more “Load more…” buttons hiding within. So even if you know there was an interesting comment, and you remember a word or two of it, page-searching in your browser will do no good if the comment in question is buried one or more XMLHTTPRequest calls deep.</p>
<p>“I really wish GitHub had an ‘expand all comments’ button at the top or something,” Brian said (or words to that effect).</p>
<p>Well, it was a Friday afternoon and I was feeling code-hacky, so I wrote a bookmarklet. Here it is in easy-to-save hyperlink form:</p>
<p>
<a id="ghload" href="javascript:function start(){let buttons=document.querySelectorAll('button');let loaders=[];for(let i=0;i<buttons.length;i+=1){if(buttons[i].textContent.trim()=='Load more%E2%80%A6'){loaders.push(buttons[i]);buttons[i].dispatchEvent(new MouseEvent('click',{view:window,bubbles:false}))}}if(loaders.length>0){setTimeout(start,5000)}}setTimeout(start,500);void(20240130);">GitHub issue loader</a>
</p>
<p>It waits half a second after you activate it to find all the buttons on the page (in my test runs, usually <em>six hundred</em> of them). Then it looks through all the buttons to find the ones that have a <code>textContent</code> of “Load more…” and dispatches a click event to each one. With that done, it waits five seconds and does it all again, waits five seconds to do it again, and so on. Once it finds there are zero buttons with the “Load more…” <code>textContent</code>, it exits. And, if five seconds is too quick due to slow loading times, you can always invoke the bookmarklet again should you come across a “Load more…” button.</p>
<p>If you want this ability for yourself, just drag the link above into your bookmark toolbar or bookmarks menu, and whenever you load up a mega-thread GitHub issue, fire the bookmarklet to load all the comments. I imagine there may be cleaner ways to do this, but I was able to codeslam this in about 15 minutes using <a href="https://violentmonkey.github.io/">ViolentMonkey</a> on live GitHub pages, and it does the thing.</p>
<p>I did consider complexifying the ViolentMonkey script so that any GitHub page is scanned for the “Load more…” button, and if one is present, then a “Load all comments” button is plopped into the top of the page, but I knew that would take at least another 15 minutes and my codeslam window was closing. Also, it would require anyone using it to run ViolentMonkey (or equivalent) all the time, whereas the bookmarlet has zero impact unless the user invokes it. If you want to extend this into something more than it is and share your solution with the world, by all means feel free.</p>
<p>The point of all this being, if you too wish GitHub had an easy way to load all the comments without you having to search for the “Load more…” button yourself, now there’s a bookmarklet made just for you. Enjoy!</p>
<style>#ghload {border: 1px solid; padding: 0.75em; background: #FED3; border-radius: 0.75em; display: block; margin-inline: auto; max-width: max-content; margin-block: 1.5em; box-shadow: 0.25em 0.33em 0.67em #0003; text-indent: 0;}</style>
<hr><p>Have something to say to all that? You can <a href="https://meyerweb.com/eric/thoughts/2024/02/05/bookmarklet-load-all-github-comments/#commentform">add a comment to the post</a>, or <a href="mailto:eric@meyerweb.com?subject=In%20reply%20to%20%22Bookmarklet:%20Load%20All%20GitHub%20Comments%22">email Eric directly</a>.</p>]]></content:encoded>
<wfw:commentRss>https://meyerweb.com/eric/thoughts/2024/02/05/bookmarklet-load-all-github-comments/feed/</wfw:commentRss>
<slash:comments>2</slash:comments>
</item>
<item>
<title>Once Upon a Browser</title>
<link>https://meyerweb.com/eric/thoughts/2024/01/02/once-upon-a-browser/</link>
<comments>https://meyerweb.com/eric/thoughts/2024/01/02/once-upon-a-browser/#comments</comments>
<dc:creator><![CDATA[Eric Meyer]]></dc:creator>
<pubDate>Tue, 02 Jan 2024 16:22:01 +0000</pubDate>
<category><![CDATA[CSS]]></category>
<category><![CDATA[Design]]></category>
<category><![CDATA[Projects]]></category>
<guid isPermaLink="false">https://meyerweb.com/eric/thoughts/?p=5475</guid>
<description><![CDATA[I am pleased to inform you that I’m back on my generative art BS again.]]></description>
<content:encoded><![CDATA[<p>Once upon a time, there was <a href="https://en.wikipedia.org/wiki/Once_Upon_a_Forest">a movie called <cite>Once Upon a Forest</cite></a>. I’ve never seen it. In fact, the only reason I know it exists is because a few years after it was released, <a href="https://joshuadavis.com/"> Joshua Davis</a> created a site called Once Upon a Forest, which I was doing searches to find again. The movie came up in my search results; the site, long dead, did not. Instead, I found its original URL on <a href="https://en.wikipedia.org/wiki/Joshua_Davis_(designer)">Joshua’s Wikipedia page</a>, and the Wayback Machine coughed up snapshots of it, <a href="https://web.archive.org/web/20110902144221/http://www.once-upon-a-forest.com/"> such as this one</a>. You can also find static shots of it on Joshua’s personal web site, if you scroll far enough.</p>
<p>That site has long stayed with me, not so much for its artistic expression (which is pleasant enough) as for how the pieces were produced. Joshua explained in a talk that he wrote code to create <a href="https://en.wikipedia.org/wiki/Generative_art">generative art</a>, where it took visual elements and arranged them randomly, then waited for him to either save the result or hit a key to try again. He created the elements that were used, and put constraints on how they might be arranged, but allowed randomness to determine the outcome.</p>
<p>That appealed to me deeply. I eventually came to realize that the appeal was rooted in my love of the web, where we create content elements and visual styles and scripted behavior, and then we send our work into a medium that definitely has constraints, but something very much like the random component of generative art: viewport size, device capabilities, browser, and personal preference settings can combine in essentially infinite ways. The user is the seed in the RNG of our work’s output.</p>
<p>Normally, we try very hard to minimize the variation our work can express. Even when crossing from one experiential stratum to another  —  that is to say, when changing media breakpoints  —  we try to keep things visually consistent, orderly, and understandable. That drive to be boring for the sake of user comprehension and convenience is often at war with our desire to be visually striking for the sake of expression and enticement.</p>
<p>There is a lot, and I mean a <strong>lot</strong>, of room for variability in web technologies. We work very hard to tame it, to deny it, to shun it. Too much, if you ask me.</p>
<p>About twelve and half years ago, I took a first stab at pushing back on that denial with <a href="https://meyerweb.com/eric/thoughts/2011/06/03/spinning-the-web/">a series posted to Flickr called “Spinning the Web”</a>, where I used CSS rotation transforms to take consistent, orderly, understandable web sites and shake them up hard. I enjoyed the process, and a number of people enjoyed the results.</p>
<figure>
<img decoding="async" src="https://meyerweb.com/once-upon-a-browser/2023-12/google.com-2023-11-25.jpg" class="border" alt="" />
<figcaption>google.com, late November 2023</figcaption>
</figure>
<p>In the past few months, I’ve come back to the concept for no truly clear reason and have been exploring new approaches and visual styles. The first collection launched a few days ago: <a href="https://meyerweb.com/once-upon-a-browser/2023-12/">Spinning the Web 2023</a>, a collection of 26 web sites remixed with a combination of CSS and JS.</p>
<p>I’m announcing them now in part because this month <a href="https://genuary.art/">has been dubbed “Genuary”</a>, a month for experimenting with generative art, with daily prompts to get people generating. I don’t know if I’ll be following any of the prompts, but we’ll see. And now I have a place to do it.</p>
<p>You see, back in 2011, I mentioned that my working title for the “Spinning the Web” series was “Once Upon a Browser”. That title has never left me, so I’ve decided to claim it and created <a href="https://once-upon-a-browser.com/">an umbrella site with that name</a>. At launch, it’s sporting a design that owes quite a bit to Once Upon a Forest  —  albeit with its own SVG-based generative background, one I plan to mess around with whenever the mood strikes. New works will go up there from time to time, and I plan to migrate the 2011 efforts there as well. For now, there are pointers to the Flickr albums for the old works.</p>
<p>I said this back in 2011, and I mean it just as much in 2023: I hope you enjoy these works even half as much as I enjoyed creating them.</p>
<hr><p>Have something to say to all that? You can <a href="https://meyerweb.com/eric/thoughts/2024/01/02/once-upon-a-browser/#commentform">add a comment to the post</a>, or <a href="mailto:eric@meyerweb.com?subject=In%20reply%20to%20%22Once%20Upon%20a%20Browser%22">email Eric directly</a>.</p>]]></content:encoded>
<wfw:commentRss>https://meyerweb.com/eric/thoughts/2024/01/02/once-upon-a-browser/feed/</wfw:commentRss>
<slash:comments>2</slash:comments>
</item>
<item>
<title>2023 in (Brief) Review</title>
<link>https://meyerweb.com/eric/thoughts/2023/12/31/2023-in-brief-review/</link>
<comments>https://meyerweb.com/eric/thoughts/2023/12/31/2023-in-brief-review/#comments</comments>
<dc:creator><![CDATA[Eric Meyer]]></dc:creator>
<pubDate>Mon, 01 Jan 2024 04:32:13 +0000</pubDate>
<category><![CDATA[Books]]></category>
<category><![CDATA[Carolyn]]></category>
<category><![CDATA[Parenting]]></category>
<guid isPermaLink="false">https://meyerweb.com/eric/thoughts/?p=5488</guid>
<description><![CDATA[That was the year that was… and it had three big turning points.]]></description>
<content:encoded><![CDATA[<p>I haven’t generally been one to survey years as they end, but I’m going to make an exception for 2023, because there were three pretty big milestones I’d like to mark.</p>
<figure>
<a href="https://meyerweb.com/eric/books/css-tdg/"><img decoding="async" src="https://meyerweb.com/eric/books/css-tdg/cover-sm.jpg" alt="" class="book cover" /></a>
</figure>
<p>The first is that toward the end of May, the fifth edition of <a href="https://meyerweb.com/eric/books/css-tdg/"><cite>CSS: The Definitive Guide</cite></a> was published. This edition weighs in at a mere 1,126 pages, and covers just about everything in CSS that was widely supported by the end of the 2022, and a bit from the first couple of months in 2023. It’s about 5% longer by page count than <a href="https://meyerweb.com/eric/books/css-tdg/ed-fourth/">the previous edition</a>, but it has maybe 20% more material. <a href="http://standardista.com/" rel="friend colleague met">Estelle</a> and I pulled that off by optimizing some of the older material, dropping some “intro to web” stuff that was still hanging about in the first chapter, and replacing all the appendices from the fourth edition with a single appendix that lists the URLs of useful CSS resources. As with the previous edition, the files used to produce the figures for the book are all available online as <a href="https://meyerweb.github.io/csstdg5figs/"> a website</a> and <a href="https://github.com/meyerweb/csstdg5figs">a repository</a>.</p>
<p>The second is that Kat and I went away for a week in the summer to celebrate our 25th wedding anniversary. As befits our inclinations, we went somewhere we’d never been but always wanted to visit, the <a href="https://www.wisdells.com/">Wisconsin Dells</a> and surrounding environs. We got to tour <a href="https://www.caveofthemounds.com/">The Cave of the Mounds</a> (<em>wow</em>), <a href="https://www.thehouseontherock.com/">The House on the Rock</a> (<em><strong>double</strong> wow</em>), <a href="https://www.worldofdrevermor.com/gallery/">The World of Doctor Evermore</a> (<em>wowee</em>), and the Dells themselves. We took a river tour, indulged in cheesy tourist traps, had some fantastic meals, and generally enjoyed our time together. I did a freefall loop-de-loop waterslide <em>twice</em>, so take <em> that</em>, <a href="https://en.wikipedia.org/wiki/Action_Park">Action Park</a>.</p>
<p>The third is that toward the end of the year, Kat and I became grandparents to the beautiful, healthy baby of our daughter Carolyn. A thing that people who know us personally know is that we love babies and kids, so it’s been a real treat to have a baby in our lives again. It’s also been, and will continue to be, a new and deeper phase of parenthood, as we help our child learn how to be a parent to her child. We eagerly look forward to seeing them both grow through the coming years.</p>
<p>So here’s to a year that contained some big turning points, and to the turning points of the coming year. May we all find fulfillment and joy wherever we can.</p>
<hr><p>Have something to say to all that? You can <a href="https://meyerweb.com/eric/thoughts/2023/12/31/2023-in-brief-review/#commentform">add a comment to the post</a>, or <a href="mailto:eric@meyerweb.com?subject=In%20reply%20to%20%222023%20in%20(Brief)%20Review%22">email Eric directly</a>.</p>]]></content:encoded>
<wfw:commentRss>https://meyerweb.com/eric/thoughts/2023/12/31/2023-in-brief-review/feed/</wfw:commentRss>
<slash:comments>1</slash:comments>
</item>
<item>
<title>Pixelating Live with SVG</title>
<link>https://meyerweb.com/eric/thoughts/2023/12/21/pixelating-live-with-svg/</link>
<comments>https://meyerweb.com/eric/thoughts/2023/12/21/pixelating-live-with-svg/#comments</comments>
<dc:creator><![CDATA[Eric Meyer]]></dc:creator>
<pubDate>Thu, 21 Dec 2023 15:35:28 +0000</pubDate>
<category><![CDATA[SVG]]></category>
<guid isPermaLink="false">https://meyerweb.com/eric/thoughts/?p=5455</guid>
<description><![CDATA[In which I ask for SVG filter assistance, because I can’t figure this out.]]></description>
<content:encoded><![CDATA[<p>For reasons I’m not going to get into here, I want be able to pixelate web pages, or even parts of web pages, entirely from the client side. I’m using <a href="https://violentmonkey.github.io/">ViolentMonkey</a> to inject scripts into pages, since it lets me easily open the ViolentMonkey browser-toolbar menu and toggle scripts on or off at will.</p>
<p>I’m aware I could take raster screenshots of pages and then manipulate them in an image editor. I don’t <em>want</em> to do that, though  —  I want to pixelate <em>live</em>. For reasons.</p>
<p>So far as I’m aware, my only option here is to apply SVG filters by way of CSS. The problem I’m running into is that I can’t figure out how to construct an SVG filter that will exactly:</p>
<ul>
<li>Divide the element into cells; for example, a grid of 4×4 cells</li>
<li>Find the average color of the pixels in each cell</li>
<li>Flood-fill each cell with the average color of its pixels</li>
</ul>
<p>As a way of understanding the intended result, see the following screenshot of Wikipedia’s home page, and then the corresponding pixelated version, which I generated using the Pixelate filter in <a href="https://flyingmeat.com/acorn/">Acorn</a>.</p>
<figure class="standalone">
<a href="https://meyerweb.com/eric/thoughts/wp-content/uploads/wikipedia-home.png"><img decoding="async" src="https://meyerweb.com/eric/thoughts/wp-content/uploads/wikipedia-home.png" alt="" class="border" /></a>
<a href="https://meyerweb.com/eric/thoughts/wp-content/uploads/wikipedia-home-pixelated.png"><img decoding="async" src="https://meyerweb.com/eric/thoughts/wp-content/uploads/wikipedia-home-pixelated.png" alt="" class="border" /></a>
<figcaption>Wikipedia in the raw, and blockified.</figcaption>
</figure>
<p>See how the text is rendered out? That’s key here.</p>
<p>I found a couple of SVG pixelators in <a href="https://stackoverflow.com/questions/37451189/can-one-pixelate-images-with-an-svg-filter">a StackOverflow post</a>, but what they both appear to do is sample pixels at regularly-spaced intervals, then dilate them. This works pretty okay for things like photographs, but it falls down hard when it comes to text, or even images of diagrams. Text is almost entirely vanished, as shown here.</p>
<figure class="standalone">
<a href="https://meyerweb.com/eric/thoughts/wp-content/uploads/wikipedia-home-svged.png"><img decoding="async" src="https://meyerweb.com/eric/thoughts/wp-content/uploads/wikipedia-home-svged.png" alt="" class="border" /></a>
<figcaption>The text was there a minute ago, I swear it.</figcaption>
</figure>
<p>I tried Gaussian blurring at the beginning of my filters in an attempt to overcome this, but that mostly washed the colors out, and didn’t make the text more obviously text, so it was a net loss. I messed around with dilation radii, and there was no joy there. I did find some interesting effects along the way, but none of them were what I was after.</p>
<p>I’ve been reading through various tutorials and MDN pages about SVG filters, and I’m unable to figure this out. Though I may be wrong, I feel like the color-averaging step is the sticking point here, since it seems like <a href="https://developer.mozilla.org/en-US/docs/Web/SVG/Element/feTile"><code><feTile></code></a> and <a href="https://developer.mozilla.org/en-US/docs/Web/SVG/Element/feFlood"><code><feFlood></code></a> should be able to handle the first and last steps. I’ve wondered if there’s a way to get a <a href="https://developer.mozilla.org/en-US/docs/Web/SVG/Element/feConvolveMatrix">convolve matrix</a> to do the color-averaging part, but I have no idea  —  I never learned matrix math, and later-life attempts to figure it out have only gotten me as far as grasping the most general of principles. I’ve also tried to work out if <a href="https://developer.mozilla.org/en-US/docs/Web/SVG/Element/feDisplacementMap">a displacement map</a> could be of help here, but so far as I can tell, no. But maybe I just don’t understand them well enough to tell?</p>
<p>It also occurred to me, as I was prepared to publish this, that maybe a solution would be to use some kind of operation (a matrix, maybe?) to downsize the image and then use another operation to upsize it to the original size. So to pixelfy a 1200×1200 image into 10×10 blocks, smoothly downsize it to 120×120 and then nearest-neighbor it back up to 1200×1200. That feels like it would make sense as a technique, but once again, even if it does make sense I can’t figure out how to do it. I searched for terms like <kbd>image scale transform matrix</kbd> but I either didn’t get good results, or didn’t understand them when I did. Probably the latter, if we’re being honest.</p>
<p>So, if you have any ideas for how to make this work, I’m all ears  —  either here in the comments, on your own site, or as forks of <a href="https://codepen.io/meyerweb/pen/mdoboMq">the Codepen I set up for exactly that purpose</a>. My thanks for any help!</p>
<hr><p>Have something to say to all that? You can <a href="https://meyerweb.com/eric/thoughts/2023/12/21/pixelating-live-with-svg/#commentform">add a comment to the post</a>, or <a href="mailto:eric@meyerweb.com?subject=In%20reply%20to%20%22Pixelating%20Live%20with%20SVG%22">email Eric directly</a>.</p>]]></content:encoded>
<wfw:commentRss>https://meyerweb.com/eric/thoughts/2023/12/21/pixelating-live-with-svg/feed/</wfw:commentRss>
<slash:comments>18</slash:comments>
</item>
<item>
<title>Three Decades of HTML</title>
<link>https://meyerweb.com/eric/thoughts/2023/12/06/three-decades-of-html/</link>
<comments>https://meyerweb.com/eric/thoughts/2023/12/06/three-decades-of-html/#comments</comments>
<dc:creator><![CDATA[Eric Meyer]]></dc:creator>
<pubDate>Thu, 07 Dec 2023 03:40:15 +0000</pubDate>
<category><![CDATA[(X)HTML]]></category>
<category><![CDATA[History]]></category>
<category><![CDATA[Web]]></category>
<guid isPermaLink="false">https://meyerweb.com/eric/thoughts/?p=5449</guid>
<description><![CDATA[A few days ago was the 30th anniversary of the first time I wrote an HTML document.]]></description>
<content:encoded><![CDATA[<p>A few days ago was the 30th anniversary of the first time I wrote an HTML document. Back in 1993, I took a <a href="https://en.wikipedia.org/wiki/Usenet">Usenet</a> posting of the “Incomplete Mystery Science Theater 3000 Episode Guide” and marked it up. You can see <a href="https://meyerweb.com/eric/cwru/mst3keg/mst3kf.html">the archived copy</a> here on meyerweb. At some point, the markup got updated for reasons I don’t remember, but I can guarantee you the original had uppercase tag names and I didn’t close any paragraphs. That’s because I was using <code><P></code> as a shorthand for <code><BR><BR></code>, which was the style at the time.</p>
<p>Its last-updated date of December 3, 1993, is also the date I created it. I was on lobby duty with the <a href="https://films.cwru.edu/">CWRU Film Society</a>, and had lugged a laptop (I think it was an Apple PowerBook of some variety, something like <a href="https://en.wikipedia.org/wiki/PowerBook_180">a 180</a>, borrowed from my workplace) and a printout of <a href="https://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt"> the HTML specification</a> (or maybe it was “<a href="http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html">Tags in HTML</a>”?) along with me.</p>
<p>I spent most of that evening in the lobby of <a href="https://commons.wikimedia.org/wiki/File:Strosacker_Auditorium,_Case_Western_Reserve_University,_Cleveland,_OH_(28593864547).jpg">Strosacker Auditorium</a>, typing tags and doing find-and-replace operations in Microsoft Word, and then saving as text to a file that ended in <code>.html</code>, which was the style at the time. By the end of the night, I had more or less what you see in the archived copy.</p>
<p>The only visual change between then and now is that a year or two later, when I put the file up in my home directory, I added the toolbars at the top and bottom of the page  —  toolbars I’d designed and made a layout standard as <a href="https://en.wikipedia.org/wiki/Case_Western_Reserve_University">CWRU</a>’s webmaster. Which itself only happened because I learned HTML.</p>
<p>A couple of years ago, I was fortunate enough to be able to relate some of this story to <a href="https://en.wikipedia.org/wiki/Joel_Hodgson">Joel Hodgson</a> himself. The story delighted him, which delighted me, because delighting someone who has been a longtime hero really is one of life’s great joys. And the fact that I got to have that conversation, to feel that joy, is inextricably rooted in my sitting in that lobby with that laptop and that printout and that Usenet post, adding tags and saving as text and hitting reload in <a href="https://en.wikipedia.org/wiki/Mosaic_(web_browser)">Mosaic</a> to instantly see the web page take shape, thirty years ago this week.</p>
<hr><p>Have something to say to all that? You can <a href="https://meyerweb.com/eric/thoughts/2023/12/06/three-decades-of-html/#commentform">add a comment to the post</a>, or <a href="mailto:eric@meyerweb.com?subject=In%20reply%20to%20%22Three%20Decades%20of%20HTML%22">email Eric directly</a>.</p>]]></content:encoded>
<wfw:commentRss>https://meyerweb.com/eric/thoughts/2023/12/06/three-decades-of-html/feed/</wfw:commentRss>
<slash:comments>4</slash:comments>
</item>
</channel>
</rss>
If you would like to create a banner that links to this page (i.e. this validation result), do the following:
Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src
attribute if necessary):
If you would like to create a text link instead, here is the URL you can use:
http://www.feedvalidator.org/check.cgi?url=http%3A//meyerweb.com/eric/thoughts/rss2/summary