W3C home > Mailing lists > Public > www-style@w3.org > February 2014

Re: [CSSWG] Minutes Telecon 2014-02-26

From: Brian Kardell <bkardell@gmail.com>
Date: Wed, 26 Feb 2014 22:34:51 -0500
Message-ID: <CADC=+jd4ROcdHi5krFFG-4nfcR6X3Fd2ve=zj3xoHVRGNG2sXw@mail.gmail.com>
To: Dael Jackson <daelcss@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
[snip]

> ShadowDOM
> ---------
>
>   TabAtkins: I've been talking over fantasai suggestion from last
>              week about switching to pseudo elements.
>   TabAtkins: Mostly I'm okay. For shadow and content it works.
>   TabAtkins: Only one issue is with shadow-deep because it doesn't
>              correspond to anything real.
>   TabAtkins: fantasai explained it as switching to a virtual tree,
>              but that is weird.
>   TabAtkins: It wouldn't match anything is CSS. Potentially queries
>              could return the shadow roots.
>   TabAtkins: We're uncomfortable with making that as pseudo. We want
>              that as a combinator.
>   TabAtkins: Then it seems odd for them to be sometimes pseudo,
>              sometimes combinators.
>
>   fantasai: I'm not convinced shadow-deep needs to be a combinator
>             because there could be something in the DOM. It's a
>             thing you can talk about and define as existing.
>   fantasai: That our DOM isn't structured shouldn't change the CSS
>             syntax.
>   TabAtkins: But we'll never have a DOM thing for that.
>   fantasai: But it exists as a concept. So our syntax shouldn't be
>             restricted. We should chose from conceptual consistency.
>
>   bkardell: The shadow root looks okay, but shadow-deep root doesn't
>             make sense as a thing to talk about instead of nesting
>             roots.
>   TabAtkins: We talk about the composed tree, not something rooted
>              at a post. So shadow-deep doesn't exist.
>   fantasai: What you're doing is a sub tree of the tree.
>   bkardell: It's a tree, though, real or conceptual.
>   fantasai: If you're talking about foo, it's great grandmother's
>             niece may have a shadow, but you wouldn't reach it.
>
>   TabAtkins: My problem is this may let us define everything as a
>              pseudo instead of combinator.
>   fantasai: I don't think so.
>   TabAtkins: The reference combinator could be seen as something
>              hanging off in an alternate tree.
>   fantasai: No. There's a connection, but no one is making a
>             different tree for the child.
>   fantasai: There's no child/parent there. It's just a link.
>   TabAtkins: But that's all parent/child is. It's just a link.
>   fantasai: That's too abstract.
>   TabAtkins: I think your example is too.
>
>   bkardell: Pseudo is supposed to select the whole tree. A pseudo
>             element, not the whole tree
>   bkardell: So, we can define it as the root instead of the whole
>             tree. I think the concept is a bit off.


FWIW, the comments above attributed to me were not me.  I don't know
who they were.  The one below are correctly attributed.


>   TabAtkins: You can map it to whatever element is hanging off.
>   TabAtkins: The tree isn't exposed. It won't be in any way.
>   fantasai: Neither is ::first-line.
>   TabAtkins: We plan to expose it more.
>
>   bkardell: Is there any reason you'd need to piece some? Or do you
>             intend to piece everything?
>   TabAtkins: If you only want to grab a foo-button that's a
>              descendant of some thing.
>
>   TabAtkins: I think we should be more judicious to what we expose
>              as pseudo elements to things that could be returned as
>              javascript.
>   TabAtkins: That seems to be a reasonable rule.
>   TabAtkins: Attributes have that. Some representation of the DoM.
>              Shadow, roots, work that way.
>   TabAtkins: I don't think an element in the tree can be exposed
>              usefully.
>   TabAtkins: I don't think it's an ultimate node in a tree. And
>              that's a pseudo element.
>
>   TabAtkins: So...what do we do now? Fantasai and I have a knife
>              fight and the winner is right?
>   TabAtkins: Before we have a knife fight, any other opinions?
>   Rossen: Are you planning on getting together for this?
>   fantasai: Yes.
>   rossen: I think we'd be interested in being there too.
>
>   florian: think the conceptual is a bit off.
>   fantasai: I'm worried that things like regions would be off from
>             shadow DOM for esoteric reasons we discuss here.
>   TabAtkins: Well and who knows what pages will use.
>   florian: I'd rather have actual consistency than theoretical
>            explanations about what should be pseudo elements.
>   glazou: Will you report to mailing list about the results of the
>           meeting?
>   TabAtkins: Yeah.
>   TabAtkins: Was that the last thing?



Additionally to the minutes, I'd like to add that I agree with Tab's
basic statement. On the one hand  ::shadow makes sense, the
pseudo-element you are referencing is basically like the shadow
membrane itself, not really an element - but a lot like one for our
purposes... and it has some kind of nice parallels which almost make
it seem like you could explain things like ::before and ::after as
actually being very similar (in fact, they might be explainable as
shadow dom exposed named parts, but that's a different topic).  On the
other hand though, the "pierce all" sort of thing currently referred
to as "shadow deep" really is playing the role of what combinators do
today... It's like "descendant plus plus" as in "no, I really really
mean ALL descendants, crossing all barriers I can cross".  I don't
think that plays well as a pseudo element.  Can we consider ::shadow
pseudo-element and /bikeshed/ combinator?
Received on Thursday, 27 February 2014 03:35:19 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 27 February 2014 03:35:26 UTC