It might be a good idea to prefix all Flex CSS with a Flex prefix so it does not step on settings for the rest of the web page. For this example something like this:
.apacheFlex *, . apacheFlex *:before, . apacheFlex *:after { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; } As long as the base div of the application has an apacheFlex class, that should isolate the css to the app. On Apr 8, 2014, at 12:59 PM, <mark.kessler....@usmc.mil> wrote: > 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 >>>>> >>>> >>> >>> >