December 2009 - Dillo-dev - lists.mailman3.com

display: inline

by tim.nieradzik＠gmx.de

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

Dec. 13, 2009

display: inline

by Johannes.Hofmann＠gmx.de

On Sat, Dec 12, 2009 at 09:38:20PM +0000, corvid wrote: > Johannes wrote: > > Ok, I understand your concerns now. > > It might be better to simply not create dw-widgets in the > > display:none case. At least we should try that option to see if it's > > simpler. My reasons are: > > > > * we would not pollute dw/* which is complex already. > > dw/* would not look at style.display at all. > > * as Tim mentioned, you can always switch off remote CSS to see > > display:none stuff. > > * it does not mean that elements with display:none would not be part > > of the DOM tree, as the DOM tree will be separate from the widget tree. > > > > I also understand now your's and Tim's concerns about the style > > pointer in struct Word. As soon as we start to modify styles in an > > existing widget tree we will get into trouble with all those > > pointers as we can't modify style objects in place. > > > > So I would propose to do display handling in html.cc. > > Your suggestion seems quite sensible to me now :) Let's see :) > > > Then we can convert Doctree to a real DOM tree. With that in place > > we can come back to the style in struct Word issue. We might simply > > have a pointer to the corresponding DoctreeNode, which could hold > > the style. We might even drop the style sharing code then - but > > let's see. > > Would dw/ understand the contents of DocTreeNodes? Sorry, what I said was misleading. dw/ would not include doctree.hh. However we could have one style object per DocTreeNode and then all objects in the widget tree (widgets or struct Words) that correspond to that DocTreeNode could point to that single style object - which we could then modify in place. The main link between DocTree and widget tree would be the other way round. Each DocTreeNode would have a pointer to the widget that is responsible for displaying it - we might need further information like the word indices if a single widget displays multiple DocTreeNodes.

Dec. 12, 2009

display: inline

by corvid＠lavabit.com

Johannes wrote: > Ok, I understand your concerns now. > It might be better to simply not create dw-widgets in the > display:none case. At least we should try that option to see if it's > simpler. My reasons are: > > * we would not pollute dw/* which is complex already. > dw/* would not look at style.display at all. > * as Tim mentioned, you can always switch off remote CSS to see > display:none stuff. > * it does not mean that elements with display:none would not be part > of the DOM tree, as the DOM tree will be separate from the widget tree. > > I also understand now your's and Tim's concerns about the style > pointer in struct Word. As soon as we start to modify styles in an > existing widget tree we will get into trouble with all those > pointers as we can't modify style objects in place. > > So I would propose to do display handling in html.cc. Your suggestion seems quite sensible to me now :) > Then we can convert Doctree to a real DOM tree. With that in place > we can come back to the style in struct Word issue. We might simply > have a pointer to the corresponding DoctreeNode, which could hold > the style. We might even drop the style sharing code then - but > let's see. Would dw/ understand the contents of DocTreeNodes?

Dec. 12, 2009

display: inline

by Johannes.Hofmann＠gmx.de

