Re: [css3-gcpm] Running elements

> On Oct 2, 2013, at 10:47 AM, Alan Stearns <stearns@adobe.com> wrote:
> 
>> On 10/2/13 8:39 AM, "Cramer, Dave" <Dave.Cramer@hbgusa.com> wrote:
>> 
>> On 9/26/13 12:09 PM, "Brad Kemper" <brad.kemper@gmail.com> wrote:
>> 
>> 
>>>> On Sep 25, 2013, at 11:58 AM, Håkon Wium Lie <howcome@opera.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> title { position: running(header), normal }
>>>> @page { @top-center {
>>>>   content: element(header) }
>>>> }
>>>> 
>>>> I'm happy to resurrect the feature, though -- it's very useful.
>>>> Changing 'position' to take a comma-separated list is a big deal and
>>>> there may be better ways to achieve the same.
>>> 
>>> It feels kind of strange to me to be using the 'position' property to get
>>> running headers. I think it would be more natural to extend the
>>> properties used for regions, which already do a lot of similar things.
>>> So, for instance, if the element is to be moved, not copied, then
>>> something like this:
>>> 
>>> title { flow-into: header running }
>>> @page { @top-center {
>>>  flow-from: header;
>>>  }
>>> }
>>> 
>>> Thus the "running" keyword would mean that the flow repeats on each page
>>> (like a header or footer) instead of flowing from page to page (like
>>> footnotes might), and that anything else with 'flow-into: header' (with
>>> or without the "running" keyword) would replace the existing 'header'
>>> flow. You could also add your 'element()' second arguments to
>>> 'flow-from', like this:
>>> 
>>>  flow-from: header first-except;
>>> 
>>> Those second arguments could be useful even if it wasn't a running flow.
>>> 
>>> Then, for Dave's use case, where the element is to be copied, not moved,
>>> we'd use a 'running-copy' keyword, instead of just 'running':
>>> 
>>> title { flow-into: header running-copy }
>>> 
>>> This to me feels right. It leverages what people would already know about
>>> flow-into and flow-from, styling with @region or ::region(), etc.
>>> 
>>> I'd like to use '::before' on the margin boxes, to pick up some of the
>>> string content ideas (note that the regions draft already allows the
>>> 'content' keyword in the 'flow-into' value):
>>> 
>>> title {
>>> flow-into: HEADER content running;
>>> counter-increment: header;
>>> }
>>> @page { @top-center {
>>>  flow-from: HEADER;
>>>  }
>>> @top-center::before {
>>>  content: "Chapter " counter(header) ": ";
>>>  }
>>> }
>>> 
>>> This feels simpler and easier, and more consistent with region syntax,
>>> than the current or past gcpm equivalents.
>> 
>> That makes sense to me. And Prince is already using the idea of "flow" to
>> move content into margin boxes; I hope they'll update this to use the
>> regions syntax (plus the ability to copy a flow).
> 
> I agree as well. Using flow-into and flow-from make a lot of sense here.
> But I think we should discuss whether running headers are best served by
> making a copy of the flow, or by defining fragment containers that display
> but do not consume a fragment of flow content, as I've suggested before
> [1].
> 
> Thanks,
> 
> Alan
> 
> [1] http://lists.w3.org/Archives/Public/www-style/2013Jan/0172.html

That would be OK, but it seems like it would be less efficient for the browser. Like, wouldn't the software want to know at the flow-from stage whether or not it needed to remove all it's content? I image the steps might be something like this:

1. Element (#A) has 'flow-from', so it's content (or element box) is removed and put into a named buffer.
2. Another element (#B) has 'flow-from' of the same name, so it empties itself and pulls from the buffer for its content.
3. Element #B sees that it is supposed to persist the original source(s) of the flow, so it goes back and re-inserts content into #A, which then might affect the position or page of #B.

Maybe I have it wrong, but that third step doesn't seem great. 

Also, the thing with 'flow-from' would just disappear if the thing with with 'flow-from' didn't exist in that particular document/chapter. Thus, if you wanted to use an H3 as part of your footer, but the footer didn't occur on every page, you wouldn't want all H3s to disappear from pages that didn't have footers. 

Also, I think it is important that when using content like the H3, that the flow-from is getting the latest assignment of content only, on not just grabbing every H3 and adding it to the same flow. That seems like it would be simpler when at the flow creation stage.

Received on Thursday, 3 October 2013 15:07:44 UTC