- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Dec 2018 00:43:08 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Why \"Pseudo-elements cannot be represented by the matches-any pseudo-class\"?`, and agreed to the following: * `RESOLVED: Defer this issue to L5` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Why \"Pseudo-elements cannot be represented by the matches-any pseudo-class\"?<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2284<br> <dael> fantasai: I wanted to ask if this is something we should try and define or close as no change<br> <dael> TabAtkins: Valid.<br> <dael> TabAtkins: I know that safari allows pseudo elements, but it doesn't make sense and I don't know why<br> <TabAtkins> .foo:matches(::before):hover<br> <dael> TabAtkins: This selector ^ bothers me.<br> <dael> TabAtkins: Unclear if it means before when foo is hovered or when foo.before is hovered.<br> <TabAtkins> .foo:matches(::before).bar is invalid, then<br> <dael> fantasai: If we're going to define we have to define if a selecotr ends in a pseudo element and has same meaning as if you placed element outside of matches.<br> <TabAtkins> .foo:matches(::before, .baz).bar is invalid, too<br> <dael> fantasai: That's invalid, right.<br> <dael> TabAtkins: Reasonable sort of thing to define on<br> <dael> TabAtkins: It's weird and I don't like it, but if it's what we want I'm okay<br> <dael> ericwilligers: What's the need for this?<br> <TabAtkins> .foo:matches(::before, ::after)<br> <dael> TabAtkins: Safari does it for selectors like ^<br> <dael> TabAtkins: You want to assign a style to multiple psuedo elements. Can't do that with matches right now. That's annoying, I agree<br> <dael> TabAtkins: Reasonable thing. Even bikeshed stylesheet would like to do a selector like this.<br> <fantasai> s/matches/is/ btw ;)<br> <TabAtkins> .foo:matches(::before, .bar)<br> <TabAtkins> ^ invalid<br> <dael> TabAtkins: Another option is we're more limited and you can put psuedo elements in if they're the only thing in the selector. All options have to be pseudo elements<br> <TabAtkins> .foo:matches(::before:hover) is valid<br> <dael> TabAtkins: That would be okay way to deal<br> <plinss> .foo:matches(::before):matches(:hover) ?<br> <TabAtkins> would be valid by my rule I think<br> <dael> fantasai: Thing that's tricky is different pseudo elements can be followed by different things. No need to make first example invalid b/c each branch is valid. If any branch is invalid whole is invalid.<br> <dbaron_> Pseudo elements seem like they might differ in what is allowed after them<br> <dael> fantasai: More restrictive I'm not sure that gains us a whole lot. You'll still need contextual checking.<br> <fantasai> s/checking/checking, even if they're all pseudo-elements/<br> <dael> TabAtkins: ericwilligers we don't support pseudo elements in matches right now, correct?<br> <dael> ericwilligers: Correct<br> <dbaron_> It seems like you might want to ensure that all branches of the :matches end in the same restriction state<br> <dael> TabAtkins: FF or Edge, how does this sound. Should I close no change and Safari violates spec? Or do we want?<br> <TabAtkins> dbaron_, I agree with that as a good restriction if we go this way<br> <dael> Rossen: Curious to hear from Safari folks.<br> <dael> Rossen: dbaron_ is on IRC [reads]<br> <dbaron_> (where we need to be conservative about what is the same, e.g. before and after OK but not selection)<br> <TabAtkins> :matches(::before, ::spelling-error) would be invalid<br> <dael> TabAtkins: before and after are fine, but before and spelling wouldn't work because allow different things<br> <dael> ericwilligers: Safari uses different selector name. So it doesn't matter too much.<br> <dael> TabAtkins: Not a backwards compat concern. It's what we want to do for the future<br> <dael> TabAtkins: I'm perfectly fine saying close no change<br> <dbaron_> Still have mixed feelings about whether to allow pseudos in v1<br> <dael> TabAtkins: dbaron_ is unsure. We can relax restriction later<br> <dbaron_> (typing on phone, BTW)<br> <dael> Rossen: smfr said Safari folks can't follow because they're in a meeting<br> <dael> Rossen: Objections to resolving no change?<br> <dael> fantasai: I think deferred<br> <dael> fantasai: Close no change means we don't want to accept. We might accept in future<br> <dael> fantasai: I'd prefer...if we're going to consider in the future we leave it open for selectors 5. If it's a baad idea we close no change.<br> <dael> Rossen: Don't disagree<br> <dael> Rossen: objections to defer to L5?<br> <dael> RESOLVED: Defer this issue to L5<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2284#issuecomment-444705870 using your GitHub account
Received on Thursday, 6 December 2018 00:43:10 UTC