Hi,
Michael Drake <michael.drake@codethink.co.uk> wrote on 14 Apr 2020:
> They work here. What version of NetSurf are you running?
I was using the 3.9 release but following your prompt I downloaded the
test build from yesterday, 3.10 build 5057, and the problem remains.
At least some of my problem can be seen at these 2 simplified test pages:
https://timebus.co.uk/riscos/webtest/using-html4.htm
https://timebus.co.uk/riscos/webtest/using-html5.htm
There are 3 images with captions, separated by 2 horizontal rules for
clarity. The idea (of using inline-block CSS property) is the captions
display to the right of the images if your browser window is wide enough,
otherwise underneath.
The HTML4 one works as I expect, the HTML5 one makes a mess in NetSurf;
the display nests the elements in a cascade. It's almost like NetSurf
fails to recognise the closing figcaption tags.
The only structural difference is that the HTML4 one uses all DIVs,
whereas the HTML5 one uses figure and figcaption elements.
The figure is bordered red, the figcaption is bordered blue.
The HTML4 page has no errors at https://validator.w3.org/
The HTML5 page has no errors at https://validator.w3.org/nu/
Both pages use the same CSS file, which is as follows:
.figure {
margin-bottom: 20px;
border-color: red;
border-style: solid;
}
.figcaption {
display: inline-block;
border-color: blue;
border-style: dotted;
}
.img {
width: 100px;
display: inline-block;
}
If Netsurf is supposed to support HTML5 elements perhaps I should log this
as a bug on the tracker. The development progress page says HTML5 support
is "just started".
Best regards
Ewen
--
Ewen Pring, St. Albans, Herts
using RISC OS 5
https://timebus.co.uk/riscos/
Tuesday, 14 April 2020
Re: Libcss fails to compile with msvc 2019 (windows)
On Tue, Apr 14, 2020 at 09:19:31AM -0300, Ranier Vilela wrote:
> Em ter., 14 de abr. de 2020 às 07:59, Michael Drake <mdrake.unique@gmail.com>
> escreveu:
>
> > Please try with libwapcaplet updated to the latest master.
> >
> > This commit should fix the problem:
> >
> >
> > http://git.netsurf-browser.org/libwapcaplet.git/commit/?id=9df4abc696ec938f184ca8e345c379f9b6499ccc
> >
> Yes, fixed. Thanks.
>
> Unfortunately msvc not fully support C99, and do not have the keyword
> "restrict".
NetSurf is written in C99, so you will need to use a C99 compiler or
maintain your own fork of our libraries. Additionally, our Makefile is
written in GNU Make. Again, you will either need to use GNU Make, or maintain
your own fork.
B.
> Em ter., 14 de abr. de 2020 às 07:59, Michael Drake <mdrake.unique@gmail.com>
> escreveu:
>
> > Please try with libwapcaplet updated to the latest master.
> >
> > This commit should fix the problem:
> >
> >
> > http://git.netsurf-browser.org/libwapcaplet.git/commit/?id=9df4abc696ec938f184ca8e345c379f9b6499ccc
> >
> Yes, fixed. Thanks.
>
> Unfortunately msvc not fully support C99, and do not have the keyword
> "restrict".
NetSurf is written in C99, so you will need to use a C99 compiler or
maintain your own fork of our libraries. Additionally, our Makefile is
written in GNU Make. Again, you will either need to use GNU Make, or maintain
your own fork.
B.
Mailing list host, scheduled downtime
Hi all,
I have been working on a new mail-backend for Pepperfish and one of the
changes we're doing is to migrate from mailman 2 to mailman 3. This migration
will, obviously, affect the mailing lists slightly.
Other than a period of downtime next weekend, most of you should be unaffected
by this. However the new mailman list archiver (hyperkitty) should be much
more effective at providing archives, and is a more modern web interface
permitting you to read the mailing list in a browser rather than your mail
client if that's what you prefer. (Unfortunately I doubt it'll work great in
NetSurf, but it'll give us a reason to work on improving things further I
guess)
There may be some delay getting the archives back up after the transfer, but I
do expect everything to be done within a day of starting, and I hope that
afterwards, some of the problems we've had with people not being able to
subscribe etc, will go away. And digests (blech) might work better, perhaps.
I'll pop a mail on the list a little before, and a little after, the transfer
so that you're all forewarned, and told when things are back up and running.
If you have any concerns, please contact me *off list* and I'll do my best to
allay them.
Regards,
Daniel.
--
Daniel Silverstone http://www.digital-scurf.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
I have been working on a new mail-backend for Pepperfish and one of the
changes we're doing is to migrate from mailman 2 to mailman 3. This migration
will, obviously, affect the mailing lists slightly.
Other than a period of downtime next weekend, most of you should be unaffected
by this. However the new mailman list archiver (hyperkitty) should be much
more effective at providing archives, and is a more modern web interface
permitting you to read the mailing list in a browser rather than your mail
client if that's what you prefer. (Unfortunately I doubt it'll work great in
NetSurf, but it'll give us a reason to work on improving things further I
guess)
There may be some delay getting the archives back up after the transfer, but I
do expect everything to be done within a day of starting, and I hope that
afterwards, some of the problems we've had with people not being able to
subscribe etc, will go away. And digests (blech) might work better, perhaps.
I'll pop a mail on the list a little before, and a little after, the transfer
so that you're all forewarned, and told when things are back up and running.
If you have any concerns, please contact me *off list* and I'll do my best to
allay them.
Regards,
Daniel.
--
Daniel Silverstone http://www.digital-scurf.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Re: HTML5 element support
On 14/04/2020 13:39, Ewen Pring wrote:
> Specifically, my web site has over 60 pages that use the HTML5 figure and
> figcaption elements to contain content (images and their captions
> alongside). Netsurf doesn't recognise these and doesn't act upon styles
> applied to them in CSS. The page renders as if they were not there.
They work here. What version of NetSurf are you running?
--
Michael Drake https://www.codethink.co.uk/
> Specifically, my web site has over 60 pages that use the HTML5 figure and
> figcaption elements to contain content (images and their captions
> alongside). Netsurf doesn't recognise these and doesn't act upon styles
> applied to them in CSS. The page renders as if they were not there.
They work here. What version of NetSurf are you running?
--
Michael Drake https://www.codethink.co.uk/
HTML5 element support
I'd like to make a feature request. The Netsurf documentation says to post
it on this list rather than using the bug reporting system.
The Netsurf progress page says an HTML5 parser is being in the process of
development; that's good but HTML5 has been used for 6 years now and what
seems to me (if I'm right) a minor change might allow the existing engine
to display HTML5 as it was intended, even if it doesn't 'understand' the
concept of some of the new elements/structures.
Specifically, my web site has over 60 pages that use the HTML5 figure and
figcaption elements to contain content (images and their captions
alongside). Netsurf doesn't recognise these and doesn't act upon styles
applied to them in CSS. The page renders as if they were not there. But
I've set properties such as making them inline-blocks with vertical
centering next to each other, OK on Chrome/Firefox but none of this works
in Netsurf whose display output is ruined in a cascade of incorrectly
positioned elements.
It seems to me that if the figure and figcaption elements were simply
considered as being div elements, the display would work as intended.
At present the only way I could get around the issue is to wrap the HTML5
elements in a div, and apply the styles to the div and not the HTML5
element.
OK ideally the new elements should have default styles (for example
Firefox puts a 16 pixel top/bottom and 40 pixel left/right margin on the
figure element, whereas a normal div has none) but that doesn't matter
much as if Netsurf supported styles on HTML5 elements, I would be able to
set all those things manually.
Whilst I've only tested this on figure and figcaption, other HTML5
elements like aside, nav, footer are also I suppose in the same boat.
Best regards
Ewen Pring
--
Ewen Pring, St. Albans, Herts
using RISC OS 5
https://timebus.co.uk/riscos/
it on this list rather than using the bug reporting system.
The Netsurf progress page says an HTML5 parser is being in the process of
development; that's good but HTML5 has been used for 6 years now and what
seems to me (if I'm right) a minor change might allow the existing engine
to display HTML5 as it was intended, even if it doesn't 'understand' the
concept of some of the new elements/structures.
Specifically, my web site has over 60 pages that use the HTML5 figure and
figcaption elements to contain content (images and their captions
alongside). Netsurf doesn't recognise these and doesn't act upon styles
applied to them in CSS. The page renders as if they were not there. But
I've set properties such as making them inline-blocks with vertical
centering next to each other, OK on Chrome/Firefox but none of this works
in Netsurf whose display output is ruined in a cascade of incorrectly
positioned elements.
It seems to me that if the figure and figcaption elements were simply
considered as being div elements, the display would work as intended.
At present the only way I could get around the issue is to wrap the HTML5
elements in a div, and apply the styles to the div and not the HTML5
element.
OK ideally the new elements should have default styles (for example
Firefox puts a 16 pixel top/bottom and 40 pixel left/right margin on the
figure element, whereas a normal div has none) but that doesn't matter
much as if Netsurf supported styles on HTML5 elements, I would be able to
set all those things manually.
Whilst I've only tested this on figure and figcaption, other HTML5
elements like aside, nav, footer are also I suppose in the same boat.
Best regards
Ewen Pring
--
Ewen Pring, St. Albans, Herts
using RISC OS 5
https://timebus.co.uk/riscos/
Re: Libcss fails to compile with msvc 2019 (windows)
Em ter., 14 de abr. de 2020 às 07:59, Michael Drake <mdrake.unique@gmail.com> escreveu:
Please try with libwapcaplet updated to the latest master.This commit should fix the problem:
Yes, fixed. Thanks.
Unfortunately msvc not fully support C99, and do not have the keyword "restrict".
computed.h (line 82):
css_error css_computed_style_compose(
const css_computed_style * _restrict parent,
const css_computed_style * _restrict child,
css_error (*compute_font_size)(void *pw,
const struct css_hint *parent,
struct css_hint *size),
void *pw,
css_computed_style ** _restrict result);
const css_computed_style * _restrict parent,
const css_computed_style * _restrict child,
css_error (*compute_font_size)(void *pw,
const struct css_hint *parent,
struct css_hint *size),
void *pw,
css_computed_style ** _restrict result);
WIth msvc 2019, change restrict to _restrict solves.
Another problem is, with msvc makefile.
nmake do not support c source file name repeated, I think.
Libcss have two directory parse and select, with files names repeated.
I think I'll have to create two separate makefiles.
regards,
Ranier Vilela
Re: Libcss fails to compile with msvc 2019 (windows)
Please try with libwapcaplet updated to the latest master.
This commit should fix the problem:
Cheers,
Michael
On Mon, 13 Apr 2020 at 14:31, Ranier Vilela <ranier.vf@gmail.com> wrote:
Hi,I'm trying to compile libcss on windows, with msvc 2019 and the following error is appearing.stylesheet.clibcss\src\parse/language.h(88): error C2059: erro de sintaxe: '{'libcss\src\parse/language.h(88): error C2059: erro de sintaxe: ')'libcss\src\parse/language.h(88): error C2059: erro de sintaxe: '=='libcss\src\parse/language.h(98): error C2059: erro de sintaxe: 'return'libcss\src\parse/language.h(99): error C2059: erro de sintaxe: '}'Msvc 2019, translate tokenIsChar to:static inline _Bool tokenIsChar(const css_token *token, uint8_t c)
{
if (token != ((void *)0) && token->type == CSS_TOKEN_CHAR &&
({(void)( (!!(token->idata != ((void *)0))) || (_wassert(L"token->idata != NULL", L"C:\\usr\\src\\libpdf\\libcss\\src\\parse/language.h", (unsigned)(86)), 0) ); (token->idata)->len;}) == 1) {
char d = ({(void)( (!!(token->idata != ((void *)0))) || (_wassert(L"token->idata != NULL", L"C:\\usr\\src\\libpdf\\libcss\\src\\parse/language.h", (unsigned)(87)), 0) ); (const char *)((token->idata)+1);})[0];
if ('A' <= d && d <= 'Z')
d += 'a' - 'A';
return (d == c);
}
return 0;
}Libcss uses some gcc resource?This is compatible with C99?best regardsRanier Vilela
Subscribe to:
Posts (Atom)