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

Re: [csswg-drafts] [selectors] Postcede selector (#1705)

From: KIBI Gô ♀ via GitHub <sysbot+gh@w3.org>
Date: Mon, 25 Mar 2019 03:44:55 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-476045114-1553485494-sysbot+gh@w3.org>
> Can anybody else think of any compelling use-cases for a previous element selector in CSS?

Sure. Say I'm writing a basic webpage (just HTML and CSS). It has a number of sections, either `<nav>` or `<section>`. They look like this:

section {
    height: 100vh; /* Fills the screen */
    overflow: hidden;

For clarity, I want to stick an arrow at the bottom of these sections so that readers know that they can keep scrolling. This arrow isn't really a part of the document's contents (and shouldn't be rendered in alternate environments like Reader View), so it makes sense to add using CSS:

section::after {
    display: block;
    position: absolute;
    bottom: 0;
    margin: auto;
    width: 1em;
    content: "↓";

Naturally I don't want an arrow pointing towards nothing, so I can hide it on the last child.

section:last-child::after { content: none }

**However,** my document might have a page footer (a `<footer>`). I don't want an arrow pointing towards the footer *either*, if it exists. **So, I need to find the section *which precedes the footer* and hide the arrow there.**

1. I can't use `:last-of-type` because the final section could be EITHER a `<section>` or a `<nav>`.

2. I can't use `:nth-last-child()` because the footer might not be shown on every page.

3. Changing the order of the elements in the document is a no-go, since it reduces accessibility and messes up important features like Reader View.

4. It is silly to require JavaScript for a simple static, textual webpage, and requiring authors to manually type `class="LASTONE"` makes webpages more difficult to maintain (what if I forget to delete it when I add a new section?).

section:immediately-precedes(footer) { content: none }

I kept the above example as simple as possible but things get even more complicated if we consider a grid layout; suppose I want to display a page footer at the right-hand side of the grid rather than at the bottom. This could potentially affect the positioning of *all* preceding elements. (It could happen! In such cases, one might even want *both* `:precedes` and `:immediately-precedes`.)

**TL;DR: forms and web apps are definitely *not* the place where this selector seems most useful; vanilla text-based webpages with innovative typographic layouts are. *Not* having this feature leads to inaccessible webpages, by encouraging people to code documents whose tree doesn't reflect what is rendered on the page. This breaks important features like Reader View.**

(As a sidenote, since `:last-of-type` (and `:not(:last-of-type)`) already allows the addition/removal of siblings late in the tree to affect early ones, I'm not *entirely* clear as to how `:precedes()` is any different? Which is to say, it might be slowish, but hopefully not *unforgivably* slowish? (Maybe it just needs to be limited to simple selectors? `:last-of-type` is just `:not(:precedes(elt))` after all.))

GitHub Notification of comment by marrus-sh
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1705#issuecomment-476045114 using your GitHub account
Received on Monday, 25 March 2019 03:44:57 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:26:58 UTC