Re: [csswg-drafts] [css-gcpm][css-content] "string-set" on elements with no boxes: How to determine which page the assignment is on (#8404)

Agree this is complex, and definitely agree going back through the DOM makes more sense rather than to try and guess what-might-have-been based on layout.

I created a test to see what current implementations do:

```html
<!DOCTYPE HTML>
<html>
<head>
<style>
@page {
    margin: 72px;
    @top-center {
        content: "String is "  string(foo, first);
    }
}
.set {
    display: none;
    string-set: foo attr(string);
}
h1 {
    break-after: page;
}
</style>
</head>
<body>
 <h1>Page 1</h1>
 <div class="set" string="string1">string1</div>
 <h1>Page 2</h1>
 <div class="set" string="string2">string2</div>
 <h1>Page 3</h1>
 <div class="set" string="string3">string3</div>
</body>
</html>
```

If I understand your proposal correctly you'd expect to see "string1, string2, string3" at the top of the three pages, correct? Testing with the engines at https://printcss.live gives:

* AH Formatter is "string1, string1, string2"
* Prince is "_blank_, string1, string1"
* BFO (our dev build) and Vivliostyle are both "_blank_, string1, string2"
* Weasyprint, paged.js and (currently) PDFReactor don't seem to support strings on `display:none` elements.

other findings

* the results are unchanged if I change `h1` to `break-before: page`
* if I move the string-set element before the `h1` then AH, BFO and Vivliostyle all give "string1, string2, string3". Prince gives "string1, string1, string1"
* if I change the string-set element to `display:block` then AH Formatter, BFO, PDFReactor, Prince, Vivliostyle and Weasyprint all give the correct output, which is "_blank_, string1, string2"

So of the three tools trying to do this properly (Prince seems a bit lost here), the only ambiguity is where the string-set is immediately _followed_ by a page break. In this situation, both Vivliostyle and BFO are moving the string-set to the top of the next page, rather than the bottom of the previous one as in your proposal. `break-before` and `break-after` are ignored.



So that's the data. Based on this I think there are four options.

1. go with your proposal; this means a change for BFO and Vivliostyle
2. go with the behaviour of BFO and Vivliostyle; I presume this is going to mean a change to your current work.
3. Try and consider the behaviour of `break-before` and `break-after` in this decision - I fear this might be over-complicating things for little benefit.
4. when `string-set` falls on a page boundary like this, leave it undefined as to whether it is considered to be on the previous or next page, so long as it follows the DOM order.

I'm obviously leaning towards (2), not just because that's what we've done but because if string-set is used, it seems like this would be done at the _start_ of any section relating to that string: it should stick to content that follows it.

```html
<section>
 <div style="display:none; string-set: chapter "Widget"></div>
 ... content relating to widgets ...
</section>

<section>
 ... content relating to widgets ...
 <div style="display:none; string-set: chapter "Widget"></div>
</section>
```

The first of those two seems more likely to me, and the existing css-gcpm test at https://github.com/web-platform-tests/wpt/blob/master/css/css-gcpm/string-set-011.html seems to agree.

cc @MurakamiShinyu for Vivliostyle's opinion.

----

Related question: The definition for `string(nnn, start)` states that "If the element is the first element on the page, the value of the first assignment is used". Can an element that is `display:none` ever be the first element on the page?

-- 
GitHub Notification of comment by faceless2
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8404#issuecomment-1429930103 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 14 February 2023 15:26:43 UTC