New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 906660 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 26
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Universal selector (*) with combinator ( > ) have effect on specificity

Reported by konr...@gmail.com, Nov 19

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36

Steps to reproduce the problem:
1. Create <div> that will be used as a main container (with class: ".main") 
2.  Create another div inside the div we've defined above (with class ".wrapper")
3. Inside inner element (with class ".wrapper") define <p> HTMLElement with some text.
4. Open Developer Tools and click on the + sign to create New Style Rule (sign resides along side ":hover" and ".cls" buttons inside style tab
5. In new created rule write the following: .main > * { font-size: 7rem;  }
6. Create another Style Rule (see step 4)
7. In the new created rule define: .wrapper { font-size: 1rem; }

What is the expected behavior?
Universal selector (*), combinators (+, >, ~, ' ') and negation pseudo-class (:not()) have no effect on specificity.
So .wrapper class's font-size should be 1rem;

What went wrong?
.wrapper class's font-size is overridden by the ".main > *" selector

Did this work before? N/A 

Chrome version: 70.0.3538.102  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 

Link to the example with HTML already defined:
https://goo.gl/ieKous
 so all you have to do is open developer tools and define 2 selectors:
1.) .main > * {
    font-size: 7rem;
}
2.) .wrapper {
 font-size: 1rem; 
}
 
FWIW, no bug here in Chrome 69, 70, 72.
Labels: Needs-Triage-M70
Cc: krajshree@chromium.org
Labels: Triaged-ET Needs-Feedback
reporter@ - Thanks for filing the issue...!!
Could you please provide a sample test file or url to test the issue from TE-end. By navigating to https://goo.gl/ieKous only shows "Some text for the test" and does nothing. If possible please provide a screen cast for better understanding of the issue. This will help us in triaging the issue further.

Thanks...!!
Here is the link to the screen share video that I've made.
https://goo.gl/VeP1Rm
Project Member

Comment 5 by sheriffbot@chromium.org, Nov 20

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Reporter, your video in comment 4 shows a completely different case, where Chrome still behaves correctly: your first selector applies to the child <H1> so it stays red.
It should be black, because it's parent has color property set to black which should override the property with universal selector and combinator.
re 7, the C in CSS stands for cascading and that's what's happening here: the child <H1> has an applicable rule which overrides the parent rule so Chrome renders it correctly in red - same as Firefox or even IE and any other CSS-compliant browser.

P.S. here's a simplified html shown in the video:

    <style>
    .a > * { color: red }
    .b { color: blue }
    </style>
    <div class="a b">
      <h1>test</h1>
    </div>
Let me ask you something @woxxom, are you from the Chromium team or maybe from the Google? If not please don't clutter the chat. And if you have some free time learn about specificity and order in CSS it will help you a lot. 

I do agree that ".container" class on the wrapper of the H1 is misleading but this still should work and H1 should get black color instead of the red.
I'm not a Chromium or Google engineer but they can't do anything without a reproducible test case so they won't be even assigned to this issue. I've been trying to create that test case to help triaging the issue, but as I wrote in comment 1 the bug didn't reproduce (the font-size displayed was 1rem). Then you've shown a completely different use case in your video, still without providing a reproducible test case either via a file or URL.

Maybe I've used the wrong term, it should have been "filtering" or "inheritance", not "cascading".
More info in the spec: https://www.w3.org/TR/css-cascade-3/#declared-value
In the video the red color belongs to <H1> which has just one matching rule: .container > * { color: red }
And consequently it wins over the inherited value from another rule for the container: .body-content { color: black }
Sorry if this wasn't helpful, I hope you'll get an answer from a Chromium engineer eventually.
Status: WontFix (was: Unconfirmed)
Thanks woxxom for taking a first look at this.
TBH i'd defer to woxxom on matters of CSS inheritance as much as I would most experts. that explanation sounds right on point to me.

thx

Sign in to add a comment