The Responsive HTML5 output adds few extra characters in the output.
Is this something that can be controlled/changed?
Is there a way to still generate an output similar to the Web Help output without t=?
Or is t= something specific to Responsive HTML5 layout that will remain?
The t= contains the path to the current topic that should be available. The current implementation requires this to be in the URL. Even if Adobe would rewrite this, there would probably be some other type of URL parameters. Some browsers (like Safari on Mac) hide this part of the URL.
That leaves me to wonder why this is important. Is this confusing your readers in some way?
Not confusing the users.
We had the traditional Web Help integrated into the product build which had a specific way to invoke the context-sensitive help pages.
When we generate a Responsive HTML5 output of the same Web Help project, this is the only new addition. The t= in the URL.
So the logic/code to invoke the context-sensitive pages of Responsive HTML5 output will have to be tweaked a bit. We know what the change is and where to make it in out code. But just wanted to check if as authors do we have control over the t=
You have control over the t=. You can use it to open specific topics. You just can't hide it.
CSH has changed in Responsive HTML5. So your developers indeed need to tweak their call. You can find all the details here: https://www.helpessentials.com/2017/08/05/context-sensitivity-in-responsive-and-multiscreen-html5/
I don't know if this helps or informs, but here's what we do.
Our applications refer to an .xml file we maintain and publish as a baggage file in our RH projects. This XML file is an exact copy of the project's .ali file. So before we publish, we copy the ali file contents into the XML file (we just call it HELP.xml). This file is referred to by the application when a client clicks on Help.
And that worked fine until we transitioned to the HTML5 output, where we immediately saw the issue you reported.
So now, we technical writers just have one small additional task before we publish. We copy the contents of the .ali file into the xml file, then we do a Replace, where we replace
Takes just an extra few minutes, and was determined to be the least invasive / laborious way to resolve the issue.