ID exports HTML CSS in wrong order!

[James Gifford—NitroPress]

I just spent 20 minutes trying to tweak an HTML export page with some CSS, and finally realized the output wasn't reading any of my changes. 

So I looked at the code... and found ID is placing the added CSS before the generated CSS file!

This has to be a new bug, or it would have been noted long ago, I think. I'm pretty sure I've done HTML CSS before with no problems..

[Laubender]

Hi James,

did you use InDesign 2023 version 18.5.0 ?

( Still I cannot see the release version for it here in Germany, but I'd be able to test the Prerelease version on my Windows 10 machine. )

Regards,
Uwe Laubender
( Adobe Community Expert )

[James Gifford—NitroPress]

Still on 18.4 here. I should have noted that. 

[James Gifford—NitroPress]

This really needs to be reported as a bug and acknowledged for fixing, but all I see is the Feature Request forum, which is not the same thing.

Unless someone with 18.5 wants to run a quick test and see if the reversed CSS export was a one-release glitch...

[James Gifford—NitroPress]

And yes, this fault persists in v18.5 under Windows. This needs to be acknowledged as a bug needing a fairly urgent fix, as it completely cripples the ability to use CSS files with HTML exports and in a subtle way that will surely confound many users.

[James Gifford—NitroPress]

And, just a bump on this, v19/2024 is still exporting the CSS in the wrong order. A warning to anyone exporting to HTML with an associated CSS file.

[James Gifford—NitroPress]

No fix in v19.1:

[James Gifford—NitroPress]

Sigh. No fix in v19.2:

[James Gifford—NitroPress]

It took me a while to get back around to this with the release of v20. I had hopes the issue had been fixed since there was major attention paid to HTML in this release, with the addition of 'HTML5' export.

Nope.

"Legacy HTML" still exports user CSS links in the wrong order, placing them before the base "idGenerated" file and thus having them negated or overwritten in actual browser interpretation.

Really, Adobe, this has been a problem for well over a year and several major releases, and if it needs more than fifteen minutes from one of your most junior coders I'd be gobsmacked. Can this simple technical error be rectified soon, and make HTML export from ID for all but the most basic users functional again?

[Joel Cherney]

if it needs more than fifteen minutes from one of your most junior coders I'd be gobsmacked.

I don't want to rile any feathers by speculatin' as to what is going on with the dev team, but I don't find it surprising that we got a brand-new fancy HTML5 exporter, but that no bugs fixed in the old exporter. Also the word "Legacy" was tacked on to the old exporter, to inform you covertly that it's never seeing dev attention ever again.

[James Gifford—NitroPress]

Yeah, I thought of that. But of course no one wants to export documents to HTML except in the massively wonky page-emulation mode of PO/HTML5.

Whatever, this glitch can be fixed in seconds in any code editor, moreso if a macro or script is used. But it's a pointless waste of time to have to do it on every iterative export, it was a really stupid mistake on someone's part around v17 and even the most resolute idea to sunset that useless old HTML export shouldn't be a reason not to fix it.

[Joel Cherney]

Complete agreement!

If only we could get a few hundred people to a) agree, and then b) vote-bomb the Uservoice, then maybe we could get the dev team to put their most junior coder on the task.

[James Gifford—NitroPress]

I guess the Venn intersection of (1) users who export to HTML and (2)  use custom CSS for export and (3) have noticed it doesn't really quite work and (4) care is... this —> ·

It's the slapstick nature of the fault and the likely triviality of fixing it that throw me, here.