Hello @AydinE,

We use HTML validation in our UI tests, see: https://github.com/Lombiq/UI-Testing-Toolbox/blob/68d72b676e7ba75882a4887df325e5b05ddd793e/Lombiq.Tests.UI/Docs/Tools.md#:~:text=HTML%20markup%20validation%20can%20be%20done%20with%20html%2Dvalidate%20via%20Atata.HtmlValidation.

I also don't fully get the relation with the other linked issue.

The relation is only this part: atata-framework/atata-htmlvalidation#8.

So if there is an HTML validation problem it renders like this:

  91:6   error  <button> is missing required "type" attribute  element-required-attributes
  91:93  error  Class "shepherd-button" duplicated             no-dup-class

✖ 2 problems (2 errors, 0 warnings)

More information:
  https://html-validate.org/rules/element-required-attributes.html
  https://html-validate.org/rules/no-dup-class.html

This is okay, but in the code, it's also just one big string. So if we want to ignore some rules from the code, we would have to write complex regexes, etc. to search for specific patterns to ignore. Instead of this, it would be nice to have an array of objects, which contains the rule id, description, etc. when there is an error.

A good example of that is what the accessibility checking does: https://github.com/Lombiq/UI-Testing-Toolbox/blob/68d72b676e7ba75882a4887df325e5b05ddd793e/Lombiq.Tests.UI/Docs/Tools.md#:~:text=Accessibility%20checking%20can%20be%20done%20with%20axe%20via%20Selenium.Axe%20for%20.NET.
During a UI test, if we have accessibility errors and you debug the code here (axeResult): https://github.com/Lombiq/UI-Testing-Toolbox/blob/dev/Lombiq.Tests.UI/Services/AccessibilityCheckingConfiguration.cs#L65-L66
You could see, that the problems are in an array of objects with descriptions, ids, etc.

Is this addressed?

Keep the simple text output too, but this output should from then on be the recommended way. Change all built-in features to use that.

Is this addressed?

Keep the simple text output too, but this output should from then on be the recommended way. Change all built-in features to use that.

Yes, but we did in a way, that the output is still human readable, both the file and the output in VS. But at the same time, you can ignore rules easier error.RuleId is not "prefer-native-element". And yes, this is the default now.

OK, great!