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

On Jun 16, 2014 7:20 AM, "Jirka Kosek" <jirka@kosek.cz> wrote:
>
> On 13.6.2014 18:35, Tab Atkins Jr. wrote:
> > 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.
>
> I think that developing something special for meta elements doesn't make
> sense. You can have similar info stored in microdata markup or something
> else, so generic approach for pulling content from arbitrary element or
> attribute should be available.

I said "go meta", not " go <meta>". ^_^  I meant a function for generalized
document metadata.

> >> 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.
>
> ES I18N API uses object for passing parameters which will make it very
> hard to combine this with CSS syntax. XPath date function use just
strings.

Right, the input part is different, but we can align the output definition.

Let me be clearer, though: there is no way we'd add XQuery to CSS. It's a
redundant query language that browser's are not interested in. Following
its *model* for something is possible, but I think it's far more useful to
align with JS APIs, as authors in general are far more likely to be
familiar with JS stuff.

~TJ