6:49 p.m.
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.
MSIE and FireFox on Windows do as I have specified, but NetSurf
insists on keeping the link colour as blue. Is this a known fault?
It seems a very fundamental thing to be so complicated that it has
been left until later to implement.
I have just downloaded the latest build (r6778 12th March 2009) and it
still does it.
In this instance it is not a problem for me as it is unlikely that
users of the site will be using RISC OS. I was just a bit surprised.
David
--
David J Worden
6:52 p.m.
On Fri, 13 Mar 2009 10:49:25 +0100
David J Worden <aux.auges(a)free.fr> wrote:
MSIE and FireFox on Windows do as I have specified, but NetSurf
insists on keeping the link colour as blue. Is this a known fault?
It seems a very fundamental thing to be so complicated that it has
been left until later to implement.
Yes. NetSurf does not obey link colours specified in the body tag,
only specified via CSS. It is more complicated than you might imagine.
B.
6:20 a.m.
On 13 Mar 2009 Rob Kendrick wrote:
On Fri, 13 Mar 2009 10:49:25 +0100
David J Worden <aux.auges(a)free.fr> wrote:
> MSIE and FireFox on Windows do as I have specified, but NetSurf
> insists on keeping the link colour as blue. Is this a known fault?
It's a long-standing bug.
> It seems a very fundamental thing to be so complicated that it
has
> been left until later to implement.
Yes. NetSurf does not obey link colours specified in the body tag,
only specified via CSS. It is more complicated than you might imagine.
Evidently, but I can't help thinking that it might have been easier to
do the basic html support first, and then add the CSS support, rather
than the other way around!
--
_
|_|. _ Richard Porter http://www.minijem.plus.com/
|\_||_ mailto:ricp@minijem.plus.com
Disclaimer: Please imagine about 50 lines of pointless clutter.
8:31 a.m.
On Fri, 13 Mar 2009 21:20:02 GMT
Richard Porter <ricp(a)minijem.plus.com> wrote:
Evidently, but I can't help thinking that it might have been
easier
to do the basic html support first, and then add the CSS support,
rather than the other way around!
We've been here before. You may think that all you wish. It's
actually more complex than you may think; NetSurf is a CSS browser at
its core. Doing this requires the injection of CSS rules.
NetSurf is a modern browser, unlike many others that have long
histories. Implementing HTML first and then CSS later would be the
wrong approach; it'd result in something bloaty and not render as well
as it does.
Of course, if you think differently, you know where to send patches...
B.
8:59 a.m.
On 13 Mar 2009 Rob Kendrick wrote:
We've been here before.
I'm well aware of that!
NetSurf is a modern browser, unlike many others that have long
histories.
But many web sites have long histories too!
Implementing HTML first and then CSS later would be the wrong
approach; it'd result in something bloaty and not render as well as it
does.
OK, I concede that the two should be designed together, but one would
expect a web browser first and foremost to be able to interpret html.
That should be a given.
Sorry, but I can't see why it should be so difficult to parse the
<body> tag and use the link colours as defaults rather than some
hard-coded colours that you can't even set in Choices... And if you
ignore the link colours why use the bgcolor attribute which can just
as easily be overridden by CSS? Using one without the other doesn't
make sense and is bound to cause contrast problems.
--
_
|_|. _ Richard Porter http://www.minijem.plus.com/
|\_||_ mailto:ricp@minijem.plus.com
Disclaimer: Please imagine about 50 lines of pointless clutter.
9:02 a.m.
On Fri, 13 Mar 2009 23:59:36 GMT
Richard Porter <ricp(a)minijem.plus.com> wrote:
Sorry, but I can't see why it should be so difficult to parse the
<body> tag and use the link colours as defaults rather than some
hard-coded colours that you can't even set in Choices...
I invite you to look at the source code and formulate a patch to
implement this functionality.
B.
9:10 a.m.
On 14 Mar 2009 Rob Kendrick wrote:
I invite you to look at the source code and formulate a patch to
implement this functionality.
You have done so a few times, but I wouldn't dream of starting with
the source code. I'd want to familiarise with the functional
specification and design documentation in order to design the
necessary changes. The changes would then be peer-reviewed before
proceeding to the coding stage. Maybe you don't work that way!
--
_
|_|. _ Richard Porter http://www.minijem.plus.com/
|\_||_ mailto:ricp@minijem.plus.com
Disclaimer: Please imagine about 50 lines of pointless clutter.
9:19 a.m.
On Sat, 14 Mar 2009 00:10:03 GMT
Richard Porter <ricp(a)minijem.plus.com> wrote:
> I invite you to look at the source code and formulate a patch
to
> implement this functionality.
You have done so a few times, but I wouldn't dream of starting with
the source code. I'd want to familiarise with the functional
specification and design documentation in order to design the
necessary changes. The changes would then be peer-reviewed before
proceeding to the coding stage. Maybe you don't work that way!
I invited you to formulate a patch if you thought it so easy; I said
nothing about accepting it :) (We routinely review changes made by
new contributors; nothing goes in blindly from them.)
Either trust me that it's not as trivial as you think, or prove
otherwise by implementing it. It's as simple as that. All the
documentation you need is there.
B.
7:15 p.m.
On 14 Mar 2009 Rob Kendrick wrote:
I invited you to formulate a patch if you thought it so easy;...
Either trust me that it's not as trivial as you think, or prove
otherwise by implementing it.
I'm quite happy to accept your word that it's non-trivial, especially
to bolt on retrospectively. Nothing about a web browser is going to be
trivial. I merely observed that on the face of it, it would not appear
to be a difficult problem.
What I am saying is that implementing basic html should be a starting
point, 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. 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.
--
_
|_|. _ Richard Porter http://www.minijem.plus.com/
|\_||_ mailto:ricp@minijem.plus.com
Disclaimer: Please imagine about 50 lines of pointless clutter.
8:06 p.m.
2009/3/14 Richard Porter <ricp(a)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:jesshampshire@googlemail.com (also facebook & myspace)
8:34 p.m.
On 14 Mar, Richard Porter wrote in message
<2fdad83b50.ricp(a)user.minijem.plus.com>:
On 14 Mar 2009 Rob Kendrick wrote:
> I invited you to formulate a patch if you thought it so easy;...
> Either trust me that it's not as trivial as you think, or prove
> otherwise by implementing it.
I'm quite happy to accept your word that it's non-trivial, especially
to bolt on retrospectively. Nothing about a web browser is going to be
trivial. I merely observed that on the face of it, it would not appear
to be a difficult problem.
What I am saying is that implementing basic html should be a starting
point, 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.
I think Rob's point, quite legitimately, is that NetSurf is an open-source
project developed by a group of programmers in their spare time. Anyone
can get involved.
As such, criticising the priorities, or the work that has been done, isn't
on *unless* you are prepared to get involved yourself and do the things
better. What you can't do is simply say "I think you should be doing X,"
or "You've gone about doing Y wrong," while sitting on the sidelines. At
least, not in the way that this thread has degenerated into.
If you were paying for NetSurf, it would be a different matter.
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.
True. And, as you've now been told many times, the way is open for you to
look into the problem and resolve it. Given that they're working on
NetSurf for reasons other than (direct)[1] financial reward, the current
developers could have all manner of other priorities for their time.
1. That "direct" is in there to deflect the pedants. I can see that
having NetSurf on one's CV might be a path to indirect financial benefit
at some future time, but such an outlook would simply prioritise a
developer towards work that he or she considered would be useful on his or
her CV. As such, it just backs up my point.
I've no idea what the motivations of any of the NetSurf team are, so that
isn't meant to imply anything in particular.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
9:22 p.m.
In article <2fdad83b50.ricp(a)user.minijem.plus.com>,
Richard Porter <ricp(a)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/
10:36 p.m.
On 14 Mar 2009 Michael Drake wrote:
In article <2fdad83b50.ricp(a)user.minijem.plus.com>,
Richard Porter <ricp(a)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:ricp@minijem.plus.com
Disclaimer: Please imagine about 50 lines of pointless clutter.
10:31 p.m.
In article <7ea8523b50.david(a)david.wanadoo.fr>,
David J Worden <aux.auges(a)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: #000000;
color: #ffffff;
}
a:visited { color: #ffffcc }
a:link { color: #ccffcc }
a:hover { color: #ffcccc }
"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
11:07 p.m.
On 14 Mar 2009 Tim Hill wrote:
... the problem of ignored link body tags can be easily overcome
_if_
you have control of the web site.
Occasionally I visit sites that I don't have control of. I know it's
dangerous but I can't resist it. :-)
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?
Indeed.
--
_
|_|. _ Richard Porter http://www.minijem.plus.com/
|\_||_ mailto:ricp@minijem.plus.com
Disclaimer: Please imagine about 50 lines of pointless clutter.
12:11 a.m.
In a mad moment - Richard Porter mumbled :
On 14 Mar 2009 Tim Hill wrote:
> ... the problem of ignored link body tags can be easily overcome
_if_
> you have control of the web site.
Occasionally I visit sites that I don't have control of. I know
it's
dangerous but I can't resist it. :-)
> 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?
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)
--
|) [
|)ryn [vans mail to - BrynEvans(a)bryork.freeuk.com
6:45 a.m.
In article <nsebf4f33b50.Bryn(a)yo.rk>,
Bryn Evans <netsurf(a)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!
7:05 a.m.
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.
I'm not the one who's advocating disabling CSS but I can see the
point. You might just stand a chance of making the content of an
unreadable page readable even though you could lose its formatting.
This could be useful where you have text and/or images obscuring one
another.
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.
--
_
|_|. _ Richard Porter http://www.minijem.plus.com/
|\_||_ mailto:ricp@minijem.plus.com
Disclaimer: Please imagine about 50 lines of pointless clutter.
8:25 a.m.
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
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.
11:31 p.m.
In a mad moment - John-Mark Bell mumbled :
[snip]
Re.my suggestion of disabling CSS
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.
Thank you for a clear explanation of the problem, and the solutions
that you are working towards.
Your efforts are STILL very much appreciated.
--
|) [
|)ryn [vans mail to - BrynEvans(a)bryork.freeuk.com
5309
days inactive
5311
days old
netsurf-users@netsurf-browser.org
19 comments
10 participants
participants (10)
-
Bryn Evans -
David J Worden -
jess hampshire -
John-Mark Bell -
Keith Hopper -
Michael Drake -
Richard Porter -
Rob Kendrick -
Steve Fryatt -
Tim Hill