- Dillo-dev - lists.mailman3.com

[Dillo-dev]javascript links

by Jorge Arellano Cid

Hi there, The CVS is just updated for 0.8.2-pre. The first patch is a tiny handler for javascript links. It's very simple, it will try to make a normal link from a javascript-based href. Please test it and tell me how it works. Cheers Jorge.-

May 21, 2004

Re: [Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)

by Jorge Arellano Cid

On Fri, 21 May 2004, Sebastian Geerken wrote: > On Mon, May 17, Jorge Arellano Cid wrote: > > > > Hi Sebastian, > > > > This HTML example shows the black row (after patch): > > [...] > > The DwPage below the topmost table gets an additional word, most > probably a break, which it should not (and which it does not get with > the unmodified parser). What the modified HTML parser does, seems > still a bit immature. Actually it's not the changes to the parser, but to dw_page.c. If you pick a vanilla 0.8.1 and apply: + if (page->words[nw].orig_space != 0) { + /* We have already a space, add a blank word before. */ + a_Dw_page_add_text (page, g_strdup(""), style); + nw = page->num_words - 1; + } It will render the black row, even on the splash page. Cheers Jorge.-

May 21, 2004

Re: [Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)

by Jorge Arellano Cid

On Fri, 21 May 2004, Sebastian Geerken wrote: > On Fri, May 14, Jorge Arellano Cid wrote: > > [...] > > but what do we do with this: > > > > 'Some text' > > > > If we ignore white space after the start tag and before the end > > tag, it becomes > > > > 'Sometext' (with no space at all!) > > What I find indeed reasonable. (See below for my reasons.) Agreed. > > > If we "collapse" as the SPEC says should be done, we have two > > possibilities: > > What part of the spec do you refer to? HTML-4.01, sec 9.1: <q> [...] Note that a sequence of white spaces between words in the source document may result in an entirely different rendered inter-word spacing (except in the case of the PRE element). In particular, user agents should collapse input white space sequences when producing output inter-word space. This can and should be done even in the absence of language information (from the lang attribute, the HTTP"Content-Language" header field (see [RFC2616], section 14.12), user agent settings, etc.). [...] </q> > From what I have understood, > spaces should be collapsed at the raw data level. > That is, if you have > the part "Some text", it will be parsed into the following > tree: > > ... > `- > +- > | `- "Some " > `- "text" > > Then, the question is, what should be done with the space at the end > of "Some ". If "the raw data level" means that this: Some   text would be parsed as: `- +- | `- "Some   " `- "text" and after that, the final space removed, producing: `- +- | `- "Some  " `- "text" it seems a good idea for an implementation to me. > Generally, I'd like to stick to this tree view, and especially regard, > in this example, the words "Some " and "text" as lying in different > levels in the tree, not within a flat list. In the history, this was > not always very clear for HTML, but it is much clearer for XHTML. The > current parser does not actually build a tree, but should a bit like > as it does. Sorry, my english, what does "a bit like as it does" mean? > This approach makes also the new HTML parser in the CSS > prototype simpler. Good. > > [...] > > AFAICT, the SPEC leaves the choice open, and advices HTML > > authors against whitespace inside the tags. > > > > IMO, always collapsing white space after the start tag and > ^^^^^^^^^^ > > I'd say, we should (for most elements) simply ignore whitespaces after > the opening tag, and before the closing tag. This solves generally the > problem with "Some underlined text.", and we should not > relate spaces in different elements, e.g. by collapsing them. Yes, "ignore" is a better word. > > Now, this solution would also account for the special SGML line > > break rules: > > > > <q source='HTML-4.01 SPEC B.3.1'> > > > > SGML (see [ISO8879], section 7.6.1) specifies that a line break > > immediately following a start tag must be ignored, as must a line > > break immediately before an end tag. This applies to all HTML > > elements without exception. > > > > The following two HTML examples must be rendered identically: > > > > Thomas is watching TV. > > > > > > Thomas is watching TV. > > > > > > So must the following two examples: > > > > <A>My favorite Website</A> > > > > <A> > > My favorite Website > > </A> > > > > </q> > > Rhis is actually something different: It is only about line breaks, > and it applies to *all* elements, including <pre>. If you consider that line breaks are also white space characters (HTML-4.01 sec 9.1), this becomes a special case of general white space handling. Cheers Jorge.- PS: It seems like we'll have to modify the parser to produce a parsing tree for CSS/XML to be supported properly.

May 21, 2004

Re: [Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)

by Sebastian Geerken

On Mon, May 17, Jorge Arellano Cid wrote: > > Hi Sebastian, > > This HTML example shows the black row (after patch): > [...] The DwPage below the topmost table gets an additional word, most probably a break, which it should not (and which it does not get with the unmodified parser). What the modified HTML parser does, seems still a bit immature. Sebastian

May 21, 2004

Re: [Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)

by Sebastian Geerken

On Fri, May 14, Jorge Arellano Cid wrote: > [...] > For instance: > > > A different case is "Some text". Your patch will make > > "Some text" of it, but it should be really be > > "Some text." > > Yes, I agree, "collapsing" here should be: > > 'Some text' => > 'Some text' > > as you note. > > but what do we do with this: > > 'Some text' > > If we ignore white space after the start tag and before the end > tag, it becomes > > 'Sometext' (with no space at all!) What I find indeed reasonable. (See below for my reasons.) > If we "collapse" as the SPEC says should be done, we have two > possibilities: What part of the spec do you refer to? From what I have understood, spaces should be collapsed at the raw data leve. That is, if you have the part "Some text", it will be parsed into the following tree: ... `- +- | `- "Some " `- "text" Then, the question is, what should be done with the space at the end of "Some ". Generally, I'd like to stick to this tree view, and especially regard, in this example, the words "Some " and "text" as lying in different levels in the tree, not within a flat list. In the history, this was not always very clear for HTML, but it is much clearer for XHTML. The current parser does not actually build a tree, but should a bit like as it does. This approach makes also the new HTML parser in the CSS prototype simpler. > 'Some text' (as it was: underline the whitespace) > > and > > 'Some text' (move the space out of the tag) > > > AFAICT, the SPEC leaves the choice open, and advices HTML > authors against whitespace inside the tags. > > IMO, always collapsing white space after the start tag and ^^^^^^^^^^ I'd say, we should (for most elements) simply ignore whitespaces after the opening tag, and before the closing tag. This solves generally the problem with "Some underlined text.", and we should not relate spaces in different elements, e.g. by collapsing them. > before the end tag is the simplest to implement. Even more, as > the SPEC doesn't define what to do in this case, it's an option > left to the User Agent: > > <q source='HTML4.01 SPEC, 9.1'> > In order to avoid problems with SGML line break rules and > inconsistencies among extant implementations, authors should not > rely on user agents to render white space immediately after a > start tag or immediately before an end tag. Thus, authors, and in > particular authoring tools, should write: > > We offer free <A>technical support</A> for subscribers. > > and not: > > We offer free<A> technical support </A>for subscribers. > </q> So, at least, the authors are warned ;-) > Now, this solution would also account for the special SGML line > break rules: > > <q source='HTML-4.01 SPEC B.3.1'> > > SGML (see [ISO8879], section 7.6.1) specifies that a line break > immediately following a start tag must be ignored, as must a line > break immediately before an end tag. This applies to all HTML > elements without exception. > > The following two HTML examples must be rendered identically: > > Thomas is watching TV. > > > Thomas is watching TV. > > > So must the following two examples: > > <A>My favorite Website</A> > > <A> > My favorite Website > </A> > > </q> Rhis is actually something different: It is only about line breaks, and it applies to *all* elements, including <pre>. Sebastian

