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

Re: [parser-api] Polyfilling CSS

From: Brian Kardell <bkardell@gmail.com>
Date: Tue, 7 Apr 2015 20:41:54 -0400
Message-ID: <CADC=+jd0cZ7vpDp9y4_ewZM4tNXb0iS18_1a+nj6rPfORVxsnQ@mail.gmail.com>
To: Rick Byers <rbyers@chromium.org>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Paul Irish <paul.irish@gmail.com>, "public-houdini@w3.org" <public-houdini@w3.org>
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.

Brian Kardell :: @briankardell :: hitchjs.com
Received on Wednesday, 8 April 2015 00:42:21 UTC

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