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
>>>>>
>>>>
>>>
>>>
>
