[css-env] getting access to the document title

[frivoal]

It can be useful to reuse the title of the document (the string found in the <title> element of an HTML document) in ::before or ::after. An easily recognizable example is running headers and footers, but that's limited to actually paged media, and it would be nice to achieve a similar effect in general.

A possible solution for this would be exposing it via env(doc-title).

[css-meeting-bot]

The CSS Working Group just discussed getting access to the document title.

The full IRC log of that discussion

<dael> Topic: getting access to the document title
<dael> github: https://github.com//issues/3685
<tantek> q+ to note "title of the document" is not necessarily <title> but sometimes (often) <h1> etc.
<dael> florian: There is a feature in GCPM that lets you in paged media generate header and footer with repeating document title in box. Interesting, but highly specific so not impl by mainstream browser. Base feature to take doc title and inject somewhere visible is useful. nth function seems like it could achieve that. Proposal is to have nth-doc-title expose the title of the element to be used in generated content
<tantek> right, I know that. I'm saying your use-case is disconnected from your solution.
<dael> florian: I'm specifically referring to a title element, not an h1. This isn't regions. H1 can have complex markup which wouldn't transfer to nth. HTML title element is just text so it's useful as well. Regions is useful but bigger
<Rossen_> gtg, bye
<dael> tantek: Not about extra markup but typical title elements contain things from name of website to author to doc name. If looking to solve use case and you want to repeat the huma readable title of document that information is often in first H1. If the use case is the repeating thing that doens't solve with how people publish on web today.
<dael> florian: I think will work with most eBooks but you have a point
<emilio> q+
<bkardell_> hmm
<dael> tantek: I would want to double check solution
<astearns> ack tantek
<Zakim> tantek, you wanted to note "title of the document" is not necessarily <title> but sometimes (often) <h1> etc.
<bkardell_> I cannot hear - is the call running?
<emilio> Audio went out
<emilio> Oh well
<emilio> Will comment on the issue
<astearns> thanks
<AmeliaBR> +1 to tantek's argument on practicality. But I like the general idea of env() to access document properties.
<dael> astearns: We're out of time. THanks everyone for calling in

[emilio]

What I was going to say at the end of the call was that I'm not particularly opposed to this feature, though all implementations of environment variables assume that they don't change frequently, and it's a common thing to change the document title on an interval and such.

It's not an unsolvable problem of course, but it makes it a bit less straight-forward to implement than what it seems.

[frivoal]

I think @tantek (see the minutes in the previous comment) is right in the general case, but the general solution is much harder (something like this). This proposal only works in some simple cases, but it's implementation would be comparatively trivial, and re-uses an mechanism we've already introduced anway, so it still seem worth doing to me.

[css-meeting-bot]

The CSS Working Group just discussed getting access to the document title.

The full IRC log of that discussion

<dael> Topic: getting access to the document title
<dael> github: https://github.com//issues/3685
<dael> astearns: This was intorduced last week, discussion of scope and that it's not usefulin all situations. What else did you want on this florian ?
<dael> florian: Not much to add, just cut by clock. I think it would be useful to be able to acess doc title from env. tanpointed out this is not powerful enough for general problem
<dael> florian: The generic solution pretty much calls for regions, though. This is much simplier and solves some cases so I think it's good to do. I recognize it's not a full solution
<dael> AmeliaBR: One thing is that CSS has a mech for what florian wants in GCPM module. That is a much more complex and nuanced system of pulling bits of text from a heading and reusing in other parts of layout.
<dael> AmeliaBR: I don't know if there's any interest in getting that cleaned and into browsers or if we want the quick win
<dael> florian: I think we should do this regardless. Other is slighly more powerful, but it's still plaintext only and only works in paged margin boxes so if you don't paginate you get nothing. So this is less expressive but more applicable and simplier
<dael> florian: I was discussing in context of Viviostyle and there were cases to not envoke the whole complex process, just I want the title and put it there.
<dael> florian: I don't think I wouldn't be pushing if we didn't have nth function. We have the mech so this is exposing a value through it
<dael> Rossen: Main motivation is in paginated scenarios?
<dael> florian: Commonly seen in paginated but this doesn't have to be restricted. With nth works everywhere. If you want something pagination-like you can envoke things like this
<dael> Rossen: Just curious use cases
<dael> florian: Same type of layout as paginated media but actual pagination with css level of page is one thing, but something that visually looks like pages is another. I'm aware of wanting to do things that look page-like is a use case
<dael> fantasai: Concern is this is too simple for what's wanted. If we go in this direction we'll be too limited. Don't know how urgent this is. If it's not something we have to do really soon might be worth trying to sort out more generic that solves this class of problems rather then special casing this
<bkardell_> it seems like we have maybe a lot of things that are almost related to this
<dael> florian: Don't think particularly urgent. In that sense okay with punting. More generic is way more complicated. I don't see this as trying to solve whole problem. If want to expose more through nth it seems reasonable.
<dael> fantasai: If it would solve 80% use cases it's worth, but seems closer to 20% so I don't know it's worth introducing a new pattern if we're not planning to pursue patterns
<dael> florian: I think for ebook this would solve most of the problems. Depends on how you say 100%
<dael> fantasai: But they also want page number and chapter
<bkardell_> q+
<dael> florian: But ebooks has chapters. It is simple
<dael> bkardell_: I'm interested in this use case. I feel like I would like to talk to florian a bit to understand more off call. If it only can give you the plain text would you not be able to achieve most by setting a custom prop for now? I think we said it's just plain text so the 20% of use cases wouldn't they be served equally as well with a css custom prop?
<dael> astearns: It's content duplication and you run the risk of out of sync. This is slightly better then dup in custom prop
<dael> florian: ebook with 25 chapters if you use nth you pull from doc, custom prop you have it for each chapter
<dael> bkardell_: That's what I'd like to understand more. They're not input manually, they're built.
<dael> bkardell_: Would mean multiple rules
<florian> s/But ebooks has chapters/but in ebooks, chapters are HTML files, so, it is sufficient for that case/
<dael> astearns: Prob enough for now. Not hearing enough to persue for now. Maybe if we saw use of custom properties for this could make better solution
<dael> florian: I'm hearing sufficent skeptisism we're punting
<dael> AmeliaBR: florian worth looking if there are similar doc properties where worth a common mech. Doc URL or parts of URL might be similarly useful. Have permalink on a file. I haven't looked and it's a matter of looking at what people are actually using to insert into the generated content
<dael> florian: We can think of a few more, but that's enough for the topic today. We can go offline