W3C home > Mailing lists > Public > www-style@w3.org > November 2018

Re: [css-content] Generated content: should distinguish between content that's above or below a reference

From: Peter Moulder <pjrm@mail.internode.on.net>
Date: Wed, 14 Nov 2018 08:50:40 +1100
To: Hans Meiser <brille1@hotmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <20181113215040.25rwwnn3skeede3k@mail.internode.on.net>
On Tue, Nov 13, 2018 at 11:45:44AM +0000, Hans Meiser wrote:

> The issue is that documentation like AngularJS, WebPack, NodeJS, NPM,
> ASP.NET Core etc. is only fed by HTML/CSS pages. There is no PDF
> involved, and printing is done in the web browsers, ad-hoc.

No doubt any pdf-based user agent can be used for printing, but if you mean
that you want something that works even in web browsers (for which printing
is not a priority), then you're somewhat out of luck, as none of the web
browsers can print using even "on page 5" or a table of contents according
to a quick web search:

  https://stackoverflow.com/questions/30871237/is-css3-function-target-counter-supported-in-the-browsers-like-chrome-ie-etc

That's why people do use dedicated tools to print HTML/CSS.

So for code documentation (for the general public), the best you can do is
either to stick to section numbers, and/or to include CSS for target-counter 
for the benefit of those who do wish to use the likes of Prince (perhaps
via a web service such as DocRaptor):

  a[href ^= "#"]::after {
      content: " (on page " target-counter(attr(href), page) ")";
      content: " (on " prince-script(...) ")";
      /* (i.e. as in previous message) */
  }

(You shouldn't need @supports here, as CSS rules for error handling
and cascading are enough: web browsers should drop both declarations,
non-Prince user agents will drop the declaration that mentions
prince-script, and the later declarations win in UAs where both are
supported.  Furthermore, target-counter was around a long time before
@supports, so using @supports would even hinder some software.)


As an aside, regarding using "above" or "below" when the target is on
the same page as the referring text: using DOM alone can break down if
either the referring text and/or target text occurs in any kind of float,
whose position may differ from the position of its "place-holder" that's
most directly visible in the DOM.  One might want to use different wording
if the target or referring text are in different flows.  This is another
example of where the complexity of what sort of description one might
want argues in favour of a solution that involves script in general.

pjrm.
Received on Tuesday, 13 November 2018 21:51:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:11 UTC