Needs to prevent Flash Of Unstyled Content (FOUC) as well as content shifts
If we were to apply a class on page load after the page had painted, it would introduce a massive layout shift to make the content expand
Other features we may use this for:
Dark mode - this would have a FOUC
Font-size - would have a layout shift if we did not render block
Concerns:
If we open this up, and in a yearâs time, because of volunteers and extensions, weâve got 10,000 features that use this, is this ok?
AS: there are many ways to poison the cache
If you mess with stored HTML you will poison the cache
For now, Which class on the body will change :
AS - Suggestion: Startup module - tell it to load another set of modules if the cookie is set there
You have different solutions here - the constraint is very very important - you may end up with different solutions that arenât the way that have been envisioned
âBloatâ of size and features are concerns
Concern: Sending large amounts of CSS to everyone
Question: What is bloat, what is acceptable?
MS: Ownership: who owns this, who says what should and shouldnât come in? We shouldnât find ourselves in 2 yearsâ time with 10k of these
MS: Just booleans?
Need to consider what kind of data can / should be stored
Font-size will not be a boolean
>2 but not a lot of values?
A requirement could be: no arbitrary/string value. Only bool or set of options
JF: Are there existing settings we might want to migrate?
JF: Thumbnail size - currently hard-coded, only available to logged-in users, splits parser cache
JF: Will e.g. thumbnail size be migrated to client side preference?
JF: A way to balance performance cost and performance benefit
RK: this would also require changing how the preference is handled for logged in users!
JF: and providing an API for thumb sizes, which has been open for 10 years now
AS: If you change the image size, it will be part of HTML, unless you load a large size and make it smaller. It gets nasty, and quickly
MS: Logged in vs. not-logged-in users , what are the implications here?
Cookies have expirations. Will we ever consider, especially if weâre moving between non- and logged-in users,
IP Masking - non-logged in users are kind of logged in!
NR: The way we currently handle limited width, we use an inline script that handles cookies for anonymous users; logged in users donât get this script at all
This was probably a mistake. After speaking with the team
Ideally everything that works for anons also works for logged in
This is a device preference, it doesn't matter if youâre logged in or anonymous
We always want this for our features: Limited width, font-size, dark mode
VG: treating anons and logged in users the same will be beneficial
This could trigger inconsistencies, may not look good
VG: also worried about a per-device setting - this could enable tracking of devices
MS: Per-Device?
esp. Re: a11y, Iâm not sure all settings make sense to be per-device - font-size would be expected to persist across devices
Would logged-in users want their font-size (or other accessibility features) to stick regardless of the device they are on
If this is true, then this is a concern you will need to look into
Do we just move it to preferences, in this case?
AS: when you log in, many cookies are flashed. Not necessarily all?
Users have a different UX than non-logged out: gadgets, different views, etc.
MS: If I am logged in and set my preference to be bigger, I would not expect them to persist when anonymous.
But if I set this device, I would expect it to remain
Up to you all to define this - we should see how users will react
Itâs complicated, but is it worth solving?
Anything that would be bad to store client side?:
AS: Anything that needs to persist for legal reasons
RK: things with many values, many arbitrary values, large impacts on the page
One thing you could do is have a separate UX and hide it behind a CSS class - 5KB of HTML and have âdisplay: noneâ set . As an intuition, everything weâve talked about so far has been style changes - changing the appearance of things that donât exist. Show/hide smaller things, but not showing/hiding entire UX - things that take a lot of space to store
JF: skin preference; desktop vs. mobile; which languages to display - 500 versions of the doc in DOM; anything with a large ratio of performance impact!
This is hard to enforce technically, better to enforce socially!
Historically, we havenât been successful at enforcing things socially - âletâs make an exception in this caseâ
MS: How can we be defensive? what is created here is an enablement of something - a cookie that you can add features into. There is no good way to create a pipeline for it. Itâs easy to keep track of how many things add cookies. Could a gadget do this, because itâs a FE cookie? We need a way to shine a light on what is impacting the cookie. Otherwise we can lose control over this. How can we be defensive?
JF: "I'll just re-implement MonoBook as a Gadget".
NR: this is definitely a concern I have as well. Maybe an allow-list, either in the inline script, or, in the script, we donât allow it to add what is in the cookie
NR: performance will always trump other preferences - perf is always first
MS: if we limit it to 5, should we create a pipeline?
AS: saying âperformance comes firstâ is a misnomer - if you change perf drastically, everything will become complicated. This is more about scale. It doesnât matter how many preference, but rather people should understand how the caching pipeline and mediawiki works. There are complex use cases that touch sensitive areas of MW.
NH: ways to future-proof this from a naming POV?
JF: all of our naming conventions have changed over time
NH: migration implications?
JF: We could handle this the standard way. Once youâve got a stable name, you can make changed rapidly
NR: Internal-only restriction? MS brought up the question of whether gadgets could use this. One idea I had : when launching this, we restrict it to internal-only usage. The concern is releasing it, opening the floodgates, people use it in ways we didnât anticipate. Being conservative: this is internal use only, seems easier. Does anyone see a problem with this strategy?
AS: I donât and I think itâs a good idea!
RK: I think this is fine, but even something for internal use needs to be well-documented! We donât all know each other. Not super-discoverable, not announced, etc., but this doesnât free us from having to think about use cases and documentation. Explaining that this is not something you should use lightly / should not use without approval from team X, will be an important part of this communication. Even if itâs internal use, we still need to document it well (how do we use it, you need to get approval from x team, etc)
MS: having this as restricted is a good idea. But we need to take into account what happens when it is not restricted. But - the definition of âinternalâ is tricky - does this include WMDE? âOnly staffâ gets complicated. Iâm in favor of restricting, but how do we do this? Just by numbers?
AS: One way to look at it is to not put it as a gadget / allow users to use it as a gadget.
JF: There are ~400 people who can merge code into MW, about ~50 of them are from WMDE, and about ~50 of them aren't on Slack. Roughly.
MS: a combination of defensive coding but also policy
JF: we do this with beta features! The beta-feature allow list uses this - if you donât list a feature in SiteConfig, you canât use it. You must email James F if you want to use it. It wonât go live to production unless you go through this gate.
NR: This is for the beta features extension?
JF: we could use this for Core - if in array, then quick check
AS: We need to make sure this is clear: This is touching core of caching in mediawiki, do not touch it unless you're sure it's not going to bring down everything
MS: the next step, a group of people who are interested in a solution will brainstorm. Please alert Moriel if youâre interested in participating in this. Also - if there are other people who should be here
