I don't see any mention of the box-sizing CSS property. Are you aware of it?
- Josh On Thu, May 28, 2015 at 8:53 AM, Peter Ent <p...@adobe.com> wrote: > Hi, > > FlexJS is having a little bit of an identity crisis when it comes to > layout and dimensions; specially, when it comes to determining the size of > a component. Flex makes it pretty clear what the .width property returns, > for example. We have been going back and forth on this with FlexJS since > the Flex way is a little different than the browser/CSS way. > > In Flex, when you set the width of a component, you are setting the > bounding box which includes: the width of the content the component holds > any padding (left and right), and the border thickness (I might be wrong > about the border thickness being taking into account, but for the sake of > this discussion, let's assume so). If you change a component's padding, the > interior space of the component shrinks. > > Because FlexJS also lives in HTML/CSS land, we need to take into account > how components are sized in both the ActionScript/Flash world and the > JavaScript/HTML world. On the JavaScript/HTML side, FlexJS sets up the CSS > Box Model[1]. According to the WWW CSS docs, setting the width of an > element just sets the interior or content space. If you want to know the > overall width, you must get the element's padding, border, and margin and > calculate that. In other words, if you set a <div> to have a width of 100 > pixels and a padding of 10 pixels and a border of 2 pixels, the overall > width is going to be 100+2*10+2*2 = 124 pixels. > > Many components in FlexJS have their base element a <div> on the > JavaScript side. If you set a component to be 100 pixels, the ActionScript > version will be 100 pixels but the JavaScript version may not, depending on > the padding, etc. > > We need a consistent and unified way of knowing (and setting) the size of > component. > > The CSS Box Model seems fine to work with when you are developing HTML > pages and web sites, but I'm not so certain it makes it easy for > application developers making apps. I think when you set a component's > width to 100 your expectation is that is how much space it occupies > (padding and border already being taken into account). I believe it would > be easier to make FlexJS/ActionScript conform to the CSS Box Model than it > would the other way around, but I'm not sure that makes it easier - in the > end - for developers and users of FlexJS. > > I'm looking for your thoughts and preferences in this matter and I'm > including a proposal: > > The .width and .height property SETTER functions would set a component's > .explicitWidth/.explicitHeight value. Depending on the component, the > amount of horizontal interior space for children would be what is left over > after subtracting left and right padding and left and right border > thickness. > > The .width and .height property GETTER functions would return values based > on how the component is being sized in their respective dimensions. For > example, if .width is set to 100, then the .width getter would return 100 > since that is its explicit size. But if the component did not have a height > set, .height getter would return the vertical space occupied by the > component's children, plus top and bottom padding, plus top and and bottom > border thickness. > > Margin values would only be used by layout algorithms to determine spacing > between components in the layout. > > The .explicitWidth and .explicitHeight properties would be read-only and > if set, indicate a constant size for the component in that dimension. > > The .percentWidth and .percentHeight properties would be read/write and if > set, indicate how much of the parent space to use. The percentage value > would act like an explicit value because the component is not being sized > by its content, rather as a percentage of its parent component. If the > .width or .height SETTER is used, it would unset the corresponding .percent > property. > > The affect of border and padding on a component is then determined by how > the component is being sized. For components being explicitly sized, > border and padding cause the interior space of the component to change. > Thus a component that is .width=100 and a padding of 0 (zero) and no border > would have a content area of 100. But if the component were to have a > padding of 10 set, then the content area would become 80 (100 - 10 left - > 10 right); the component's layout algorithm would have to deal with this > situation. > > If a component is being sized by its content, then padding and border > change the overall size. For example, if a component has a child that is > 100 pixels wide, the component's .width GETTER would return 100. If the > component then had a padding of 10 added to it, the .width GETTER would > return 120. In this case, the child has determined the component's minimum > size and padding and border just add to that. > > For application developers, I think one function should return a > component's width or height so calculations can be easily made. This > enables a layout to work based solely on the values returned by the .width > and .height GETTER functions while allowing styling, such as padding and > border, to be set apart from the code. If a component is set to a specific > size, changing padding won't cause a ripple effect on the screen, but > components loosely placed (i.e., relying on layout algorithms to place > them) would be easily styled with padding and borders. > > For example, a horizontal container with no explicit width might have 4 > buttons in it, also with no width set on them. The container's width is > then determined by the sum of the widths of the button children. By setting > a padding of 5 on the horizontal container, the container would widen by 10 > pixels. Setting padding on each button to 5 would make the container 40 > pixels wider still. > > If the developer decided to fix the horizontal container to 400 pixels, > adding the padding of 5 pixels would change the interior layout space from > 400 to 390 but the container would not increase in size as it would if it > were being sized by its content. > > Thanks for your time, > Peter Ent > Adobe Systems > > [1] http://www.w3schools.com/css/css_boxmodel.asp >
