Validate HTML - #3782
Conversation
rjsparks
left a comment
There was a problem hiding this comment.
This is really wild.
I think the spot where we end up with a csrf token outside of a form needs touching before this is merged.
It would be super nice if you could get your editor to leave file endings alone, or to customize it to leave an LF at the end of .py files.
A few other questions/comments inline
|
|
||
| # keep the html-validate configs here, so they can be kept in sync easily | ||
| config = {} | ||
| config["frag"] = { |
There was a problem hiding this comment.
Is this a preferable place for settings vs settings.py?
There was a problem hiding this comment.
I would rather have test_runner settings in test_runner than in settings.py. These aren't settings production needs, and this seems to be the right level of encapsulation for them. But instead of trying to alter the object that comes from django.config.settings perhaps there should be a module object for them instead?
Use tempfile to handle large validation responses.
Address some other review comments by @rjsparks.
1077c59 to
a5ee6b5
Compare
|
I think we can merge this now. I'll restructure the option that's being bolted onto settings later (it should go into the construction of our specialized template engine. |
With this PR, all HTML generated during the test run will be validated (with HTML-validate).
The bulk of the PR is fixes to various templates, so they actually validate.
This increases the run time of the test suite from ~20 minutes to ~24 minutes on my system. I consider this acceptable and have hence enabled this by default. There is a
--no-validate-htmloption to turn validation off.