- From: Jon Rimmer <jon.rimmer@gmail.com>
- Date: Sun, 27 Oct 2013 11:20:57 +0000
- To: Håkon Wium Lie <howcome@opera.com>
- Cc: www-style list <www-style@w3.org>
- Message-ID: <CA+ZDCiCeG44555zHFY-c2hhqxMSEKjzam+2tVZTPoRxnSiuowg@mail.gmail.com>
On 26 October 2013 19:11, Håkon Wium Lie <howcome@opera.com> wrote: > Jon Rimmer wrote: > > > I'd like to propose a text() function that returns an element's > inner-text, > > similarly to how attr() returns the value of an attribute. > > Note that there already is a functional notation for getting the > textual content: > > http://www.w3.org/TR/css3-gcpm/#setting-named-strings-the-string-set-pro > http://books.spec.whatwg.org/#named-strings > > The use until now has been for running headers and footers. > Ah, interesting. From reading the spec, it seems the strings are always scoped to the page? So this wouldn't meet the use case unless it was extended to allow more precise control of the scope. I noticed the obsolete Generated Content L3 spec also proposed a 'contents' value for the content property[1], that can make a pseudo render the element's descendants, but it explicitly disallows duplication. It seems like the GCPM spec is a robust effort aimed at printed media requirements, but is also probably some way off completion and widespread implementation. My thought with text() was that it solves this use-case without requiring much additional complexity, particularly if it was limited only to use with the content property. Most user agents already provide innerText/textContent properties on DOM nodes, so there is code available, and its behaviour is understood by authors. [1] http://dev.w3.org/csswg/css-content/#inserting-and-replacing-content-with-the Thanks, Jon
Received on Sunday, 27 October 2013 11:21:24 UTC