Proposal: Add wrapper pseudo element

[ianthedev]

Please find the information of ::wrap pseudo element through this hyperlink.

There are abundant use cases of this pseudo element. For example, because there has been no wrapper element for wrapping <dt> and <dd> pairs in description list <dl>, web developers have been having no choice but to resort to JavaScript to insert <li role="presentation"></li> into <dl> or even use less semantic list elements like <ul>. Yet another example is that layout designs such as "left and right columns" is everywhere so we have been having to add extra wrapper <div>s into HTML for that kind of purpose.

The aforementioned examples are just a tip of iceberg. The use cases of ::wrap are a lot more than the use cases of :first-child, :empty, etc.

Could we please have this ::wrap pseudo element be formally adopted? With this pseudo element, web developers would be able to write more semantic HTML and no longer have to resort to JavaScript, which can result in the unwanted FOUC. From the aspect of use case, there seems to be no reason why this pseudo element should not be adopted.

[ianthedev]

If you support this proposal, please reply so that we can get more people involved and underline the importance of ::wrap pseudo element.

[SebastianZ]

The most important part of this proposal is that it allows to get rid of wrapper HTML elements, which are only used for layout purposes.

An example for this can be seen on this very GitHub page, which currently has a structure like this:

<div id="discussion_bucket" class="clearfix">
  <div class="discussion-sidebar js-sticky is-stuck" style="position: sticky;">
    …
  </div>
  <div class="discussion-timeline js-quote-selection-container ">
    …
  </div>
</div>

With this pseudo-element it would be possible to replace the outer <div> by a CSS rule like this:

#show_issue::wrap(:first-child, :last-child) {
  display: block;
}

#show_issue::wrap(:first-child, :last-child)::before {
  content: "";
  display: table;
}

#show_issue::wrap(:first-child, :last-child)::after {
  clear: both;
  content: "";
  display: table;
}

Note: This example also requires stacking of pseudo-elements. Though even without pseudo-element stacking there are use cases for a wrapper pseudo-element.

For reference, this proposal was previously discussed on www-style.

Sebastian

PS: @Ian-Y, please change the summary to "Add wrapper pseudo element" to be more general (and remove [css3-selector], as Selectors Level 3 is already a recommendation). This may rather be part of the CSS Pseudo-Elements Module.

[ianthedev]

@SebastianZ Thank you for the example of use case. And I had changed the thread title as per your suggestion.

[SebastianZ]

Here are some older discussions about this:

• Proposing ::contents pseudo-element‏‏
• A *:body pseudo class
• [selectors] New pseudo-element ::inner-wrapper & ::outer-wrapper (feature)
• [css4-pseudo] The need for more powerful pseudo elements
• [whatwg] wrapper element

I skimmed through them and saw three counter proposals:

Use tags for the start and end elements

Idea

Tag the start and end elements via group-open and group-close properties and introduce a ::group() pseudo-element making use of that tags to style the elements between them.

This was proposed by Marat Tanalin in '[selectors] New pseudo-element ::inner-wrapper & ::outer-wrapper (feature)'.

Example

DL.example > DT {group-open: myGroupName; }
DL.example > DD {group-close: myGroupName; }

/* Show green border around each `DT`/`DD` group. */
::group(myGroupName) {
  border: 2px solid #0d0;
}

Use decorators

Idea

Introduce an @decorator at-rule defining decorative elements, which can then be applied via a decorator property.

@FremyCompany mentioned this in '[css4-pseudo] The need for more powerful pseudo elements', which was obviously inspired by an old version of the Web Components spec.

Example

@decorator video {
  content: contents slot(icon) slot(text);
  @slot(icon) { content: ' V'; font-family: ...; }
  @slot(text) { content: ' video'; }
}

@decorator fog {
  content: slot(wrapper);
  @slot(wrapper) {
    content: contents slot(overlay);
    position: relative;
  }
  @slot(overlay) {
    position: absolute; top...;
    background: rgba(...);
  }
}

@decorator only-first-image {
  content: contents(img:first-of-type);
}

Use a pseudo-class

Idea

Introduce a :body pseudo-class matching all non-heading elements.

This is obviously restricted to some specific use case and was proposed by Leif Halvard Silli in 'A *:body pseudo class'.

He didn't provide a proper example of how he imagined the pseudo-class to work, though as he's talking about something that "encapsulates the entire "body text"", I assume he mixed up the use cases of pseudo-classes and pseudo-elements.

Sebastian

[SebastianZ]

Some important comments from the related www-style thread:

@tabatkins:

It's definitely not impossible! … New pseudos that wrap "real" elements in
some way are... not popular among implementors. The idea for ::wrap
goes back well over a decade, and the complexity it adds to the
platform versus the benefit you get, when compared to just adding
wrapper elements in your HTML, has meant that implementors have never
bitten at the idea.

@Crissov

You’d need to convince Hixie et al., though.

Why isn’t there a grouping-type element for description lists to represent individual name-value groups (e.g., a “dli” element)? It would make styling as well as adding microdata to individual groups much easier.
HTML should group <dt>s and <dd>s together in <di>s!

This FAQ says:

This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.

@Marat-Tanalin:

So virtual containers are far more than just a way to group DT/DD elements, instead they would be a powerful layout mechanism absolutely unachievable with current HTML and CSS.

[tabatkins]

As I and @fantasai stated in the email thread, implementors have historically been strongly against this sort of functionality; it makes for a very complicated implementation, apparently. Features don't really do well without implementor interest, and in this case we have clear implementor anti-interest, which is a strong signal that we should not add the feature to a spec, as it will not be successful.

See https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F for a rough idea of how adding new features work. Author interest is one part of the process, but not all of it!

[Crissov]

Everybody agrees that the dt-dd use case is a valid one, but effectively, @tabatkins says WONTFIX in CSS and @Hixie says WONTFIX in HTML. Both represent Google/Chrome. Can you figure out this deadlock internally?

[tabatkins]

It's very possible for something to be WONTFIX in both languages!

But also, Hixie hasn't been the editor of HTML for a while now. This could possibly be relitigated in WHATWG; Domenic and Anne may have different opinions now. (And I'm happy to support reusing <li> for this purpose.)