[css3-regions] region-overflow:nobreak

Alex Mogilevsky <alexmog <at> microsoft.com>
2012-02-01 00:47:16 GMT

Currently ‘region-overflow’ has two values – ‘auto’ and ‘break’, which technically are enough for what it defines.

However what if it had an explicit option of ‘nobreak’? It would do exactly what ‘auto’ does on last region but… it would also prevent that region from ever being linked. That may be useful when defining auto-sizing regions (which will
want to be either single-region flows or the last regions in flow)…

[css3-regions] spec notes

I have a few notes on the spec. Mostly editorial, if there are issues for discussion I’ll start separate threads.

2.3.
Regions flow breaking rules

… regions are a predefined set of recipient boxes for the named flow content.

[am] I think we are defining regions as a lower-level primitive, so
it is not correct to say that regions are “predefined”. Something like “dynamic generation of regions is out of scope of this specification” would be closer.

The edges of the first region in a region chain associated with a named flow establish the rectangle that is the initial containing block of the
named flow.

[am] I am not sure if this is related, but would this definition of
ICB have any effect on decisions about region stacking context (again excuse my ignorance on stacking context details)?

The first region defines the
writing mode for the entire flow. The writing mode on subsequent regions is ignored.

[am] Perhaps this should have some explanation, at least to understand
where it would make a difference. My understanding is that it affects default direction of overflow, scrollbar placement (if some UAs) and if named flow was an anonymous block containing flow nodes, that would be writing mode of that anonymous block. Am I
right? Is there a cleaner explanation of what it means?

Note 2

... However, the

table * {flow-into: table-content}

selector will move all the descendants of table elements in the ‘table-content’
named flow.

[am] perhaps this could show a more appropriate selector also. Maybe:

... However, the

table > * {flow-into: table-content}

selector will move all immediate children of all table elements into
the ‘table-content’
named flow (which will usually result in merging rows of multiple tables, may be useful), but

table * {flow-into: table-content}

will move all descendants of table elements into
the ‘table-content’
named flow, transforming element tree into a flat list in order of opening tags (which is probably not intentional).

[am] The spec already requires the UA to be smart enough to recognize
the recursion here. Why not break the recursion in a way that doesn’t drop the non-recursive content, or at least leave it undefined and see what gets implemented?

Example 3

In the following example, the inline content coming from the body_textnamed flow wraps around the #float box…

[am] I don’t think that example adds anything non-obvious at this point.
It probably did when it actually used exclusions, now it is just confusing – what is unusual about this example? Especially with no picture. I suggest removing the example.

4.3.
Region flow break properties

…Note that there is no region break in the last region associated with a named flow.

[am] That note is out of sync with ‘region-overflow’ property.

The behavior of region breaks with regards to regions is identical to the behavior of page breaks with regards to pages, as defined in the
[CSS21].

[am] I would expect this section to also define what how other break
types are interpreted in regions, and does even if they have no effect.

[am] For example, in a single-column region, does “break-inside:avoid-column”
have any effect? Or should region-specific values ever have effect when not in a region?

4.4.
The region-overflow property

[am] I think region styles should also support multicolumn properties.
Channing width will already affect number of columns, so for implementation it will make very little difference.

Region styling does not apply to nested regions

[am] I agree that is the right default. Will it be possible though?
It seems that if everything in a region is white on black, there should be a way to make nested regions also white on black.

[am] Are nested <at> region rules allowed?

6.
CSSOM view and CSS regions

Note 7

Since an element may be split into multiple regions, invoking
getClientRects on it
must return the list of rectangles for the element in all the regions it is part of.

[am] In what coordinate system are the rects? This question is related
to elementFromPoint() and other OM for layout results. This section needs to either define how coordinates in fragmented layout or (better) refer to [css3-breaks]. I’ll propose something to include here as part of elementFromPoint.

[am] how settled are we on names here? I think “content” instead of
“contentNode” and “getRegionsByContent” instead of “getRegionsByContentNode” would be more readable. And most DOM members don’t have “Node” in their names, even if they take or return nodes (e.g. Node.children, Node.appendChild, etc.)…

the region element's content overflows the region's
content box. Note that the region's
overflow property value can be used to control the visibility of the overflowing content.

[am] This is not how I define ‘overflow’, or how IE implementation
works. ‘overflow’ means that this region has content from the flow and it ends with a break. It doesn’t make sense to relate it to the old ‘overflow’ property: content can visually overflow for many reasons (e.g. because it is too wide), while the main purpose
of this property is to tell that there is more content for next region.

