On Sat, 2009-03-14 at 22:05 +0000, Richard Porter wrote:
On 14 Mar 2009 Keith Hopper wrote:
> "Disabling" CSS makes absolutely no difference to the need for both of
> the parts of the rendering engine. So! It would seem merely a
> 'surface' option which placates a user but makes absolutely no
> difference in the code which has to exist for any form of rendering to
> take place. Perhaps it isn't a useful option after all??
I thimk you're Barking up the wrong creek.
Actually, Keith's assessment was about right. Disabling CSS is precisely
as difficult as dealing with non-CSS presentational hints. It's probably
slightly simpler (in that you can throw in a hack to prevent loading of
all stylesheets), but really not worth the development time,
particularly for a hack.
A related feature that I have requested is the ability to turn off
document colours (as in Oregano) which could overcome lack of contrast
This is precisely as difficult as non-CSS presentational hints. Given
that they have not yet been fully implemented, it's unlikely that this
will be any time soon, either. I suspect that it is highly unlikely that
we will provide support for ignoring document colours (as such an option
makes no sense in a CSS world). Far more likely will be the ability to
select which (groups of) stylesheets are applied to a page. One of these
groups may well be "no author styles".
As Michael has explained, the issue with link colours is that NetSurf's
current handling of non-CSS presentational hints (including the link
attribute on the body element) is a hideous mess of nested layers of
hackery, all of which interact with each other in non-obvious ways to
produce something approximating what the page should look like. Given
this, you can perhaps understand our reticence to do anything about
improving this short of a wholesale replacement of the entire thing.
A wholesale replacement (in the form of LibCSS and its eventual
integration into NetSurf) is exactly what I have been working on since
May 2008. Prior to this (since NetSurf 1.0 was released in May 2007), I
was making significant inroads into our future architecture:
Firstly, the design and implementation of LibDOM, a library for DOM
Level 3 Core (which has languished for some time in a state of
incompleteness and has recently been revived by a new developer, Bo
Yang). Ideally, work will progress further in future to incorporate
support for the entirety of the DOM APIs. LibDOM has not yet been
integrated into NetSurf itself, because of its incompleteness.
Secondly, the design and implementation of LibParserUtils, a utility
library to aid writing efficient streaming parsers for web-based
Thirdly, the design and initial implementation of Hubbub, our HTML
parser. This was taken on by Andi Sidwell for his Google Summer of
Code project last summer and was integrated into NetSurf in the
autumn. It is currently entirely in line with the HTML5 parser
The fourth component, LibCSS, won't make it into NetSurf 2.0 for the
simple reason that it isn't ready yet, not least as development is on
hold while we get 2.0 out the door.
LibCSS is a new CSS parser and selection engine. It fixes the issues
with NetSurf's current CSS parser (and many others, besides). It offers
efficient selection of styles for the components in a document and, in
doing so, will bring support for the long-missing CSS pseudo classes and
elements. It will also address the issues of non-CSS presentational
hints once and for all.
If it helps to understand exactly how much effort has gone into the
above, consider this:
LibDOM : 7,566 lines of code
LibParserUtils : 5,648 lines of code
Hubbub : 15,793 lines of code
LibCSS : 26,301 lines of code
55,308 lines of code
NetSurf's codebase: 100,943 lines of code
Therefore, the above changes constitute half as much new code written in
the past 22 months as has been written in the almost 7 years of
NetSurf's life. This doesn't factor in the huge number of other, more
visible changes (such as PDF export, major improvements to page
rendering, and a far improved GTK UI, let alone the addition of the
Amiga, BeOS, and framebuffer frontends) that have happened since NetSurf
1.0 was released.
All of the above is a long-winded way of saying that we are aware that
link colours aren't handled at all and have a solution in hand. As I
said, it won't appear in NetSurf 2.0 and I'm currently unwilling to
provide any kind of timescale for when it will appear in development
builds after 2.0 is released. All I will say is that if you want it
sooner rather than later, then you're welcome to give us a hand.