W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2015

Re: [whatwg] Case-sensitivity of CSS type selectors in HTML

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 7 May 2015 14:23:52 -0700
Message-ID: <CAAWBYDAfft-Bw1yKeMajYABvU=ZuRK=QaaOpTDXkFzyGw1L-PA@mail.gmail.com>
To: Elliott Sprehn <esprehn@chromium.org>
Cc: WHATWG <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>, Rune Lillesveen <rune@opera.com>
On Thu, May 7, 2015 at 2:11 PM, Elliott Sprehn <esprehn@chromium.org> wrote:
> On Thu, May 7, 2015 at 2:09 PM, Boris Zbarsky <bzbarsky@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

Received on Thursday, 7 May 2015 21:24:37 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:31 UTC