Ah, I completely forgot about box-sizing. It turns out that I had set box-sizing to border-box in FlexJS defaults.css.
So with border-box set for box-sizing, it means on the JavaScript/HTML side, the width and height sizing properties do include padding and border. This means we can say that the FlexJS JavaScript implementation can be more closely matched to ActionScript. That is, if I make a component 200 pixels wide, it will include its padding and border as described below. Thanks, Josh. This will make it easier. ‹peter On 5/28/15, 12:45 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: >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 >>
