This is good information.
To keep things simple for the time being, the JS side pretty much has
everything wrapped in its own <div> with a couple of exceptions, I think.
The display mode is always block. We pretty much want the developer to
have control over position just as they do with Flex. Containers with
layouts will implement the layout in JavaScript as best as possible. I'm
sure we will all be doing some tuning on this front.
I'm not sure about SVG and skins and such so keep the discussion going.
Peter Ent
Adobe Systems
On 4/9/14 8:54 PM, "jude" <flexcapaci...@gmail.com> wrote:
>One more thing to keep in mind is display modes. There are some such as
>inline(?) that ignore width and height values and instead size to fit.
>Then
>there are some, like block, that fill all available space in a container
>pushing all other elements to the next line. Then there is inline-block
>which allows you to set the width or height and still remain inline.
>
>I've also encountered a case where text has padding above it and this
>increases the larger the font size. Flash does not do this (in my tests).
>The text is always flush against the top of it's own container. But in the
>browser (or merely in my tests) it's more like 1-10 px more offset from
>it's container. This partially has to do with line-height. This is the
>current problem I'm trying to solve and have a couple of solutions which
>partially work but there is still a small amount of padding and haven't
>been extensively tested. Feel free to email me or better yet continue to
>post to the list.
>
>Another thing to consider is if it's possible to use different skin types.
>Since there are different bead types, you could have a view that takes a
>different approach to how it renders the visuals using browser controls
>(vanilla) that point to a style name or something like pseudo facade
>controls that are based on static images (that don't stretch) or dynamic
>pseudo controls that drawn on the canvas or with svg (that can dynamically
>be resized and continue to appear correctly).
>
>
>
>On Tue, Apr 8, 2014 at 7:53 AM, Peter Ent <p...@adobe.com> wrote:
>
>> 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
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>
>> >
>>
>>
