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

Re: [parser-api] Polyfilling CSS

From: Rick Byers <rbyers@chromium.org>
Date: Tue, 7 Apr 2015 20:26:43 -0400
Message-ID: <CAFUtAY__x4Q61KVOFOKNN9mge94KCbHm4CrR5oaNq_tyB1tSQg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Paul Irish <paul.irish@gmail.com>, "public-houdini@w3.org" <public-houdini@w3.org>
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?

I.e. why can't custom CSS properties just shadow built-in ones and
developers can cope with name conflicts exactly as they have been
(seemingly without total disaster) in JS for ages?

> I need a hook for unrecognized items like rulesets, @at-rules and
> selectors.
> <http://dev.w3.org/csswg/css-extensions/>, when I finish writing it,
> will give hooks for custom versions of all of these things.  You won't
> be able to directly intercept stuff that's valid in one browser but
> unknown in another, but you will be able to create a custom ~whatever~
> that can delegate to the built-in version when possible, and do
> something custom in older browsers.
> > For rulesets, I want a mechanism to address matching elements.
> Could you expand on this?  Do you mean like, a way to tell what
> elements will match a given selector, and get informed when new
> elements match it, or old elements stop matching it?
> ~TJ
Received on Wednesday, 8 April 2015 00:27:31 UTC

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