Hi, On Fri, Dec 11, 2009 at 08:53:18PM +0100, Johannes Hofmann wrote: > Hi, > > On Fri, Dec 11, 2009 at 07:46:33AM +0000, corvid wrote: > > Here's the nightmarish hackery that I ended up with > > while getting show/hide to work on display:none. > > There might be issues with the implementation - I need to look at it > in more detail - but the result is pretty amazing! > > Let me check your patch in detail... > > > bleh. > > But I realized it still won't work right for the case like > > <form action=...> > > <input type=text name=... value="something to right-click on"> > > <div style="display:none"> > > <textarea name=...> > > text > > </textarea> > > </div> > > </form> > > because I would have to start digging into display:none Textblocks in > > search of not-display:none form things, but then normally you don't want > > to display not-display:none things inside display:none...so...ummm... > > this is all a demonstration of what not to do. > > As for what _would_ be non-horrible, good question. > > > > I suppose a way just to toggle whether display:none is obeyed at all > > might be nicer for us, albeit not for the user. Ok, I understand your concerns now. It might be better to simply not create dw-widgets in the display:none case. At least we should try that option to see if it's simpler. My reasons are: * we would not pollute dw/* which is complex already. dw/* would not look at style.display at all. * as Tim mentioned, you can always switch off remote CSS to see display:none stuff. * it does not mean that elements with display:none would not be part of the DOM tree, as the DOM tree will be separate from the widget tree. I also understand now your's and Tim's concerns about the style pointer in struct Word. As soon as we start to modify styles in an existing widget tree we will get into trouble with all those pointers as we can't modify style objects in place. So I would propose to do display handling in html.cc. Then we can convert Doctree to a real DOM tree. With that in place we can come back to the style in struct Word issue. We might simply have a pointer to the corresponding DoctreeNode, which could hold the style. We might even drop the style sharing code then - but let's see. Here comes a simple example to demonstrate why I think DOM-tree and widget tree should be separate - and I suppose that this is what Sebastian also had in mind with his CSS plan. This piece of HTML: <html> <body> <ul> <li>foo</li> <li>ba<b>r</b></li> </ul> </body> </html> results in: DOM-Tree: Widget-Tree: ========= ============ html | body Textblock | | ul Textblock / \ / \ li li AlignedTextblock AlignedTextblock | b whereas: <html> <body> <ul> <li style="display: inline">foo</li> <li>ba<b>r</b></li> </ul> </body> </html> results in: DOM-Tree: Widget-Tree: ========= ============ html | body Textblock | | ul Textblock / \ | li li AlignedTextblock | b Cheers, Johannes

Dec. 12, 2009

Adding CSS properties and values

by Johannes.Hofmann＠gmx.de

Hi Tim, On Fri, Dec 11, 2009 at 10:53:17PM +0100, Tim Nieradzik wrote: > I've just started work on support for the "float" property but I'm > already running into difficulties when trying to add the detection for > its values. > > Every website gets screwed up after applying my patch. Any ideas? The problem is that you added more CSS_PROPERTY_* values. The CSS_PROPERTY_* values need to correspond with the CssPropertyInfo in cssparser.cc. By inserting CSS_PROPERTY_* values all properties after CSS_PROPERTY_FLOAT_LEFT will no longer match. But you don't need to add CSS_PROPERTY_* values anyway. There is one CSS_PROPERTY_* value for each CSS property (http://www.w3.org/TR/CSS2/) For floats there is only one property "float" for which there is already CSS_PROPERTY_FLOAT in css.hh. It can have the values you correctly defined in Css_float_enum_vals. So your patch looks good, just leave out the change in css.hh. But that was the easy part... The real problem is what to do with those values. We need a way to render floating elements in dw/* Johannes > > --Tim > diff --git a/src/css.hh b/src/css.hh > index 79ba302..815c14a 100644 > --- a/src/css.hh > +++ b/src/css.hh > @@ -166,7 +166,9 @@ typedef enum { > CSS_PROPERTY_DIRECTION, > CSS_PROPERTY_DISPLAY, > CSS_PROPERTY_EMPTY_CELLS, > - CSS_PROPERTY_FLOAT, > + CSS_PROPERTY_FLOAT_LEFT, > + CSS_PROPERTY_FLOAT_RIGHT, > + CSS_PROPERTY_FLOAT_NONE, > CSS_PROPERTY_FONT_FAMILY, > CSS_PROPERTY_FONT_SIZE, > CSS_PROPERTY_FONT_SIZE_ADJUST, > diff --git a/src/cssparser.cc b/src/cssparser.cc > index 5f5bde0..4b6c2ad 100644 > --- a/src/cssparser.cc > +++ b/src/cssparser.cc > @@ -101,6 +101,10 @@ static const char *const Css_text_decoration_enum_vals[] = { > "underline", "overline", "line-through", "blink", NULL > }; > > +static const char *const Css_float_enum_vals[] = { > + "left", "right", "none", NULL > +}; > + > static const char *const Css_vertical_align_vals[] = { > "top", "bottom", "middle", "baseline", "sub", "super", NULL > }; > @@ -145,7 +149,7 @@ const CssPropertyInfo Css_property_info[CSS_PROPERTY_LAST] = { > {"direction", {CSS_TYPE_UNUSED}, NULL}, > {"display", {CSS_TYPE_ENUM, CSS_TYPE_UNUSED}, Css_display_enum_vals}, > {"empty-cells", {CSS_TYPE_UNUSED}, NULL}, > - {"float", {CSS_TYPE_UNUSED}, NULL}, > + {"float", {CSS_TYPE_ENUM, CSS_TYPE_UNUSED}, Css_float_enum_vals}, > {"font-family", {CSS_TYPE_SYMBOL, CSS_TYPE_UNUSED}, NULL}, > {"font-size", {CSS_TYPE_ENUM, CSS_TYPE_LENGTH_PERCENTAGE, CSS_TYPE_UNUSED}, > Css_font_size_enum_vals}, > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Dec. 11, 2009

Adding CSS properties and values

by tim.nieradzik＠gmx.de

I've just started work on support for the "float" property but I'm already running into difficulties when trying to add the detection for its values. Every website gets screwed up after applying my patch. Any ideas? --Tim

Dec. 11, 2009

display: inline

by Johannes.Hofmann＠gmx.de

On Wed, Dec 09, 2009 at 09:07:53PM +0100, Tim Nieradzik wrote: > > Just yesterday, I added the DISPLAY_NONE to dillo mainline, just as > > you did here :-) > > Oh, I just had a look at your private repository and noticed that it > wasn't yet implemented. :) > > > I'm still uncertain on what to do in case that DISPLAY_NONE is set. > > As you noticed it's not enough to not call the tag open functions, > > as text will still be added. > > I'd suggest to add the elements to the dw representation regardless of > their "display" value. But we should introduce a 'flag' that disables > drawing of elements with "display: none". > > > Also I don't know, whether e.g. inputs in forms which have > > DISPLAY_NONE, should send their contents to the server in case of > > submit, or should they be just non-existent? > > Since CSS only "describes the presentation semantics" (Wikipedia), the > form elements are still available but 'hidden'. In Gecko, the DOM > contains hidden elements as well. "display: none" is commonly used for > menus: With the help of JavaScript, you could fiddle inside the DOM and > toggle "display"-value to make the submenu visible. Yes, that's a problem. We definately need a way to toggle the hidden state. Otherwise pages get less accessible as we don't support JavaScript. > > > Regarding tagIsDisplayEnabled, I don't quite follow what you > > intended? I had added this flag to gradually transform the > > Html_tag_open_*() functions to the new display handling. It > > can only be removed once all these functions have been converted. > > I thought the only sense in implementing tagIsDisplayEnabled was to > prevent Dillo to crash? While playing around with DISPLAY_NONE > detection, the "stack->getRef (stack->size () - 1)->style == NULL" > assert failed for Html_tag_open_body(). Checking > html->styleEngine->style ()->display for DISPLAY_NONE resulted in > initializing the style engine too early. > > > Hm, maybe you are right and as long as the corresponding tags are > > set to DISPLAY_INLINE, which is the default, it would work even > > without the tagIsDisplayEnabled flag. Anyway, I think it's still a > > good marker to see which functions have been converted. > > To what extent would they need to be converted? Why do we care at all if > a tag supports the "display" attribute? Currently the Html_tag_open_*() functions add textblocks, or parbreaks as it fits. The idea is to convert them so that they only do HTML specific attribute parsing, setNonCssHints()-handling, and HTML error reporting. Building the dw widget tree would be solely determined by the current style (mainly the display part). I want to make this transition gradually, leaving e.g. forms and tables as they are atm. Cheers, Johannes

Dec. 9, 2009

display: inline

by Johannes.Hofmann＠gmx.de

On Wed, Dec 09, 2009 at 08:47:46PM +0000, corvid wrote: > Tim wrote: > > > I'm still uncertain on what to do in case that DISPLAY_NONE is set. > > > As you noticed it's not enough to not call the tag open functions, > > > as text will still be added. > > > > I'd suggest to add the elements to the dw representation regardless of > > their "display" value. > > This sounds right to me, too. I'll take a look at preventing them from > being drawn and taking up space. Great, it showing and hiding of hidden form entries works nicely already. > > Also, iterators would have to ignore undisplayed words for copying text. > Is there any case where iterators would need to be able to notice them? No, I don't thinks so. For searching and text selection it should not be needed.

Dec. 9, 2009

display: inline

by tim.nieradzik＠gmx.de

> Is there any case where iterators would need to be able to notice them? No, I don't think so. As for form submitting (src/form.cc) the EmbedIterator is not used at all. The input fields refer directly to the matching embed object (see Html_add_input()). --Tim

Dec. 9, 2009

display: inline

by corvid＠lavabit.com

Tim wrote: > > I'm still uncertain on what to do in case that DISPLAY_NONE is set. > > As you noticed it's not enough to not call the tag open functions, > > as text will still be added. > > I'd suggest to add the elements to the dw representation regardless of > their "display" value. This sounds right to me, too. I'll take a look at preventing them from being drawn and taking up space. Also, iterators would have to ignore undisplayed words for copying text. Is there any case where iterators would need to be able to notice them?

Dec. 9, 2009