Re: [css-gcpm] String-set issues

> On Nov 22, 2014, at 4:11 PM, Liam R E Quin <liam@w3.org> wrote:
> 
> On Sat, 22 Nov 2014 10:18:43 -0800
> Brad Kemper <brad.kemper@gmail.com> wrote:
> 
>> I've been giving some attention named strings in the latest GCPM draft [1]. I have some issues and comments. I'll start with the things I think are problems, and then I'll propose how I'd like to see it improve.
> 
> 
> Brad, agree 100% that string-set is sucky. There are several problems I see, one of which is that we're supposed to be declarative and assignment sounds awfully procedural,

Yeah, agreed. 

> but a bigger one is that (as you point out) strings are not adequate.
> 
> Some quick comments....
> 
> There's a proposal in one of the GCPM drafts to be able to copy an element (right now you can only move it into the flow of another element using GCPM, which means you can end up with extra duplicate elements all over the place).

I think you are referring to running elements[1], which could also be completely replaced by my proposal. If someone actually wanted the element removed from the flow, then just use 'flow-into' instead of 'copy-into'. I dislike the idea of using position:running() for that.

I'll start a separate thread soon about footnotes, but so far I see them as fitting best as part of page templates, with something to get them to start in a slot of the page where their content appears.

> Basing content flows on the spec that defines content flows (regions) seems on the face of it very sensible and I agree we should explore it.
> 
> It's so common to need a mix of fixed strings, formatted strings and element content that the solution should make that easy -- e.g. consider page numbers like
>  003-14 14.2.1 The Section Title Here            [ short form of current lemma title ]
> where the chapter number is 2 digits, there's a fixed hyphen before the page number, and the running header contains MathML (or Japanese Ruby)...

I think this might be an argument in favor of being able to concatenate strings together in the places where all the values are available, instead of assigning them to separate names to concatenate later in the 'content' property (in other words, dismissing my problem #7). I was thinking about that and can see the value of that, actually. It still seems weird, and initially confusing, to have that stringing together step in two different places, but that might be better than having lots of extra names to hold the different parts. Maybe that step could be part of the 'copy-to' step (or 'flow-copy-into' or whatever).

> Rather than keywords (content, text, attribute...) maybe a function should use CSS selectors

I was considering something like that when I was jotting ideas down. It has the advantage of not needing an intermediary name to hold the value if you did something like 'content: get("h2:first-on-page", contents)', but it didn't seem quite as elegant to me as basing this on flow concepts. Especially in that I prefer to not keep resorting to functional notation if it can be avoided. And it felt wrong to use selectors in such a non-standard place instead of finding a way to use them in the usual place instead. The selectors might exist in the standard position somewhere in the style sheet already, and it it seems clunky to have to re-type them into a property value too.

It also seemed more likely that the author would need to type the same selector multiple times if he needed to get, say, the contents and a couple different counters from the same element. You solve that by concatenating inside the function, something like this: 'content: get("h3:first-on-page", counter(chapter) "." counter(section) "." counter(subsection) " " contents ", page " counter(page))'.


1) http://www.w3.org/TR/css3-gcpm/#running-elements