- 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>
> -----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. Thanks, Rossen
Received on Thursday, 12 December 2013 19:58:11 UTC