On Thu, May 7, 2015 at 10:42 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Thu, May 7, 2015 at 11:23 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote:
>> Well, beyond the existing conflicts of <style>, <script>, and <a>.
>> (<font> too, but that's dropped from SVG2, so who cares.)
>
> <textArea> is out too?
<textArea> was never in - it was an SVG Tiny element, and thus never
appeared in any web-compatible version of SVG.
> With respect to case-insensitive matching, I don't really understand
> why we simultaneously want to make these rather trivial changes to SVG
> while at the same time move to constructors for creating elements,
> which is even stricter than createElementNS() (literal has to be
> correctly spelled or you get an exception). If we want to move to a
> world where people write
>
> new SVGRectElement
>
> why would we even bother making
>
> document.createElement("RECT")
>
> work?
It's not about that, it's about making, say, "lineargradient {...}"
work, because you can case selectors any which way for HTML, and it's
confusing that you can't for SVG.
(And I'm still not convinced on constructors, anyway - they're so
verbose! And we would to have to fix so many of them!)
> Same for CSS, the majority of CSS already uses type selectors where
> the case matches up with the HTML. Is complicating it really worth it?
> We should bring the languages closer, but we shouldn't put the
> mistakes we made with HTML into SVG.
I don't think ascii case-insensitivity is a mistake here.
~TJ