This means that the region is the last one in the region chain and not able to fit the remaining content from the
named flow.

[am] it is possible to define that ‘overflow’ can only be returned
for the last region, but then it would mean that the value for a given region will change while nothing is changing about the region itself.

[am] I propose this:
formatting of content in this region ended with a break. There is more content available for next region. Regions with “region-overflow:nobreak” or last region with “region-overflow:auto” will never return this value.

‘fit’

the region element's content fits into the region's
content box. It does not overflow. If the region is the last one in the region chain, it means that the content fits without overflowing. If the region is not the last one in the region chain,
that means the named flow content is further fitted in subsequent regions. In particular, in this last case, that means the region may have received no content from the
named flow (for example if the region is too small to accommodate any content).

[am] see above. Proposed text:
this region is not empty and formatting of contend was completed without a break (either because there is enough space or because “region-overflow” doesn’t allow content breaking in this region

‘empty’

the region element has no content and is empty. All content from the
named flow was fitted in regions with a lower document order.

[am] this is correct. Note:
it should be defined what happens when there is no content at all. I think all regions should be ‘empty’ if there is no flow with that name, but if there is a flow and it has no content the first region should be ‘fit’.

Re: [css3-regions] regions forming stacking contexts

Region is a viewport, anything visible within a region should behave the same way as if it was on screen scrolled to that point. There may be exceptions due
to really complicated cases but in general it should work the same, shouldn’t it?

No. The problem I referred to in my previous email occurs when different parts of an element are visible in two or more different regions at the same time. The semantics of 'opacity' and 'filter' (among other properties) on the element demand that the entire contents of the element be rendered as a unit, which will be impossible if the regions are in different stacking contexts.

There is no analogous issue with viewports since an element can't appear simultaneously in multiple viewports.

Rob

-- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]

Re: FW: [css3-flexbox] flex distribution

On Mon, Jan 30, 2012 at 9:49 PM, Alex Mogilevsky <alexmog <at> microsoft.com> wrote:
> I wonder if there will be cases when at different iterations free space will
> change sign. I think it is possible, and it can be nasty.
>
Indeed, your algorithm in the way it is explained tends to oscillate I
think (didn't do excessive
analysis though).
It should look like this:
0. Let TOTAL_FLEXES be a sum of all flexes. Let TOTAL_SPACE be an
available space.
Let SET be a list of flexible items.
1. From all flexible items in the SET reset sizes to their preferred value.
2. If either
a. TOTAL_SPACE is zero or
b. TOTAL_FLEXES is zero or
c. SET is empty.
we are done - exit.
3. Find free space by subtracting sum of item sizes from available space.
4. Distribute free space proportional to flex.
5. Fix min/max violations:
a. If size of flex item is less than min value set the size
to that min value and
exclude (subtract) flex value of the item from
TOTAL_FLEXES and the size from
TOTAL_SPACE. Exclude the item from the SET. Go to step 1.
b. If size of flex item is greater than max value set the
size to that max value and
exclude (subtract) flex value of the item from
TOTAL_FLEXES and the size from
TOTAL_SPACE. Exclude the item from the SET. Go to step 1.
By its nature this algorithm will do max of sizeof(SET) iterations so is stable.
One of possible implementations is here:
http://www.terrainformatica.com/w3/flex-layout/spring-engine.h--
--
Andrew Fedoniouk.
http://terrainformatica.com

Three UAs retain the original cssText, excepting Safari which translates to the longhand properties only. Three UAs also report 4 items, including those that return only one shorthand property in cssText.

There are clearly some interoperability requirements here that need to be resolved in both CSSOM and in the UAs.

Re: [css3-values] RE: CSSStyleDeclaration#length and shorthands.

Boris Zbarsky <bzbarsky <at> MIT.EDU>
2012-02-01 04:49:17 GMT

