October 2003 - Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Frank de Lange

Sebastian Geerken wrote: >Hi, > >I've only taken a glance at it, but made two changes to Frank's >work. The patch is attached, and is to be applied after Frank's patch: >The changes: > > - Fixed a bug in focus.c: Now, spaces are also drawn, between the > words of a multi-word link. Somewhere, it is documented, that you > have to highlight up to strlen(word->content.data.text) + 1, to > highlight also the space. > > - I've modified the page widget to draw the focus-highlighted text > with a border, not inverse, as done with found and selected text. > >Sebastian > > {Have you thought about | Is there} a way to highlight text using a pattern (like the 'gray-out' highlight for images)? I have explicitly not used a line-stile highlight for keyboard focus, because this makes it often hard to see where focus is. Links are sometimes small, no more than a '*' or a subscripted number. A line-style highlight is hard to see in those cases... I do agree that it is necessary to use a different highlight style for focus, search and selection, but the traditional focus highlight ((dotted/dashed) line around word) is not very useful in many cases. This goes even more for people with bad eyesight. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Oct. 20, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Frank de Lange

Sebastian Geerken wrote: >Hi, > >I've only taken a glance at it, but made two changes to Frank's >work. The patch is attached, and is to be applied after Frank's patch: >The changes: > > - Fixed a bug in focus.c: Now, spaces are also drawn, between the > words of a multi-word link. Somewhere, it is documented, that you > have to highlight up to strlen(word->content.data.text) + 1, to > highlight also the space. > > Hmmm... that was intentional, so that focused links could be recognized more easily... Same for the next one by the way. Anyway, it would be even better if the focus could be drawn in another pattern or color, so that it is visible even when overlayed with a selection or found highlight. Btw, apart from looking only fleetingly at it, did you try keyboard navigation? If so, any remarks about the functionality itself? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Oct. 20, 2003

Re: [Dillo-dev] FLTK

by Melvin Hadasht

[Thanks Indan for your reply] > If > the only reason to switch to GTK2 is to have better fonts support, then > I > would just stick to GTK 1 and use the freetype library directly, > something > along the line of prerendered fonts and use them as small pictures, > whatever is fastest. According to http://www.dillo.org/Notes.html, Gtk+ is seen as a mean to support Unicode, not as a mean to display "nice" fonts. But the issue of font rendering speed is also there and as you suggest, these can be optimized depending on context. > Personally I don't need unicode support, can > understand that there are a lot people that need or want it, but maybe > it's not Dillo's task to support it, maybe a poll on the main website to > ask the users about it? For me CSS support is much more important than > most other features. Personnaly, I'd prefere Unicode support (or more precisely multi languages support), than CSS support. I personnaly do not browse only English web pages, and as the Internet is meant to allow information sharing throughout the world, I think Unicode and multi-language support is important. IMO, more important than CSS support, but I let developers decide which is more important and which is easier to implement and which will be implemented first, as each feature depend not only on user wishes but also on available resources. I think Gtk+2 is a nice library which is meant for ease of use and to fullfill most developers wishes in an easy way. This introduces some more abstraction and generalization in the way its widgets are implemented at the cost of specialized and optimized implementations. On modern hardware (>1Ghz, not like my 266Mhz chip), the slower than gtk1.2 library should still be quite usable (although, I did not test it on fast hardware). For example, the GtkTreeView: it is a very flexible widget and provides many features, but it is not a specialized widget anymore, so it is way slower than GtkCList or GtkCTree (AFAIS, it is not used in Thunderbird). Concerning Pango, it has to analyze each string to decide with which rendering engine the string will be rendered, this implies analyzing each character to determine to which language class it belongs, if there are RightToLeft and LeftToRight words etc... Each language may use a different set of fonts, and each font must be checked for its size. This computation is complex so to achieve fast rendering Pango should be studied carefully and rendering or drawing (on the expose events) algorithms should hand crafted. For example, maybe knowing that the page is in a certain non-unicode encoding, we could spare Pango some of its computation if Pango API allows such approach. So to summarize: I think porting Gtk+2 would need a quite deep knowledge of Pango and Gtk2 drawing pipeline and even more efforts on optimizations, as Dillo is meant to be a fast browser before being feature- rich browser. -- Melvin Hadasht

Oct. 19, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Sebastian Geerken

