headers
Boris Zbarsky | 1 Jun 2010 04:52
Picon
Favicon

Re: [css3-text-layout] New editor's draft - margin-before/after/start/end etc.

On 5/31/10 5:35 PM, Håkon Wium Lie wrote:
> So, you are not storing separate values for *-start/end, nor do you
> remember whether the physical values come from *-start/end or not?

In Mozilla's case, specified values are stored separately for 
*-start/end and *-left/right.  However, nly *-left/right have computed 
values and where that computed value came from is not stored.  An 
"inherit" specified value for *-start/end inherits either *-left or 
*-right from the parent depending on the directionality of the _child_.

-Boris
Permalink | Reply | 0 comments |
headers
Andrew Fedoniouk | 1 Jun 2010 05:26
Favicon

Re: [css3-flex] calc(flex) and concept of free space.


--------------------------------------------------
From: "Brad Kemper" <brad.kemper <at> gmail.com>
Sent: Monday, May 31, 2010 10:30 AM
To: "Andrew Fedoniouk" <news <at> terrainformatica.com>
Cc: "Tab Atkins Jr." <jackalmage <at> gmail.com>; "Zack Weinberg" 
<zweinberg <at> mozilla.com>; <www-style <at> w3.org>
Subject: Re: [css3-flex] calc(flex) and concept of free space.

>
> On May 30, 2010, at 8:00 PM, Andrew Fedoniouk wrote:
>
>> Anyway, tell me better what would be the width of inner div here:
>>
>> <div width:1000px padding-left:1fx>
>>   <div width:calc(500px + 1fx) />
>> </div>
>>
>> Something tells me it will get zero, correct?
>
> The flex units are based on distributing the space of the children of 
> flexboxes. So, even if these two DIVs had flexbox parents, they are two 
> different generations, and the flex of one distributes space from a 
> different pool than the other. So, the '1fx' of the outer DIV depends on 
> how much space is available in its parent flexbox (if that is a 1000px, 
> based on your other examples, then the padding would be 0). The 1fx on the 
> inner DIV is meaningless unless the outer one is 'display:flexbox', 
> otherwise it is distributing a 500px (1000 - 500) to itself.
>
>
(Continue reading)

Permalink | Reply | 10 comments |
headers
L. David Baron | 1 Jun 2010 05:28
Gravatar

