Closed beaufortfrancois closed 1 year ago
Note: Previous version of this specification used the name :picture-in-picture for this pseudo-class. This name has been deprecated because it was too vague. Web developers may have thought that this pseudo-class would apply to the element in the Picture-in-Picture window, whereas it applies to the element in the web page.
This doesn't make any sense. In this specification, those two elements are the same. In fact, adding this comment is more confusing than the original name, not less.
Isn't this what we discussed @jernoble during the WG call? The idea is that :picture-in-picture-inline
will do exactly what :picture-in-picture
is currently doing which will allow us to create another pseudo-class with a different name if we want to have it interact with the window part of the Picture-in-Picture element. We are not defining that in the spec at the moment because we don't need it which is why the spec just changed the name and marked the old one as deprecated. Does that match what you understood from the call?
That spec doesn't exist yet, so this problem you're trying to solve doesn't exist yet either. Therefore, this change is not necessary, and making it will cause more confusion, not less. Furthermore, it's not evident that even in the hypothetical future where a spec exists that allows arbitrary element to go into PiP that this tension between where this pseudo-class applies even exists, nor whether this is the best way to solve that tension.
This is very much putting the cart before the horse.
I'm not sure it's hypothetical. Picture-in-Picture, has two parts: where the elements used to be and where it's visible now. By simple trial and error, any web developer can figure out that :picture-in-picture
will style the representation (though empty) of the element in the page because we keep something. But it may very well not be clear to someone who didn't read the spec and didn't try the implementation which one :picture-in-picture
is going to style.. The name isn't very descriptive. The name change isn't really specific to arbitrary elements going in Picture-in-Picture (though mostly about it): we could imagine styling the Picture-in-Picture window in some ways like adding transparency.
As a side note, this name was copied from Fullscreen but the difference with the Fullscreen API is that the user doesn't usually see the original page with Fullscreen (until we allow fullscreening to a different screen). Though, it's worth pointing out that :picture-in-picture
behave in some ways exactly the opposite to :fullscreen
as the element in the page is styled instead of the new rendering.
I think it may help the discussion to split the name change and the name discussion as two different topics: do we believe :picture-in-picture-inline
is a good name? Personally, I think it's good and clear. Is it worth changing after Safari already launched the :picture-in-picture
one? I'm sympathetic to that problem and if you have data about the usage and how much of a pain it would be to deprecate (if even realistic), it would help. I wouldn't advocate to have Safari implement both names for the foreseeable future. My hope is that because Safari's launch was recent and Chrome never launched this, it may be possible to do a change without too much impact,
It's currently literally impossible to style the contents of the PiP window, purposefully. So there is no ambiguity in the name. Pages which try to style the contents of the PiP window will fail, regardless of the name.
do we believe :picture-in-picture-inline is a good name?
No, it's self contradictory (both picture-in-picture and inline at the same time). "inline" is also a word that has completely different meaning in other areas of CSS.
Would keeping the :picture-in-picture
CSS pseudo-class name for the element in the page and having a potentially new :picture-in-picture-window
CSS pseudo-class for the Picture-in-Picture window element help?
I don't think -window
is quite right either; window
has existing meaning in the DOM which doesn't match the usage here. Have you considered :picture-in-picture-root
? There's already an existing pseudo class :root
which targets the root node in a document; I presume that :picture-in-picture-root
would target the root node of the picture-in-picture "context". The other possibility is :picture-in-picture-host
which is parallel to the Shadow DOM pseudo class [:host
](https://developer.mozilla.org/en-US/docs/Web/CSS/:host()) for accessing the node of the hosting element.
Maybe if we want to discuss names, we should try to think about how we would name something to style the window content if anything. -root
and -host
have some good to them but I wonder if it may be unclear what it would do. WDYT of :picture-in-picture-placeholder
?
gentle ping @jernoble
As the :picture-in-picture
CSS pseudo class has been implemented in Safari now, I'm going to close this issue.
As Discussed during the Media WG call on 12 May 2020, this PR renames CSS pseudo-class
:picture-in-picture
to:picture-in-picture-inline
@mounirlamouri @jernoble @tidoust
Fix: https://github.com/w3c/picture-in-picture/issues/172
Preview | Diff