On Thu, May 7, 2015 at 2:11 PM, Elliott Sprehn <espr...@chromium.org> wrote: > On Thu, May 7, 2015 at 2:09 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: >> On 5/7/15 5:07 PM, Tab Atkins Jr. wrote: >>> I believe the SVGWG is fine with a parsing-based approach, exactly >>> like what HTML does. An SVG element created with mixed casing, or >>> imported from an XML document, might not match a lowercase tagname >>> selector, but SVG written in HTML will. >> >> Hmm. The main problem here is for scripts that create SVG elements in an >> HTML document, since those have to use createElementNS and pass the >> mixed-case names (e.g. for foreignObject). > > One idea could be to make createElement() return SVG elements for svg tag > names embedded in HTML. > > Neither spec is ever going to have a conflicting tag name.
Well, beyond the existing conflicts of <style>, <script>, and <a>. (<font> too, but that's dropped from SVG2, so who cares.) But the SVGWG already resolved to allow HTML elements inside of SVG, so they don't have to, say, add an <svg:video> element. (I'm on the hook to define the SVG layout model in terms of the CSS box model, which is trivial, but I haven't had the time to do it yet.) But yeah, the SVGWG resolved to never add new conflicts, and I assume HTML is similarly okay with not adding tagnames that SVG has already claimed. ~TJ
