[meta] Rechartering 2025-2027

[svgeesus]

The current charter ends on 12 March 2025. So to get the ball rolling, here is a proposed recharter.

To avoid distracting diff-churn, the list of deliverables (with last publication dates, etc) is copy-pasted from the current charter. It will need to be regenerated just before this goes for AC review.

Here is a diff to current charter and (mainly of use on the boilerplate-ey sections) diff to template

The scope is unchanged, except that (to follow current practice) an introductory paragraph got moved into the Motivation and Background section.

The decision policy is the same as the previous charter, too.

Basically this is a straightforward, "another two years" recharter.

I had a look at the 2023 timeline (the prediction of what modules would get to Recommendation in the charter period) and compared it to the actual situation. The results could be better, some modules have had a bunch of work but have not been published to /TR at all in the current charter period. Perhaps some of these could be republished before the charter period ends.

@astearns @atanassov

[Crissov]

I did not investigate why, but some links randomly display in a larger font size, at least on mobile Safari. This affects both the current and the proposed charter document.

[frivoal]

Many of the changes since the previous charter seems fine or good to me, but the following text has been removed, and I'd rather it weren't:

This list of modules is not exclusive: The WG may also create new CSS modules, within its scope. Also, it may split or merge CSS modules. If no participant in the group believes a proposed module is out of scope, and the group has consensus to add it, the group may add a new module. If the participants who object sustain their objection after discussion, a re-charter to clarify the scope may be needed.

[svgeesus]

Oh good catch, that was not an intentional removal.

[svgeesus]

but the following text has been removed, and I'd rather it weren't:

Fixed.

[svgeesus]

To avoid distracting diff-churn, the list of deliverables (with last publication dates, etc) is copy-pasted from the current charter. It will need to be regenerated just before this goes for AC review.

Charter now has current deliverables list including Intersection Observer

[svgeesus]

I had a look at the 2023 timeline (the prediction of what modules would get to Recommendation in the charter period) and compared it to the actual situation. The results could be better, some modules have had a bunch of work but have not been published to /TR at all in the current charter period. Perhaps some of these could be republished before the charter period ends.

This has improved, but we still have a bunch of specs whose last publication was 2013, 2014 etc.

[svgeesus]

The AC review has completed and their are four comments, which need to be discussed as a group: (these are all member-only links)

• https://lists.w3.org/Archives/Member/w3c-css-wg/2025JanMar/0020.html
• https://lists.w3.org/Archives/Member/w3c-css-wg/2025JanMar/0019.html
• https://lists.w3.org/Archives/Member/w3c-css-wg/2025JanMar/0018.html
• https://lists.w3.org/Archives/Member/w3c-css-wg/2025JanMar/0017.html

@astearns could these be on this weeks call please

[svgeesus]

From the AC Review form (Member-only link)

Although most fonts used on web pages are delivered on demand (web fonts), fonts installed on the user's system remain important for legacy content, for support of minority languages, and to support rare or recently-encoded characters. However, exposing the set of installed fonts is a known and significant fingerprinting vector. There is thus a tension between the desire for privacy and the desire to render pages in some languages well (or indeed, at all).

The CSS WG is working with the Privacy WG and the I18n WG to find an equitable solution to this problem.

[svgeesus]

Also from the review form (this was the discussion document for the TPAC 2024 breakout):

A white paper, Fonts, Privacy, and Not Breaking the Web

[css-meeting-bot]

The CSS Working Group just discussed [meta] Rechartering 2025-2027.

The full IRC log of that discussion

