Project

General

Profile

Actions

Bug #105014

closed

CKEditor `contentsCss`: Selectors with `:has()` and `:where()` are not properly prefixed

Added by Leonie Philine 2 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
RTE (rtehtmlarea + ckeditor)
Target version:
-
Start date:
2024-09-17
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
12
PHP Version:
8.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Steps to reproduce:

1. Create and apply an RTE configuration with contentsCss.
2. In the referenced CSS file, declare CSS using :has and or :where selectors.
3. Edit content in the backend, and inspect with the browser devtools. Selectors with :has and :where will not be applied. They seem to be missing in the constructed CSS.

Example:

ul li:has(& > p.text-center) {
  color: red;
}

Then, in the editor, create a list and center it. The list item will not be colored red. The devtools web inspector will not show any sign of these selectors.

Note that this isn't a nesting standard incompatibility. This does not work either:

ul li:has(> p.text-center) {
  color: red;
}

Note that neither :has() nor :where() selectors work, but pseudo-classes like ::before do.

According to AST explorer, css-tree, the package used to preprocess editor CSS content, parses the :has selector just fine: https://astexplorer.net/#/gist/244e2fb4da940df52bf0f4b94277db44/8f51276c0fcd8ce562da7cc695fb33d0b2fbef1a

Actions #2

Updated by Garvin Hicking 2 months ago

  • Subject changed from CKEditor `contentsCss`: Selectors with `:has()` and `:where()` are not applied to editor content. to CKEditor `contentsCss`: Selectors with `:has()` and `:where()` are not properly prefixed

I've debugged this in part. Indeed the prefixing is executed for me, though.

It turns this:

ul li:has(& > p.text-center) 
{
    color: red;
}

into this:

#data_tt_content__2685__bodytext_ckeditor5 .ck-content ul li:has(#data_tt_content__2685__bodytext_ckeditor5 .ck-content &>p.text-center){
    color:red
}

note that the prefixer also applies all the `has()` parts with the prefix, too. And of course the `ul li` cannot contain a p.text-center inside of it, wrapping the prefixed part again.

Probably the AST walker of Build/Sources/TypeScript/rte_ckeditor/css-prefixer.ts in method cssPrefixer has to be adapted to recognize if it's inside context of a PseudoClassSelector and skip application. My tries to implement this failed though.

Actions #3

Updated by Gerrit Code Review about 2 months ago

  • Status changed from New to Under Review

Patch set 1 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/86305

Actions #4

Updated by Benjamin Franzke about 2 months ago · Edited

The nesting selector &https://developer.mozilla.org/en-US/docs/Web/CSS/Nesting_selector – is not meant to be used within :has(), that code actually does not work, even without the css-prefixer.

But you are right, the css-prefixer must not prefix nested selectors and I pushed a patch to address that: https://review.typo3.org/c/Packages/TYPO3.CMS/+/86305

Edit: That means you should actually use:

ul li:has(> p.text-center) {
    color: red;
}
Actions #5

Updated by Gerrit Code Review about 2 months ago

Patch set 2 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/86305

Actions #6

Updated by Gerrit Code Review about 2 months ago

Patch set 3 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/86305

Actions #7

Updated by Gerrit Code Review about 2 months ago

Patch set 1 for branch 12.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/86332

Actions #8

Updated by Benjamin Franzke about 2 months ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #9

Updated by Benni Mack about 1 month ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF