W3C home > Mailing lists > Public > www-style@w3.org > October 2011

[css3-gcpm] Named strings: place of assignment

From: Peter Moulder <peter.moulder@monash.edu>
Date: Fri, 07 Oct 2011 16:07:12 +1100
To: www-style@w3.org
Message-id: <20111007050712.GA25364@bowman.infotech.monash.edu.au>
The current [2011-09-23 editor's draft] css3-gcpm text uses the phrases
"entry/exit value for that page", "no assignment on the page" and so on
without defining them.

Some cases where the answer might be either unclear or surprising are
when a named string is set both by an element and a child of that
element, or when an element is split (over multiple pages, or multiple
lines, or split for bidi), or when an element is floated or absolutely
positioned to past where another element sets the same named string.

(For example, if an element is split over pages then is the string
considered to be set on all of those pages or just one of them, and if
just one then first or last page?)

For block-level elements, is the page of assignment based on the border
box or content box?  (I'd say probably not the padding box or the
outer/margin box.  I think I'd go with content box as the best
behaviour, if it is based on one of these boxes.)

I believe the main use case for named strings is where string-set is set
for a heading element (h1 etc.).  A closely related use case mentioned in
the spec is where the "heading" element is a <dt> in a glossary, or each
item in a list of words or names.

Perhaps the most common case for the string-set element to be split over
pages would be the glossary case.  I think in that case I'd want the
"last" item on the first page of that element to include that split
element, so I think I'd want it to be considered assigned on the first
page where the element occurs whether or not it's also considered
assigned on any other pages.  With (even) less conviction, I'd also tend
to think that it shouldn't be considered assigned on any other pages.

It's rare to make headings out of flow (perhaps floated for run-in
effect?), and if out of flow then it's rare for placeholder to differ
(in order or page) from rendered position;
but if I had to pick then I'd say by placeholder.

(In the case of abspos elements, picking the placeholder is based on the
assumption that the element is usually positioned near the static
position.  The behaviour is rather questionable if that's not the case,
but on the other hand I'm not sure that we get a reasonable ordering if
we try to go by rendered position of abspos boxes.)

If the same named string were ever assigned by both an ancestor and a
descendant, then I suppose it would be where it was set on a
<section>-like element rather than a heading-like element, in which case
the most likely wanted behaviour would be the scoped behaviour of
counters (so that the sub-sections value doesn't apply after the end of
the sub-section).  However, I would expect this to be a rare case, and I
would expect this to be disproportionally costly to implement (and
specify and test).

For the bidi rearrangement case, the obvious behaviour to want when it
makes a difference would be based on logical (in-source-document) order.
However, I expect that it's extremely rare for it to make a difference,
so the answer could be decided by consistency with other answers we
decide on.

Based on the above considerations, the tentative suggestion would be
that the assignment is considered to occur in exactly one place for an
element, namely at the start of that element, and based on content box;
or the location of the placeholder in the case of out-of-flow elements
(including display:none, assuming the currently specified behaviour of
string-set continuing to apply despite display:none).

The behaviour for bidi would be based on logical (i.e. in-source-document)
order, which happens to be a conceptual match for the choice of placing
out-of-flow things according to their placeholder (source location)
rather than visual position.

Are there any other use cases to consider?  (In particular, use cases
where any of these issues make a difference more often?)

Received on Friday, 7 October 2011 05:07:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:58 UTC