Page MenuHomePhabricator

Hieroglyphs are no longer inline
Open, Needs TriagePublic

Description

I92acda377f4eaf7238888bb2fe2703b2f8aa5646 broke hieroglyphs inline in text.

For example, here:

CurrentExpected

Community discussion: https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2018/11#Hieroglyphs

Event Timeline

MaxSem created this task.Nov 29 2018, 4:06 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 29 2018, 4:06 AM

Community discussion of the bug here.

Looks like Esander's change is not the problem here. Even after returning the CSS, it doesn't display on the same line. Looking at the rendered HTML, hieroglyphs are rendered on a table that's outside of the paragraph text (paragraph <p></p> is closed before the hieroglyph).

This looks like some behavior change of HTML generation, or maybe a HTMLTidy/Remex problem

@ssastry - Do you know of any changes in the HTML rendering on Commons around November 25th that might be related to this?

ssastry added a comment.EditedDec 30 2018, 5:22 AM

@ssastry - Do you know of any changes in the HTML rendering on Commons around November 25th that might be related to this?

I don't. I tried echo '<center><hiero>S5</hiero><hiero>S6</hiero> </center>' | php maintenance/parse.php locally after enabling wikihiero and even when I checked out code from a couple months back, the two of them render vertically, not horizontally since each instance is rendered in its own table. I even tried with Tidy and same results.

The complaint about this rendered correctly "In the past" is not helpful in figuring out when this "broke".

Looking at archive.org, this snapshot from Sep 12 2017 shows that the hieroglyphs are rendered horizontally .. So, as of Sep 2017, this was rendering as desired. The next snapshot from Nov 19, 2018 is the broken rendering. So this has been broken well before Nov 25 and we'll need to git bisect both mediawiki core and wikihiero codebase in the Sep 2017 - Nov 2018 timerange to see what broke this.

Inspecting the HTML and CSS of the affected hieroglyphics in Firefox, it looks like it is not the HTML that has changed, but the CSS that applies. The Sep 2017 snapshot has this CSS that isn't in the Nov 2018 snapshot

.mw-hiero-outer {
    display: inline-block;
}

Hope this helps you all in tracking down the problem.

I verified that this would fix the problem by opening https://de.wikipedia.org/wiki/%C3%84gyptische_Hieroglyphen in Firefox and adding the above CSS rule -- it fixes the rendering to the desired version.

I verified that this would fix the problem by opening https://de.wikipedia.org/wiki/%C3%84gyptische_Hieroglyphen in Firefox and adding the above CSS rule -- it fixes the rendering to the desired version.

This is not correct. Those hieroglyphs are inside a template that give a specific format (a table), which doesn't produce a <p>. This is not a normal test case.

Please test again with this page and you'll see what I said on T210695#4842920 : https://es.wikipedia.org/wiki/Usuario_discusi%C3%B3n:Ciencia_Al_Poder#Textos_que_incluyen_jerogl%C3%ADficos

I don't see how bare text will remain p-unwrapped when tidied (whether with Tidy or with Remex). See below. I am checking out mediawiki 1.29.0 which is very old and has Tidy (not Remex). See mediawiki HTML output below. So, this is a broken expectation of the wikihiero extension if it is relying on bare text not being p-wrapped.

[subbu@earth:~/work/wmf/mediawiki] git checkout 1.29.0
HEAD is now at a112e4fa48 Allow SVGs using an older proposed recommendation DTD
[subbu@earth:~/work/wmf/mediawiki] echo "x <table><tr><td>foo</td></tr></table> y <table><tr><td>foo</td></tr></table> z" | php maintenance/parse.php --tidy
parse.php: warning: reading wikitext from STDIN. Press CTRL+D to parse.

<p>x</p>
<table>
<tr>
<td>foo</td>
</tr>
</table>
<p>y</p>
<table>
<tr>
<td>foo</td>
</tr>
</table>
<p>z</p>

https://web.archive.org/web/20171216123532/https://en.wikipedia.org/wiki/Female_genital_mutilation#Antiquity demonstrates what I am saying there. The text preceding and following the hieroglyphs have been paragraph wrapped and the hierographys render on a different line.

Now, look at https://en.wikipedia.org/w/index.php?title=Egypt&action=edit&section=1 ... and you see that the article editors use a <div style="display:inline;"> wrapper around the hieroglyphs for this reason. If you apply the CSS style I mentioned above, the page renders "as expected".

So, the summary is that the wikihiero extension makes a bad assumption about rendering in the presence of text. In practice, editors work around this by either using <div> wrapping tricks either inline or possibly via templates. In this case, the noticed regression is caused by the CSS rule. If that CSS rule is fixed, the workarounds will "work around" as expected.

The longer term solution fix is to update the wikihiero extension.

Ok, I wrongly assumed that the user who asked for help in my talk page, was using a real example from other pages where this happened, but it appears not. Sorry for the confusion.

Dvorapa added a subscriber: Dvorapa.

Dvorapa: I am going to remove the Tidy and RemexHtml tags ... this is not a Tidy or RemexHtml problem as I mentioned above.

Ah, I see, I should read the whole discussion here (facepalm to my own dumbness), sorry

Okay, so we know, what caused this bug (T202359), we know, who caused this bug (@Esanders) and who were his accomplice (@Jdforrester-WMF, @Ryasmeen). Should we A) revert and reopen the former bug or B) find a different solution to make the table inline (is there any)?

Okay, so we know, what caused this bug (T202359), we know, who caused this bug (@Esanders) and who were his accomplice (@Jdforrester-WMF, @Ryasmeen).

Accusatory language like this is deeply unhelpful and violates the Code of Conduct. Please cease.

Should we A) revert and reopen the former bug

I would suggest "break editing pages with hieroglyphics for all users of Chrome so that they render nicely" would be a bad change, so no.

or B) find a different solution to make the table inline (is there any)?

I'd be happy to help implement a fix. Suggestions welcome.

Okay, so we know, what caused this bug (T202359), we know, who caused this bug (@Esanders) and who were his accomplice (@Jdforrester-WMF, @Ryasmeen).

Accusatory language like this is deeply unhelpful and violates the Code of Conduct. Please cease.

Sorry, it was only a humor.

or B) find a different solution to make the table inline (is there any)?

I'd be happy to help implement a fix. Suggestions welcome.

@Jdforrester-WMF Okay, if display:inline-block was breaking editing for Chrome users, will display:inline-table work for them? (https://stackoverflow.com/a/7458122)