May 21, 2004

[Dillo-dev]White space handling

by Sebastian Geerken

Hi! This mail is just to collect what I have found in the specs, and how I understand it. I'll comment Jorge's mails seperately. Sebastian. ---------------------------------------------------------------------- HTML ---- Unfortunately, I do not have the SGML spec at hand, so I only refer to the parts of the HTML spec, which refer to general SGML topics. There is something in chapter 6, although I did not find anything about how #PCDATA (which is used in the DTD for the texts, which are relevant in this context), only about #CDATA: > 6.2 SGML basic types > > The document type definition specifies the syntax of HTML element > content and attribute values using SGML tokens (e.g., PCDATA, CDATA, > NAME, ID, etc.). See [ISO8879] for their full definitions. The > following is a summary of key information: > > * CDATA is a sequence of characters from the document character set > and may include character entities. User agents should interpret > attribute values as follows: > > o Replace character entities with characters, > o Ignore line feeds, > o Replace each carriage return or tab with a single space. > > User agents may ignore leading and trailing white space in CDATA > attribute values (e.g., " myval " may be interpreted as > > "myval"). Authors should not declare attribute values with leading > or trailing white space. > > For some HTML 4 attributes with CDATA attribute values, the > specification imposes further constraints on the set of legal > values for the attribute that may not be expressed by the DTD. About HTML: > 9.1 White space > > [...] > For all HTML elements except PRE, sequences of white space separate > "words" (we use the term "word" here to mean "sequences of non-white > space characters"). When formatting text, user agents should > identify these words and lay them out according to the conventions > of the particular written language (script) and target medium. > [...] This is, what is currently the difference between calls to a_Dw_page_add_text() (which adds a word), and a_Dw_page_add_space(), which adds a "word separation". > B.3.1 Line breaks > SGML (see [ISO8879], section 7.6.1) specifies that a line break > immediately following a start tag must be ignored, as must a line > break immediately before an end tag. This applies to all HTML > elements without exception. > > The following two HTML examples must be rendered identically: > > Thomas is watching TV. > > > Thomas is watching TV. > > > So must the following two examples: > > <A>My favorite Website</A> > > <A> > My favorite Website > </A> Notice this: "This applies to all HTML elements without exception." That is, also for <pre>. But it does not say anything about white spaces in general. XHTML ----- First of all from the XML 1.1 spec: > 2.10 White Space Handling > > In editing XML documents, it is often convenient to use "white > space" (spaces, tabs, and blank lines) to set apart the markup for > greater readability. Such white space is typically not intended for > inclusion in the delivered version of the document. On the other > hand, "significant" white space that should be preserved in the > delivered version is common, for example in poetry and source code. > > An XML processor MUST always pass all characters in a document that > are not markup through to the application. A validating XML > processor MUST also inform the application which of these characters > constitute white space appearing in element content. First of all, we do not have a distinction between the (basic) XML processor, and the application. (In the CSS prototype, this is clearer, and because it is always a good decision to make the implementation structure resemble the structure of the specifications, this should be kept in mind.) How I understand this basicly: It is (in most cases, see below) the task of the application (in this case XHTML) to determine how to deal with whitespaces. Anyway, I did not find anything in the XHTML 1.0 specification, so I believe that the same rules apply, as for HTML 4.01. > A special attribute named xml:space MAY be attached to an element to > signal an intention that in that element, white space should be > preserved by applications. In valid documents, this attribute, like > any other, MUST be declared if it is used. When declared, it MUST be > given as an enumerated type whose values are one or both of > "default" and "preserve". For example: > > <!ATTLIST poem xml:space (default|preserve) 'preserve'> > <!ATTLIST pre xml:space (preserve) #FIXED 'preserve'> > > The value "default" signals that applications' default white-space > processing modes are acceptable for this element; the value > "preserve" indicates the intent that applications preserve all the > white space. This declared intent is considered to apply to all > elements within the content of the element where it is specified, > unless overridden with another instance of the xml:space > attribute. This specification does not give meaning to any value of > xml:space other than "default" and "preserve". It is an error for > other values to be specified; the XML processor MAY report the error > or MAY recover by ignoring the attribute specification or by > reporting the (erroneous) value to the application. Applications may > ignore or reject erroneous values. If you look at the DTDs of XHTML 1.1, you'll find three elements setting this: <style>, <script>, and <pre>. As to the patch: <style> and <script> are currently rather unimportant, while for <pre>, the HTML parser switches into the DILLO_HTML_PARSE_MODE_PRE mode, where white spaces are handled differently. > The root element of any document is considered to have signaled no > intentions as regards application space handling, unless it provides > a value for this attribute or the attribute is declared with a > default value.

