I'll sometimes add a bit of CSS to do text styling,
like so. This is something that I have fairly mixed feelings about, and for that reason, I have never mentioned it on the lists. I still consider this an area for exploration that is in need of more formal design decisions.
My reasoning at the moment is that HTML (Hyper-Text Markup Language) is somewhat acceptable as a text markup language (it's original reason for existence, and the motivation for its design). It became out of control terrible when people just kept adding and adding features one at a time to solve all sorts of unrelated problems in a seemingly ad-hoc fashion with little to no foresight or concern for abstractions (sorry to any spec-writers who may read this, I do think this process has gotten better in the last couple years).
Sometimes those problems (vertical centering) really could not fit in a language designed for text markup. Microsoft Word does not have vertical centering for the same reason, it's not really a meaningful operation on text itself. You need to have a meaningful notion of a container, and at that point you probably would design things totally different (cough, Elm, cough). This is also why setting the color of a div sets the text color, not the color of the div! Text color came first because it is a text markup language. Fun fact, the original version of HTML did not even have an <img> tag because it's kind of nonsense to put images in text. This is also why inline-text images were (are?) the default. It was a very controversial feature at the time and ended up getting added by Netscape as a non-spec feature that just caught on. I suspect there are many other shitty parts of CSS that can be explained by this tension between being a language for text and a language for layout.
So overall, I use some CSS on text and I don't feel bad about it. It was designed for this, and it is alright. I have no temptation to do other stuff with it because it's always much easier to work with layout in Elm.
As it is, there are definite limitations on this, so I would rely on this as lightly as possible. One example is asynchronously loading fonts. Since Elm always knows the dimensions of elements, having a font load and change the size of something can mess things up. I think this means that the fonts need to be known before rendering can commence, which is the default when fonts are loaded from the user's system. I think the solution here may be to register this font information with the code or runtime or something. This is one of the design uncertainties that has led me to not talk about this feature.
And before people go wild talking about inconsistency, sell-out, etc. etc. remember that I am doing my best and am happy to have a civil discussion to try to find a better, more consistent way. There is nothing more frustrating than being talked down to on a topic that I understand well, and one that already bothers me. I have some thoughts in the direction of markdown interpolation and embedding Elm in HTML that may actually unify this stuff in a reasonable way.