May 2004 - Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] White spaces handling

by Sebastian Geerken

On Fri, May 21, Jorge Arellano Cid wrote: > On Fri, 21 May 2004, Sebastian Geerken wrote: > > On Mon, May 17, Jorge Arellano Cid wrote: > > > 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. Interestingly, if you take the modifications in html.c, without the modifications in dw_page.c, everything works: the table above is rendered correctly, the other tables are centered, and even the page "underline-strike-and-spaces.html" looks like we want it to look like. Actually, the modifications in html.c should make the modifications in dw_page.c obsolete, since the latters handle the case that a_Dw_page_add_space is called twice in sucsession, without any new words between them. I would have thought that the modified HTML parser should avoid exactly this, but this does not seem the case. It would be interesting to insert the line g_return_if_fail (page->words[nw].orig_space != 0); instead of the code, which is inserted by the patch, and start dillo in gdb with the option "--g-fatal-warnings", to see, under which circumstances the code would have been called. Sebastian

May 22, 2004

[Dillo-dev]BugTrack

by Jorge Arellano Cid

Hi there! Dillo's bugtrack was just updated so email addresses are mangled with images to protect from SPAM robots. The "submitter" camp was also added, so we can contact the poster for details. Cheers Jorge.-

May 22, 2004

[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