May 21, 2004

Re: [Dillo-dev]Tabs/Frames/Kbnav

by Patrick Shanahan

* Jorge Arellano Cid <jcid(a)dillo.org> [05-20-04 13:01]: > > Now that dillo 0.8.1 is done, I want to clarify what happened > with the Tabs/Frames/KeybNav patch. Sometime has passed since, > but at the time we decided to not stir an already ungrateful > situation. perhaps 'ungraceful' unless you intend to pour salt ??? -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711

May 21, 2004

Re: [Dillo-dev]Tabs/Frames/Kbnav

by Riccardo Mottola

Jorge Arellano Cid wrote: > > Hi, > > Now that dillo 0.8.1 is done, I want to clarify what happened > with the Tabs/Frames/KeybNav patch. Sometime has passed since, > but at the time we decided to not stir an already ungrateful > situation. > I'm very sorry to read this thread. It has this "deja vue". Something that comes on and on in open source software. Splits and forks. If by one side the reason may be evident, on the other side the effect is that resources spread and many projects either die or remain understaffed for the potential they have. I often hope that addition could be worked in into the main tree and maybe chosen at configure time (I'm thinking again of a motif or other backend like Amaya or VIM did) or they could be 'officially' forked, like mozilla, firefox and camino. This can ensure a tigher collaboration, like in the case of those three browsers, the core engine updates I don't think dillo should have tabbed browsing and I see keyboard navigation as a secondary feature, but Frames is something that is needed for serious navigation. Not that I like frames, but they happen to be popluar and in some circumstances they can be smart even for minimalist webdesign. That is my 2cents. Riccardo

