Re: [parser-api] Polyfilling CSS

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