jwj61
commented
4 years ago Running this on another page, it seems that a knowl generates an error since knowl is not a legal attribute of an anchor. That will make it hard to run cleanly.
Open AndrewVSutherland opened 4 years ago
jwj61
commented
4 years ago Running this on another page, it seems that a knowl generates an error since knowl is not a legal attribute of an anchor. That will make it hard to run cleanly.
alexjbest
commented
4 years ago The w3c validator has pretty good "message filtering" options, so while we'lll never get it to fully validate, its easy to hide those knowl attribute errors when checking out a page.
AndrewVSutherland
commented
4 years ago I think the right way to handle knowls is to create a custom HTML element for knowls rather than adding illegal tags to anchor elements. E.g. the HTML
<!DOCTYPE html>
<html lang="en">
<head><title>hi</title></head>
<body>
<a-knowl title="Elliptic curve over a field [ec]" knowl="ec" kwargs="">elliptic curves</a-knowl>
</body>
</html>will compile cleanly. I think it would only take a small change to the KNOWL template and the code in knowl.js to actually make this code work (but there are surely others who know more about this than I do).
There is actually no guarantee that our current implementation of knowls will work in all browsers, they would be well within their rights to discard the illegal attributes we are adding.
edgarcosta
commented
4 years ago That sounds like a good fix for the knowl thing, but perhaps more natural is to equip the anchor with a class, and link to the show knowl page in case the JavaScript is disabled.
On Sat, Aug 15, 2020, 17:04 Andrew Sutherland notifications@github.com wrote:
I think the right way to handle knowls is to create a custom HTML element for knowls rather than adding illegal tags to anchor elements. E.g. the HTML
<!DOCTYPE html>
hi elliptic curves will compile cleanly. I think it would only take a small change to the KNOWL template and the code in knowl.js to actually make this code work (but there are surely others who know more about this than I do).
There is actually no guarantee that our current implementation of knowls will work in all browsers, they would be well within their rights to discard the illegal attributes we are adding.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LMFDB/lmfdb/issues/3981#issuecomment-674447022, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACO2BSI4MC2RK22K3QTO3LSA3Z4VANCNFSM4P7W6UUA .
AndrewVSutherland
commented
4 years ago @edgarcosta I like this idea, and in fact there is no need to create a custom HTML element, we could just do
<!DOCTYPE html>
<html lang="en">
<head><title>hi</title></head>
<body>
<a class="knowl" data-title="Elliptic curve over a field [ec]" data-knowl="ec" data-kwargs="" href="/knowledge/show/ec">elliptic curves</a>
</body>
</html>which validates fine and would be an even easier change.
The site https://validator.w3.org/ provides an HTML validator that can dynamically verify the syntax of any URL. For example, the results for the LMFDB's front page can be found at
There are many error/warning messages (currently 137), all of which are likely benign, but it would be useful (as with pyflakes) to cleanup our html to the point where we could used this validator to find actual bugs in our html (and there definitely are problems like missing quotes or tags on various pages of the LMFDB). There are really three parts to this issue:
Setup a script that travis could run on each pull request to verify the HTML markup on a designated list of pages (e.g. the browse page and an object page for each section).
Cleanup our standard templates (e.g. base.html and homepage.html) so that they validate cleanly and we can start catching actual problems in particular pages.
Address all the errors/warnings flagged by the validator so that we can reach a point where the travis validation tests all run cleanly.