Re: [css-gcpm] String-set issues

On Sat, Nov 22, 2014 at 1:18 PM, Brad Kemper <brad.kemper@gmail.com> wrote:

> Regarding the first point above, I think in some ways, 'string-set' is
> similar to 'flow-into', especially if we axe the concatenation stuff of #7
> above. They both use the similar 'content' or 'contents' keywords to create
> a variable-like name to hold the original contents of the element. I think
> we can play off that, using that as mental equity for changing the name and
> syntax of 'string-set'. So, instead of 'string-set', I propose the
> following:
>
> Name:   copy-into
> Value:  none |  [ [ <custom-ident>  <content-level>] [,  <custom-ident>
> <content-level>]*  ]?
> Initial:        none
> Applies to:     All elements, but not ::first-line or ::first-letter.
> Inherited:      no
>
> The 'copy-into' property contains one or more pairs, each consisting of an
> custom identifier (the name of the named string) followed by a content-level
> keyword describing how to construct the value of the named string.

I like this. I want to think more about the benefits and/or drawbacks
of separating this from flow-into.

>
> <ident> = The element or its contents, or its text, or the value of a
> specified attribute or counter is copied and placed into an non-rendered
> content fragment with the name '<ident>'. The values none, inherit, default,
> auto and initial are invalid content fragment names.
>
> <content-level> expands to one of the following values:
> element|contents|text|attr(<identifier>)|<counters>
>
> element
> the entire element is copied into the named content fragment (i'm using
> 'named content fragment' to mean the same thing as a named flow, but not
> intended to be flowed through multiple elements).
>
> contents
> only the element’s contents are copied into the named content fragment. This
> is the default if <content-level> is not specified.
>
> text
> only the element’s text (including normally collapsed white space) is copied
> into the named content fragment.
>
> attr(<identifier>)
> the string value of the attribute <identifier> is copied into the named
> content fragment
>
> <counters>
> the value of a counter() function, as described in [CSS21] is copied into
> the named content fragment.
> -----------------------------
>
> So basically, it is the same as "flow-into", except that it does not remove
> anything, just a copy, and it has some other choices besides just "content"
> and "element" (I would also change "content" to "contents" in Regions).
> Plus, it can list several different names to copy stuff into, e.g. like
> this: 'copy-into: myContents contents, chapNum counter(chapter)'. And it has
> 'contents' as the default if one of the other levels is not specified
> instead.

I'm not sure I fully understand this bit:

h1 { copy-into: myContents contents, chapNum counter(chapter) }

What's the advantage of assigning the counter to a named content
fragment here? That's something that's not related to the element.

@top-center { content 'Chapter' chapNum ': ' myContents }

could be written as

@top-center { content 'Chapter' counter(chapter) ': ' myContents }

I think it might be conceptually simpler to use copy-into solely to
get the content of the element, given that the content property
already gives us access to counters, attributes, and literal text.

>
> By default, the content fragment name would be global, as the named flow is
> with 'flow-into'. But if one of the following pseudo-classes are used on the
> subject of the selector, then the name is locally scoped to just the page
> the element is on.
>
> :nth-of-page(n)    The element is the nth matched element on the page.
> :first-of-page       Same as :nth-of-page(n), but where n = 1 (it is the
> first matched element on the page).
> :last-of-page       The element is the last matched element on the page.
> :start-of-page      The element is the first matched element on the page,
> and neither it nor its ancestors have any previous siblings that appear on
> the page.
>
> The content property would be able to accept the named content fragment as
> one of its value parts, just by using the identifier. It would not be part
> of a region chain, unless the whole element containing the named content
> fragment had "flow-into" something else.
>

So in a relatively common case, using a first/start value on the left
page, and a last value on the right page, you'd have

h1:first-of-page { copy-into: chapter-title-left }

h1:last-of-page { copy-into: chapter-title-right }

@page:left {
  @top-left {
    content: chapter-title-left;
    }
}

@page:right {
  @top-right {
    content: chapter-title-right;
    }
}

It bothers me a bit that you have to create two distinct named content
fragments in order to do this. I think there are some advantages to a
syntax closer to what string() does today:

h1 { copy-into: chapter-title }

@page:left {
  @top-left {
    content: copy-from(chapter-title, first);
    }
}

@page:right {
  @top-right {
    content: copy-from(chapter-title, last);
    }
}

But then I also want page-position selectors for entirely unrelated reasons :)

Regards,

Dave

Received on Tuesday, 25 November 2014 18:08:22 UTC