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