Re: Link colour
2009/3/14 Richard Porter r...@minijem.plus.com: with all other browsers in that respect. Compatibility problems arise when background colours are specified in html and foreground colours in CSS, or vice-versa. Netsurf seems to guarantee problems for any straight html site with a dark background colour or image. As far as I can tell, if colours aren't specified, then default colours are used. Would it be better to calculate sensible values instead? (This would not solve the problem completely, but it would make some pages work, that previously don't.) -- Jess Please don't leave my whole message in your reply. mailto:jesshampsh...@googlemail.com (also facebook myspace)
Re: Link colour
In article 2fdad83b50.r...@user.minijem.plus.com, Richard Porter r...@minijem.plus.com wrote: What I am saying is that implementing basic html should be a starting point, Well it was, of course. NetSurf is a web browser after all. :) CSS was also considered early on and it would have been wrong not to do so for all sorts of reasons. CSS was already widely used when NetSurf was started. There were no RISC OS browsers with CSS support at the time NetSurf was started and it would have been silly spend all the time necessary to make a browser that was ultimately no more capable than existing browsers. The CSS specification goes pretty deep into covering most of the stuff needed for HTML layout. It even provides a information on what the default style to give to HTML elements. If we had just focused on HTML to begin with, a rewrite would have been required for CSS support. There's far more to it than this, but anyway I am convinced NetSurf would have become another dead-ended RISC OS browser if it had had not been designed to support CSS from the start. not something you think about afterwards, simply because there are so many sites out there that use it and which render adequately with all other browsers in that respect. HTML features are in exactly the same boat as CSS features, in terms of what gets implemented when in NetSurf. They get implemented when a developer with the necessary time and interest in a particular feature does the work. In the particular case of link colours specified in a BODY attribute, it requires us to have a satisfactory implementation of 6.4.4 Precedence of non-CSS presentational hints in the CSS 2.1 specification. Currently we have a bit of a bodged mess with some HTML-specified presentational hints incorrectly overriding CSS-set styles or being ignored altogether. We are working on a new CSS parser and selection engine and there is scope in that for creating a sensible way to inject non-CSS presentational hints -- the matter has been given some consideration. Compatibility problems arise when background colours are specified in html and foreground colours in CSS, or vice-versa. NetSurf seems to guarantee problems for any straight html site with a dark background colour or image. Yes, this is perfectly true and symptomatic of the current bodge. I doubt this particular issue will be fixed before we move to our new CSS engine. This is simply because it would not be sensible to spend a lot of time tinkering with the current code when it will soon be replaced with a better solution which should ultimately fix far more issues than just this link colour issue. Michael -- Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: Link colour
On 14 Mar 2009 Michael Drake wrote: In article 2fdad83b50.r...@user.minijem.plus.com, Richard Porter r...@minijem.plus.com wrote: What I am saying is that implementing basic html should be a starting point, Well it was, of course. NetSurf is a web browser after all. :) [snip] I doubt this particular issue will be fixed before we move to our new CSS engine. This is simply because it would not be sensible to spend a lot of time tinkering with the current code when it will soon be replaced with a better solution which should ultimately fix far more issues than just this link colour issue. Michael, thank you for your courteous and informative response. Of course I agree that NS had to be designed around CSS from the start - I was just a little surprised that some (a rather inconsistent subset) of the html presentational hints had been ignored, but as you say development is dependent on what people are motivated to tackle. I hope that it will be possible for someone to have a look at these aspects in due course. Unless my circumstances change significantly I'm afraid that I won't be able to get involved in sufficient depth. Richard -- _ |_|. _ Richard Porter http://www.minijem.plus.com/ |\_||_mailto:r...@minijem.plus.com Disclaimer: Please imagine about 50 lines of pointless clutter.
Re: Link colour
In article 7ea8523b50.da...@david.wanadoo.fr,
David J Worden aux.au...@free.fr wrote:
In a two-language website for a friend I have used the colour red on
English pages and blue on French pages (in headings, etc., at her
request), and so I have specified the link colour as green rather than
the default blue.
I hope I'm not teaching you to suck eggs but the problem of ignored link
body tags (discussion of which may need to be preceded by a strict
definition of the subjective term not difficult ;) can be easily
overcome _if_ you have control of the web site. To control main document
colours with CSS use:
body{
background-color: #00;
color: #ff;
}
a:visited { color: #cc }
a:link{ color: #ccffcc }
a:hover { color: #ff }
My sites were driving me mad so NetSurf did me the favour of forcing me
to 'upgrade' to CSS because of this seemingly bizarre omission from its
fundamental repertoire. (It's as if, like, they thought nobody uses body
tags because they're deprecated, ain't they? But not when those pages
were written, they wasn't? A shame so it is that the term deprecated
seems misunderstood so widely? Innit?)
With apologies to Armstrong and Miller.
T
--
Tim Hill,
www.timil.com
Re: Link colour
In article nsebf4f33b50.b...@yo.rk, Bryn Evans nets...@bryork.freeuk.com wrote: [snip] A long while ago (2years?) I suggested that the ability for the user to disable CSS via a Choices selection might be a useful feature. Since then a lot of work has advanced things muchly and I had forgotten, until this problem was reported AND diagnosed. Would this be a difficult feature to add now? (I am not a Coder, just a grateful user) While I am not involved in the Netsurf project as a coder (have never been able to get on with C and friends) it strikes me that whether or not one 'disables' CSS there has to be some way of handling the hints offered by the old-style html attributes - like align=center! If you think about it a little you will realise that some sort of styling mechanism is still required - whether the external input is old-style html or proper CSS style rules. If I were to be involved in designing this kind of thing then the first and most important design decision I see is the need to be able to separate rendering of a document from the structure (ie the various html elements) and the content (the wuhtor's meanderings) of it. This is just what the Netsurf designers/implementers have done - indeed they have even gone further and separated rendering into two parts - one device-independent, the other device-dependent (ie WIMP, gtk, frame-buffer). Whether you are running a Windows box, MacOS, BeOS, linux or RISC OS box the device-dependent bit is needed. Whether styling data is coming from html attribute hints or from CSS style rules the device-independent bit is needed - before anything is ever made visible/audible! 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?? The only potential difference is that parsing of the 'hints' is probably simpler than parsing all of the CSS language - but the device-independent part of the rendering engine still has to be there and still has to work. Keith Hopper -- Inspired!
Re: Link colour
On Sat, 2009-03-14 at 22:05 +, 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 problems. 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 content. 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 specification. 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. John.
Re: Link colour
I seem to have stirred a hornet's nest by starting this thread! My
apologies to the hard-working developers for putting you through this!
In article 7ea8523b50.da...@david.wanadoo.fr,
David J Worden aux.au...@free.fr wrote:
In a two-language website for a friend I have used the colour red on
English pages and blue on French pages (in headings, etc., at her
request), and so I have specified the link colour as green rather than
the default blue.
I hope I'm not teaching you to suck eggs...
No, you're not. I did start to look into CSS at one point(*), but my
personal 'style' of website programming meant that I would pretty much
have to re-write all my existing sites from scratch, and I tend to use
an old site as a starting point for new ones, so I got so far and then
stopped!
(*) As I am retired there is no pressure on me these days to
keep up with later developments. If what I already know is
not sufficient to satisfy someone for whom I am preparing a
website then I will look into what else may be needed. In
this case, as I said earlier, the person concerned knows
nothing of RISC OS or NetSurf and it is unlikely that any of
her clients will either. And even if they do, the site will
still work for them, albeit not quite as I had intended.
...but the problem of ignored link body tags (discussion of which may
need to be preceded by a strict definition of the subjective term not
difficult ;) can be easily overcome _if_ you have control of the web
site.
Which I do in the case in question.
To control main document colours with CSS use:
body{
background-color: #00;
color: #ff;
}
a:visited { color: #cc }
a:link{ color: #ccffcc }
a:hover { color: #ff }
Maybe I'll look into this again, but spring and summer are approaching
fast now and I will want to be spending more time outdoors in the
southern French sun, not huddled over my computer! ;-)
My sites were driving me mad so NetSurf did me the favour of forcing
me to 'upgrade' to CSS because of this seemingly bizarre omission from
its fundamental repertoire. (It's as if, like, they thought nobody
uses body tags because they're deprecated, ain't they? But not when
those pages were written, they wasn't? A shame so it is that the term
deprecated seems misunderstood so widely? Innit?)
With apologies to Armstrong and Miller.
Given the bit-by-bit circumstances under which NetSurf is being
developed (as described elsewhere in this issue [v23,i15] of the
Digest) I think the developers between them have done and are doing a
remarkable job.
Whatever its shortcomings may be, I have graduated via Fresco, Oregano
and Oregano2 to NetSurf and I now use it exclusively under RISC OS
(other than when checking that my websites work satisfactorily with
the other browsers).
David
--
David J Worden
