This repository was archived by the owner on Oct 1, 2019. It is now read-only.
html5 semantic tags + inline-svg = weird bug in old ie #66
Closed
Description
The following
<header><svg><path /></svg></header>results in the header tag not closing in ie7 & 8 (even with the inclusion of html5shiv), whereas the following does not
<header><svg><path></path></svg></header>So should self-closing tags within svgs (and, by extension, self-closing tags outside of the core html specs) be disallowed in favour of closing them explicitly? On the surface it seems like an edge case, but as we're taking a mobile first approach inline-svgs could become quite common and would tend to break layouts in ie without this stipulation
Metadata
Metadata
Assignees
Labels
No labels
Activity
triblondon commentedon Dec 18, 2013
Probably. Do we need an SVG coding standard? @richard-still-ft, do we have one anywhere in the FT at the moment?
triblondon commentedon Jan 10, 2014
Nuding @richard-still-ft.
kavanagh commentedon Jan 10, 2014
No one make's SVGs by hand. The tools that create SVGs use self closing tags. How annoying.
triblondon commentedon Jan 10, 2014
What do we mean by 'old' here?
kavanagh commentedon Jan 10, 2014
http://caniuse.com/#feat=svg-html5 - the stuff in red.
wheresrhys commentedon Jan 10, 2014
Thinking about this, it may be a shortcoming of html5shiv. If html5shiv also created an element for each svg tag my guess is the bug would be fixed. I'll try it out sometime
triblondon commentedon Jan 10, 2014
OK. This is an issue in IE8, since SVG would be part of supporting visual style and would need to work even in CTM-failing browsers. Worth digging a bit further.
fixed non-closing svgs in ie7 & 8 Financial-Times/ft-origami#66
wheresrhys commentedon Jan 28, 2014
I've now tested out #66 (comment) and my hunch was right; the bug can be fixed by adding
svg pathto html5shiv's list of elements.Currently html5shiv (which Modernizr consumes) allows redefining the list of elements, but doesn't allow just adding to it, so I created a pull request to achieve this aFarkas/html5shiv#142.
Whether we want to use this approach though is debatable as it's quite an unwieldy dependency to express: 'This module requires html5shiv or modernizr but with a, b, c additional tags added to the list of elements that are shived' - yuk!
triblondon commentedon Feb 10, 2014
Can't we just make a build script where needed to expand self-closing paths into opening and closing tags?
triblondon commentedon Feb 18, 2014
@wheresrhys nudge.
wheresrhys commentedon Feb 18, 2014
A build script where? In build service/products, in which case its an extra overhead in adopting origami components (and an unpredictable one - update to a module version that starts using inline svg and suddenly your product's build needs a new step to process svgs).
Maybe the spec should say 'svgs must either not be inline or not use self-closing tags' I only used inline for ft-header as the ft logo is probably the thing that needs to load quickest anywhere, but for most other use cases an
<img>or background image might do (although we then bring in the perennial problem of paths forimg#src).Longer term, have you seen the new bounty feature in github? Offering a bounty to have html5shiv updated to a better api (aFarkas/html5shiv#142), and pushing for modernizr to adopt something like 'if modernizr is testing for inlinesvg then also shiv all the svg tags' could enable us to stop worrying about this entirely.
6 remaining items