Logical property *values* (Re: [css3-text-layout] New editor's draft - margin-before/after/start/end etc.)

On Wednesday 2010-04-28 19:57 +0900, MURAKAMI Shinyu wrote:
> CSS Text Layout Module Level 3
> Editor's Draft 25 April 2010
> http://dev.w3.org/csswg/css3-text-layout/

> - Logical property values: before, after, start, end

The section on logical property values says that the logical values
are added to four properties:  'float', 'clear',
'background-position', and 'text-align'.

I think the draft should really discuss these properties in two
separate groups.

In the first group, 'float', 'clear', and 'text-align', the only
values that make sense are those equivalent to 'start' and 'end'.
So the draft should propose adding 'start' and 'end' values, but
should also say what the 'left' and 'right' values do when block
progression is horizontal.  (Though there have been various
proposals for additional values of float that might get in the way
here.)

The 'background-position' property is rather different from the
others, since it supports all directions, and its syntax has a
significant number of other constraints.  (The 'transform-origin'
property in 2-D transforms (but not 3-D) also has the same syntax.)
A draft proposing to modify 'background-position' should define the
interpretation of the values, and which values are allowed.  (For
example, it should say that 'top start' is a syntax error, even
though it makes sense in lr-tb or rl-tb writing modes.  Likewise, it
(Continue reading)

Permalink | Reply | 3 comments |
headers
L. David Baron | 1 Jun 2010 05:47
Gravatar

Re: [css3-text-layout] New editor's draft - margin-before/after/start/end etc.

On Thursday 2010-05-27 09:29 +0900, MURAKAMI Shinyu wrote:
> Boris Zbarsky <bzbarsky <at> MIT.EDU> wrote on 2010/05/27 4:32:35
> > In mozilla's implementation, *-start and *-end are effectively converted 
> > into *-left and *-right as needed when determining computed values. 
> > There is no separate computed value for *-start and *-end.  A specified 
> > value like "*-start: inherit" in treated as either "*-left: inherit" or 
> > "*-right: inherit" depending on the directionality of the thing doing 
> > the inheriting.  But the value inherited will obviously depend on the 
> > directionality of the parent, if the parent itself had a "*-start" 
> > specified.
> > 
> > All of which sounds similar to what you describe for webkit.
> 
> All of which sounds similar to what I want :-)
> 
> I don't want separate computed values for logical and physical
> properties. See:
> 
> http://dev.w3.org/csswg/css3-text-layout/#logical-prop
> | The computed value of a logical property affects the computed value 
> | of the corresponding physical property, and vice versa.

This is slightly different from what Boris describes (that is, what
Mozilla implements), where the logical properties do not have a
computed value (so it does not make sense to talk about "the
computed value of a logical property").

I'd also note that there are two different proposals for how the
cascading of logical + physical properties should work.  My original
proposal was:
(Continue reading)

Permalink | Reply | 30 comments |
headers
Andrew Fedoniouk | 1 Jun 2010 06:21
Favicon

Re: [css3-text-layout] New editor's draft - margin-before/after/start/end etc.


--------------------------------------------------
From: "L. David Baron" <dbaron <at> dbaron.org>
Sent: Monday, May 31, 2010 8:47 PM
To: "MURAKAMI Shinyu" <murakami <at> antenna.co.jp>
Cc: "Boris Zbarsky" <bzbarsky <at> MIT.EDU>; "David Hyatt" <hyatt <at> apple.com>; 
"www-style list" <www-style <at> w3.org>
Subject: Re: [css3-text-layout] New editor's draft - 
margin-before/after/start/end  etc.

>
> So, really, it's 90 new properties (the 18 new above, but for
> margin, padding, border-style, border-width, and border-color), or
> perhaps 130, if you also count new shorthands separately.
>

Just for the record this number of new properties is close to
the whole number of properties that were defined in CSS2.1.

--

-- 
Andrew Fedoniouk

http://terrainformatica.com
Permalink | Reply | 0 comments |
headers
Tab Atkins Jr. | 1 Jun 2010 07:53
Picon
Gravatar

Re: [css3-flex] calc(flex) and concept of free space.

On Mon, May 31, 2010 at 8:26 PM, Andrew Fedoniouk
<news <at> terrainformatica.com> wrote:
> Terribly sorry. Forgot to add box-sizing:border-box there.
> So the question looks like:
>
> <div width:1000px padding-left:1fx box-sizing:border-box>
>  <div width:calc(500px + 1fx) />
> </div>
> What would be the width of inner div?
> In other words what exactly that preferred width means?

(Assuming that the outer div is a flexbox, but not a child of another flexbox.)

The inner div is 500px.  Read section 6.2 of my proposal for the
precise details.  The outer div's flex gets distributed in the first
round, the child's flex is distributed in the second round.  When
distributing space, you compute free space by looking at the "preflex
lengths" of the children.  That's 500px in this case, so there's 500px
of free space that the outer div's padding can soak up.

> Another question:
>
> <div width:1000px box-sizing:content-box>
>  <div #flexible width:calc(500px + 1fx) >
>      <div width:800px />
>  </div>
> </div>
>
> What would be the width of div#flexible ?
(Continue reading)

Permalink | Reply | 9 comments |
headers
Håkon Wium Lie | 1 Jun 2010 09:59
Picon
Favicon

Re: [css3-text-layout] New editor's draft - margin-before/after/start/end etc.

Also sprach L. David Baron:

 > So, really, it's 90 new properties (the 18 new above, but for
 > margin, padding, border-style, border-width, and border-color), or
 > perhaps 130, if you also count new shorthands separately.

Ouch.

 > I'd also note that there are two different proposals for how the
 > cascading of logical + physical properties should work.  My original
 > proposal was:
 >   http://lists.w3.org/Archives/Public/www-style/2002Sep/0049.html

Note the term "property glut" :)

 > which is quite similar to what is implemented in Mozilla (for -start
 > and -end properties):
 >   https://bugzilla.mozilla.org/show_bug.cgi?id=74880
 > Elika had a different proposal here:
 >   http://lists.w3.org/Archives/Public/www-style/2006Jun/0084.html