Hi, I've only taken a glance at it, but made two changes to Frank's work. The patch is attached, and is to be applied after Frank's patch: The changes: - Fixed a bug in focus.c: Now, spaces are also drawn, between the words of a multi-word link. Somewhere, it is documented, that you have to highlight up to strlen(word->content.data.text) + 1, to highlight also the space. - I've modified the page widget to draw the focus-highlighted text with a border, not inverse, as done with found and selected text. Sebastian

Oct. 19, 2003

Re: [Dillo-dev] Re: /. crap

by Eric GAUDET

...tidy... > OK, your response ( and the others ) has convinced me that this was a > bad idea :) > :-) More generally, my point was: there's a lot to do to improve Dillo, let's not waste our time fixing problems that are not supposed to exist in the first place. > I realize this thread comes up periodically, I only mentioned it this > time because it was a way of minimizing the problem outside of the > core, by reusing existing tools (like tidy). Also, it gets tiresome > loading up another browser after a while with large sites, like > slashdot, that can't easily fix their problems. ( That's one downside > of using dillo - once you get used it, it's hard to tolerate anything > else :) > Tidy is actually an excellent idea ... server side :-) This /. guy should give it a try. On the other hand, fixing a broken page client side everytime it's loaded really sounds terrible. About the list of excuses given for not fixing the bug right away, the only real one is the management's priorities. As for the rest, I would just say: - not fixing bugs because some customers rely on them is bad for business; - not fixing bugs beacuse it has a lot of dependencies tell the design is probably wrong; - not fixing bugs because "it's complicated" is really lame; - "why would anybody write a browser from scratch?" why would anybody do anyting? let's all use windos and IE6! Best, EG

Oct. 19, 2003

Re: [Dillo-dev] Re: /. crap

by Stephen Lewis

On Sat, Oct 18, 2003 at 08:19:49PM -0700, Eric GAUDET wrote: > -- En reponse de "Re: [Dillo-dev] Re: /. crap" de Geoff Lane, le > 18-Oct-2003 : > >> I have a suggestion regarding this: > >> While supporting broken HTML isn't really in the project goals, > >> would it be possible to wrap a tool like htmltidy using the dpi? > >> > >> So that dillo itself never even gets delivered broken HTML at all, > >> becauses it's all been pre-processed into something valid... > > > > One of the objections to accepting and attempting to display broken HTML > > is that you have no idea if the browser interpretation of the bad HTML > > matches the intention of the author. <snip> > The only effort we make towards broken html is trying as hard as we can not > to segfault. If a broken page is not rendering properly in Dillo (or any > browser), it's a bug in the page, not a bug in Dillo. Period. OK, your response ( and the others ) has convinced me that this was a bad idea :) I realize this thread comes up periodically, I only mentioned it this time because it was a way of minimizing the problem outside of the core, by reusing existing tools (like tidy). Also, it gets tiresome loading up another browser after a while with large sites, like slashdot, that can't easily fix their problems. ( That's one downside of using dillo - once you get used it, it's hard to tolerate anything else :) -- Stephen Lewis

Oct. 19, 2003

Re: [Dillo-dev] Re: /. crap

by Eric GAUDET

