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

Re: [css-gcpm] String-set issues

From: Brad Kemper <brad.kemper@gmail.com>
Date: Mon, 24 Nov 2014 08:47:08 -0800
Message-Id: <B337DF8B-40B0-4CE9-A618-18573C4C9539@gmail.com>
Cc: Liam R E Quin <liam@w3.org>, www-style list <www-style@w3.org>, Dave Cramer <Dave.Cramer@hbgusa.com>
To: Jirka Kosek <jirka@kosek.cz>
On Nov 24, 2014, at 7:23 AM, Jirka Kosek <jirka@kosek.cz> wrote:

>> On 24.11.2014 16:14, Brad Kemper wrote:
>> OK. Did you think my 'copy-to' proposal on Saturday helped with that? I had ways to target a selected element's text, or the entire element, or all its child nodes, or an attribute or counter, for inclusion in 'content'. Is that still not expressive enough?
> No, in some use cases you must do more complex processing before
> displaying some value found in document -- for example format date
> stored in metadata element/attributed in the format YYYY-MM-DD has to be
> formatted in locale dependant way. Sensible way to do this is to apply
> yet to be introduced format-date() function to a value extracted by
> selector.

My proposal would not prevent a format-date() feature from being added to an item inside the 'content' value.

> Your proposal decouples reading of value, it's possible processing (e.g.
> date formatting) and outputting -- which is unnecessary complex.

A certain amount of that decoupling already exists in the existing and previous drafts. 

But, if I understand you correctly, the part you are objecting to is that I am saying all the concatenation should happen within 'content', instead of having some of it inside 'content' and some at the place where the information is read. This was to address what I identified as problem #7. 

However, I am leaning back towards your point of view, now that I see how many names it has to create in order to string them together at 'content' assembly time. I think this can still work with the rest of my proposal if I replace <content-level> with a space-separated <content-list> of the same values, plus literal text. Instead of assigning each value to a separate name, you could string several together, along with text (dashes, colons, spaces, or whatever, as separators mostly). Would that address your concerns? It makes the reading step more complex to learn, but makes the whole thing overall simpler to use.
Received on Monday, 24 November 2014 16:47:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:26 UTC