WHATWG on 2023-03-13

08:08	<sideshowbarker>	Sam Sneddon [:gsnedders]: jgraham it’d be great if one of you could either give me owner access to the html5lib-tests repo, or else take a look at https://github.com/html5lib/html5lib-tests/pull/152 and figure out why the workflow isn’t running. I suspect it may be because the repo has some setting that requires approvals for workflows in PRs before they can run. Otherwise, I don’t know what would be preventing the workflow from running there.
10:44	<Sam Sneddon [:gsnedders]>	Domenic: yes I encountered these exact issues when I was chasing layout thrashing in wikipedia. e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1054515. My opinion is that interop around mouse events is terrible. Perhaps this can go into interop2024? documenting all the cases where it's caused problems (like layout thrashing in Wikipedia) seems like it would both be a lot of effort but would probably make a much more compelling argument in favour of including it in Interop
10:49	<jgraham>	Yeah, seems like it would be an investigation, right? Unless we already have a very clear idea of what the behaviour should be and the problem is just that people aren't implementing it right. I don't off the top of my head have loads of examples of it causing webcompat issues, but maybe if it's a perf footgun that would be enough of an argument.
11:07	<Noam Rosenthal>	Sam Sneddon [:gsnedders]: the wikipedia case was documented here: https://techblog.wikimedia.org/2020/11/23/web-performance-case-study-wikipedia-page-previews/
11:10	<Noam Rosenthal>	I think the spec is actually clear enough, but implementations do all kinds of funny stuff which created de-facto interop issues
11:12	<Noam Rosenthal>	e.g. offsetX/Y issues in chromium: (1) computed lazily instead of when the event comes - layout thrashing and inaccurate results. (2) computed from the nearest block element (ignores inline). Other implementations have other similar issues, it's kinda described in the aforementioned WPTs
12:05	<Jake Archibald>	annevk: is there a spec definition for a user agent stylesheet that isn't html specific?
12:06	<Jake Archibald>	Context: we want view transitions to work in other document types, and we need somewhere to put the default styles. I could invent a "view transition user agent stylesheet".
12:44	<Domenic>	annevk: is there a spec definition for a user agent stylesheet that isn't html specific? Each spec defines their own. E.g. SVG's is at https://www.w3.org/TR/SVG2/styling.html#UAStyleSheet , MathML's is at https://w3c.github.io/mathml-core/#user-agent-stylesheet
12:44	<Jake Archibald>	Ahh cool, I'll do the same then
12:44	<Jake Archibald>	Cheers!
12:53	<Domenic>	By this, I hope you mean, will send a PR to each of them? Unless you are creating a new markup language, those should be the three canonical UA stylesheet specs on the web.
12:57	<Jake Archibald>	Domenic: oh, my plan was to create a global view transition UA stylesheet. Would that not be easier for implementers, rather than fragmenting the feature across multiple specs? As a middle ground, could the change to HTML/SVG/MathML say something like "Include the [=global view transition user agent stylesheet=]"?
12:59	<Domenic>	Jake Archibald: so, if something is applicable to all elements, then usually it isn't done via the UA style sheet. It's done via changing the relevant CSS infrastructure directly. E.g. there's no need to add `* { display: inline; }` to the UA stylesheet, because the initial value for `display` is `inline`.
13:00	<Domenic>	Or, e.g., if you want to change how something behaves on the root element (regardless of what type of root element), you'd use language like https://w3c.github.io/csswg-drafts/css-display/#root
13:02	<Jake Archibald>	Domenic: In our case, we have default styles for pseudo-elements https://drafts.csswg.org/css-view-transitions-1/#ua-styles, but we also create dynamic styles in the UA stylesheet that are scoped to the document https://drafts.csswg.org/css-view-transitions-1/#ref-for-document-view-transition-style-sheet%E2%91%A3. I'm in the process of removing the HTML requirement here (eg replacing `html` with `:root`)
13:06	<Domenic>	It looks like there is no good precedent for this. Every other CSS spec has done the bad thing, and ambiguously monkeypatched "the UA stylesheet" (which one of the three?). Sometimes even as a recommendation instead of a requirement. https://drafts.csswg.org/css-pseudo-4/#highlight-ua-styles https://w3c.github.io/csswg-drafts/css-lists-3/#marker-properties
13:09	<Domenic>	I don't know what a good pattern would be, if CSS doesn't have the infrastructure to handle default styles on psuedo-elements without using something like a "UA stylesheet". Ideas: Someone (CSS? HTML?) defines a "global all-namespaces UA stylesheet". 2a. Each CSS spec monkeypatches that as it desires. 2b. Everyone sends PRs against that in a coordinated fashion. 2c. Everyone sends PRs adding "also include [this portion defined over here]".
13:10	<Domenic>	2b and 2c are the only ones that have a hope of detecting conflicts or ordering issues
13:11	<Jake Archibald>	Domenic: Ok, I'll proceed with https://github.com/w3c/csswg-drafts/pull/8572, but also file an issue proposing 1 and 2c with the csswg
13:11	<Jake Archibald>	I'll note it as an issue in our spec too
13:12	<Jake Archibald>	Specifically the lack of coordination in the current model
13:12	<Domenic>	Sounds great
13:12	<Domenic>	I think also your spec might be easier to read if all the UA styles were in one place, but maybe you want to delay that until we have a 2c model.
13:19	<Jake Archibald>	Domenic: We went back and forward on that. I guess all in one place is better for implementers. Whereas documenting the default UA styles with each pseudo seems better for reference.
13:54	<Sam Sneddon [:gsnedders]>	Domenic: We went back and forward on that. I guess all in one place is better for implementers. Whereas documenting the default UA styles with each pseudo seems better for reference. Having both is always an option, like how we have an IDL index at the end of most specs.
13:56	<Jake Archibald>	Sam Sneddon [:gsnedders]: hah, I had the same thought, but I'm not keen on maintaining it twice. I guess I could write a script to gather them up. I wonder if bikeshed has a plugin system…
13:58	<Sam Sneddon [:gsnedders]>	Sam Sneddon [:gsnedders]: hah, I had the same thought, but I'm not keen on maintaining it twice. I guess I could write a script to gather them up. I wonder if bikeshed has a plugin system… There's always "file a bug on BS"
13:59	<Sam Sneddon [:gsnedders]>	I don't know what a good pattern would be, if CSS doesn't have the infrastructure to handle default styles on psuedo-elements without using something like a "UA stylesheet". Ideas: Someone (CSS? HTML?) defines a "global all-namespaces UA stylesheet". 2a. Each CSS spec monkeypatches that as it desires. 2b. Everyone sends PRs against that in a coordinated fashion. 2c. Everyone sends PRs adding "also include [this portion defined over here]". there should probably be some bug somewhere tracking the problem of the fact we essentially have multiple UA stylesheets with no defined cascade between them… is there?
14:02	<Jake Archibald>	Filed https://github.com/w3c/csswg-drafts/issues/8573. But yes, the HTML, MathML and SVG stylesheets should say they appear 'after' this universal UA stylesheet.
14:38	<Sam Sneddon [:gsnedders]>	Filed https://github.com/w3c/csswg-drafts/issues/8573. But yes, the HTML, MathML and SVG stylesheets should say they appear 'after' this universal UA stylesheet. does https://github.com/w3c/csswg-drafts/issues/8573#issuecomment-1466263142 seem fair?
14:46	<Jake Archibald>	replied. I think it's ok in some cases