W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2019

Re: [csswg-drafts] [css-shadow-parts] What's the purpose of multiple idents in ::part()? (#4412)

From: Peter Linss via GitHub <sysbot+gh@w3.org>
Date: Sat, 12 Oct 2019 18:48:22 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-541351749-1570906100-sysbot+gh@w3.org>
Ok, I think we understand each other here (and as an aside, thanks, this has been a helpful and productive conversation for me).

I agree that we need to expose class-like semantics of parts, I just think we should *also* be exposing a tag-like semantic.

I also agree that using regular classes within a shadow tree should stay within the shadow tree, and that we need to improve handling of pseudo element selectors in general (which has come up multiple times in the past).

The current model is the moral equivalent of using divs for markup and differentiating them purely by classes. It works (and many people do it), but it breaks the semantic model of HTML and has second-order costs. 

I'd like to see the part model extended so that a part exposes a tag-like label, that carries structural and semantic meaning, which is exposed via a pseudo element, and additionally can expose class-like information. There's value in the tag semantic, and I want to see that preserved for parts. Among other things, I'm thinking about how screen readers would process these (presuming no additional accessibility info was exposed by the custom element).

(I also think the specificity difference is valuable, even tho I agree it's not likely to be a considerable factor for most. It's more of a 'why throw out the cascade here?' issue. Just because we have an escape hatch, there's no reason to not have a regular door.)

I don't much care how this is expressed, two possibilities off the top of my head would be for the first part name to be the 'tag', and any additional names would be 'classes' (tho that feels awkward and then precludes the part having multiple part names, which I think is valuable in itself, allowing a single part to play multiple roles, but I can be convinced otherwise), or a separate attribute to declare part classes. Either way, we could expose the part classes to CSS as regular class selectors that only apply to the pseudo element.

Something like:

    <calendar-widget>
      <day-element part="day" partclass="weekend holiday">1</day-element>
    </calendar-widget>

    calendar-widget::part(day).weekend.holiday { color: green; }

Yes, it adds a bit of complexity, but it gives the part semantic information in addition to class information (and clearly differentiates them) as well as makes custom parts fit in with the rest of the model more cleanly IMO.

Also, I think if the part itself is a custom element it should be able to expose it's own `:state`. It's not clear to me if that's been accounted for yet. (And possibly it's own `::part`s, tho probably the containing custom element should be involved there, not sure how that'd work yet, but food for thought). 


-- 
GitHub Notification of comment by plinss
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4412#issuecomment-541351749 using your GitHub account
Received on Saturday, 12 October 2019 18:48:23 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:54 UTC