[css-pseudo-4] Mark unimplemented CSSPseudoElement features at-risk

[fantasai]

Gecko is implementing parts of the CSSPseudoElement interface to integrate with Web Animations, so those parts should stay. If there aren't strong use cases for other parts, we should either drop them (if we're not sure of the design) or mark them at-risk (if we're sure they're correctly designed, but not sure if they're needed).

[fantasai]

If nobody implements or plans to implement or is seriously advocating for the CSSStyleDeclaration style attribute, then I'd like to remove it. Otherwise I think we've stripped this down to the minimum at this point... @birtles any comment?

[fantasai]

@heycam writes...

I wonder if we should leave ::selection off this list. It feels like a pretty different thing from ::before, ::after, ::first-letter, and ::first-line, all of which basically have a box corresponding to them (at least for Gecko). Or would it be allowed to return a CSSPseudoElement for ::selection but not to support e.g. Web Animations targeting it?

So another question is what we want to support wrt ::selection here. See also #3607 and #3603 which might inform this decision.

[birtles]

We don't have any specific plans at this point to implement any more than:

[Exposed=Window]
interface CSSPseudoElement {
    readonly attribute CSSOMString type;
    readonly attribute Element element;
};

Furthermore, for type we only support ::before and ::after. We don't implement Element.pseudo() either or have any specific plans to do so but it might be worth doing just to clarify the identity issues @heycam raised since they probably affect what we currently return.

(In our implementation the only way to get a CSSPseudoElement is to create a CSS animation / transition on a pseudo, then call getAnimations() and fetch the effect.target of the returned CSSAnimation or CSSTransition.)

[css-meeting-bot]

The CSS Working Group just discussed Mark unimplemented CSSPseudoElement features at-risk, and agreed to the following:

• RESOLVED: Drop style from this level, restrict API to ::before and ::after, add a note to why the other things are not yet supported

The full IRC log of that discussion

<dael> Topic: Mark unimplemented CSSPseudoElement features at-risk
<dael> github: https://github.com//issues/3540
<dael> fantasai: Suggestion is mark things unimplemented or drop them if no one plans to implement. No one place to impl style method. Other question is which pseudo elements do we want to support. ::selection or jsut those that generate boxes? Moz only supports ::before and ::after
<dael> astearns: I don't have an opinion as to which we have to support. I noticed when reading spec there are lots of others in the spec not mentioned here. It would be nice to havea note as to why others are omitted
<dael> fantasai: I suggest we trim spec to subset moz supports unless anyone intends to implement?
<leaverou> if it only supports a subset of supported pseudo-elements, that's yet another reason to not throw when other pseudos are used that are supported by the browser but not by that API
<dael> astearns: Obj to trim set supports to ::before and ::after?
<dael> fantasai: And no style
<dael> astearns: Objections to either
<dael> RESOLVED: Drop style from this level, restrict API to ::before and ::after, add a note to why the other things are not yet supported
<dael> fremy: Begs question to what we should do for other things browser supports. WE should say what to do with other stuff.
<dael> fantasai: Yeah
<dael> astearns: Can you add a comment to the other issue mentioning we should define that?
<dael> fremy: I can