W3C home > Mailing lists > Public > www-style@w3.org > December 2013

RE: [css3-break] Editorial comments

From: Rossen Atanassov <Rossen.Atanassov@microsoft.com>
Date: Thu, 12 Dec 2013 19:57:42 +0000
To: Mihai Balan <mibalan@adobe.com>, "WWW Style (www-style@w3.org)" <www-style@w3.org>
Message-ID: <3e64915eb3304272b13d5b3dfd64f184@BY2PR03MB192.namprd03.prod.outlook.com>
> -----Original Message-----
> From: Mihai Balan [mailto:mibalan@adobe.com]
> Sent: Wednesday, December 4, 2013 5:46 AM
> Also, I feel a clarification is needed about what does "truncation" means in
> the context of section 5.2 Margins at breaks[1]. I've talked to multiple people
> and they seemed to be equally divided on two possible interpretation of
> what "truncate" means:
>   1. effectively set to 0 (similar to the truncate() C function for files :) )
>   2. trim it to whatever length there is between the content edge of the
> content and the content(?) edge of the fragmentation container.

That's a good point and I have clarified it. By truncation we meant that the used value of the margins become that of the remaining fragmentainer extent (this maps to your option 2 above). Why? Because it is a testable behavior - if we set them at zero and there is an inline auto-positioned abs pos element it will fit if the margins were truncated to 0 and pushed to the next fragment otherwise (which is the behavior the spec defines).

> - in section 2 of the spec, the _fragmented flow_ is defined in terms of a
> _fragmenation root_ - notice the missing _t_ in _fragmenation_
> - in in section 3.3, in the second to last paragraph, in the second paragraph
> describing the allowed values for `orphans` and `widows`, an _and_ is missing
> after _are invalid_
> - when describing the behavior for line breaking, at times CSS 2.1 is
> mentioned and sometimes CSS3TEXT is. I couldn't find an exact reason why
> that is and I think it would be better to be consistent

Thanks, these are now fixed.

Received on Thursday, 12 December 2013 19:58:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:37 UTC