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

Reply via email to