-- En reponse de "Re: [Dillo-dev] Re: /. crap" de Geoff Lane, le 18-Oct-2003 : >> I have a suggestion regarding this: >> While supporting broken HTML isn't really in the project goals, >> would it be possible to wrap a tool like htmltidy using the dpi? >> >> So that dillo itself never even gets delivered broken HTML at all, >> becauses it's all been pre-processed into something valid... > > One of the objections to accepting and attempting to display broken HTML > is that you have no idea if the browser interpretation of the bad HTML > matches the intention of the author. Not only that, but it is also a significant effort to : - detect that the html is broken (it can have thousands of different problems) - pick the right fix for it (the one that most browser will agree on, because there's no standard for rendering broken pages, by definition) - fix it so it displays somewhat properly (meaning, change the internal representation of the page) By "significant effort", I mean we need develpment time to add a lot of non-trivial error recovery code, and also it will slow down the rendering process because it will need some sort of second-pass parsing of the page. That's why Dillo's attitude is to stick to the standard, not because we're standard fanatics: that's the only way to have a bounded and reliable definitoin of what rendering should be. The only effort we make towards broken html is trying as hard as we can not to segfault. If a broken page is not rendering properly in Dillo (or any browser), it's a bug in the page, not a bug in Dillo. Period. Best, Eric ------------------------------------------------------------------------ Eric GAUDET <eric(a)rti-zone.org> Le 18-Oct-2003 a 20:10:05 "Parler pour ne rien dire et ne rien dire pour parler sont les deux principes majeurs et rigoureux de tous ceux qui feraient mieux de la fermer avant de l'ouvrir." ------------------------------------------------------------------------

Oct. 19, 2003

XHTML (was Re: /. crap)

by Kelson Vibber

On Saturday 18 October 2003 5:50 pm, Ivo wrote: > On Sunday 19 October 2003 01:53, Kelson Vibber wrote: > > I believe that's the reason the XHTML spec says it should not even be > > rendered if it's invalid. And believe me, this is a good way to ensure > > you've got valid code. > > Does this also work on IE? If it does, God forbid the day that some bright > engineer at MS decides they should change their code to try to render it > anyway. No, IE doesn't handle XHTML at all. However, XHTML was designed with backward compatibility in mind. If an XHTML page is sent with the content type text/html, it looks like HTML 4.01 with a few extra attributes that can be ignored. The content type for XHTML, application/xhtml+xml, is only recognized by a few browsers right now, possibly only the Gecko-based ones and Amaya. Since Mozilla trusts the server to send the correct mime type, it assumes that a text/html page is HTML, not XHTML, and parses it as HTML. Any errors found are treated the same way it treats errors in HTML. It's only when it's served with the XHTML mime type that Mozilla enforces the well-formed XML requirement. IE can trash XHTML if you're not careful, though - since IE assumes the server is likely to be misconfigured, it will sometimes see the XML declarations at the beginning of an XHTML file and try to display it as plain XML, even if your server has told it the file is HTML. I saw this when I had more than one stylesheet attached as an XML declaration. Browsers that really display XHTML (through an XML parser, requiring it to be well-formed) should put application/xhtml+xml in their HTTP Accept header. (Gecko browsers do.) Documents in XHTML 1.1 or using features only found in XHTML should always be served with this mime type. For XHTML 1.0 documents intended for a wider audience, the server should use content negotiation to determine which the browser can handle, and serve either text/html or application/xhtml+xml. I should mention that, AFAIK, the don't-even-render-it rule only applies to XML well-formedness. So mis-nested or extra tags (like the extra </td></tr> in Slashdot) would cause the browser to display an error, but unfamiliar tags (such as RDF embedded in XHTML) would simply be ignored as long as they don't invalidate the XML structure. For example, you can serve the following: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head><title>Blah</title></head> <body> <h1>Header</h1> <blargquote><img src="whatever.jpg" /></blargquote> </body> </html> ...and it will display the way you would expect - ignoring the fictitious "blargquote" element (which would be caught by a validator). But if you instead do this (note the missing close tag for blockquote): <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head><title>Blah</title></head> <body> <h1>Header</h1> <blockquote><img src="whatever.jpg" /> </body> </html> ... Mozilla will display this error message: XML Parsing Error: mismatched tag. Expected: </blockquote>. Location: test.xhtml Line Number 8, Column 3: </body> --^ But if you send the exact same file with the text/html content type, it will use the HTML parser and try to guess where the blockquote is supposed to end. -- Kelson Vibber www.hyperborea.org

Oct. 19, 2003

localhost

by Ivo

Hi all, I noticed the following behaviour, with 0.7.3 and also with the current CVS (just checked out the latest version an hour ago). When I type the following at the location bar: http://www.cnn.com/ Opens the webpage (offcourse) www.cnn.com Opens the webpage (it prepends http://) http://localhost/ Connects to my webserver localhost Connects to my webserver (prepends http://) http://localhost:2317/ It connects to my geneweb server localhost:2317 It fails, saying ERROR: unsupported protocol Is this normal and expected behaviour, or considered a bug? Opera, for example, prepends http:// and all works like expected. --Ivo

Oct. 19, 2003

Re: [Dillo-dev] Re: /. crap

by Ivo

On Sunday 19 October 2003 01:53, Kelson Vibber wrote: > I believe that's the reason the XHTML spec says it should not even be > rendered if it's invalid. And believe me, this is a good way to ensure > you've got valid code. Does this also work on IE? If it does, God forbid the day that some bright engineer at MS decides they should change their code to try to render it anyway. --Ivo

Oct. 19, 2003