This is an interesting idea. I'll try it out.

Thanks!
--peter

On 4/8/14 7:44 AM, "Harbs" <harbs.li...@gmail.com> wrote:

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

Reply via email to