Website updates

[Daniel Sahlberg <da...@gmail.com>]

Hi,

I've spent some time updating the website:
- Migrating from fixed layout to a responsive design that adjusts to screen
size (mobilefriendlyness) while keeping the existing look&feel.
- Migrating to HTML5 including using CSS for design instead of hardcoding
in the "build system".
- Making sure all links are working

All pages now validate under https://validator.w3.org/ with one notable
exception:
Due to Ant/Velocity/Anakia being used as "build system" to generate the
HTML code, the "source files" must be valid XML. In XML, a self-closing tag
(ie, one that doesn't have a </end> tag) must be written as <xml />.
However in HTML, it must NOT be end with />. This causes problems for
guidelines.xml/html and versioning.xml/html. I don't see a way to fix this,
on the other hand I don't think any web browser wouldn't accept this. The
only other option would be to move away from Anakia completely: Subversion
is using Server side includes to bring in the common HTML fragments instead
of prebuilding complete HTML-files.

I personally found the "generate HTML" less intuitive than the SSI based
approach of Subversion. With the webpage now using CSS, there is less need
to have an XML transform adding different properties to all instances of
the same tag. But I don't want to rip out a whole build system with 20
years of history...

Speaking about Anakia and SSIs: I tried to be cleaver with the
/coverage/index.html file. It works fine as it is right now, but I can't
figure out a way to generate the <!--#include directive. Currently we have
to edit the index.html file manually before committing.

I've also updated the script generating the coverage report to work with
the above SSI changes.

If you find any issues, please report them here and I'll take a look!

Cheers,
Daniel

Re: Website updates

[Ruediger Pluem <rp...@apache.org>]

On 9/13/25 10:14 PM, Daniel Sahlberg wrote:
> Hi,
> 
> I've spent some time updating the website:
> - Migrating from fixed layout to a responsive design that adjusts to screen size (mobilefriendlyness) while keeping the existing
> look&feel.
> - Migrating to HTML5 including using CSS for design instead of hardcoding in the "build system".
> - Making sure all links are working

The site looks good to me. Thanks for your hard work on this.

Regards

Rüdiger

Re: Website updates

[Ruediger Pluem <rp...@apache.org>]

On 9/15/25 10:49 AM, Daniel Sahlberg wrote:

> 
> HTTPd is using ASF Pelican [1] to generate static pages from HTML. I agree with Brane on preferring MD over XML and with the
> simple integration of Pelican in GitHub Actions it makes updating the site a lot easier. (The documentation in our site is good,
> but it still took me a while to setup a JRE and run Anakia the first time).
> 
> The upside of using Pelican is that it is more widely used and actively supported. The version of Anakia/Velocity we have in
> /libs/ is a little dated.. Not that it couldn't be updated to an active version but I tried and failed...
> 
> I'm not sure when I would be able to contribute a significant amount of time to migrate to Pelican but if it is in the interest of
> the project, we could decide to make it a longterm goal to migrate.

I think it would make sense to switch to Pelican. Let's have it as a goal.

Regards

Rüdiger

Re: Website updates

[Daniel Sahlberg <da...@gmail.com>]

Den lör 13 sep. 2025 kl 22:29 skrev Branko Čibej <br...@apache.org>:

> On 13. 9. 25 22:14, Daniel Sahlberg wrote:
>
> Hi,
>
> I've spent some time updating the website:
> - Migrating from fixed layout to a responsive design that adjusts to
> screen size (mobilefriendlyness) while keeping the existing look&feel.
> - Migrating to HTML5 including using CSS for design instead of hardcoding
> in the "build system".
> - Making sure all links are working
>
> All pages now validate under https://validator.w3.org/ with one notable
> exception:
> Due to Ant/Velocity/Anakia being used as "build system" to generate the
> HTML code, the "source files" must be valid XML. In XML, a self-closing tag
> (ie, one that doesn't have a </end> tag) must be written as <xml />.
> However in HTML, it must NOT be end with />.
>
>
> This is true for HTML 5, but the site is XHTML 1.0, which should be happy
> with things like <br/> instead of <br>. In fact, if I point the validator
> at https://apr.apache.org/, it detects the doctype and shows no errors or
> warnings.
>

I think you missed the second bullet point above, that I changed the
doctype to HTML5 (or, should I say "Living standard" as I just learned it
is called nowadays).

I could, of course, revert that particular change but since XHTML has been
retired since 2018 it is probably time to move on.

This causes problems for guidelines.xml/html and versioning.xml/html. I
> don't see a way to fix this, on the other hand I don't think any web
> browser wouldn't accept this. The only other option would be to move away
> from Anakia completely: Subversion is using Server side includes to bring
> in the common HTML fragments instead of prebuilding complete HTML-files.
>
> I personally found the "generate HTML" less intuitive than the SSI based
> approach of Subversion. With the webpage now using CSS, there is less need
> to have an XML transform adding different properties to all instances of
> the same tag. But I don't want to rip out a whole build system with 20
> years of history...
>
>
>
> SSI is a sad hack, IMO. It puts extra burden on the server. I'm all for
> generating static pages wherever possible. Note that HTTPd generates HTML
> from Markdown, which is much easier on the eyes than XML. I mean, once you
> have XML, you might as well use HTML + static templates instead...
>

I think the extra load is negligible compared to other things in whole
stack (SSL or running a full-blown CMS solution ...PHP...). But of course
it takes more time than just shoving a static page down the network.

HTTPd is using ASF Pelican [1] to generate static pages from HTML. I agree
with Brane on preferring MD over XML and with the simple integration of
Pelican in GitHub Actions it makes updating the site a lot easier. (The
documentation in our site is good, but it still took me a while to setup a
JRE and run Anakia the first time).

The upside of using Pelican is that it is more widely used and actively
supported. The version of Anakia/Velocity we have in /libs/ is a little
dated.. Not that it couldn't be updated to an active version but I tried
and failed...

I'm not sure when I would be able to contribute a significant amount of
time to migrate to Pelican but if it is in the interest of the project, we
could decide to make it a longterm goal to migrate.

Cheers,
Daniel


[1] https://infra.apache.org/asf-pelican.html



>
>
> Speaking about Anakia and SSIs: I tried to be cleaver with the
> /coverage/index.html file. It works fine as it is right now, but I can't
> figure out a way to generate the <!--#include directive. Currently we have
> to edit the index.html file manually before committing.
>
> I've also updated the script generating the coverage report to work with
> the above SSI changes.
>
> If you find any issues, please report them here and I'll take a look!
>
> Cheers,
> Daniel
>
>
>

Re: Website updates

[Branko Čibej <br...@apache.org>]

On 13. 9. 25 22:14, Daniel Sahlberg wrote:
> Hi,
>
> I've spent some time updating the website:
> - Migrating from fixed layout to a responsive design that adjusts to 
> screen size (mobilefriendlyness) while keeping the existing look&feel.
> - Migrating to HTML5 including using CSS for design instead of 
> hardcoding in the "build system".
> - Making sure all links are working
>
> All pages now validate under https://validator.w3.org/ with one 
> notable exception:
> Due to Ant/Velocity/Anakia being used as "build system" to generate 
> the HTML code, the "source files" must be valid XML. In XML, a 
> self-closing tag (ie, one that doesn't have a </end> tag) must be 
> written as <xml />. However in HTML, it must NOT be end with />.

This is true for HTML 5, but the site is XHTML 1.0, which should be 
happy with things like <br/> instead of <br>. In fact, if I point the 
validator at https://apr.apache.org/, it detects the doctype and shows 
no errors or warnings.


> This causes problems for guidelines.xml/html and versioning.xml/html. 
> I don't see a way to fix this, on the other hand I don't think any web 
> browser wouldn't accept this. The only other option would be to move 
> away from Anakia completely: Subversion is using Server side includes 
> to bring in the common HTML fragments instead of prebuilding complete 
> HTML-files.
>
> I personally found the "generate HTML" less intuitive than the SSI 
> based approach of Subversion. With the webpage now using CSS, there is 
> less need to have an XML transform adding different properties to all 
> instances of the same tag. But I don't want to rip out a whole build 
> system with 20 years of history...


SSI is a sad hack, IMO. It puts extra burden on the server. I'm all for 
generating static pages wherever possible. Note that HTTPd generates 
HTML from Markdown, which is much easier on the eyes than XML. I mean, 
once you have XML, you might as well use HTML + static templates instead...


> Speaking about Anakia and SSIs: I tried to be cleaver with the 
> /coverage/index.html file. It works fine as it is right now, but I 
> can't figure out a way to generate the <!--#include directive. 
> Currently we have to edit the index.html file manually before committing.
>
> I've also updated the script generating the coverage report to work 
> with the above SSI changes.
>
> If you find any issues, please report them here and I'll take a look!
>
> Cheers,
> Daniel
>