- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 25 Feb 2019 19:01:09 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `CSS Pseudo Elements`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: CSS Pseudo Elements<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/3607<br> <fantasai> heycam: Last time we discussed this on a call, I was suggesting that the pseudo() function which returns a CSSPseudoElement object<br> <fantasai> heycam: should always return the same object regardless of what values content has<br> <fantasai> heycam: just so that we don't have to rely on what the current style state is to know when these objects should be dropped and recreated<br> <fantasai> heycam: It felt a little strange at the time<br> <fantasai> heycam: one thing that might argue against returning same object is if we have an API in the future that can create from script one of htese objects and insert it into the tree<br> <fantasai> heycam: Might be problematic to have stable objet identiy created for style, vs created from script<br> <fantasai> heycam: But that's similar to what we do for @font-face<br> <fantasai> TabAtkins: If you reparse the style sheet, we'll create new objects<br> <fantasai> myles: Actually, I spent a week of my time making that not true.<br> <fantasai> TabAtkins: Can you open an issue on not doing that?<br> <fantasai> myles: I originally wanted to do the thing you said<br> <fantasai> myles: was brought to my attention that it was very common in JS that authors would tack on properties to random objects<br> <fantasai> myles: so you can't just delete and recreate them<br> <fantasai> mstensho: For Blink implementation, we used to recreate the speudo-element internally when content changed, but we don't do that anymore<br> <fantasai> mstensho: when content property changes, we regenerate ... but the object stays the same<br> <mstensho> That's futhark speaking, not me<br> <fantasai> emilio: But you still regenerate when you switch content property to none and back again, right?<br> <fantasai> TabAtkins: If you turn content to none and then ask for the pseudo, you do return an object that you can return style on right?<br> <astearns> s/mstensho/futhark/<br> <fantasai> mstensho: Are you talking about the pseudo() method or gCS()<br> <fantasai> TabAtkins: pseudo<br> <fantasai> futhark: We don't implement it<br> <fantasai> emilio: Do we want to keep them lightweight objects or do we add .style?<br> <fantasai> emilio: If we add .style we need to keep the ? around anyway<br> <gregwhitworth> fantasai: currently we've dropped .style from the spec<br> <gregwhitworth> TabAtkins: wait, we dropped .style?<br> <fantasai> heycam: we kept .type and .element and it's an event target<br> <fantasai> TabAtkins: OK<br> <fantasai> emilio: If you add some stateful thing that we don't want to disappear randomly, then keeping object itself around is not a huge deal because you need to keep that info around<br> <fantasai> emilio: but if not, then recreating it would be better<br> <fantasai> TabAtkins: I think it should have .style<br> <fantasai> TabAtkins: later<br> <fantasai> TabAtkins: Because pseudos act like DOM elements, they fill a similar purpose<br> <fantasai> TabAtkins: Having object identity work it's nice<br> <fantasai> TabAtkins: Without that it's more annoying<br> <fantasai> TabAtkins: ...<br> <fantasai> TabAtkins: Myles's argument about FontFace objects suggests that they should stay around on these objects, too.<br> <fantasai> myles: I don't know how applicable that argument is to pseudos<br> <florian> q+<br> <fantasai> dbaron: I think one other comment about expandos is that CSSOM objects are historically one of the objects where expandos don't stay around<br> <fantasai> dbaron: They stay around in lots of places, but not in CSSOM objects<br> <fantasai> TabAtkins: Is it just font face objects that are conneted, or ??<br> <fantasai> q+<br> <fantasai> myles: Font face rules will change... I don't remember.<br> <florian> q-<br> <fantasai> florian: Another argument in favor of long-lived is if they're not, we need to specify in detail what their lifecycles are<br> <fantasai> florian: And if we don't we'll expose a lot of implementation details<br> <AmeliaBR> https://developer.mozilla.org/en-US/docs/Glossary/Expando "Expando properties are properties added to DOM nodes with JavaScript, where those properties are not part of the object's DOM specification"<br> <fantasai> florian: Do you regenerate on content property changing form on estring to another? flipt o none and back? n a display : none subtree?<br> <fantasai> florian: etc.<br> <fantasai> TabAtkins: [soething about garbage collector]<br> <fantasai> TabAtkins: Need to be either long-lived or regenerated on every call<br> <fantasai> myles: Most important part is that right now it's undefiend when the CSS engine decides to reparse rules or recreate derived objects<br> <fantasai> myles: That's pretty important fo roptimization<br> <fantasai> myles: so tying JS-visible semantics to that schedule would be scary<br> <fantasai> myles: Instead we should define something more rigorous<br> <fantasai> dbaron: Why is your GC idea not viable?<br> <fantasai> TabAtkins: It allows you to detect when GC happens by seeing how long the expando survives<br> <fantasai> dbaron: traditional way around that is that the expando makes it not collectible<br> <fantasai> TabAtkins: OK. My idea was to just hold it as a weak ref<br> <fantasai> dbaron: I think your weak ref idea is workable if we make expandos make it not collectible.<br> <fantasai> myles: It's true in our engine also<br> <fantasai> TabAtkins: If that's the case, then all the exposed possibibitlities for GC are handled if expando force a strong reference<br> <florian> ScribeScribe: Florian<br> <xfq> ack fantasai<br> <florian> fantasai: one concern was about keeping around a lot of memory if you iterate the entire tree<br> <florian> fantasai: if the pseudo doesn't generate a box, you return null, but as soon as you generate a box you generate the object and keep it around<br> <fantasai> emilio: that's also incompatible with making that API work with stuff like selection<br> <fantasai> TabAtkins^: incompatible with .style<br> <fantasai> emilio: For ::first-line ::first-letter, fine, but won't work for some other stuff<br> <fantasai> TabAtkins: I think returning null is OK only for things that don't exist, like the name is invalid<br> <TabAtkins> s/[soething about garbage collector]/If we just make the element have a weak ref to its pseudo, then expandos let you observe GC.<br> <fantasai> fantasai: Shouldn't that throw an error?<br> <fantasai> TabAtkins: No<br> <fantasai> astearns: We already talked about that<br> <fantasai> florian: How long-lived is it?<br> <fantasai> heycam: So we always return the same object, and it's kinda like it's connected to the element you call it on<br> <fantasai> TabAtkins: You're allowed to drop the object if doing so is unobservable<br> <fantasai> TabAtkins: e.e.g if no expando, no references, can drop it and recreate it<br> <fantasai> TabAtkins: I guess you can't observe object identity without a reference<br> <fantasai> smfr: Same object in IDL?<br> <fantasai> TabAtkins: That's advisory in the IDL. Have to say in algorithm what happens<br> <fantasai> myles: Can we make another IDL attribute that means "for real"? :)<br> <smfr> [SameObject]<br> <fantasai> heycam: What it means for a particular API is not particularly clear, so need to sayin the prose what type of object and stuff.<br> <fantasai> heycam: It's a hint to the JS engine, that's all.<br> <fantasai> myles^: so it means nothing<br> <fantasai> florian: There's a hint to the spec reader that there's some prose somewhere that matters?<br> <fantasai> TabAtkins: yes<br> <fantasai> astearns: So afaict, the proposed resolution is that pseudo() will return the same object always<br> <TabAtkins> Proposed Resolution: pseudo() must always return the same object (up to observability)<br> <fantasai> astearns: and we will have text suggesting that htis can be GC if that is unobservable<br> <fantasai> astearns: Objections/concerns?<br> <TabAtkins> "same object" for a given element/pseudo pair<br> <fantasai> RESOLVE: pseudo() must always return the same object. Note that object can be GC'd if this is unobservable.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3607#issuecomment-467136978 using your GitHub account
Received on Monday, 25 February 2019 19:01:11 UTC