May 20, 2004

[Dillo-dev]Tabs/Frames/Kbnav

by Jorge Arellano Cid

Hi, Now that dillo 0.8.1 is done, I want to clarify what happened with the Tabs/Frames/KeybNav patch. Sometime has passed since, but at the time we decided to not stir an already ungrateful situation. Here I'm forwarding a couple of emails that should be enough to do it (dillo-dev archives holds the rest). Sincerely Jorge.- -------------------------------------------------------------------------- From akemnade(a)informatik.uni-bremen.de Mon May 17 08:44:51 2004 Date: Sat, 27 Mar 2004 14:25:31 +0100 From: Andreas Kemnade <akemnade(a)informatik.uni-bremen.de> To: Sebastian Geerken <s.geerken(a)ping.de> Cc: jcid(a)dillo.org Subject: Re: [Dillo-dev]Frame support in CVS Hi Sebastian, Hi Jorge, On Sun, 7 Mar 2004 22:14:49 +0100 Sebastian Geerken <s.geerken(a)ping.de> wrote: > Hi Andreas. > > (I'm writing this in English to make forwarding etc. simpler.) > > Jorge and I would indeed like to incorporate Frank's work into the > main trunk, but unfortunately Frank refused to clean up the code, and > finally, he quit the project, and plans to make an own version of > dillo. I've a mail of 8 Jan, which I can forward you, if you are > interested. > Please send me that mail. Ok, perhaps I was not deep enough in the archives. I just did not find any statement about what has to be done with the patch. I think other readers of dillo-dev do not know about that, too. Perhaps it would be better if that was more clarified but I also understand that you do not want to repeat yourself too often. > If you want to commit some work, you may clean up the patch, > especially split it up into several parts. Most important, there are > three parts: DilloDoc (which I'd like to be renamed), frames, and > tabs. They are of course related, but it would be handy to have single > patches for them (because of the over-linear correlation of patch size > and review time). > Most the time I was just happy to be able to apply the frames patch. I was not forced to look at the code. But with the massive conflicts the patch produces when I applied it to 0.8 I really had to start to look at the patch. Sometimes being not a maintainer has really big advances... If I checked the patch size before fixing the conflicts I guess I would have given up. I have never noticed before how big the patch was. If splitting does not work, then there is something really wrong with the code. So let's divide and conquer. I think an important part is to remove nice (but not very important) features from the patch which can be added separetely later on. I think I can find time in the next month to split and clean up the frame patch. Greetings Andreas Kemnade -------------------------------------------------------------------------- From s.geerken(a)ping.de Mon May 17 08:44:37 2004 Date: Sat, 10 Jan 2004 13:04:11 +0100 From: Sebastian Geerken <s.geerken(a)ping.de> To: Jorge Arellano Cid <jcid(a)dillo.org> Subject: Fwd: Re: Notes on keyboard navigation FYI. [ Part 2: "Included Message" ] Date: Thu, 08 Jan 2004 22:31:10 +0100 From: Frank de Lange <frank(a)unternet.org> To: Sebastian Geerken <s.geerken(a)ping.de> Subject: Re: Notes on keyboard navigation Sebastian Geerken wrote: >Hi Frank. > >First of all, a happy new year! > >Several notes on keyboard navigation: > >1. Jorge and I decided, that we do not immediately support keyboard > configuration, also because it is rather unclear what widget > toolkit will be used in the future. So the version of keyboard > navigation, which will be integrated the first time, should have > hard-coded keys. > >2. Some days ago, I committed some changes to iterators, you may be > interested in. There is some description within doc/Dw.txt, section > "Anchors and Scrolling", subsection "Scrolling". Especially, > scrolling has now two dimensions, there is a new scrolling > position, DW_[HV]POS_INTO_VIEW, and DwIterator::scroll_to has been > replaced by the more general DwIterator::get_allocation. > >3. I noticed some performance problems with stress tests, I'm not sure > they play a role in real life. Anyway, you wrote on the list that > you are already working on in. > >Sebastian > > Happy new year as well... and thanks for the notice. For keyboard navigation to work in a sensible way x coördinate support is useful... so useful that I had already implemented it. The performance problems have been solved in my tree as well, as I have stated in my last message to the list. They are caused by the use of g_list_search_custom to find the focusable in focus.c. Using a hash table solved this. But... I have decided to discontinue support to the Dillo project as of the 'infringer' message to the list, so I will no longer post or update patches to Dillo. Instead, I am working on a new browser which should fill the same niche as Dillo (small, fast, enough features for most sites so it can be used as main browser). Starting point for this is my patched version of Dillo, with additional changes: - dpi and dpid and related things are gone (DONE) - library plugins for everything dpi did, and more (mime decoders, schemes, etc) (DONE) - ccc is on the way out, to be replaced by something less convoluted and more general (WORK IN PROGRESS) - DOM support with new xml parser (WORK IN PROGRESS) The project currently uses GTK+ as toolkit, but might switch to something else (FLTK is a candidate). A side goal for this project is to be developer-friendly. Patches are welcome, they will get their own space on the site (which will be on savannah, which is still not completely recovered from the break-in yet... hence the delay). I may post a short notice to the list if/when the project is up and ready for testing. Good luck with Dillo. 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." ]

May 20, 2004

[Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)

by Jorge Arellano Cid

Hi Sebastian, One thing that puzzles me about the patch that collapses whitespace at the parser level, is that some tables no longer are centered! For instance: http://www.dillo.org/stats/ http://www.dillo.org/stats/usage_200405.html Cheers Jorge.-

May 19, 2004