Re: Forward compatibility and custom things

On Mar 16, 2014 11:11 AM, "Karl Dubost" <karl@la-grange.net> wrote:
>
> Brian,
>
> Le 16 mars 2014 à 23:39, Brian Kardell <bkardell@gmail.com> a écrit :
> > Historically, CSS has been kind of hostile to the idea of author
defined anything- but now we're reconsidering.  I think that there is much
sense in advising on a similar scheme that works everywhere in CSS for
author provided custom things.
>
> Could you provide an example, use case on how you think it would work
taking into account interoperability issues (Web Compatibility) for small
players.
>
I don't understand the question.  If you mean author specified things in
general, I'll leave that to the proposals.  If you mean the way they are
written I'm doubly confused.  I'm not trying to be evasive, I just don't
understand what you mean or maybe vice versa.  I'm not suggesting features
here - there _are_ suggested features and more coming.


> >  Secondarily, it would be even better in my opinion if one could
logically draw sense of the relationship to existing vendor provided custom
things.
>
> Could you clarify? I don't understand this part.
>

Sure,  you might be reading too much into that second part -- in fact,
there are already two examples in the original thread which are attempting
to do this... I'm just suggesting that there are already a few options
which are explainable or already used in other parts of the system, we
probably shouldn't invent another unless we have to.  Summarizing the ones
I see:

One (contains a dash ) attempts to align learning from Custom Elements and
apply here (http://w3c.github.io/webcomponents/spec/custom/#concepts).  So
when we document or teach it, you can say "just like a custom element in
HTML contains a dash anywhere after the first character, a custom thing in
CSS contains an underscore anywhere after the first character.  That's not
terrible, but it's worth noting that it has to be underscore here because
CSS makes prolific use of dashes, so it really "looks" different.  If
you're not clear on this one, it would mean that we wind up saying "if we
ever have them, examples would look like this":

An author defined pseudo element
::x_thinger

An author defined property
x_too:  blue;

An author defined pseudo-class
:x_lessthan(value, 100)


Another would attempt to use the vendor keywords(
http://www.w3.org/TR/CSS2/syndata.html#vendor-keywords) reservation to
explain by simply saying that given the existing

'-' + vendor identifier + '-' + meaningful name

An author defined property is one without a vendor, so that space
collapses, thus you can identify the same examples as before applying this
rule:

An author defined pseudo element
::--thinger

An author defined property
--too:  blue;

An author defined pseudo-class
:--lessthan(value, 100)

This may have some problems with the parse, so I don't know if that's
really valid, but I like how simple it is to explain personally.


Finally, we could just reserve a name like we did with var-* (I'm not
literally suggesting that it would be var, but why not, those aren't
actually variables either).  Using that sort of thing you'd wind up with:

An author defined pseudo element
::var-thinger

An author defined property
var-too:  blue;

An author defined pseudo-class
:var-lessthan(value, 100)




>
> --
> Karl Dubost 🐄
> http://www.la-grange.net/karl/
>