I believe the only thing to lookout for when using the global(*) on the border-box is that it will affect images too. Meaning it will push border size and padding inside of its bounding area and scaling the image down. Setting the images back to a regular box should work.
-Mark -----Original Message----- From: Peter Ent [mailto:p...@adobe.com] Sent: Monday, April 07, 2014 2:46 PM To: dev@flex.apache.org Subject: Re: [FlexJS] CSS Box Model Thanks your help and insight. After some experimentation, the border-box model is how we'll proceed. Thus .width and .height properties will be the bounding box for the component with border and padding inside this box. We'll take the margin information under advisement, but I think I agree with this, too. --peter On 4/7/14 10:32 AM, "jude" <flexcapaci...@gmail.com> wrote: >Welcome to HTML world. I've been mulling over this for the last few >months. >I agree that the border box model would be closer to what people would >expect. The default box model is based on the original use case of layout >and position of documents not applications. The border box model was >specifically made to give you more control over the layout and design. > >Fortunately, it's at a point you can use it, >http://caniuse.com/#search=border-box. > >You can enable or disable it or box model with: > >*, *:before, *:after { > -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: >border-box; >} > >Also, for an interesting insight into what it does add an outlines: > >*, *:before, *:after { > outline:1px dotted red; >} > >There have been talks about using SVG for components visuals and I think >there's something there. Om did some work with SVG skins and I've been >experimenting with them as well. There's a strong possibility of getting a >1:1 of both the Flash and HTML visuals that way. The size, position and >look are nearly identical in my tests. Why it's not used more is a mystery >to me. But it shouldn't be surprising. AJAX was around for 4yrs before it >was used. Someone just needs to prove it's possible for it to take off. > >For buttons, for example, you would use: > ><input id="Button1447" type="button" value="Button" class="buttonSkin"> > >.buttonSkin { > background: url(assets/svg/button_skin_up.svg) 0 0 no-repeat; > border: 0px; >} > >.buttonSkin:hover { > background: url(assets/svg/button_skin_over.svg) 0 0 no-repeat; > border: 0px; >} > >.buttonSkin:active { > background: url(assets/svg/button_skin_down.svg) 0 0 no-repeat; > border: 0px; >} > >Conversion will be much easier if we don't support margins. The only place >I would use margins is in horizontal or vertical layout. For example, if >you have 5 elements in a div, set the right margin on all the elements but >the last to the gap. I believe that was what margins were intended for to >begin with. > >My thought is that we don't support the HTML style unless or until we >support it in Flex. So for example, HTML supports border top, bottom, >left, >and right but FlexJS / Flex 4 doesn't (out of the box). We wouldn't >support >this until we have a Flex skin that supports it. > >HTML also has a unsupported styles thing that you saw in the css before: > > -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: >border-box; > >When you start adding in all the browsers you'll have -ie, -moz, -webkit, >-chrome, etc just for one style. IMO if you go that route you're gonna >have >a bad time. If we can use SVG you can gain that ground back. > >Also, imo, I wouldn't try and support the lowest common denominator. Go >for >a baseline of something like IE 8 or IE9 and use polyfills for fallback >(some of which are FP) if absolutely vital. > > >On Mon, Apr 7, 2014 at 8:20 AM, Peter Ent <p...@adobe.com> wrote: > >> So this is a crazy, no-win situation. Our box model is either compatible >> with the "standard" of most browsers or compatible with some quirk or >> extra feature that attempts to make sense out of something that >>shouldn't >> have been done in the first place. >> >> Or, to put it another way, we are trying to impose a UI/graphics-focused >> model & framework onto a system not designed for it and geared toward >>page >> layout. >> >> Sigh, >> Peter >> >> On 4/6/14 6:41 AM, "Harbs" <harbs.li...@gmail.com> wrote: >> >> >I think the default of the css box model is broken by design. >> > >> >I'd think the solution is simply to stick to using border-box. >> >http://css-tricks.com/box-sizing/ >> > >> >On Apr 4, 2014, at 9:54 PM, Peter Ent wrote: >> > >> >> Hi, >> >> >> >> I've been working on a mobile app example for FlexJS as a way to try >> >>out the Flex JS in a practical manner with the intent of running the >>app >> >>using PhoneGap. In the course of doing this I've been running into >> >>things that need adjustment. >> >> >> >> One of them is the box model. Right now FlexJS is sort of a hybrid >> >>between ActionScript and JavaScript. I'll use the .width property as >>an >> >>example. >> >> >> >> In Flex, when you give a component a width of 50 pixels that >>component >> >>is 50 pixels wide. Some components, such as a container, would embed a >> >>scrollbar if its content were greater than 50 pixels. But you can be >> >>sure that your component is 50 pixels wide and you can position other >> >>components knowing that. >> >> >> >> If you add padding to the component, that will offset the interior by >> >>that amount. If you make a Container 200 pixels wide and give it a >> >>padding of 10 pixels, positioning a child of that container at (0,0) >> >>will render the child 10 pixels in from the left and 10 pixels down >>from >> >>the top. The child thinks it is at (0,0) and the Container will remain >> >>200 pixels wide. >> >> >> >> In the CSS Box model, things work differently. If you make an HTML >> >>element 50 pixels wide and give it a padding of 10 pixels, the overall >> >>width of the HTML element will be 70 pixels: the 50 pixels are the >>width >> >>of the content area and 2*10 pixels (left and right) are the padding >> >>added to that. >> >> >> >> HTML goes further and adds on border thickness and margin; Flex >>doesn't >> >>have margins. >> >> >> >> I was having trouble getting things to align because I would make a >> >>ButtonBar 480 pixels wide and it was turning out to be wider than >>that. >> >>When I looked into the code, I saw that making a component 480 pixels >> >>was just the start: I was getting that plus a padding on each of the >> >>buttons that make up the button bar plus the width of the border >>around >> >>each button. >> >> >> >> This makes alignment very difficult because you must ask for more >>than >> >>just width (or height). >> >> >> >> I suggest FlexJS completely adopt the CSS Box Model. This means >>setting >> >>a component's width isn't going to take into account its padding, >>border >> >>thickness, and margin - it is just going to set the component's >>content >> >>area width. For example, if I make a Button's width be 50 pixels, the >> >>text will be placed within that 50 pixel content area, but there may >>be >> >>padding, a border, and a margin surrounding the Button. If I want all >>of >> >>my Buttons to align horizontally with no gaps, I should make sure the >> >>Buttons do not have any margin. >> >> >> >> What this means is that .width won't set the overall width of the >> >>component. This may affect layout calculations which will have to >> >>examine the component's margin, border thickness, and padding values. >>So >> >>I suggest making it simple (height dimension would have similar >> >>properties of course): >> >> >> >> .width is the content area. >> >> .padding is the padding around the content area, inside the border. >> >> .borderThickness is the thickness of border that surrounds the >>padding >> >>and content area. >> >> .margin is space around the component. >> >> .x will position a component's upper-left margin. >> >> >> >> .overallWidth will be .width + 2*.margin + 2*.padding + >> >>2*.borderThickness >> >> >> >> You can use .overallWidth to position elements in layouts as it will >> >>account for all of the extra space in a component's box. >> >> >> >> Further, for Flex JS 1.0, I suggest we keep it simple to padding, >> >>margin, and borderThickness and leave edge specifics (e.g., >>padding-top, >> >>margin-bottom) to another release or a developer can create their >> >>component or override functions to account for that. >> >> >> >> Finally, it should be easier to build applications because you can >>let >> >>CSS have a greater say in the size and positioning of components. For >> >>example, if I want to make a row of buttons that are all touching, I >> >>just create a Container with a horizontal layout and put the Buttons >> >>into it. Then in CSS, I specify that the Buttons have zero margin and >>if >> >>I want them inset within the Container, I give the Container, via CSS, >> >>some padding. >> >> >> >> Thanks for your time, >> >> >> >> Peter Ent >> >> Adobe Systems >> >> >> > >> >>
