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

Re: [css-gcpm] Example 3 in string()

From: Cramer, Dave <Dave.Cramer@hbgusa.com>
Date: Thu, 13 Feb 2014 11:39:56 -0500
To: Alan Stearns <stearns@adobe.com>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <CF212A99.4734C%david.cramer@hbgusa.com>
On 2/11/14 7:37 PM, "Alan Stearns" <stearns@adobe.com> wrote:


>On 2/10/14, 7:33 PM, "Cramer, Dave" <Dave.Cramer@hbgusa.com> wrote:
>>
>>I've reworked the example based on your feedback. The name of the string
>>is now "heading". I've changed the text of the first caption to make this
>>a bit more clear, and I've also labelled the h1 and h2 elements in the
>>figures themselves.
>>
>>Do you think this helps? It's tricky enough that when I first started
>>writing tests for this feature, I discovered a bug in one of the
>>implementations.
>
>Yes, those changes helped.
>
>I have some further questions on first/start and fragmentation. Lets
>suppose we have two elements populating a string set - element A which is
>fragmented across the boundary between page 1 and page 2, and element B
>that appears on page 2. My reading of string-set assignments says that
>since the element A assignment occurs only on page 1, youıll get the
>contents of element B with string() using Œfirstı and the contents of
>element A with string() using Œstartı. Is that the intended behavior?
>

Yes. In dictionaries and other reference works, it's common for a running
head to reflect the first *whole* entry on a page. "First" lets you do
that, while "start" lets you use whatever value is in effect at the
beginning of the page.

I'll add some language about what happens if the element used for the
assignment is fragmented across the page boundary.

Thanks!

Dave


This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.
Received on Thursday, 13 February 2014 16:40:25 UTC

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