Re: [css-gcpm] content() function doesn't allow formatting of values

On Fri, Jun 13, 2014 at 1:06 AM, Jirka Kosek <jirka@kosek.cz> wrote:
> On 12.6.2014 22:19, Tab Atkins Jr. wrote:
>> It sounds like this has nothing to do with content().  Your example
>> isn't even remotely doable with content(), since the content you're
>> trying to get at is an attr value; it'd need attr().
>
> Sorry, you are right. But given apart date formatting issue for now, I
> doubt that current draft allows even putting metadata into
> headers/footers. I can do something like:
>
> meta[name="DCTERMS.modified"] {
>   string-set: last-modified-date attr(content)
> }
>
> @page {
>    @top-center {
>      content: string(last-modifed-date)
>    }
> }
>
> But this shouldn't work as string-set is not working on elements which
> are not generating boxes (see 1.1.1.1: "The content values of named
> strings are assigned at the point when the content box of the element is
> first created (or would have been created if the element’s display value
> is none). The entry value for a page is the assignment in effect at the
> end of the previous page. The exit value for a page is the assignment in
> effect at the end of the current page.")

Ah, true.  Hmm, that limitation makes good sense, as in the content of
your document you dont' want hidden things to affect the string, and
display:none'd things dont' generally generate structures in the box
tree, and so don't get styles resolved for themselves.

But it's troublesome here.  We could maybe go meta and have a function
for retrieving document metadata specifically; some type of non-local
attr() for example.  But that would require some thinking.

> Then this is a serious limitation itself. It should be possible to put
> arbitrary content from the document into a header/footer. Is there any
> provision for using arbitrary selector inside content, something like:
>
> content: query(meta[name="DCTERMS.modified"]::attr(content))

Not yet, but nothing's really stopping us.

> That would help in many cases, but once more complex processing is
> required, selectors will not be enough: With XPath support one could write:
>
> content: xpath("//meta[@name='DCTERMS.modified']/@content/format-date(.,
> '[D]. [M]. [Y]')")
>
>> You're asking, it looks like, for a way for CSS to reformat a
>> date/time/number value into a specific localization format.  We've
>> discussed this before; Håkon had a proposal for an env() function and
>> some formatting options, which I thought he had in some draft, though
>> I can no longer find it.  I think it's a good idea; we'd have to
>> define how to parse text into the given abstract format (or lean on
>> some other part of the web platform that already does this parsing, to
>> be consistent), and then for the output I assume we'd follow the
>> example of the JS l10n API in terms of arguments and abilities.
>
> I think that respecing what is already done in XPath is regarding dates
> is lost time.

Browsers don't implement XPath 2.  Even if they did, bodging a second
query language into CSS just for a single use-case would be a
*terrible* thing to do to authors, especially when the query-language
part is actually completely irrelevant, and it's just the handful of
formatting functions that they actually want.

Note that I'm suggesting we use *another* existing standard, the ES
Localization/Internalization API, to inform our API design and provide
definitions of parsing/serialization; I'm not suggesting we invent our
own independent system.

> Also date/time/numbers are not only problem. Consider
> keywords stored as
>
> <keywords>
>  <keyword>A</keyword>
>  <keyword>B</keyword>
>  <keyword>C</keyword>
> </keywords>
>
> Now you want to display them as "A, B, C". This is doable with some
> fiddling using ::after and :last-child(). But when this should go to
> header/footer it's not longer possible. The question is whether this
> should be doable in sole CSS. But if the answer is yes, then we need
> much powerful machinery for generated content then current definition of
> content property allows.

That's more arbitrary content transformation, and even further beyond
what we've imagined so far.  While we could possibly address the
simplest of use-cases with something like this, we can't ever add
enough control to be satisfactory; at some point we must switch over
to letting JS handle it.

~TJ

Received on Friday, 13 June 2014 16:35:54 UTC