datatracker
datatracker copied to clipboard
ietf-tools
feat: Use bs5 for htmlized doc
This gets rid of a bunch of old code by re-using document_main to render htmlized docs into a new set of bs5-based templates.
Also fixes #4057 and #3653.
This depends on https://github.com/ietf-tools/rfc2html/pull/11 and https://github.com/ietf-tools/rfc2html/pull/12.
This is a pretty big change of what's really the most heavily fetched format from the datatracker. We may want to phase this in? (and possible fix the html brokenness in rfc2html at the same time).
As mentioned out of band, when I first moved this to the datatracker, I didn't preserve the colored header and got immediate feedback that people wanted it back.
Please look at #3466.
We may want to phase this in?
We should definitely deploy on sandbox first and ask for feedback.
@rjsparks should we chat about how to make this available for community feedback?
We can do a deployment of the branch on the sandbox server using a new DNS name (such as htmlize-preview.ietf.org), or you could look at rewiring the PR to put this htmlization at a different endpoint than the current, so that they are both available in production for some time (/doc/htmlpreview/ perhaps). If we go with deploying the branch, it would be good to keep it close to main.
~~I'll look I to adding another button for deployment testing via main.~~
Actually, it will require a lot of work to rework the PR for that. I think deploying the branch is easier. We can also first get some initial feedback during the codesprint.
@rjsparks I think this is ready for you to take a look (htmlization and pdfization of various documents). If you think it's ready, maybe we do public testing?
@martinthomson the recent CSS changes don't work in the Weasyprint PDFization:
Ugh, that's clearly a lack of CSS grid support.
I do have to ask why you are feeding this stylesheet in for printing to PDF though. Isn't the regular style sheet better for that?
Because so far, the htmlized text was pdfized by the datatracker. Maybe that should change. I think the RFC Editor pdfizes the html?
Hmm, I can maybe try to use @supports to provide some fallback styling (which won't look like the original). Or you can do what rfc-editor.org does. For example: https://www.rfc-editor.org/rfc/rfc9261.pdf
I think you're getting confused between pdf output from xml2rfc v3 and pdf of htmlized documents. Martin is pointing to v3 pdf output with his link above.
As with most places where we have confusion across the v3 boundary wrt -ized documents, we need to consider whether people will expect the fundamental structure of what they're getting back to be the same for pre-v3 and post-v3 documents. For the endpoints that advertise themselves as -ized, I think they should return the same kind of thing.
Moving this into a branch at ietf-tools to assist with a feedback deployment