I was very excited to see Vaadin 7 alpha out of the door.
Will Vaadin 7 be addressing the serious layout issues that exist in 6?
Will Vaadin 7 be getting rid of the inline hard coding of heights and widths that plague the layouts? Will it allow developers to use relative(%) based sizing?
The alpha2 release of Vaadin 7 that is scheduled for release in a couple of weeks will contain a major overhaul of the way the framework manages layouting and sizing. Alpha4, which is a couple of months away, should in turn bring improvements to the way CSS can be used to manage the looks of applications.
It depends on what issues you are thinking of. We will do our best to increase the performance of the layouts, improve support for theming layouts using CSS (including usage of margins where they make sense), and fix various glitches e.g. when a 100% sized component has borders or when the sizing of a component is changed between undefined and relative on the fly.
We will get rid of the explicit conversion of relative sizes to pixels. There are however still cases where calculated inline heights and widths are required to support cases that some browsers can’t manage with only pure css. Whenever possible, these inline styles will however be applied to wrappers in the layouts instead of applying styles directly on the DOM elements of the child widgets. The framework should also get better at detecting when recalculations are needed.
I’m really curious to the performance of the new layouts, especially horizontal layout en vertical layout, because now I try to avoid them as much as possible because of performance.
How about the DOM structure of the Layouts? Often one only needs a simple div, and now the DOM tree can get very large.
The performance of Vertical/HorizontalLayout is quite challenging, but it’s also the primary target of the performance improvements that are under way. We are currently investigating two different approaches: doing everything with pure CSS vs. calculating everything but redesigning the ordering of operations to avoid excessive browser reflows.
The pure CSS strategy should give performance similar to CssLayout + some additional gains from dropping the explicit conversions of relative sizes to absolute pixels. There are however some features that we have not managed to implement in pure CSS, e.g. vertical alignment and multiple expand ratios. It seems that CSS3 Flexible Box could be used to implement all the required features, but that is not an option as long as we want to support IE8 and IE9.
The calculation approach is currently only giving a 2x speedup, but there’s still potential for optimizing the order of the size change propagations, which might in theory give a total gain of maybe 10x. We might also end up with a hybrid approach that uses pure CSS for optimal performance when possible and then falling back to measuring and calculating when features that can not be implemented with pure CSS are used.
How all this turns out will hopefully be clearer in a couple of weeks when alpha2 should be released.
No additional wrappers are needed for simple cases, but when including generic support for spacing, margin, component captions and e.g. relatively sized components, one or more levels of wrappers are usually needed. The Vertical/HorizontalLayout only using pure CSS needs roughly the same DOM structure as in Vaadin 6 while it seems that the layouts based on calculations can manage with only one wrapper per child. If you are concerned by the depth of the DOM tree, you could also consider some of the add-on layouts by our CSS wizard
Jouni Koivuviita
.
Reducing the complexity of the DOM structure is not a goal of our current efforts, but we do of course attempt to simplify things whenever it can easily be achieved. We must however be careful to not introduce an even deeper hierarchy, as that could cause nasty regressions with browsers which are limiting the depth of the DOM tree.
thank you for your extensive answer. I’m looking forward to the “new” layouts.
I already use some of layouts of Jouni.
Thanks for your detailed reply. Please please please please
do not do inline styling
. It is impossible to build any slick user interface with the way things are right now. Its pretty much go with Vaadins look and feel or use something else like dojo, yui jquery etc.
Our team dreads touching Vaadin for the very reason that styling is extremely extremely hard and painful. For example, one cannot even add borders, paddings or margins using CSS without blowing up the user interface. User interface is very important and Vaadin has a serious limitation in this area. We are really hoping that Vaadin 7 will address the layout issues.
I do not understand the internals of Vaadin but I am very puzzled as to why styling in pure HTML+CSS is so straightforward but such a huge issue in Vaadin.
I can promise you that there will still be inline styling in Vaadin 7, but I can also promise you that it will not be as widely used as it is in Vaadin 6. Some of this is currently being worked on for the alpha 2 release that will soon be released and some of it will be done for a later alpha release.
The basic reason for this is that Vaadin supports some layout concepts that are not easily achieved using pure HTML+CSS (without the not yet universally supported CSS3 Flexible Box model), e.g. arbitrary vertical alignment and division of extra space using expand ratios. Adding support for margins, borders and paddings on top of that is a tedious job that has partially been done for some Vaadin component, but not for all. There are also some issues with browser compatibility that has made it difficult to universally support those features, but those can be overcome in Vaadin 7 when all supported browsers support (-moz-)box-sizing: border-box and no supported browser reports zero offsetHeight/Width for certain combinations of margins and overflow. It seems that borders and paddings will be almost universally supported but that margins will still cause problems e.g. if combined with 100% size (just as with pure HTML+CSS).
The dynamic nature of web applications compared to static web pages also causes some challenges, e.g. HorizontalLayout which can be seen as
“the Holy Grail”
with the additional challenge of not knowing the widths of the sidebars in advance. Supporting this requires dynamically measuring the sizes of the sidebars and then adding inline styles based on the measurements.
One final reason is that the Vaadin framework has been designed to be usable by developers without a deep knowledge of how HTML and CSS works. When the layout features of Vaadin 6 were designed, it was thought that it would be easier for developers to develop client side add-ons if the framework would convert all relative size definitions to pixels so that the component wouldn’t need to support any other size definitions. Since that, we have realized that this approach causes performance problems (lots of reflows), makes styling using CSS very difficult (as you have also discovered) and it doesn’t make client side widget development any easier (because everything must be explicitly sized). Those three are all issues that we try to adress in Vaadin 7.
Hi Leif,
Thanks for detailing the path for layout management in Vaadin 7. Talking about layout in Vaadin 6 and possible improvement in Vaadin 7, my voice is somewhat similar with other fellow developers’ concern. Vaadin 6 tries to handle too much of the layout rendering mechanism. This may have added huge benefit when we design a layout that uses default style and behavior but normally end users want to customize, which is unfortunately not an easy route to take for Vaadin developers. On the other side is the performance problem caused by the size calculation and superfluous DOM tree generation. Performance issue sometimes discouraged a wider use and adoption of Vaadin despite its broad set of features.
I root for the effort to rethink layout in Vaadin 7. Removing unnecessary size calculation is such exciting news to me. It has been said that the new layout API will be available from alpha 2 release and onward. I don’t really have a clear view as how the process is going on since I haven’t fiddled with Vaadin 7 codebase. However, if some spoilers are worth telling about the distinct difference between version 6 and 7, it may have added more into the excitement. Among the things I want to know are how a series-of-boxes model (horizontal or vertical, nested or sibling-like) will be rendered in Vaadin 7. In Vaadin 6, the sizes of the boxes should be set explicitly which then come out as the inline styles of the generated divs. I wonder if explicit sizing is now optional in Vaadin 7. Additionally, I’d like to know whether the border and margin glitch in Vaadin 6 will have been resolved. The number of generated divs also adds into my curiousity, but since it’s been told that reducing DOM tree is currently not a top priority, I try to draw my own conjecture regarding the improvement being worked on.
I think I’ll want to chime in to this conversation as well, since it’s also one of the main pains in my butt when theming Vaadin apps.
I did a couple of HTML/CSS prototypes for both CSS3 Flex Box and CSS display: table based layouts (vertical and horizontal). They’re both quite functional, but some edge cases might not work. They represent on alternative for the new layouts, and you can inspect the DOM from there and provide comments.
Flex Box version:
http://jouni.virtuallypreinstalled.com/upload/layout-proto/flexbox/
Display:table version:
http://jouni.virtuallypreinstalled.com/upload/layout-proto/
I also created a Vaadin layout from the Flex Box version, and you can see the (ugly, not properly structured, already using outdated API) source for it here:
Marc Englund has been working a Vaadin layout from the display:table version:
As you see, most of the functionality is controlled with external CSS, not inline styles. Some edge cases require the use of inline styles (which could be moved to CSS classes, of course). One of the trickiest situations is when you have a horizontal layout with undefined height, and some component inside it has a percentage height. Now that percentage should be calculated from the child component which is the highest (i.e. defines the height of the layout). This usually requires a calculation for the highest child component and setting an explicit height for the layout.
My current understanding (haven’t been involved in the development for a while) is yes, no explicit sizing should happen if you use undefined sizes on the server. Explicit sizes set on the server will still produce inline width/height for the components root element. But again, inside the component root element, no explicit sizes should be used. Some components will have to make an exception here (at least for the time being), like Table, which require internal size calculations for complex parts.
As Leif mentioned, border and padding are ok (again with the exception for internal component calculations like the Table does for column widths), but margins are still a bit tricky to handle in certain situations (i.e 100% sizes). But in normal cases margins should work fine, and basically it’s just CSS.
One thing on my priority list is to reduce CssLayout to just one DIV, which is what many users have been wanting for long. With that, you should be able to do layouting easily using vanilla CSS.
Then a question:
Would you be OK if the DOM structure changed depending on the features used on the server side? For example,if alignments are used, an extra wrapper element would be added to handle that. Or would you prefer that the DOM stays the same no matter what is set on the server?
Looking forward to the alpha2 myself as well 
We are steadily approaching something that it would be meaningful to release as alpha2. According to the initial plans, alpha2 should have been released several weeks ago. Along the way we did however realize that we needed to refactor additional parts of the client side API in order to provide a meaningful set of features that could make it all the way to a final Vaadin 7 release without extensive structural changes.
Regarding the layouts, the status is that we have a new framework in place which should enable most of the features that you and others in this thread have been hoping for, but those actual features are not yet fully implemented. We have not yet managed to produce any significant improvements to performance as we are first focusing on making a usable API and getting all core widgets to work as expected with the new framework. There is however potential for significant performance improvements once we start looking in that direction.
The new framework enables making widgets what doesn’t require on any inline styling at all as long as no explicit sizes are defined on the server. Instead it could get all dimensions from static CSS in combination with its own contents (e.g. Label width varying with text length and font size). For a row of horizontal or vertical boxes, there are essentially the same two options as in Vaadin 6; Horizontal/VerticalLayout or CssLayout.
For CssLayout, the new framework should eliminate most of the issues where e.g. nesting multiple CssLayouts might cause undesired effects. It should also be quite easy to change between horizontal and vertical layouting by changing between display: block and display: inline-block for the children. Furthermore, we are considering removing the extra wrapper levels from CssLayout for the theming changes for alpha3 but we haven’t yet determined how to manage backwards compatibility.
With HoriztonalLayout and VerticalLayout, we are currently using two different client side implementations. The first is very simple and fully functional with support for all existing features without any custom tweaks but it is based on explicit calculations and absolute positioning. The other implementation lets the browser take care of the layouting whenever possible but we’re still having issues with some of the features that are not easily implemented in the browser, e.g. some aspects of expansion rations and some alignment features. Alpha 2 will most likely ship with the simpler layout based on absolute positioning but we will hopefully replace it with the other implementation in some upcoming alpha release as it should give significantly better performance in most cases.
All problems with borders and margins should be fixed on the framework level, but there might still be glitches inside some components until they have all been properly migrated to benefit from the new layout framework.
There is still much unclear regarding the DOM tree depth. E.g. the HorizontalLayout and VerticalLayout implementations with absolute positioning only use one level of wrappers whereas the final DOM structure for the other implementation depends on what is required to get all features working in all supported browsers using minimal calculations and inline css.
I did a quick look on the utilities you nicely crafted and spent some time tinkering with them. I also read the notes put inside the source codes and found the issues highlighted somewhat tricky and challenging to solve. Having observed the two approaches, I’d like to share my notes taken when inspecting the DOM and observing the behaviors of the two. I did the experiment only on Chrome, so what I write here may not apply to other browsers (especially the notorious IE ;)):
I like the idea of adding the “flag” css classes “has-"and "no-” for adding and removing inline styles. It’s also nice to notice that an inline style does not propagate to child div elements anymore and instead is only applied to the container where the size is set. This approach will bring more flexibility in styling the child elements and overall layout.
The stylesheet declaration is also slicker. Thanks for the effort. I didn’t spot redundant “overflow:hidden” or other avoidable styling.
As for default behavior, I prefer flexbox. This is primarily because the styling is more straightforward and the behavior is more predictable when it contains stacks of elements inside. However, I notice that when a container contains fixed size child div with borders, the child div will be clipped on its edge when its size in pixels is set to be the same with its parent. This is not the case with the display:table approach where the table will automatically expand to fit the child div size.
In my opinion, the display:table approach handles better in cases where overflow is expected (which i believe is more common). However, the behavior may not be preferred when the size of the child div element is less than the container. I am not a CSS wizard per se, but I tend to believe that this is something workable with additional CSS rules and tweaks.
Yep, I concur that styling is handled better now… I can see how the new styling concept translates into the client side code. Just out of curiosity, it’s pretty interesting that the API now relies on ApplicationConnection. I suspect something has changed in thread management, but I’m not really sure and will take a deeper look into current code to understand it better.
The undefined height case you mentioned is also tricky to solve especially when other similar undefined height-percentage case is nested under the child div. At this extreme, I would agree that Vaadin takes precaution of user’s bad design and adds inline styles to render the component properly.
I can see this reaffirmed in the code. It’s nice to see this change.
Border seems to be okay with display:table approach but there could be similar glitch with flexbox approach as I noted earlier.
I am a strong propoent for this change. But I can understand why even CssLayout has to have two DIVs. It’s the different box model used in AbstractLayout.
I think there are two important constraints here: flexibility and predictibility. If the DOM structure changes accordingly with the feature used, it has to be predictable. When it’s predictable, it will be easier to manage the styling and manipulate the DOM on the fly. If the change is not consistent and too disperse, in the end it will result in similar complaints like what is airing with Vaadin 6. Flexibility is the reduction of the inline styles and offloading the style management to CSS classes. It’s obviously great to have a consistent DOM tree regardless of the feature used (optimum predictability). But if this translates to less flexibility as a trade-off, it could be worthy to consider another avenue.