<bramus> ChrisL: few responses
<bramus> ChrisL: 1st response saying nothing special
<bramus> ChrisL: 2nd asking extra language
<bramus> ChrisL: response is that it sounds great and doesnt sound specific to CSS. suggestion to suggest to other group or some wording. no response yet.
<dbaron> s/nothing special/editorial addition saying CSS is good for a11y/
<bramus> ChrisL: suggestions welcome here
<ChrisL> https://www.w3.org/2024/09/font-i18n-privacy.html
<bramus> ChrisL: here is a link to a doc I wrote for tpac
<bramus> … long running issue is sometimes called a privacy issue or an i18n issue that pulls in opposite directions
<bramus> … had good discussion at TPAC
<bramus> … now, third comment … from center for democracy and technology
<fantasai> Regarding the previous point, how much of what's requested actually belongs in the charter?
<bramus> … looking forward to collaborating with css and privacy and i10n
<bramus> … not sure we can change charter to say we have more progress on this
<bramus> … i think they are saying that we should keep going
<bramus> … would love to reply that we will do that
<bramus> … does that seem reasonable?
<bramus> astearns: sounds reasonable
<bramus> ChrisL: can you send that?
<bramus> astearns: where to send it to?
<bramus> ChrisL: somewhere public would be good
<bramus> … should be addressed to the privacy wg and i18n wg
<bramus> … all of those were comments of the form whether we are doing things about something
<bramus> … last one is from brave and is a formal objection
<ChrisL> https://lists.w3.org/Archives/Member/w3c-css-wg/2025JanMar/0017.html
<bramus> ChrisL: unfortunately they were not able to attend the meeting at tpac back in the day
<bramus> … its not clear whether they realize work had been done, although they sort of quote a bit from that
<bramus> … i think they are aware but htey are saying we are doing nothing and are not addressing things
<ChrisL> Brave will happily remove our FO to the rechartering if the group proposes
<ChrisL> a plan to address the fingerprinting surface, and to commit to
<ChrisL> incorporating mitigations for this fingerprinting vulnerability into the
<ChrisL> group's specs.
<bramus> … they will remove FO if the WG plans to remove the fingerprinting surface
<bramus> … (see copy-paste)
<bramus> … also saying that our _refusal_ to address is concerning
<bramus> … what should we do as a group?
<bramus> astearns: my recollection is that we sort of had a plan, but not one that we can push through the specs directly
<bramus> … we thought that there would be a way of threading th eneedle between i18n and privacy
<bramus> … in saying that “yes browsers can limit access to user installed fonts if they provide a UI that popped in“
<bramus> ChrisL: my recollection as well, but have no resolution on that
<astearns> s/popped/opt
<bramus> … i think that nick dotty was of the opionion that UAs should do that
<bramus> … cost is that its an opt-in, either web wide or site-specifici
<bramus> … seems clear enough to propose as spec text
<jensimmons> q+
<bramus> … also true that ther eare other fingerprinting issues and should commit to solving those
<bramus> jensimmons: if there is gonna be text that mandates a UA to turn off privacy preservering features then I need to discuss internally
<bramus> astearns: but that has been a way forward for a while
<bramus> … maybe apple have arleady been thingkin gabout this
<bramus> jensimmons: I will try to find out
<bramus> ChrisL: Of course I will put proposed text into an issue, not directly in the spec.
<bramus> … dont want to break the web
<ChrisL> qq+
<bramus> fantasai: one of the things we can do to reduce the surface is to only allow access to user installed fonts if they give you access to code points that is outside the range of those served by the system
<bramus> … could limit it to letters
<bramus> … outside of the normal range
<astearns> ack jensimmons
<astearns> ack fantasai
<bramus> … but would allow a browser to uncoditoianlly allow access to user installed fonts, but only when necesaary
<astearns> ack ChrisL
<Zakim> ChrisL, you wanted to react to a previous speaker
<bramus> ChrisL: sometimes people install a newer version of a font because some glyphs were wrong, so doing a codepoint by codepoint thing means they would still get the broken behavior
<bramus> astearns: for the purpose of this discussion: chris you will open an issue with a proposed text and we will discuss that on a call very very soon and show that as the proposed plan that brave is requiring
<bramus> ChrisL: yes
<bramus> fantasai: when does our charter expire?
<bramus> ChrisL: have until march
<bramus> fantasai: so can discuss at f2f
<bramus> jensimmons: would love to see this fonts issue written out separately, in 1 place
<bramus> ChrisL: the whitepaper I linked to is basically that writeup

[kbabbitt]

On the fonts/privacy/i18n issue, are there minutes or other notes captured from the discussion at TPAC that I could catch up on?

[svgeesus]

The meeting was held at lunch, after leaving the hotel due to a prolonged power cut. There are no minutes.

That said: after a round of introductions (and summarizing the white paper, for those who had not had a chance to read it) the main new points coming out of the discussions were:

• not just minority languages are affected. Major languages, such as Chinese, will only render certain characters correctly if using the latest (user installed) fonts. And these are too large to use as webfonts
• preventing access to user-installed fonts is not just "this odd thing Safari started doing" but a good idea in general (reduced fingerprinting)
• providing opt-in access to user-installed fonts (either web-wide or, preferably, on a per-site basis) was necessary to correct the breakage that would otherwise occur (anything from a few wrong glyphs to the entire site being unreadable)
• as with all user permission prompts, thought is needed to cater for non-technical users