Alex Mogilevsky | 1 Feb 01:47 2012
Picon

[css3-regions] region-overflow:nobreak

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)…

Alex Mogilevsky | 1 Feb 03:46 2012
Picon

[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.

4.1. The ‘flow-into’ property

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] …(just a suggestion, the example is OK as is).

4.2. The ‘flow-from’ property

…if the element is part of the flow with name <ident>, then the element does not format any content visually.

[am] It seems this rule is protecting from recursive flows, but it also disallows some interesting uses, such as drop caps:

.story { flow-into:story; }

.dropcap { width:5em; height:5em; flow-from:story; }

<at> region .dropcap { font-size:500%; /*define wrap shape from text outline*/}

<div class=story>

  <div class=dropcap></div>

  Once upon a time...

</div>

[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_text named 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

Value: auto | break

[am] maybe also ‘nobreak’ value to explicitly create single-region flows? (see separate email)

4.5. The <at> region rule

[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.

interface NamedFlow {

  readonly attribute boolean overflow;

  readonly attribute NodeList contentNodes;

  NodeList getRegionsByContentNode(Node node);

  };

};

[am] there is an extra closing brace

[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.)…

6.2. Extension to the Element interface

The regionOverflow attribute can take one of the following values:

[am] can *have* … values?

overflow

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’.

undefined

The element is not a region.

--Alex

 

Robert O'Callahan | 1 Feb 04:05 2012

Re: [css3-regions] regions forming stacking contexts

On Sat, Jan 7, 2012 at 1:16 AM, Alex Mogilevsky <alexmog <at> microsoft.com> wrote:

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]
Andrew Fedoniouk | 1 Feb 04:48 2012

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

Glenn Adams | 1 Feb 05:40 2012

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

Testing the following sample:


<script>
function getItems(d) { var items = ""; for (i=0;i<d.length;i++) { items += " " + d.item(i); }; return items; }
function onLoad() { var e = document.getElementsByTagName("div")[0]; alert("cssText: {"+e.style.cssText+"},\nlength: "+e.style.length+",\nitems:"+getItems(e.style)); }
</script>
<body onload="onLoad();"><div style="border-width: 2px 4px"/></body>

yields three different results on 4 UAs, IE and Opera being the same:

Safari 5.1.2:
cssText: {border-top-width: 2px; border-right-width: 4px; border-bottom-width: 2px; border-left-width: 4px; },
length: 4,
items: border-top-width border-right-width border-bottom-width border-left-width

Opera 11.60:
cssText: {border-width: 2px 4px},
length: 4,
items: border-top-width border-right-width border-bottom-width border-left-width
 
IE 9.0.8112: (with <meta http-equiv="X-UA-Compatible" content="IE=9"/>)
cssText: {border-width: 2px 4px; },
length: 4,
items: border-top-width border-right-width border-bottom-width border-left-width
 
Firefox 9.0.1: 
cssText: {border-width: 2px 4px;},
length: 8,
items: border-top-width border-right-width-value border-bottom-width border-left-width-value border-left-width-ltr-source border-left-width-rtl-source border-right-width-ltr-source border-right-width-rtl-source

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.

Boris Zbarsky | 1 Feb 05:49 2012
Picon

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

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

Phillips, Addison | 1 Feb 06:00 2012

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

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.


Bjoern Hoehrmann | 1 Feb 06:16 2012
Picon
Picon

Mailing list traffic

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/ 

Bjoern Hoehrmann | 1 Feb 06:20 2012
Picon
Picon

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

* Phillips, Addison wrote:
>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.

(I mostly agree with this.)
--

-- 
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/ 

Glenn Adams | 1 Feb 07:13 2012

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



On Tue, Jan 31, 2012 at 9:49 PM, Boris Zbarsky <bzbarsky <at> mit.edu> wrote:
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.

"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

item
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.

combined with the language that

cssText of type DOMString The parsable textual representation of the declaration block (excluding the surrounding curly braces).
 
a more simple reading would be that length/item() should correspond only to those declarations present in the value of cssText, since both ostensibly represent "the declaration block"

it would be nice if we could dredge up what was intended by the phrase "explicitly set" in the above; the text doesn't elaborate, so it is anyone's guess at this point

Gmane