GWT 1.5 and standards-mode support

[Joel Webber]

All,

As you may recall, it has been a goal of the GWT 1.5 release to increase our support for standards-mode rendering (i.e. what you get with a typical <!DOCTYPE> declaration). And we have made a lot of progress, in particular dealing with most of the issues that crop up in methods like Window.getClientWidget(), Element.getAbsolutePosition(), and so forth.

A while back, we made the decision to shift all of our samples (and the output of the application creator) to include a standard <!DOCTYPE> declaration, with the idea that we would use this as a way to fix any issues that came up with rendering and layout. We made a lot of progress on this front as well, but ultimately hit a brick wall with a few of the existing widgets. Specifically, it turns out that it is basically impossible to make a StackPanel layout properly in IE standards-mode if its height is ever set (as it is in the Mail sample). We spent a *lot* of time trying to work through this case, but it seems that standards-mode treatment of tables, along with poor support in IE for CSS layout of <div> elements, conspire to make the problem apparently insoluble.

To make matters worse, a number of constructs that we've depended upon for layout in the past are broken in standards-mode on most browsers. Case in point: setting a <div> in a <td> to 100% width or height has no effect whatsoever! Faced with the prospect of apparently-unfixable bugs in standards mode, but that work well in quirks mode, we've come to the conclusion that we need to remove the <!DOCTYPE> declarations from our samples.

Note that this is *not* to say GWT applications won't work in standards mode. They will work, though you will find that some of the table-based panels behave in surprising ways. But the other standards-mode bugs (such as with getAbsoluteLeft/Top() and such) have been dealt with.

As we move ahead to subsequent GWT versions, we will be investigating (hopefully with your help), more general solutions to the problem of application layout that will help us to move past all of these issues. As soon as the 1.5 dust settles, I will start a thread outlining some ideas on this front for further discussion.

Cheers,

joel.

[Bruce Johnson]

I should also point out that this issue is the only thing that has been holding up GWT 1.5 GA.

With the compromise Joel describes, we can ship GWT 1.5 RC2 without further delay (i.e in as little as a few more days).

Thank you Joel, John L, Emily, and Kelly for making this judgment call and explaining the reasoning so that we can move on and get GWT 1.5 finished.

[Fred Sauer]

Joel,

There was a thread a while back where I looked into the height:100% issue in standard's mode. That was back in this thread:
  http://groups.google.com/group/Google-Web-Toolkit-Contributors/msg/b8593d255f1718ba


Quoting from that email:

I wanted to follow up on the CSS height:100% issue, which I believe stems from  http://www.w3.org/TR/REC-CSS2/visudet.html#the-height-property, specifically:

The percentage is calculated with respect to the height of the generated box's containing block. If the height of the containing block is not specified explicitly (i.e., it depends on content height), the value is interpreted like 'auto'.

In quirks mode setting the body height:100% fills the entire page height. In standard mode it does not. This is not because the CSS height is ignored, but because the surrounding element (= the HTML document element) essentially has height:100% in quirks mode and height:auto in standard mode.


So, where one would in quirks mode write

body{height:100%}

you would need this in standard mode for the same effect:

html,body{height:100%}

Also, if you want any given block level element (usually a DIV based widget within a table) to have 100% height to say fill the table cell vertically (or any height greater than what is required to fill the contents of that block), you must walk up the DOM tree from that widget and either:

• set an absolute height, such as height:300px or height:10em
• set a percentage based height (height:100%), and then repeat with the widget's parent

Your goal is to have an unbroken chain of percentage heights from some ancestor which has an absolute height. For this purpose body (quirks mode) or html (standard mode) has an absolute height.

If what I wrote there pans out, do you think it addresses the widget use cases such as the stack panel with height? I know I specifically looked at the <div> in a <td> case.

HTH
Fred Sauer
fr...@allen-sauer.com

[dflorey]

