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
