Yup. We had this discussion a long time ago. The defaults of HTML are really kind of odd… ;-)
On May 28, 2015, at 8:24 PM, Peter Ent <p...@adobe.com> wrote: > 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 >>> >