The current draft [1] seems to sketch a simpler model where:

  - the properties are not real properies but aliases for existing
    properties (although they are referred to as "logical properties";
    this should probably be changed to "direction-dependent aliases"
    (DDAs) or something, I'll use that term here)

  - DDAs are mapped to their respective properties as soon as the
    computed value of 'writing-mode' is known; thereafter DDAs --
(Continue reading)

Permalink | Reply | 28 comments |
headers
Alan Gresley | 1 Jun 2010 10:51
Favicon

Re: [css3-text-layout] New editor's draft - margin-before/after/start/end etc.

Håkon Wium Lie wrote:
> Also sprach David Hyatt:
> 
>  > I can't speak for Mozilla, but in WebKit our *-start and *-end
>  > properties are faked. When applied to an element they resolve
>  > immediately to left or right (depending on the direction). We don't
>  > carry around a real notion (possibly inherited) that the start side
>  > should be used.
> 
> So, you are not storing separate values for *-start/end, nor do you
> remember whether the physical values come from *-start/end or not?
>>From this test, it seems you do remember some information:
> 
>   http://people.opera.com/howcome/2010/tests/log.html
> 
> That is, when the direction is changed from ltr to rtl through DOM,
> the padding switches sides.
> 
> -h&kon
>               Håkon Wium Lie                          CTO °þe®ª
> howcome <at> opera.com                  http://people.opera.com/howcome

That is correct Håkon. The changing of bidirection from ltr to rtl or 
from rtl to ltr changes what side the padding isb on but also many 
other things change or should change.

<http://lists.w3.org/Archives/Public/www-style/2010Mar/0544.html>

<http://lists.w3.org/Archives/Public/www-style/2009Dec/0100.html>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Duffin | 1 Jun 2010 12:01

[css3-background] - border-image-slice inconsistent should behave like edge shorthands

border-image-slice could be viewed as a shorthand for the following properties:
* border-image-slice-top
* border-image-slice-bottom
* border-image-slice-left
* border-image-slice-right
* border-image-slice-fill: discard|preserve

Now I am not proposing that they be added as individual properties (although it would be consistent) but
simply that border-image-slice should behave in the same way as edge related shorthands such as
padding/margin/border-color/ etc. The order in which the edges are specified is consistent, what is not
is what happens when < 4 values are specified.

At the moment the specification states at
http://www.w3.org/TR/2009/CR-css3-background-20091217#border-image-slice that
    "If the fourth number/percentage is absent, it is the same as the second. If the third one is also absent, it
is the same as the first. If the second one is also absent, it is the same as the first."

That is different to the way that ALL the edge shorthands are specified.
* http://www.w3.org/TR/CSS2/box.html#propdef-padding
* http://www.w3.org/TR/CSS2/box.html#propdef-margin
* http://www.w3.org/TR/CSS2/box.html#propdef-border-width
* http://www.w3.org/TR/CSS2/box.html#propdef-border-style
* http://www.w3.org/TR/CSS2/box.html#propdef-border-color

Which state that:
    "If there is only one value, it applies to all sides. If there are two values, the top and bottom borders are
set to the first value and the right and left are set to the second. If there are three values, the top is set to
the first value, the left and right are set to the second, and the bottom is set to the third. If there are four
values, they apply to the top, right, bottom, and left, respectively."
(Continue reading)

Permalink | Reply | 3 comments |
headers
Øyvind Stenhaug | 1 Jun 2010 12:36
Picon
Favicon

Re: [css3-background] - border-image-slice inconsistent should behave like edge shorthands

On Tue, 01 Jun 2010 12:01:11 +0200, Paul Duffin <pduffin <at> volantis.com>  
wrote:

> At the moment the specification states at  
> http://www.w3.org/TR/2009/CR-css3-background-20091217#border-image-slice  
> that
>     "If the fourth number/percentage is absent, it is the same as the  
> second.

(...)

> When 2 values are specified they are inconsistent:
>     border-image-slice: 1 2 = border-image-slice: 1 2 1 1

It seems this should be 1 2 1 2 given the sentence quoted above.

>     border-width: 1px 2px = border-width: 1px 2px 1px 2px
>
> When 3 values are specifed they are inconsistent:
>     border-image-slice: 1 2 3 = border-image-slice: 1 2 3 1

Similarly, here it specifies 1 2 3 2.

>     border-width: 1px 2px 3px = border-width: 1px 2px 3px 2px

--

-- 
Øyvind Stenhaug
Core Norway, Opera Software ASA
(Continue reading)

Permalink | Reply | 2 comments |

Gmane