- Dillo-dev - lists.mailman3.com

css

by Johannes.Hofmann＠gmx.de

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

Oct. 24, 2008

https error handling

by james＠bsdgroup.org

What do you guys think about limiting the https certificate errors to one per page request, and not one per each item within the page request. Hopefully that makes sense. The issue is when you go to a site like [0] and don't have the issuing cert installed, in this case Valicert and GoDaddy, you get bombarded with tons of dialogs asking you to continue or cancel. I've tried to come up with a way myself, without much luck. Any ideas? [0] https://https.openbsd.org/cgi-bin/order -- James Turner BSD Group Consulting http://www.bsdgroup.org

Oct. 24, 2008

pasting URL

by jcid＠dillo.org

On Thu, Oct 23, 2008 at 01:07:32AM +0200, Thomas Orgis wrote: > Am Wed, 22 Oct 2008 22:46:52 +0100 > schrieb higuita <higuita7(a)yahoo.co.uk>: > > > you can already paste a URL to the X icon in the urlbar and it > > will load... > > Indeed. Good to know. > > > the midle click on the body is reserved to dragging the page > > Now that's funny. I have my middle button configured to emulate scroll > wheels when pressed+dragging (EmulateWheel option in Xorg config). > This is kindof convenient in all around X11, especiall with a > trackpoint or trackball... > The funny part is that this Xorg feature hides the middle click + dragging > action from dillo -- it gets vertical and horizontal scroll events instead, > while the single middle click that could paste the URL (let through by > Xorg, because of EmulateWheelclickToo) is blocked from that by dillo, which > prepares for movement of the mouse -- which is impossible to get in this > config. > > So an unreachable feature of dillo (dragging) makes a different expected > feature (middle-click pasting into window) unreachable. > > I envision making this configurable in dillo (deactivate dragging to > activate pasting)... or recreate the EmulateWheelclickToo behaviour to > use the isolated click for the differing action. Please try the attached patch and let us know how it works for you. If you're a developer you may send me a patch with the middle_click_dragscrolls_page=YES dillorc option that went set to NO acts as the attached patch. -- Cheers Jorge.-

Oct. 24, 2008

pasting URL

by jcid＠dillo.org

On Thu, Oct 23, 2008 at 01:07:32AM +0200, Thomas Orgis wrote: > Am Wed, 22 Oct 2008 22:46:52 +0100 > schrieb higuita <higuita7(a)yahoo.co.uk>: > > > you can already paste a URL to the X icon in the urlbar and it > > will load... > > Indeed. Good to know. > > > the midle click on the body is reserved to dragging the page > > Now that's funny. I have my middle button configured to emulate scroll > wheels when pressed+dragging (EmulateWheel option in Xorg config). > This is kindof convenient in all around X11, especiall with a > trackpoint or trackball... > The funny part is that this Xorg feature hides the middle click + dragging > action from dillo -- it gets vertical and horizontal scroll events instead, > while the single middle click that could paste the URL (let through by > Xorg, because of EmulateWheelclickToo) is blocked from that by dillo, which > prepares for movement of the mouse -- which is impossible to get in this > config. > > So an unreachable feature of dillo (dragging) makes a different expected > feature (middle-click pasting into window) unreachable. > > I envision making this configurable in dillo (deactivate dragging to > activate pasting)... or recreate the EmulateWheelclickToo behaviour to > use the isolated click for the differing action. Agreed. -- Cheers Jorge.-

Oct. 24, 2008

css

by jcid＠dillo.org

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.-

Oct. 24, 2008