On 1/31/12 11:40 PM, Glenn Adams wrote:
> Three UAs retain the original cssText, excepting Safari which translates
> to the longhand properties only.
Your test doesn't show that, actually. What it _does_ show is that at
least three UAs try to produce shorthands in cssText.
I know for a fact that Gecko does NOT retain the original cssText here.
It stores longhands internally, and tries to produce the shortest text
representation it can for cssText.
The only way to tell what UAs are really doing here is to try multiple
different values of the original cssText and see what happens to it. In
addition to the shorthand you tried, you should also try
"border-top-width: 2px; border-right-width: 4px; border-bottom-width:
2px; border-left-width: 4px" (which won't change the output in gecko and
WebKit; not sure about the others), and perhaps things like
"border-width: 3px 4px; border-bottom-width: 2px; border-top-width: 2px"
and so forth....
> Three UAs also report 4 items, including those that return only one shorthand property in cssText.
The only reason Gecko reports more than 4 is that our implementation of
border-start and border-end involves a few extra longhand properties
dealing with border widths, and the border-width shorthand sets those
additional longhand properties.
> There are clearly some interoperability requirements here that need to
> be resolved in both CSSOM and in the UAs.
Yep.
-Boris

non-support of using surrogate pairs in CSS escapes [I18N-ACTION-90] [I18N-ISSUE-147]

Phillips, Addison <addison <at> lab126.com>
2012-02-01 05:00:06 GMT

Dear CSS WG,
I am writing to you on behalf of the I18N Core WG. During a recent teleconference [1] I was actioned with
responding to a recent thread on your mailing list [2].
Here's a quote of much of that email:
--
WebKit browsers don’t support this syntax for characters outside the
BMP: https://bugs.webkit.org/show_bug.cgi?id=76152 ...
There seems to be another way to escape these characters, namely by
breaking them up in UTF-16 code units: `\d834\df06 `. All browsers
except Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=717529)
seem to support this, even though this isn’t mentioned in the spec.
Should the spec be changed to reflect reality?
--
The Internationalization Core WG strongly opposes making such a change to the CSS spec. The Character
Model [3] in requirement C045 requires that escape sequences be related to Unicode code point values, not
to the code unit values used in some specific Unicode encoding (such as UTF-16). It is a barrier to content
authors to have to convert escapes into UTF-16 surrogate pair sequences: it obfuscates the stylesheet,
introduces additional processing complexity, and adds no value to support this syntax. Instead,
user-agents should be encouraged to better meet the specification.
Regards (for I18N),
Addison
[1] http://www.w3.org/2012/01/25-i18n-minutes.html#item05
[2] http://lists.w3.org/Archives/Public/www-style/2012Jan/0536.html
[3] http://www.w3.org/TR/charmod/#sec-Escaping
Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)
Internationalization is not a feature.
It is an architecture.

Mailing list traffic

Bjoern Hoehrmann <derhoermi <at> gmx.net>
2012-02-01 05:16:47 GMT

Hi,
January 2012 was the busiest month of all time for www-style according
to the archives, with over a quarter more mails than the previous
record. I am used to this amount of traffic and it might be an
exception, but the Working Group should probably start making plans
splitting the list if the traffic levels sustain (such as splitting it
into a "static" and a "dynamic" portion, where the latter would discuss
APIs and animations while the former discusses the rest, as an example).
regards,
--
--
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Re: [css3-values] RE: CSSStyleDeclaration#length and shorthands.

Three UAs retain the original cssText, excepting Safari which translates
to the longhand properties only.

Your test doesn't show that, actually. What it _does_ show is that at least three UAs try to produce shorthands in cssText.

I know for a fact that Gecko does NOT retain the original cssText here. It stores longhands internally, and tries to produce the shortest text representation it can for cssText.

"retain" here simply means that the output is equal to the input; it matters not what internal transformation occurs;

The only way to tell what UAs are really doing here is to try multiple different values of the original cssText and see what happens to it. In addition to the shorthand you tried, you should also try "border-top-width: 2px; border-right-width: 4px; border-bottom-width: 2px; border-left-width: 4px" (which won't change the output in gecko and WebKit; not sure about the others), and perhaps things like "border-width: 3px 4px; border-bottom-width: 2px; border-top-width: 2px" and so forth....

i'm not trying to tell what UAs are "really doing" under the covers, just try a simple example to see what variations hold from a black box perspective

Three UAs also report 4 items, including those that return only one shorthand property in cssText.

The only reason Gecko reports more than 4 is that our implementation of border-start and border-end involves a few extra longhand properties dealing with border widths, and the border-width shorthand sets those additional longhand properties.

ok; it is clear that neither DOM2 Style nor CSSOM make clear what is intended to be reported via length/item(); however, one does wonder about the language in DOM2 Style

Used to retrieve the properties that have been explicitly set in this declaration block. The order of the properties retrieved using this method does not have to be the order in which they were set. This method can be used to iterate over all properties in this declaration block.