Re: [parser-api] Polyfilling CSS

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