On 29. 7. 2026 14:15, Daniel Sahlberg wrote:
Den ons 29 juli 2026 kl 12:58 skrev Branko Čibej <[email protected]>:
On 29. 7. 2026 11:38, Ivan Zhakov wrote:
On Tue, 28 Jul 2026 at 19:51, Nathan Hartman
<[email protected]> wrote:
On Tue, Jul 28, 2026 at 10:57 AM Ivan Zhakov
<[email protected]> wrote:
>
> On Tue, 28 Jul 2026 at 17:11, Nathan Hartman
<[email protected]> wrote:
>>
>> On Fri, Jul 24, 2026 at 12:40 PM <[email protected]> wrote:
>> >
>> > Author: ivan
>> > Date: Fri Jul 24 16:39:48 2026
>> > New Revision: 1936555
>> >
>> > Log:
>> > In site/staging:
>> >
>> > Use 'content' CSS property to add section link symbol.
>> >
>> > * style/site.css
>> > (.sectionlink::before): New class. Add 'pilcrow'
symbol via 'content' CSS
>> > property.
>> >
>> > * blog/2006-09-10-EnhancingSubversionServer.html
>> > * blog/2007-03-27-authz-and-anon-authn-agony.html
>> > * blog/2007-06-13-merge_auditing.html
>> > * blog/2008-03-29-merging-from-foreign-repositories.html
>> > * blog/2008-05-06-merge-info.html
>> > * blog/2009-11-19-where-did-that-mergeinfo-come-from.html
>> > *
blog/2012-10-24-reducing_network_traffic_in_subversion_1-8.html
>> > *
blog/2013-06-24-repository-dictated-configuration-part-1-inheritable-properties.html
>> > *
blog/2013-06-25-repository-dictated-configuration-part-2-autoprops.html
>> > *
blog/2013-06-26-repository-dictated-configuration-part-3-global-ignores.html
>> > * blog/2013-06-28-foreign-repository-copies.html
>> > * blog/index.html
>> > * contributing.html
>> > * docs/community-guide/building.part.html
>> > * docs/community-guide/conventions.part.html
>> > * docs/community-guide/debugging.part.html
>> > * docs/community-guide/general.part.html
>> > * docs/community-guide/issues.part.html
>> > * docs/community-guide/l10n.part.html
>> > * docs/community-guide/mailing-lists.part.html
>> > * docs/community-guide/releasing.part.html
>> > * docs/community-guide/roles.part.html
>> > * docs/community-guide/web.part.html
>> > * docs/index.html
>> > * docs/release-notes/1.1.html
>> > * docs/release-notes/1.10.html
>> > * docs/release-notes/1.11.html
>> > * docs/release-notes/1.12.html
>> > * docs/release-notes/1.13.html
>> > * docs/release-notes/1.14.html
>> > * docs/release-notes/1.15.html
>> > * docs/release-notes/1.2.html
>> > * docs/release-notes/1.3.html
>> > * docs/release-notes/1.4.html
>> > * docs/release-notes/1.5.html
>> > * docs/release-notes/1.6.html
>> > * docs/release-notes/1.6.zh.html
>> > * docs/release-notes/1.7.html
>> > * docs/release-notes/1.8.html
>> > * docs/release-notes/1.9.html
>> > * docs/release-notes/index.html
>> > * download.html
>> > * faq.html
>> > * faq.ja.html
>> > * faq.zh.html
>> > * features.html
>> > * ideas.html
>> > * index.html
>> > * mailing-lists.html
>> > * news.html
>> > * opw.html
>> > * packages.html
>> > * pronunciation/index.html
>> > * quick-start.html
>> > * reporting-issues.html
>> > * roadmap.html
>> > * security/index.html
>> > * source-code.html
>> > Remove "¶" from section links: we add it via
'content' CSS property.
>>
>> Hi,
>>
>> Sorry, this change doesn't seem to work on Firefox.
>>
>> I am using the very latest Firefox, version 153.0.1.
>>
> I am using Firefox 153.0.1 and it works for me.
>
> I have also tested Microsoft Edge 150.0.4078.99 and it also
works.
>
> May it's some kind of caching issue?
You are correct, it was a caching issue. This confused me
because I
believed that I had force-reloaded the page. However, I just
checked
and it turns out that Cmd + R only reloads the HTML. You have
to press
Cmd + Shift + R to also reload stylesheets. I had forgotten this.
Strangely, an earlier change of the stylesheets (to add
td.success,
td.warning, td.danger) took effect here without any special
action on
my part.
This issue is rather annoying. I was searching for a reliable
method
to force browsers to reload CSS when it changes without forcing a
reload every time the page is accessed. One StackOverflow
page [1]
contains an entire debate about this. The most simplistic
idea from
that page is to rename the CSS file with some sort of
monotonically
increasing version number in the filename each time the file is
edited. This method would always work; the downside is that
it would
necessitate changes to all the files across the site, each
time we
edit the CSS. That could be annoying for us.
An alternative solution would be to add a query argument and
increment it on every CSS change. Something like this:
<link rel="stylesheet" href="/style/site.css?v=1" type="text/css"
media="all">
But we would still have to update 63 HTML files on every CSS
change. I'm not sure it is worth it, but I can do this
It's not worth it. Some browsers are just notorious for caching
too much. That is not the case for Firefox – the difference
between ^R/Shift-^R (or ⌘R/Shift-⌘R on the Mac) is well known.
Safari, on the other hand, is way too smart, it doesn't have an
equivalent to Shift-⌘R and will happily cache CSS and favicons and
such even when they no longer exist at the source...
TL;DR: This will only happen to people who are regularly tracking
the changing staging web site.
It will also happen to anyone who regularly check the main website,
whenever we merge this kind of changes. I have no idea how long it
takes before the web browsers refresh a cached resource.
That said, I don't think it is worth changing 63 HTML files on every
CSS change.
One possible solution: We already use mod_ssi to <!-- #include -->
other files. One possible solution would be to have the head as a
separate include. If I understand mod_ssi correctly, we could <!--
#set var="title" value="Some title" --> and then <title><!-- #echo
var="title" --></title> in the header file. That way we only need to
update the header-include file.
Changing this in the source code just smells wrong to me. I had a quick
look and it appears that none of the HTML responses from apache.org have
any cache control headers set. However, the response for our
'style/site.css' does have both ETag and Last-Modified (about 3 hours
ago on the main site, apparently). Still, since there's no Cache-Control
max_age or similar, any browser can decide to cache the page as long as
it likes.
The correct way to fix this is to set cache-control headers
appropriately, but this should be done by Infra, not us.
-- Brane
