PP 1.41, xhtml, and validation

[rconn]

Hi Tim:

It seems that with PP 1.41, the web help is always created as xhtml, regardless of the setting in the H&M "HTML Export Options / Export XHTML 1.1 compliant HTML".

Unfortunately, that means that my 1191 help pages have gone from validating successfully to each having 17 errors and 22 warnings, for things like:

Warning Line 27, Column 20: character "<" is the first character of a delimiter but occurred as data
togTocButton = '<%TOGTOC_BUTTON%>' == "button" ? true : false;

Error Line 179, Column 48: there is no attribute "border"
…img name="main" src="home.gif" border="0" alt="Home topic" title="Home topic" …

etc.

Is there a way to either get the generated xhtml to validate, or to switch back to html?

Thanks for your help.

Rex

[Tim Green]

Hi Rex,

Yes, XHMTL is an absolute requirement for the Premium Pack skins, they won't work without them. The errors and warnings are all non-critical so I wouldn't worry about them. Even so, we'll see what we can do to tidy them up a bit for the next release. Even so, the focus is not on making validators happy but on making web pages that work. (The <%TOGTOC_BUTTON%> variable is a bit of a kludge we introduced for a customer, I think we should probably remove it or populate it with a dummy value...)

[Tim Green]

Hi Rex,

Update: Most of these errors are caused by the lack of CDATA tags around the JavaScript that is dynamically generating the page, so the Validator is trying to interpret the script as HTML. These are not actually real errors, just the validator reading the wrong code. We'll fix it as soon as possible but the messages can actually be ignored here.

[rconn]

Hi Tim:

Thanks for the response; I'll wait for the update and let you know how it works.

Rex

[Tim Green]

Note: I've just discovered that it won't be possible to enclose the inline javascript in cdata blocks in the short term because that would trash the templates in Help & Manual. You should also NOT try to do it manually in your own templates! The problem is that HM's internal source is all XML, and the templates are actually already contained in cdata blocks inside the project's XML source. If you add additional cdata blocks within those the XML parser will end the template too soon, and the results are not good.

We're going to look into this for future updates but for the moment it's really just a validator problem, not a real one.

[TonyNiemann]

I just discovered this CDATA issue myself. I have written a tool to migrate my H+M document into a Drupal site. To do this I convert the HTML Page Template to XML with CDATA blocks ... it works until I close and reopen the project, at that point everything in my template past the first CDATA closure "]]" is lost.

For now I guess am going to replace the closure with a code string and then do a batch string replace on my output xml files but it would be nice to avoid this extra step.

Perhaps H+M could do a URL Encode on the template before storing it in it's .HMXP XML file, I think that would solve the problem.

Thanks,
Tony

[Tim Green]

Hi Tony,

Perhaps H+M could do a URL Encode on the template before storing it in it's .HMXP XML file, I think that would solve the problem.

That won't work, unfortunately, because Help & Manual's own XML parser needs to read all the project source as well-formed XML. Escaping the CDATA enclosures would sabotage that process...

[TonyNiemann]

I'm not sure that escaping the CDATAs that I add in the template would not make the project file into poorly formed XML.

See this article: http://stackoverflow.com/questions/6910 ... data-block

[Tim Green]

Hi Tony,

You could escape your Cdata inside HM's Cdata blocks, that would not be a problem for HM (but possibly for you later unless you allowed for that in your code). But it would be invalid for HM to escape its own Cdata blocks because then they wouldn't work -- I thought that was what you meant.