Printing music with CSS grid
Laying out sheet music with CSS grid—sounds extreme until you see it abstracted into a web component.
We need fluid and responsive music rendering for the web!
Laying out sheet music with CSS grid—sounds extreme until you see it abstracted into a web component.
We need fluid and responsive music rendering for the web!
Those HTML web components I made for date inputs are very simple. All they do is slightly extend the behaviour of the existing input
elements.
This would be the ideal use-case for the is
attribute:
<input is="input-date-future" type="date">
Alas, Apple have gone on record to say that they will never ship support for customized built-in elements.
So instead we have to make HTML web components by wrapping existing elements in new custom elements:
<input-date-future>
<input type="date">
<input-date-future>
The end result is the same. Mostly.
Because there’s now an additional element in the DOM, there could be unexpected styling implications. Like, suppose the original element was direct child of a flex or grid container. Now that will no longer be true.
So something I’ve started doing with HTML web components like these is adding something like this inside the connectedCallback
method:
connectedCallback() {
this.style.display = 'contents';
…
}
This tells the browser that, as far as styling is concerned, there’s nothing to see here. Move along.
Or you could (and probably should) do it in your stylesheet instead:
input-date-future {
display: contents;
}
Just to be clear, you should only use display: contents
if your HTML web component is augmenting what’s within it. If you add any behaviours or styling to the custom element itself, then don’t add this style declaration.
It’s a bit of a hack to work around the lack of universal support for the is
attribute, but it’ll do.
This is a great thought exercise in progressive enhancement …that Scott then turns into a real exercise!
I love it when I come across some bit of CSS I’ve never heard of before.
Take this article on the text-emphasis
property.
“The what property?”, I hear you ask. That was my reaction too. But look, it’s totally a thing.
Or take this article by David Bushell called CSS Button Styles You Might Not Know.
Sure enough, halfway through the article David starts talking about styling the button in an input type="file”
using the ::file-selector-button
pseudo-element:
All modern browsers support it. I had no idea myself until recently.
Then I remembered that I’ve got a file upload input in the form I use for posting my notes here on adactio.com (in case I want to add a photo). I immediately opened up my style sheet, eager to use this new-to-me bit of CSS.
I found the bit where I style buttons and this is the selector I saw:
button,
input[type="submit"],
::file-selector-button
Huh. I guess I did know about that pseudo-element after all. Clearly the knowledge exited my brain shortly afterwards.
There’s that tautological cryptic saying, “You don’t know what you don’t know.” But I don’t even know what I do know!
Adam makes a very good point here: the term “vertical rhythm” is quite chauvanistic, unconciously defaulting to top-to-bottom writing modes; the term “logical rhythm” is more universal (and scalable).
Heydon does a very good job of explaining why throwing away the power of selectors makes no sense.
Utility-first detractors complain a lot about how verbose this is and, consequently, how ugly. And it is indeed. But you’d forgive it that if it actually solved a problem, which it doesn’t. It is unequivocally an inferior way of making things which are alike look alike, as you should. It is and can only be useful for reproducing inconsistent design, wherein all those repeated values would instead differ.
He’s also right on the nose in explaining why something as awful at Tailwind could get so popular:
But CSS isn’t new, it’s only good. And in this backwards, bullshit-optimized economy of garbage and nonsense, good isn’t bad enough.
I remember Jon telling me this lovely story when we first met in person. I love the idea that we had already met in a style sheet.
I also love the idea of hosting your own little internet archive—that Bill Oddie site still looks pretty great to me!
It’s a lot like an embarrassing family photo, but I’m owning it!
With classes, we can send CSS static values but with custom properties we can send dynamic ones, which is a major shift in the way we can style state. This is something that has been true for some time—and is extremely well supported—but sometimes it takes solving a small real-world problem to make you appreciate the value of it.
I think we still haven’t come to fully appreciate the superpower of custom properties: dynamic values that are shared between CSS and JavaScript.
This looks like a handy collection of HTML web components for common interface patterns.
drab does not use the shadow DOM, so you can style content within these elements as usual with CSS.
I love how straightforward these bits of CSS are—time to rip out some of those old complicated hacks and workarounds!
The main reason I’m so hot on Light DOM is that I find the styling story of Web Components using Shadow DOM annoying.
This is an excellent step-by-step walkthrough by Tess of creating a web component, with real thought given to what should be in the HTML (which will act as a fallback) and what’s better generated in the Shadow DOM (like buttons for interactivity).
This perfectly mirrors something Chris was saying in a recent episode of the Shop Talk Show:
I think of the image comparison one. That’s a classic example in Web component. What’s inside is just two IMG tags. That’s it. When it fails, you don’t want a weird div with little arrows on it being rendered on the page. That’s not doing anything because it has failed to load the JavaScript.
You just take some normal HTML markup, wrap it with a custom element, and then write some JS to add capabilities which you can then style with regular CSS! Everything’s of the Light Side of the Web. No need to pierce the Vale of Shadows or whatever.
I think Eric’s approach here should be the default for most web components: you probably don’t need to mess around with the shadow DOM, and you should definitely be wrapping your web component around existing HTML instead of witing opening and closing tags with nothing in between.
Augment, don’t replace.
A great reminder of just how much you can do with modern markup and styles when it comes to form validation. The :user-invalid
and :user-valid
pseudo-classes are particularly handy!
While I’m talking about the SVGs on The Session, I thought I’d share something else related to the rendering of the sheet music.
Like I said, I use the brilliant abcjs JavaScript library. It converts ABC notation into sheet music on the fly, which still blows my mind.
If you view source on the rendered SVG, you’ll see that the path
and rect
elements have been hard-coded with a colour value of #000000
. That makes sense. You’d want to display sheet music on a light background, probably white. So it seems like a safe assumption.
Ah, but when it comes to front-end development, assumptions are like little hidden bombs just waiting to go off!
I got an email the other day:
Hi Jeremy,
I have vision problems, so I need to use high-contrast mode (using Windows 11). In high-contrast mode, the sheet-music view is just black!
Doh! All my CSS adapts just fine to high-contrast mode, but those hardcoded hex values in the SVG aren’t going to be affected by high-contrtast mode.
Stepping back, the underlying problem was that I didn’t have a full separation of concerns. Most of my styling information was in my CSS, but not all. Those hex values in the SVG should really be encoded in my style sheet.
I couldn’t remove the hardcoded hex values—not without messing around with JavaScript beyond my comprehension—so I made the fix in CSS:
[fill="#000000"] {
fill: currentColor;
}
[stroke="#000000"] {
stroke: currentColor;
}
That seemed to do the trick. I wrote back to the person who had emailed me, and they were pleased as punch:
Well done, Thanks! The staff, dots, etc. all appear as white on a black background. When I click “Print”, it looks like it still comes out black on a white background, as expected.
I’m very grateful that they brought the issue to my attention. If they hadn’t, that assumption would still be lying in wait, preparing to ambush someone else.
Ahmad runs through some of the scenarios where text-wrap: balance
could be handy.
Even though it’s not well-supported yet in browsers, there’s no reason not to start adding it to sites now; it’s classic progressive enhancement.
How do we write, design, and code a link that works for everyone on every device? Let’s dive into the world of creating the perfect link, without making a pig’s breakfast of it.
Check out the demo that Rich has put together to go with Amelia’s proposed syntax.
This is a terrific walkthrough from Andy showing how smart fundamentals in your CSS can give you a beautiful readable document without much work.