Re: [parser-api] Polyfilling CSS

On Tue, Apr 7, 2015 at 8:41 PM, Brian Kardell <bkardell@gmail.com> wrote:

> On Tue, Apr 7, 2015 at 8:26 PM, Rick Byers <rbyers@chromium.org> wrote:
> > On Tue, Apr 7, 2015 at 8:16 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
> >>
> >> On Thu, Apr 2, 2015 at 11:10 AM, Paul Irish <paul.irish@gmail.com>
> wrote:
> >> > I want to keep all my style information in the stylesheet, even things
> >> > not
> >> > consistently supported across all browsers. I want to drop in a JS
> >> > polyfill
> >> > for those ones.
> >>
> >> This is the troublesome bit.  We want to preserve CSS's ability to
> >> innovate in names, without worrying about name collision with custom
> >> stuff from the community.  HTML did this by requiring custom elements
> >> to have a dash in them, CSS does this by requiring custom things to
> >> start with two dashes.  In HTML you can technically use elements with
> >> custom names without dashes, but that's a legacy issue only - they
> >> aren't real Custom Elements and can't be used with that API, they're
> >> just weird <span>s with strange names.  CSS made the right decision
> >> from the beginning and dropped the unknown stuff entirely.
> >
> >
> > Can someone explain why CSS needs a stronger guarantee here than
> JavaScript?
> > I.e. why don't we make the same argument to say that all 'custom'
> variables
> > in JavaScript must have a prefix (or namespace) because we need the
> ability
> > to 'innovate' in names on the global object?
>
> Actually, I really think we should do that too - by example if
> necessary.  For example, let's take something like window.fetch -
> we're prollyfilling that now, not POLYfilling, prollyfilling - there
> are JS implementations way before native stuff and to think on day 1
> that it is compatible with the final product is, well, not very
> realistic.  If we prollyfilled window._fetch, you could at least
> reason about it semi-sanely.  If you buy into the particular
> prollyfilled contract, you keep using it.  When you upgrade your
> contract, you risk breaking, just like a libarary - it's known.  When
> eventually the prollyfill has parity with a spec/implementations you
> can just alias and call it a polyfill.  Lots of problems solved, but
> that's another list.  The benefit of it is no one is stopped in
> committee after lots of bikeshedding and has to pick some suboptimal
> name because to do otherwise could break websites.
>
> All that said, this is really how prefixes should have probably worked
> in CSS in the first place... You can follow a similar format above and
> in the worst case at the end you have a duplicate CSS entry with a
> single (not one per-vendor) polyfill fallback.  It's a hard balance to
> strike, but it works on many levels.
>

Seems reasonable, thanks for the explanation.

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.

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-)?


>
> --
> Brian Kardell :: @briankardell :: hitchjs.com
>