Hi Vadim! Nice to meet another SVG fan! :D
I totally agree with you, sorry if I didn’t make it that clear in the article, but yes, to be honest, I usually don’t use the SVG namespace in HTML and never had a problem with that. But I did have problems when working with them on CSS (as the example) or with the xlink:href
not so long ago.
My point was to make anyone aware of that, just in case they are dealing with something similar.
Thanks for mentioning this!
]]>That’s true! It’s a good point.
The only one I’m including is that mention about flexbox and position absolute behavior but is an idea that could be extended in a separate article.
I believe a nice disclaimer with a checklist or article to first check visibility, display, opacity, sizing could help :)
Thanks for the feedback!
]]>There’s a simple rule: SVG is XML, requiring a namespace on the root element to be rendered (every browser is consistent with that). Even if it’s inlined in CSS as data:uri. But when it’s inlined in HTML, there’s no need for the namespace (especially for the <html>
element), just like you don’t need type=text/javascript
for your <script>
. Every HTML5-compatible browser parser agrees with that behavior. And every browser has been HTML5 compatible for at least ten years, but probably more.
I don’t think it makes a lot of sense to add namespaces for legacy browsers today. I think among all the parts of the typical modern website, SVG without a namespace would fail the last :)
]]>Essentially all of the things that can ruin your day using <img>
or <div>
can also apply to your SVGs. I have spent a non-zero amount of time trying to debug SVGs that were hidden/clipped due to markup/styling on the page itself. Not the best use of time so always worth double checking visibility
, display
etc. and making sure devtools shows the <svg>
is actually displaying where and how you expect.