In the world of EWB1, I was always a little confused about visibility. Clearly it made things visible (or not) but it didn't stop them taking up "space". For example, if a control extended beyond its parent then the parent would invoke scroll bars, even if the control was not visible. I think this was due to HTML5's ability to specify a "visible" tag and a "display" tag. The latter of these controlled space taken up, but was not exposed by EWB1.

From testing so far, I think that visibility in EWB2 now also handles the "space" issue i.e. when a control is set to be not visible, it  also stops taking space. I can see this because when I use a layout to arrange multiple controls within a parent, then hide one of these controls, the layout "shrinks up" to fill the space. It "expands" again when I make the control visible. This is deeply cool, assuming I understand it correctly.

So, question, how does EWB2 actually handle the HTML5 visible and display tags behind the scenes?

Mark,

<< From testing so far, I think that visibility in EWB2 now also handles the
"space" issue i.e. when a control is set to be not visible, it  also stops
taking space. I can see this because when I use a layout to arrange multiple
controls within a parent, then hide one of these controls, the layout
"shrinks up" to fill the space. It "expands" again when I make the control
visible. This is deeply cool, assuming I understand it correctly. >>

You do.

<< So, question, how does EWB2 actually handle the HTML5 visible and display
tags behind the scenes? >>

It uses the CSS display attribute to hide UI elements, but it does a little
bit of "kung fu" to do what I term a "cached show".  EWB caches all
interface update operations according to the BeginUpdate/EndUpdate calls for
a given UI element and its children.  For most UI attributes, this isn't an
issue.  Visibility is a bit of a problem in this regard with the browsers,
though, because they don't allow invisible elements to be focused in any
way.  So, what EWB does is go ahead and make the element visible, but set
its opacity to 0 before doing so.  Then, when the EndUpdate is reached, the
opacity is reset back to the defined value for the element and the element
is "shown".

** Note: this applies to the the preview build 2 or higher.  I just added
the opacity bit...

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

Mark,

<< From testing so far, I think that visibility in EWB2 now also handles the
"space" issue i.e. when a control is set to be not visible, it  also stops
taking space. I can see this because when I use a layout to arrange multiple
controls within a parent, then hide one of these controls, the layout
"shrinks up" to fill the space. It "expands" again when I make the control
visible. This is deeply cool, assuming I understand it correctly. >>

You do.

<< So, question, how does EWB2 actually handle the HTML5 visible and display
tags behind the scenes? >>

It uses the CSS display attribute to hide UI elements, but it does a little
bit of "kung fu" to do what I term a "cached show".  EWB caches all
interface update operations according to the BeginUpdate/EndUpdate calls for
a given UI element and its children.  For most UI attributes, this isn't an
issue.  Visibility is a bit of a problem in this regard with the browsers,
though, because they don't allow invisible elements to be focused in any
way.  So, what EWB does is go ahead and make the element visible, but set
its opacity to 0 before doing so.  Then, when the EndUpdate is reached, the
opacity is reset back to the defined value for the element and the element
is "shown".

** Note: this applies to the the preview build 2 or higher.  I just added
the opacity bit...


Nice