- From: Florian Rivoal via GitHub <noreply@w3.org>
- Date: Wed, 25 Jun 2025 09:59:12 +0000
- To: public-css-archive@w3.org
The feature makes sense to me, and I'd be partial to the naming using "inset". It might be useful to consider potential extension path, allowing user agents to expose different values on different sides in the cases where they do know the difference, but as discussed that's not reliably knowable in the general case, so the basic version reporting the largest value make sense. But the more specific version does seem useful too: it might be detectable on some OS/printer combination, but this is also possibly something a user who knows the behavior of the target printer could enter through some settings UI. This might be more likely in the case of specialized HTMl+CSS->PDF printers than in the browser's print dialog, but it's theoretically possible in either. The challenge there though is that these value may be different per page, as some differently oriented/dimentionned page could be oriented differently in the printer (or, as mentioned, due to recto-verso printing). In which case, it's not enough to have 4 env variables to describe each side, but we'd somehow need to be able to convey a per page info. Not sure how to do that. Maybe `env()` could evaluate differently in different `@page` sub-rules, but that feels dirty somehow. As far as fingerprinting, is there any spec that describes the particularities of the browser's print-preview window? Is it normal expect for how it's invoked? Are there (specified) limitations on what happens to the scripting environment, or to the ability to conditionally load remote resources? I don't think I'm aware of any such spec. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11395#issuecomment-3004171315 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 June 2025 09:59:13 UTC