Regressions in 2.4 xhtml export [was: TESTING Tarballs for 2.4.0]

[Richard Kimberly Heck]

On 5/20/24 09:48, Pavel Sanda wrote:
> On Mon, May 20, 2024 at 03:24:30AM +0200, Thibaut Cuvelier wrote:
>>> InsetInfo shortcuts export to xhtml is borken compared to 2.3.
>>>
>>> In 2.3 we exported: <span class='info shortcut'>Ctrl+N</span>
>>> In 2.4 we expor: <bdo class="shortcut" dir="ltr">Ct+r+l+++N</bdo>
>>>
>>> Thibaut, I guess this is due to new xml routines, could you have a look?
>>>
>> Actually, it was due to the refactoring for direction in HTML5. I have
>> pushed 7cfe36e6aa4460ae8641cd36f4aab5f013390326 and
>> e3f2b10842cdc808e9f2bf235692f283009d3734 to fix that. This could make it to
>> 2.4.0, as it is a bit serious.
> I vote for 2.4.0 as well, the fix is restricted to xhtml code which
> shows regression anyway.
> Riki?

Yes, all these can go to 2.4.0, since this is a regression, and we are 
still working on the Windows build problems.

>
>> The problem is that this is configured in most layouts (HTMLStyle block),
>> so it is painful to fix.
>>
>> The best solution in the long term, in my opinion, is to switch to HTML
>> definition lists, which is semantically correct (while the current output
>> is not a good use of lists). It mostly works out of the box, with no CSS
>> changes. I believe the C++ changes would be quite minimal, but it would
>> break any custom CSS. I am attaching an excerpt from the User's guide:
>> `UserGuide_list.xhtml` for the current output, `UserGuide_list -
>> Copy.xhtml` for my proposed refactoring. The result is quite close to what
>> we have in LyX. I bet this change should be delayed to 2.4.1, as it might
>> break a bit more, or even 2.5 if we consider this kind of change breaking.
> Riki, might want to chime in here as he was behind original xhtml design.
> I find switch to html lists conceptually better, though they are visually
> somewhat distinct - label is on it's own line AFAICS.
>
> When it comes to timing:
> - CSS change could go IMHO into 2.4.0, but it will break custom CSS anyway right?
> - I do not know how C++ changes would look like, if they are indeed minimal
>    I would consider them for 2.4 as well. I understand that it might break
>    custom CSS but at the moment we are producing trash by default.
>
> Riki?

I will have a look at this. CSS changes, etc, are fine for 2.4.0.

>>> - url is text instead of url: 6.3.1, 6.15, 6.16.1 (wrong url anyway)
>>>
>> This is not possible with the current layout format. URLs are implemented
>> as flex insets, with many parameters, but the current design forces that
>> the flex inset outputs its contents only once. For this two work, we'd need
>> to output it twice: as text and as a parameter. It doesn't look not too
>> hard to implement (my current bet is on InsetText::insetAsXHTML, around
>> writing the opening outer tag with `htmltag()`), but we need a new layout
>> version, hence not in scope for 2.4.
>>
>> - bibliography items has the same huge fonts size as the section heading
>> Actually, they are output as headings (`h2`). However, I don't understand
>> anything about the HTML bibliography code (which is why it is completely
>> different in DocBook) :/. I don't understand how to set the HTMLTag for
>> bibliography items (it's always reset to `h2` when reaching
>> `xhtmlParagraphs` from `output_xhtml.cpp`'s `makeBibliography`). If anyone
>> understands the code well enough :). (Otherwise, maybe it'd be good to
>> rewrite it to be more similar to DocBook.)
> Riki imght have some idea? Otherwise I will forward this issue to trac so wehave it on the list.

I will look at this as well.

>
>>> - some nomenclanture links do not work (e.g. try "Shift" or "Alt")
>>>
>> Some magic IDs are not output, especially for list items. That's what I'm
>> changing in 2d86b881242c3ea4756af28f8458aeb7cbfa6822, a candidate for
>> backporting to 2.4.1.
> I endorse this. Riki?

OK!

Riki