Hi, I just discover this:
http://weblog.bocoup.com/dive-into-flexbox/ "Flexbox is a new layout mode in CSS3 that is designed for the more sophisticated needs of the modern web" and this: http://devbryce.com/site/flexbox/ someone was aware of this? btw, curious name "flex", isn't it? ;) 2014-04-10 15:47 GMT+02:00 Peter Ent <p...@adobe.com>: > 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 > >> >>>>>> > >> >>>>> > >> >>>> > >> >>>> > >> >> > >> > > >> > >> > > -- Carlos Rovira Director de Tecnología M: +34 607 22 60 05 F: +34 912 94 80 80 http://www.codeoscopic.com http://www.directwriter.es http://www.avant2.es
