Hi, here comes my proposal to get css support started. Note that I'm new to this stuff so I will probabely simplify things a lot and miss many issues that will have to be addressed later on. * Separate out the style handling from html.cc in a new class StyleEngine (better name welcome). This class will be fed the html tree via a SAX like interface as the document is parsed and will hand out the current Style object. * Initially StyleEngine will be implemented to just mimic the current behaviour of html.cc. So after this step everything should work as currently. * Then we can design the data structures to hold parsed css data and make StyleEngine use these structures which will be statically filled initially. Again dillo should work as it does now. * Next we can implement a css parser that is able to fill the data structures from the last step. Now we should already be able to set a fixed user style sheet. * Hooking up the css parser to automatically load css information as referenced in html pages would be next. * In parallel to all this we would need to make floating objects work in dw/textblock.cc. This approach has some issues. In contrast to http://www.dillo.org/CSS.html it would only be possible to apply style information that is available when starting parsing of a document. However we could start rendering with what style information is available and reload once all css files have been loaded. Currently dillo parses attributes on demand. So we don't have a complete list of attributes and their values. As StyleEngine might access any attribute, we might need to change this. Comments or more advanced plans would be more than welcome! Cheers, Johannes
Johannes wrote:
This approach has some issues. In contrast to http://www.dillo.org/CSS.html it would only be possible to apply style information that is available when starting parsing of a document. However we could start rendering with what style information is available and reload once all css files have been loaded.
So is the idea that your method is more lightweight and a repush() once the CSS arrives looks the same as applying the CSS on the fly? If this is deemed superior, there might be things we could rip out of dw that were written with the other scheme in mind.
On Wed, Oct 22, 2008 at 10:33:44PM +0000, corvid wrote:
Johannes wrote:
This approach has some issues. In contrast to http://www.dillo.org/CSS.html it would only be possible to apply style information that is available when starting parsing of a document. However we could start rendering with what style information is available and reload once all css files have been loaded.
So is the idea that your method is more lightweight and a repush() once the CSS arrives looks the same as applying the CSS on the fly?
That's the idea.
If this is deemed superior, there might be things we could rip out of dw that were written with the other scheme in mind.
No, I don't think this is superior. However, we need to be able to apply available styles while parsing anyway. So I would start coding that. And maybe this together with the repush thing gives acceptable behaviour already. Cheers, Johannes
On Wed, Oct 22, 2008 at 06:36:33PM +0200, Johannes Hofmann wrote:
Hi,
here comes my proposal to get css support started. Note that I'm new to this stuff so I will probabely simplify things a lot and miss many issues that will have to be addressed later on.
I like this approach, but please note I'm also new to CSS stuff. Sebastian was the main expert, and he used to give a lot of thought to things before implementing, so I'd rather keep what's in dw2 instead of removing/making changes, at least until more solid knowledge is gained. http://www.dillo.org/CSS.html was written circa 2003, so dw2 probably has a smoother design for CSS. Now, what I like of this approach is it's simplicity and that more or less it's understandable. :)
* Separate out the style handling from html.cc in a new class StyleEngine (better name welcome). This class will be fed the html tree via a SAX like interface as the document is parsed and will hand out the current Style object.
By "html tree" do you mean the generated DOM tree? (which scripting would need BTW).
* Initially StyleEngine will be implemented to just mimic the current behaviour of html.cc. So after this step everything should work as currently.
* Does this mean StyleEngine should understand and parse plain HTML style attributes too (e.g. bgcolor="#FEFEFE")? (I assume it'll parse inline CSS). * Or will it get a style object made by the HTML parser? * In case of clash, which one takes precedence, HTML attribute or CSS style? Please elaborate a bit more on this.
* Then we can design the data structures to hold parsed css data and make StyleEngine use these structures which will be statically filled initially. Again dillo should work as it does now.
OK.
* Next we can implement a css parser that is able to fill the data structures from the last step. Now we should already be able to set a fixed user style sheet.
OK.
* Hooking up the css parser to automatically load css information as referenced in html pages would be next.
OK. BTW, this is simple.
* In parallel to all this we would need to make floating objects work in dw/textblock.cc.
Yay! BTW, currently I don't know which of these two is more urgent: * floats in textblock. * DIV element. I'd say DIV. Anyway, I'd follow a bit the simple/complex CSS attributes division, and start with the simpler ones (as colors). Then go filling the gaps one at a time.
This approach has some issues. In contrast to http://www.dillo.org/CSS.html it would only be possible to apply style information that is available when starting parsing of a document. However we could start rendering with what style information is available and reload once all css files have been loaded.
It looks more than suitable for a first approach. Complex CSS attributes may change the widget tree. So a repush is necessary in this case anyway.
Currently dillo parses attributes on demand. So we don't have a complete list of attributes and their values. As StyleEngine might access any attribute, we might need to change this.
Comments or more advanced plans would be more than welcome!
Let's refine the plan, and once agreed, assign the tasks. -- Cheers Jorge.-
On Fri, Oct 24, 2008 at 11:28:01AM -0300, Jorge Arellano Cid wrote:
On Wed, Oct 22, 2008 at 06:36:33PM +0200, Johannes Hofmann wrote:
Hi,
here comes my proposal to get css support started. Note that I'm new to this stuff so I will probabely simplify things a lot and miss many issues that will have to be addressed later on.
I like this approach, but please note I'm also new to CSS stuff. Sebastian was the main expert, and he used to give a lot of thought to things before implementing, so I'd rather keep what's in dw2 instead of removing/making changes, at least until more solid knowledge is gained.
I don't intend to change/remove anything in dw/.
http://www.dillo.org/CSS.html was written circa 2003, so dw2 probably has a smoother design for CSS.
Yes, it was obviously designed with CSS in mind.
Now, what I like of this approach is it's simplicity and that more or less it's understandable. :)
That's the main point. As we are probabely all new to CSS, let's start simple.
* Separate out the style handling from html.cc in a new class StyleEngine (better name welcome). This class will be fed the html tree via a SAX like interface as the document is parsed and will hand out the current Style object.
By "html tree" do you mean the generated DOM tree? (which scripting would need BTW).
No, for now I would not create a DOM tree at all. We may come back to this later.
* Initially StyleEngine will be implemented to just mimic the current behaviour of html.cc. So after this step everything should work as currently.
* Does this mean StyleEngine should understand and parse plain HTML style attributes too (e.g. bgcolor="#FEFEFE")?
No. I would keep that in html.cc.
(I assume it'll parse inline CSS).
Yes.
* Or will it get a style object made by the HTML parser?
I currently think about a class that looks more or less like StyleAttrs together with a map indicating which of it's values are actually set. One can then start with a basic style and apply any number of objects of this new class according to the order of precedence. Applying here means overriding those values that are set according to the map.
* In case of clash, which one takes precedence, HTML attribute or CSS style?
According to http://www.w3.org/TR/CSS2/cascade.html such attributes are overidden by CSS and it's not even required for a CSS capable browser to honor them at all.
Please elaborate a bit more on this.
* Then we can design the data structures to hold parsed css data and make StyleEngine use these structures which will be statically filled initially. Again dillo should work as it does now.
OK.
* Next we can implement a css parser that is able to fill the data structures from the last step. Now we should already be able to set a fixed user style sheet.
OK.
* Hooking up the css parser to automatically load css information as referenced in html pages would be next.
OK. BTW, this is simple.
* In parallel to all this we would need to make floating objects work in dw/textblock.cc.
Yay!
BTW, currently I don't know which of these two is more urgent: * floats in textblock. * DIV element.
I'd say DIV.
Anyway, I'd follow a bit the simple/complex CSS attributes division, and start with the simpler ones (as colors). Then go filling the gaps one at a time.
This approach has some issues. In contrast to http://www.dillo.org/CSS.html it would only be possible to apply style information that is available when starting parsing of a document. However we could start rendering with what style information is available and reload once all css files have been loaded.
It looks more than suitable for a first approach.
Complex CSS attributes may change the widget tree. So a repush is necessary in this case anyway.
Currently dillo parses attributes on demand. So we don't have a complete list of attributes and their values. As StyleEngine might access any attribute, we might need to change this.
Comments or more advanced plans would be more than welcome!
Let's refine the plan, and once agreed, assign the tasks.
Cheers, Johannes
On Fri, Oct 24, 2008 at 06:30:59PM +0200, Johannes Hofmann wrote:
On Fri, Oct 24, 2008 at 11:28:01AM -0300, Jorge Arellano Cid wrote:
On Wed, Oct 22, 2008 at 06:36:33PM +0200, Johannes Hofmann wrote:
Hi,
here comes my proposal to get css support started. Note that I'm new to this stuff so I will probabely simplify things a lot and miss many issues that will have to be addressed later on.
I like this approach, but please note I'm also new to CSS stuff. Sebastian was the main expert, and he used to give a lot of thought to things before implementing, so I'd rather keep what's in dw2 instead of removing/making changes, at least until more solid knowledge is gained.
I don't intend to change/remove anything in dw/.
http://www.dillo.org/CSS.html was written circa 2003, so dw2 probably has a smoother design for CSS.
Yes, it was obviously designed with CSS in mind.
Now, what I like of this approach is it's simplicity and that more or less it's understandable. :)
That's the main point. As we are probabely all new to CSS, let's start simple.
* Separate out the style handling from html.cc in a new class StyleEngine (better name welcome). This class will be fed the html tree via a SAX like interface as the document is parsed and will hand out the current Style object.
By "html tree" do you mean the generated DOM tree? (which scripting would need BTW).
No, for now I would not create a DOM tree at all. We may come back to this later.
* Initially StyleEngine will be implemented to just mimic the current behaviour of html.cc. So after this step everything should work as currently.
* Does this mean StyleEngine should understand and parse plain HTML style attributes too (e.g. bgcolor="#FEFEFE")?
No. I would keep that in html.cc.
(I assume it'll parse inline CSS).
Yes.
* Or will it get a style object made by the HTML parser?
I currently think about a class that looks more or less like StyleAttrs together with a map indicating which of it's values are actually set. One can then start with a basic style and apply any number of objects of this new class according to the order of precedence. Applying here means overriding those values that are set according to the map.
Where/how would attribute values be stored?
* In case of clash, which one takes precedence, HTML attribute or CSS style?
According to http://www.w3.org/TR/CSS2/cascade.html such attributes are overidden by CSS and it's not even required for a CSS capable browser to honor them at all.
Thanks, I didn't have that info. -- Cheers Jorge.-
Hi, On Fri, Oct 24, 2008 at 03:09:53PM -0300, Jorge Arellano Cid wrote: ** snip **
I currently think about a class that looks more or less like StyleAttrs together with a map indicating which of it's values are actually set. One can then start with a basic style and apply any number of objects of this new class according to the order of precedence. Applying here means overriding those values that are set according to the map.
Where/how would attribute values be stored?
We will probabely need a new class that holds the attributes, but after looking at the dillo-0.8.0-css3 code I decided to go with just the "style", "id", and "class" attributes for now. Attached patch implements something between step 2 and 3 of my css proposal. There are a lot of loose ends (e.g. memory management) but it's a start. Check the end of css.cc. Here the user-agent style is filled. In html.cc Html_tag_open_a() shows how StyleEngine is intended to be used. Note that StyleEngine::apply() currently only supports a limited number of attributes. I think html.cc will become a lot simpler. Cheers, Johannes PS: I had attached the patch, but that was blocked by the list. So here is a link instead: http://www.ecademix.com/JohannesHofmann/tmp/css_prototype.dillo2
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de