01:20
<Domenic>
Yes, I think we ended up needing to figure out what CSS properties apply and don't apply, and I didn't have the bandwidth for it?
01:23
<Domenic>
Sounds like https://github.com/whatwg/fetch/issues/526
06:35
<sideshowbarker>

Given <p> HI </p>, what per-spec is the expected result for running .innerText for that element?

I’m looking at https://github.com/LadybirdBrowser/ladybird/issues/4048, which is about that returning " HI " (whitespace preserved) in Ladybird — but returning "HI" (whitespace trimmed) in all other engines.

But looking the source at https://github.com/LadybirdBrowser/ladybird/blob/6b9e8cf40c89c75d95f855b5c244c3382984eaa9/Libraries/LibWeb/HTML/HTMLElement.cpp#L368 for the Ladybird implementation of the “get the text steps” https://html.spec.whatwg.org/multipage/dom.html#get-the-text-steps, it looks to me like Ladybird has correctly implemented the spec requirements.

So I’m wondering if the difference is due to a bug in Ladybird’s implementation — or else due to other engines not strictly implementing the spec requirements.

07:50
<gernknod>
thanks, yeah it seems there's not really a lot of interest in finding a solution for this :/
07:59
<Domenic>

I think

If node is a Text node, then for each CSS text box produced by node, in content order, compute the text of the box after application of the CSS 'white-space' processing rules and 'text-transform' rules, set items to the list of the resulting strings, and return items.

Trims the text. For the same reason that the rendering of <p>Hi</p> is the same as the rendering of <p>\n Hi\n</p>.

08:02
<Domenic>
So I'd look in whatever part of Ladybird corresponds to https://drafts.csswg.org/css-text/#white-space-rules
08:03
<sideshowbarker>
OK — thanks much
08:04
<sideshowbarker>
So it’s looking like https://github.com/LadybirdBrowser/ladybird/blob/88e11eea2d1f079675bf86496c63e49f16f4a1c6/Libraries/LibWeb/Layout/TextNode.cpp#L322 might be what I need to look at further
08:09
<sideshowbarker>
or need to be ensure that https://github.com/LadybirdBrowser/ladybird/blob/88e11eea2d1f079675bf86496c63e49f16f4a1c6/Libraries/LibWeb/HTML/HTMLElement.cpp#L320 is actually causing the CSS "white-space" processing rules and "text-transform" rules to actually be applied. Because i’s not clear the one text_for_rendering function which it’s calling is actually doing that
08:09
<sideshowbarker>
anyway, thanks again
08:11
<Domenic>
Yeah, if // This collapses whitespace into a single ASCII space if the CSS white-space property tells us to. is correct, then probably it's not quite right: I think sometimes it should collapse down to zero spaces.
08:11
<sideshowbarker>
yeah, seems so
08:12
<Domenic>
https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=13586
14:41
<annevk>
How is image sizing still not interopable? I created an SVG referenced from <img> and typo'd the height attribute (no viewBox). Firefox ended up with a different height from Chrome and Safari. Not entirely sure who is correct as I'm not sure what the current algorithm to be used is. (I remember there being a change since the 300x150 days.)