No, and that's one of the things that's really nice, at least for our team: we really want our web designers to own the HTML/CSS from start to finish. If you use something like React (i.e. where there is code that emits chunks of HTML elements), you sometimes either force the designer to learn React or the designer no longer owns the markup once it gets handed off to a dev. For us at least, that was a maintenance nightmare and hindered our ability to add new features or freshen up the layout.

Svelte combines a component's HTML, Javascript, and styles into a .svelte file, so it all lives in one place, but each of those 3 things lives in their own section. The HTML looks very close to what it looks like when it was originally created by the designer, with a few key changes such as markers conditional blocks or loops and additional element attributes to set up data and event bindings. Explaining these to a web designer takes about 10 minutes and they are fine with it, especially if they've ever seen a templating language before.

This setup also leads to one of two really good workflows between dev and design; we end up using both of them and choose one based on the specific scenario. In the first, the designer goes from visual design all the way to valid HTML/CSS, and then hands it off to a dev to "wire it up" (make it functional). In the second, a dev will rough in the HTML and make it functional but hideous looking, and then hand it off to the designer to de-uglify it. In both cases, the dev owns the behavior and the designer owns styling/layout/etc. from then on, and it's rare for there to be any conflicts. YMMV of course, but it's been fantastic for us. :)

That post describes "something followed by a colon is a label in certain contexts", so you need to extrapolate a tiny bit to realize that "$:" is a label, even if the post doesn't explicitly enumerate all possible labels.