I think it’s better for sharing this way, because it decouples the question of whether the user of the button wants to override the browser’s accessibiltiy design from the button itself.
Have you tried the :focus-within psuedo-class? There’s a tiny polyfill for IE & Edge and all the other major browsers already support it.
How about:
button [ Html.Attributes.attribute "onclick" "event.target.blur();" ] []
Can’t believe that such thing exists. I’ve never heard about it 
Thank you for your suggestions – I’m happy that I can avoid components in these cases. It’s always better to use plain old functions whenever possible! But I still can imagine a lot of cases where stateful components can’t be avoided:
Html.Styled.elm-mdl where even a simple button needs some state for the animation.Depending on how many such components you have and how often you need to use them in your project, the boilerplate you need to write might or might not be acceptable. And when it’s not acceptable, you’ll need a more powerful solution.
@norpan This might also be an option. Thank you.
@norpan I think function calls like that will be sanitized in the future, right? At least I remember hearing that somewhere…
Yes, this is already disallowed in the master branch of elm-lang/virtual-dom.
There are some ways around that check, I think it was just for expedience, I’m thinking it will be more fleshed out for sanitizing before the full release. https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
Seems you derived a pretty similar solution to what I did a year ago Anyway there was also quite some flame wars at that time around this.
Anyway, the truth is that discussion is one of the harder ones. I understand the need for this but I have myself experience for working with 50k+ LOC elm single page code base. On the other hand, I even saw some newcomers to our team trying to abuse those patterns to make everything a stateful module (even though actually it’s all just function that manipulates part of a global state). The trouble though is that those things are hard to describe within text short enough one is willing to read within README or discussion. So I guess we’re doomed to argue about certain things over and over despite there is a good intention on both sides.
Anyway more to the actual topic. The experience forced me to remove view part of the type definition. You really want to use views as a regular function and pass some arguments from one view to another. Otherwise, 30% of your app code will be just for synchronization of state shared across components.