W3C home > Mailing lists > Public > public-houdini@w3.org > April 2015

Re: [parser-api] Polyfilling CSS

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 8 Apr 2015 15:48:13 -0700
Message-ID: <CAAWBYDDr2Sfx4sU+taP4Pi=2CYJ_41bQfTWrtTs-P7hAH+pf5Q@mail.gmail.com>
To: Rick Byers <rbyers@chromium.org>
Cc: Brian Kardell <bkardell@gmail.com>, Paul Irish <paul.irish@gmail.com>, "public-houdini@w3.org" <public-houdini@w3.org>
On Wed, Apr 8, 2015 at 3:22 PM, Rick Byers <rbyers@chromium.org> wrote:
> I wonder if we're really missing language namespacing features here?  In
> many other modern languages the (compiled) code contains the fully qualified
> names (often including version numbers).  When developers can type short
> names they mostly don't mind that their true API names are long.

Yes, we are missing language namespacing features.  None of the web
languages did namespacing remotely correctly from the beginning, which
is when it's generally needed.  JS is growing a module system, which
allows us to do better here, but CSS and HTML haven't done anything of
the sort, and it's harder in general to graft this kind of thing onto
them.

> Anyway that can always come later.  What bothers me here is that the browser
> (and/or the W3C) is in this uniquely privileged position of allocating the
> only "nice" names (and framework / app developers will probably always fight
> with us over the namespace).  If we're serious about avoiding name
> collisions while also empowering web developers, perhaps all new W3C-defined
> APIs should start with a prefix (-w3c-)?

Forcing a five-character tax on all languaged-defined things, versus a
two-character tax on all custom things, seems perverse. ^_^  Plus the
badness of this getting applied only to "new" things.

~TJ
Received on Wednesday, 8 April 2015 22:49:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:53:23 UTC