I am still uncertain whether doing the display:none handling in src/Html.cc is really superior. What I liked about corvid's approach is the simplicity of the changes. It did not really involve any fundamental changes. Furthermore, I think handling of hidden elements is generally better suited in dw/ because it's design-related. It would make the whole separation useless, if we mixed parsing code with complex evaluation-logic. Moreover, it should be possible to use the dw-stack completely independent from Dillo's parsing code. Otherwise, this isn't necessarily the case as the developer needs to implement hiding manually. We could also apply display:none to hidden form elements (what I've tried in my patch). This is an advantage because dw's focus is not only HTML and CSS. It should be usable for any other markup as well. Therefore, I'd propose to introduce a general 'hidden' attribute applicable to any element. In the parsing code, hidden HTML form fields are simply converted and internally represented by an ordinary text field which, however, is not displayed. I haven't done any benchmarks but I guess this approach is more efficient in terms of memory usage and rendering speed. It doesn't require to render the whole page repeatedly from scratch when hidden elements are made visible as only a flag needs to be set. It's not required to add new widgets to the dw-layout as with the other approach. As for big pages (HTML manuals with 2-5 MiB), otherwise it would imply that the entire dw-tree in memory is freed and then reallocated afterwards - just because one was made visible! Would the code be really shorter if done in src/Html.cc? I doubt that as we'd still need to check for the "display" value. Actually the patch doesn't do any more than that. So the benefits wouldn't be that striking. While I really like the idea of a DOM, I am somewhat concerned about the performance. A DOM is great when it comes to manipulating the design at runtime. It can be also useful for debugging purposes. However, as Dillo does not aim to support JavaScript there is virtually no need for a DOM. dw seems pretty flexible already and I guess it wouldn't be very difficult to do minor contents manipulation stuff. If understood your DocTree concept correctly, we won't end up with duplication as the DocTree represents both the contents and the style whereas dw only takes care about rendering, right? This sounds interesting but wouldn't it also mean that partial changes to the layout (or contents) would result in re-rendering the whole page? Therefore, I'd endorse the DocTree concept if there were some kind of 'change stack'. Changes can be 'reverted' and 'committed'. A commit then leads to only render the changes. (This idea might also come in handy with slow connections because we can make the 'commit'-rate dependent on the transfer speed. Thus, a 500 KiB website with 1 MiB/s will require only one 'commit' whereas with slower connections there might be more. How is this currently realized in Dillo, by the way?) --Tim