Different config files, batch tool

[MikeGale]

I was checking some files in batch mode today. Some I can control completely. Others have content automatically generated by frameworks, parts of the content are beyond my reach.

In such circumstances I can see benefit in being able to use different config files, in batch mode.

This could be a setup option in the URL specific Tab of a target. The developer is responsible for creating config files (that forgive the unfixable errors).

[Albert Wiersch]

Hi Mike,

That's an interesting suggestion but I don't think I could justify it at this point. Perhaps the config file could be edited with the Configuration Editor to specifically allow for these unfixable issues, but it would depend on exactly what the issue is as to how complicated it would be (if it is possible) to implement a solution that addresses only the unfixable issues.

If you'd like to send me a sample of the unfixable issues, then I will take a look and see if there is an easier solution.

[Albert Wiersch]

Also, use may be able to use the "cseignore" element. If you have a certain part or section of an HTML or XHTML document that you want CSE HTML Validator to ignore, then you can enclose it in "cseignore" tags. Perhaps you can enclose the HTML with unfixable issues in the "cseignore" tag.

Example:

Code: Select all

<cseignore>bad HTML here</cseignore>

[MikeGale]

Hi,

Your suggestions have taken me further than I was.

The <cseignore> helps in some cases. It protects against blocks that can be identified and marked in the XHTML source. (In my test case it reduced error count from 35 to 13.)

It doesn't work with injected script. The ASP.NET (1.1) framework injects script immediately after the form opening element and immediately before the form closing element. I could not find any way to easily force it to inject within a <cseignore></cseignore> block. (That's the residual 13 errors noted above.)

There is also bad markup in the head element and within the opening body tag. I can correct these before a page goes live, though the editing environment (design surface) fouled them up (in 1.1) whenever it touches them. (Fortunately this can be avoided by simply not using the design surface, ever.) I'm not sure whether protection is needed from these.

I was envisaging a solution put together by a user of CSE. For example, I have pages which have the aspx extension but are legal XHTML. Other pages with the same extension have sections that I have decided are outside my control, only those need special handling. It's a case by case thing!

The block protection mechanism in fact makes different CSE configuration unnecessary if it can be implemented completely.

<cseignore> solves a lot the issues, if there were a way to mask injected script it would in fact be exactly what is needed on the test page (and maybe a lot of others.)

I will sent a greatly cut down version of the page by email. It has viewstate and the text of many kilobytes of injected JavaScript deleted.

Summary:
1) <cseignore> is great.
2) If it could catch injected script it would be perfect in some cases. (Maybe a tag like <cseIgnoreScriptBlocksImmediatelyAfter /> / <cseIgnoreScriptBlocksImmediatelyBefore /> tag. Which ignores all contiguous script blocks until something else is found, or <cseIgnoreBlocksImmediatelyAfter tag="script,img" caseinsensitive="true" /> with a before version too.)
3) Foul ups in the head area can be fixed by the developer, I'm not sure whether protection is needed in some circumstances.

NOTE: I used camelCase in the tags, otherwise they're really hard to read, one area where I think the XHTML specification got it wrong!

Another idea: a tag acting like <cseIgnoreBeforeUntil tagUntil="form" /> would do the job and be easier for the developer to insert, he can see the form tags directly in the source.

[Albert Wiersch]

Thanks Mike. I have received your email and have replied.

I'm glad that the "cseignore" tag was very useful.

I don't believe in spending a lot of resources to make ways to ignore bad markup, after all, CSE HTML Validator is suppose to find bad markup. Therefore, it's unlikely that I will be able to add more sophisticated ways to ignore markup with tags like you suggest, although it is an interesting suggestion! Furthermore, I think there may be other ways to address the remaining issues you are having, which I am emailing you directly about.