Hi Jorge, On Tue, Oct 12, 2010 at 02:59:24PM -0300, Jorge Arellano Cid wrote:
On Mon, Oct 11, 2010 at 11:08:11PM +0200, Johannes Hofmann wrote:
On Mon, Oct 11, 2010 at 01:33:17PM -0300, Jorge Arellano Cid wrote:
Hi,
With regard to:
1 provide a dillo css compatibility table (and keep it up to date) 2 optimizing line-breaks - i.e. break at '-' but don't break e.g. <b>D</b>illo (after the 'D'). 3 support for 4 support for text-indent 5 support font-variant 6 support more vertical-align options 7 make thickness of lines for underline and line-through depending on the font size and weight 8 support more border-style options (dotted, dashed ...) 9 support border-collapse (table related)
5 and 7 are in testing phase (in the repo). AFAIK, 2,3,4,6,8 and 9 are open, with some work done for 6 by corvid.
After the big table rendering work long ago, I'm studying the tables code again.
Please notice that the doxygen dw documentation on table algorithms (the math formulas part) is not up-to-date. It's done in a different way since the big patch.
My idea is to refresh my memory on this part of the code, and then to try to devise a way to implement 8 and 9. At the same time, working on this part will help for 6.
Most probably we'll have to try to tackle these complex problems coordinating our effort/knowledge. I'll be in better shape to help with this after working for a while on tables.
@Johannes, @corvid, please state what are your plans for work on these remaining parts (if there's one already).
I'm still working on CSS for the <html>-element (the issue reported by Jeremy). As my original patch had issues with pages that have multiple <head> elements, I decided to make some major changes to the StyleEngine-API. It looks ok now, but I need to do some more tests.
I'm working on 9, and so far haven't found a convenient way to tweak CSS atributes for a certain element (most probably my fault). For instance, margin and padding are not meant as usual for tables (CSS2 SPEC), see the difference between FF and dillo here:
Oh, "The collapsing border model" in the spec looks tricky :-)
The only way I've found is to set a hard value in postprocessAttrs(), but not yet a way to do it from Html_tag_open_table().
As you're working on the API, please give me some hints on how it works.
The basic idea is that the stuff in css.cc is doing pure CSS and does not care about the actual implementation or rendering in dw/*. StyleEngine then translates this to dw::core::style::Style objects (which also were designed with CSS in mind).
As currently the cell border, padding and margin are drawn by the cell widget (textblock) inside a table, the general idea is to make textblock consider "collapse" mode when inside a table.
postprocessAttrs() does not take into account in which element we currently are (e.g. <table>, <td>, ...) You could check whether you currently are in a certain element by looking at doctree->top ()->element and do special things for certain elements. However looking at "The collapsing border model" I'm not sure whether you can get away with leaving the dw/* code as it is and just fiddling with the Style objects. For example if you have <td>1</td><td>2</td> There currently is no way to get the style of the first <td> when creating the style of the second <td> in StyleEngine - which you would need to compute the thickness of the border between the two. Actually we can't play with the values of the Style object in postprocessAttrs() as we like. They must contain what the spec mentions as "computed value". And as I read the spec, the computed value of e.g. border-width does not depend on the value of border-collapse. What *might* work is to take the Style object that StyleEngine gives you and modify it in in case that border-collapse is set before passing it to the table cell in src/table.cc:293.
Another approach is to make dw::table render its borders and margin, and only leave padding to the cell widget.
Yes, that's the other way to do it. You could still reuse the border drawing helper routines from style.cc. Nevertheless it might be pretty complex. Not sure if it is really worth it... - but of course I don't want to discourage you :-) Cheers, Johannes