Fred,
I've also spent days to find out that especially the 100%-height stuff
is simply not working in strict mode. And it will not help to have an
unbroken chain of height settings on the dom tree.
As it would be nice to have let's say a "full screen" DockPanel
working (with sticky footer added south, header north and a scrollable
content area) I assume that we have to provide completely different
solutions for different browsers/compatibility modes.
So my proposal would be to make the browser mode available to the
deferred binding (if it's not yet available) so that we can use
different implementations for different modes. E.g. DockPanel works
fine in quirks mode using tables, it could work fine in IE8/css 3 in
standard mode based on divs and could work a little bit in standard
mode on IE6/7 using divs with lots of css hacks.
To achieve a proper 100%-height handling I'd vote for methods like
expand(VERTICAL/HORIZONTAL/BOTH) applying the proper logic for the
different environments. Simply using the setSize(x,x) method will
force us to do string parsing to figure out if we have to apply the
100% hacks or if it's a simple px value.

Cheers,
Daniel

On 18 Jul., 05:47, "Fred Sauer" <f...@allen-sauer.com> wrote:
> Joel,
>
> There was a thread a while back where I looked into the height:100% issue in
> standard's mode. That was back in this thread:
>

> http://groups.google.com/group/Google-Web-Toolkit-Contributors/msg/b8...

>
> Quoting from that email:
>
> I wanted to follow up on the CSS height:100% issue, which I believe stems
> from http://www.w3.org/TR/REC-CSS2/visudet.html#the-height-property,
> specifically:
>
> The percentage is calculated with respect to the height of the generated
>
> > box's containing block. If the height of the containing block is not
> > specified explicitly (i.e., it depends on content height), the value is
> > interpreted like 'auto'.
>
> In quirks mode setting the body height:100% fills the entire page height. In
> standard mode it does not. This is not because the CSS height is ignored,
> but because the surrounding element (= the HTML document element)
> essentially has height:100% in quirks mode and height:auto in standard mode.
>
> So, where one would in quirks mode write
>
> > body{height:100%}
>
> you would need this in standard mode for the same effect:
>
> > html,body{height:100%}
>
> Also, if you want any given block level element (usually a DIV based widget
> within a table) to have 100% height to say fill the table cell vertically
> (or any height greater than what is required to fill the contents of that
> block), you must walk up the DOM tree from that widget and either:
>

> - set an absolute height, such as height:300px or height:10em
> - set a percentage based height (height:100%), and then repeat with the

> widget's parent
>
> Your goal is to have an unbroken chain of percentage heights from some
> ancestor which has an absolute height. For this purpose body (quirks mode)
> or html (standard mode) has an absolute height.
>
> If what I wrote there pans out, do you think it addresses the widget use
> cases such as the stack panel with height? I know I specifically looked at
> the <div> in a <td> case.
>
> HTH
> Fred Sauer

> f...@allen-sauer.com

[John Tamplin]

On Fri, Jul 18, 2008 at 1:54 PM, dflorey <daniel...@gmail.com> wrote:

So my proposal would be to make the browser mode available to the
deferred binding (if it's not yet available) so that we can use
different implementations for different modes.

It is certainly possible to do deferred binding on whether the host page is quirks mode or standards mode, but that would double the number of permutations and thus double the compile time.  Also, it isn't clear that most of the implementations would be sufficiently different to justify different deferred bindings instead of runtime checks.  In your example, you would still have to have runtime checks for IE8 unless you wanted to add a separate user.agent property for it.

But I think the bigger problem is simply that many of the current widgets simply cannot be implemented in standards mode in current versions of IE, so does it make sense to spend a lot of effort on something that is going to be only partially correct?

--
John A. Tamplin
Software Engineer (GWT), Google

[jgbauman]

Hi,

I only read most of the discussions revolving around this problem, but
didn't have time to try some things.
Just another idea: Since the problem is with IE6/IE7 and GWT needs
JavaScript enabled anyway,
perhaps IEs "Dynamic Properties" could be used to simulate correct
behaviour (see http://msdn.microsoft.com/en-us/library/ms537634.aspx)

[Emily Crutcher]

Your instincts are dead on, as we are using dynamic css expressions as the IE basis for some new standards-mode compliant widgets we are working on. In specific if you give up backwards compatibility and do not allow the content to naturally resize the widget,  you can use this trick to create a pretty decent new stack panel very cleanly with support in all the browsers.


The problem with the current  StackPanel, in specific, is that we simultaneously cannot set the height on the content element, as setting it at all ends up violating at least some corner cases of the original behavior and must set its height in order for the widget to display correctly.

         Cheers,

                 Emily

--
"There are only 10 types of people in the world: Those who understand binary, and those who don't"