1928605 - votermaps.org - Markings are not centered on states

Status: ASSIGNED

(Web Compatibility :: Site Reports, defect, P3)

Description

[Raul Bucata]

Environment:
Operating system: Ubuntu
Firefox version: Firefox 132.0

Steps to reproduce:

1. Navigate to: https://votermaps.org/
2. Observe the markings

Expected Behavior:
The markings are centered on the states

Actual Behavior::
The markings are off-centered

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/143427

Comment 1

[Raul Bucata]

Attachment: 20241101_111949.mp4

Comment 2

[Dennis Schubert [:denschub][OOO, back Aug 11]]

This is just a big <svg>.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Here's a reduced testcase that reproduces the bug for me (made using the testcase-reducer addon). Works as-expected in Chrome.

Comment 5

[Daniel Holbert [:dholbert]]

The markup here includes xml:space="preserve", which makes us preserve whitespace (used for indentation etc. in the raw HTML/SVG), per https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/xml:space and apparently that pushes the marker-text (the "X" characters etc) over to the right.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Here's a testcase comparing no-special-whitespace-markup vs. xml:space=preserve vs. white-space:pre.

Firefox preserves spaces (for layout purposes) in the latter two pieces. Chromium and WebKit do not.

Comment 7

[Daniel Holbert [:dholbert]]

Looks like the behavior-difference here is simply because other browsers haven't implemented this yet, per longsonr's stackoverflow answer on https://stackoverflow.com/questions/75318684/svg-text-and-white-spacepre-compatibility

He references https://developer.mozilla.org/en-US/docs/Web/CSS/white-space which has a On SVG elements row in the compat table, where Firefox is the only browser.

So: this is a case where the site is (accidentally?) using a feature that only Firefox has implemented, and it happens to produce bad output.

Ideally we should contact the site and ask them to remove xml:space="preserve" from their SVG, maybe via Twitter/X -- they seem to be here:
https://x.com/votermapsorg

We could also theoretically ship a sitepatch with this CSS, to override the xml:space="preserve" setting that the site is using here (which Firefox honors but other browsers do not):

svg { white-space: initial; }

I verified locally that this^ CSS intervention is sufficient to work around the issue.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 3, with space markup on text elements -- all browsers preserve spaces now

Comment 9

[Daniel Holbert [:dholbert]]

Aha, so this doesn't work in Chrome or WebKit specifically because they have white-space: nowrap as part of the default styles for their <text> elements. (So, white-space styling on the svg element doesn't get to inherit to those text elements as it normally would.)

But if I manually add xml:space=preserve or white-space: pre on each text element, as in my just-attached testcase 3, then that makes other browsers match Firefox.

I suspect that line in the other browsers' UA stylesheets is a legacy quirk and Firefox is correct here, but I'm not entirely sure.

Comment 10

[Daniel Holbert [:dholbert]]

In WebKit at least, the UA stylesheet rule in question dates back to 2006:

text, tspan {
   white-space: nowrap !important
}

https://searchfox.org/wubkat/rev/a5a1d966e08323065505274ba19f522b34d0fb6c/WebCore/css/svg.css#53-54

Here's the version they have today:
https://searchfox.org/wubkat/rev/b63de498aa94e9988947bd65ab87f853e9920bbf/Source/WebCore/css/svg.css#64-69

text {
    white-space: nowrap;
}

Here's the equivalent rule in Chromium, I think:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/svg.css;l=73-75;drc=ff3612ad273667afe9b77de3ba5489199749b307

So they've had this behavior ~forever (long before SVG2).

Firefox also seems to have had our "inheriting the value from the SVG element" behavior ~forever, too; we honor the spaces in the xml:space=preserve part of testcase 2 (and we have the text offset in testcase 1) at least as far back as Nightly 2011-02-01, version 4.0b11pre, which is roughly as far back as I can test.

So, independent of changes in SVG2, this behavior (where text elements have a their own default for whitespace-handling and need to be directly targeted to override that) seems to be a longstanding rendering difference between other browsers and Firefox. It might be worth adding our own UA stylesheet rule for compat here...

(It does look like WebKit has done some work in this area recently BTW, in https://bugs.webkit.org/show_bug.cgi?id=112032 , but that was just to make this inherit properly for stuff like <text style="white-space: ..."><tspan>)

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #10)

So, independent of changes in SVG2, this behavior (where text elements have a their own default for whitespace-handling and need to be directly targeted to override that) seems to be a longstanding rendering difference between other browsers and Firefox. It might be worth adding our own UA stylesheet rule for compat here...

Counterpoint: Inkscape and Opera 12.16 (pre-Blink) agree with Firefox's long-standing behavior here. So it's looking like the Chromium/WebKit behavior (of resetting the white-space handling on each text element) is just a Webkit bug that's lasted decades, I guess.

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: testcase 4 (just the xml:space part of testcase 2, as a standalone SVG, for testing in SVG engines like e.g. inkscape)

Comment 13

[Daniel Holbert [:dholbert]]

So, bottom line, it looks like we're technically correct here (the best kind of correct), and it'd be reasonable to ask the site to change their styles (and/or we could ship an intervention directly if it becomes necessary, to add some additional site-specific styles to fix things ourselves).

Our request for the site here would be to do one of the following (in the source of the main https://votermaps.org/ landing page):
(1) Remove xml:space="preserve" from the <svg> element for the map.

(2) ...or if they'd rather not do that (e.g. if that's added by some SVG tooling and might creep back in when they regenerate the map in the future), they could simply suppress the bad effects of that attribute by adding this to https://votermaps.org/styles.css:

svg { white-space: initial; }

Comment 14

[Daniel Holbert [:dholbert]]

I poked them on Twitter/X to ask them to take a look: https://x.com/CodingExon/status/1877427921515684107

Comment 15

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1928605 - add a CSS intervention for votermaps.org to center their state markers; r?denschub

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/66bf1b1947dd
https://hg.mozilla.org/integration/autoland/rev/97283233c963
add a CSS intervention for votermaps.org to center their state markers; r=denschub,webcompat-reviewers

Comment 17

[amarc]

https://hg.mozilla.org/mozilla-central/rev/97283233c963