RFC 7993

Cascading Style Sheets (CSS) Requirements for RFCs

πŸ“… published December 2016, from ietf

RFC 7993: Cascading Style Sheets (CSS) Requirements for RFCs πŸŽ€βœ¨

Okay bestie, here's the title block tea πŸ«–πŸ’– This one came from the Internet Architecture Board (IAB) stream, and it's written by H. Flanagan from the RFC Editor team. It's Informational (so not a Standards Track spec πŸ¦‹), it's dated December 2016, and it's got the ISSN 2070-1721. The title block doesn't list any RFCs it obsoletes or updates, so it doesn't claim any πŸ™ˆ


Abstract 🌸

Okay so the HTML version of RFCs gives style guidance to a special Cascading Style Sheet (CSS) that's made just for the RFC Series πŸ’… The embedded, default CSS that the RFC Editor includes is supposed to be accessibility-friendly and built on a responsive design model, so it looks good on everything πŸ“±πŸ’» This doc lays out the requirements for that default CSS. The class names come from the ones defined in "HTML for RFCs" (RFC 7992) 🧚


Status of This Memo ✨

Quick heads up: this is not an Internet Standards Track spec. It's just published for informational purposes 🌈

This doc is a product of the Internet Architecture Board (IAB). It's basically info the IAB decided was worth keeping on the permanent record πŸ“œ It shows the consensus of the IAB. Docs the IAB approves for publication are not a candidate for any level of Internet Standard, see Section 2 of RFC 7841 πŸ’œ

If you want the latest on this doc's status, any errata, or how to send feedback, check http://www.rfc-editor.org/info/rfc7993 πŸ”—


Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved πŸ’…

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, at http://trustee.ietf.org/license-info, as they stand on the date this was published. Please actually read these, because they spell out your rights and restrictions for this doc πŸ‘€πŸ“‹


Table of Contents πŸ—ΊοΈ

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Design Goal . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  General Requirements  . . . . . . . . . . . . . . . . . . . .   3
4.  Page Layout . . . . . . . . . . . . . . . . . . . . . . . . .   4
  4.1.  Title Page Header . . . . . . . . . . . . . . . . . . . .   4
  4.2.  Body  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
  4.3.  Font Choices  . . . . . . . . . . . . . . . . . . . . . .   4
5.  Printing  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
6.  Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
7.  CSS Classes and Attributes  . . . . . . . . . . . . . . . . .   5
  7.1.  .alignCenter  . . . . . . . . . . . . . . . . . . . . . .   5
  7.2.  .alignRight . . . . . . . . . . . . . . . . . . . . . . .   5
  7.3.  .artwork  . . . . . . . . . . . . . . . . . . . . . . . .   5
    7.3.1.  .art-ascii-art  . . . . . . . . . . . . . . . . . . .   5
    7.3.2.  .art-logo . . . . . . . . . . . . . . . . . . . . . .   5
  7.4.  .cref . . . . . . . . . . . . . . . . . . . . . . . . . .   5
  7.5.  .crefAnchor . . . . . . . . . . . . . . . . . . . . . . .   6
  7.6.  .crefSource . . . . . . . . . . . . . . . . . . . . . . .   6
  7.7.  .dlCompact  . . . . . . . . . . . . . . . . . . . . . . .   6
  7.8.  .dlHanging  . . . . . . . . . . . . . . . . . . . . . . .   6
  7.9.  .dlParallel . . . . . . . . . . . . . . . . . . . . . . .   6
  7.10. .docInfo  . . . . . . . . . . . . . . . . . . . . . . . .   6
  7.11. .eref . . . . . . . . . . . . . . . . . . . . . . . . . .   6
  7.12. .finalized  . . . . . . . . . . . . . . . . . . . . . . .   6
  7.13. .note . . . . . . . . . . . . . . . . . . . . . . . . . .   6
    7.13.1.  .rfcEditorRemove . . . . . . . . . . . . . . . . . .   6
  7.14. .olCompact  . . . . . . . . . . . . . . . . . . . . . . .   7
  7.15. .olPercent  . . . . . . . . . . . . . . . . . . . . . . .   7
  7.16. .pilcrow  . . . . . . . . . . . . . . . . . . . . . . . .   7
  7.17. .relref . . . . . . . . . . . . . . . . . . . . . . . . .   7
  7.18. .rendered . . . . . . . . . . . . . . . . . . . . . . . .   7
  7.19. .sourcecode . . . . . . . . . . . . . . . . . . . . . . .   7
  7.20. .toc  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
  7.21. .type . . . . . . . . . . . . . . . . . . . . . . . . . .   7
  7.22. .ulCompact  . . . . . . . . . . . . . . . . . . . . . . .   8
  7.23. .ulEmpty  . . . . . . . . . . . . . . . . . . . . . . . .   8
  7.24. .url  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
  7.25. .xref . . . . . . . . . . . . . . . . . . . . . . . . . .   8
8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
  9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
Appendix A.  List of Classes  . . . . . . . . . . . . . . . . . .  10
IAB Members at the Time of Approval . . . . . . . . . . . . . . .  14
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction 🌷

Okay so the HTML format for RFCs, which is described in [RFC7992], gives style guidance to a Cascading Style Sheet (CSS) that's specifically made for the RFC Series ✨ This CSS gets embedded in the published HTML, and you're allowed to override it with a locally defined CSS if you want πŸŽ€ The embedded, default CSS the RFC Editor includes is expected to take accessibility needs into account and be built along a responsive design model. It's giving "works everywhere" πŸ“±

This doc describes the requirements for the default CSS the RFC Editor uses πŸ’– Unless it's called out otherwise, any styling for these classes must not alter the natural language content in any visible way. A lot of these classes exist to mark elements semantically, so elements using them should just inherit their surrounding styling. The exceptions are listed below πŸ‘€ There's also a class for Internet-Drafts, so certain features that only show up in I-Ds can look different in some way inside those drafts πŸ¦‹ These requirements only apply to HTML documents the RFC Editor publishes, as per [RFC7990] 🌸

Heads up: the details in this doc are expected to change based on what gets learned while building the new publication toolsets 🧚 Revised docs will be published to capture those changes as the toolsets get finished. Other implementers must not expect those changes to stay backwards compatible with the details in this doc πŸ™ˆ


2. Design Goal πŸ’…

RFCs must be adaptable to a wide variety of devices and displays, accessible to assisted readers, and printable 🌈


3. General Requirements ⭐

  • Support the display of the semantic HTML described in [RFC7992]. πŸ’œ
  • Follow best practice for accessibility, as defined by the W3C's "Best Practices for Authoring HTML" [HTMLBP]. β™Ώ
  • Follow best practice for mobile devices, as defined by the W3C's "Best Practices for Authoring HTML". πŸ“±
  • Allow for a broad range of internationalized scripts. 🌍

4. Page Layout πŸŽ€

4.1. Title Page Header πŸ“œ

The document header must be at the top of the document and include all information described in "RFC Style Guide" [RFC7322] and "RFC Streams, Headers, and Boilerplates" [RFC7841]. It's the front-door look, so make it count ✨

4.2. Body 🌸

The body of the document must conform to the following:

  • Examples and code blocks must be in a fixed-width font πŸ’»
  • ASCII art must be in a fixed-width font 🎨
  • Reflow the text as the screen gets smaller and limit max width πŸ“±
  • Block quotes must be indented πŸ’¬
  • Tables must allow for distinct header rows πŸ“Š
  • Paragraphs should include a hover-over paragraph identifier πŸ–±οΈ

All anchor tags and URLs should be clearly distinguished as links, for example, through the use of color and/or text decoration, following appropriate accessibility standards. Nobody should have to guess what's clickable πŸ”—

4.3. Font Choices πŸ–‹οΈ

  • Default to a sans-serif font family with broad Unicode support for web browser viewing. 🌐
  • Default to a serif font family with broad Unicode support for printing. πŸ–¨οΈ
  • A fixed-width font must be used for code and artwork-tagged sections. πŸ’»
  • All fonts should be publicly licensed and supported by all major web browsers. πŸ’–

5. Printing πŸ–¨οΈ

The CSS must include support for a printer-friendly output. The print rules should be a part of the embedded style sheet. Consumers of an RFC may develop their own print-specific style sheet, as desired πŸ¦‹


6. Lists πŸ“

Lists should provide ample whitespace between list elements for legibility, unless a 'compact' class is specified (e.g., .dlCompact, .ulCompact, .olCompact) 🌷


7. CSS Classes and Attributes πŸ’…

This section describes the CSS classes that result in specific changes to the natural language content of a document. A full list of available classes, not including basic selectors, is included in Appendix A 🧚

7.1. .alignCenter πŸŽ€

To be used with '.artwork' to indicate the figure should align in the center of the page flow ✨

7.2. .alignRight πŸ‘‰

To be used with '.artwork' to indicate the figure should align on the right of the page flow 🌈

7.3. .artwork 🎨

These classes will mostly be styled as part of '.artwork'. Specific classes may include '.art-ascii-art' and '.art-svg'. Artwork gets its own block of space, centered in the page flow, and it will not float. Images should have a max width of 100% so views scale properly across a variety of screens and devices πŸ“±πŸ’»

7.3.1. .art-ascii-art πŸ’»

Must use a mono-spaced font. πŸ”€

No visible changes to the natural language content; keep in default style. Note that such images are not currently allowed in RFCs. πŸ™…β€β™€οΈ

7.4. .cref πŸ’¬

A comment within an I-D; should be visually distinct. πŸ‘€

For I-Ds only; not for RFCs. 🫢

7.5. .crefAnchor πŸ”–

A comment within an I-D; should be visually distinct. πŸ‘€

For I-Ds only; not for RFCs. 🫢

7.6. .crefSource πŸ“Ž

A comment within an I-D; should be visually distinct. πŸ‘€

For I-Ds only; not for RFCs. 🫢

7.19. .sourcecode πŸ’»

okay so code examples or components should be in a fixed-width font πŸŽ€ if the human language has one available, and they should be visually distinct πŸ¦‹. if there's no fixed-width font for that language, just use the default font for it πŸ’….

7.20. .toc πŸ“š

the table of contents should be clearly distinguished 🧚 using an indented, ordered list with the list style set to 'none', which allows for hyperlinked, in-line dotted number notation (e.g., 1., 1.1., 1.1.1.) ✨.

7.21. .type πŸ’œ

no visible changes to the natural language content, so keep it in default style 🫢.

7.22. .ulCompact πŸ“

use less spacing on a bulleted list than the default 🌸.

7.23. .ulEmpty πŸ¦‹

indent from the margin of the previous paragraph πŸ’–.

7.24. .url πŸ”—

should be clearly distinguished as links πŸ’….

7.25. .xref 🧚

should be clearly distinguished as links ✨.

8. Security Considerations 🚨

Security vulnerabilities can be introduced through the CSS, as with CSS injection attacks [CSSATTACK]. In order to avoid or mitigate any attack vectors here, the CSS used must comply with the current CSS Specifications from the W3C.

bestie, this one is serious 😭 CSS injection attacks are a real thing, so the CSS you use must comply with the current CSS Specifications from the W3C. no skipping this one πŸ’€

9. References πŸ“–

9.1. Normative References

9.2. Informative References

  • [CSSATTACK] Huang, L-S., Weinberg, Z., Evans, C., and C. Jackson, "Protecting browsers from cross-origin CSS attacks", In Proceedings of the 17th ACM conference on Computer and communications security (CCS '10), pp. 619-629, 2010, https://doi.org/10.1145/1866307.1866376.

Appendix A. List of Classes πŸŽ€

This section lists all the CSS classes 🌈. Except for those also listed in Section 7, none of these result in specific changes to the natural language content of a document πŸ’œ.

  • .adr
  • .alignCenter
  • .alignRight
  • .annotation
  • .artwork
    • .art-ascii-art
    • .art-logo
    • .art-svg
  • .ascii
  • .author
  • .authors
  • .bcp14
  • .center
  • .city
  • .compact
  • .country-name
  • .cref
  • .crefAnchor
  • .crefSource
  • .dlCompact
  • .dlHanging
  • .dlParallel
  • .docInfo
  • .ears
  • .email
  • .eref
  • .finalized
  • .fn
  • .index
  • .indexChar
  • .indexIndex
  • .indexItem
  • .indexPrimary
  • .indexSubItem
  • .initial
  • .iref
  • .irefItem
  • .irefRefs
  • .irefSubItem
  • .label
  • .left
  • .locality
  • .nameRole
  • .note
    • .rfcEditorRemove
  • .olCompact
  • .olPercent
  • .org
  • .organization
  • .pilcrow
  • .postal-code
  • .published
  • .refContent
  • .refDate
  • .refInstance
  • .refTitle
  • .reference
  • .region
  • .relref
  • .rendered
  • .RFC
  • .rfcEditorRemove
  • .right
  • .role
  • .selfRef
  • .series
  • .seriesInfo
  • .sourcecode
    • .lang-*
  • .street-address
  • .status
  • .street-address
  • .surname
  • .tel
  • .toc
  • .type
  • .ulCompact
  • .ulEmpty
  • .url
  • .workgroup
  • .xref
  • .vcard

IAB Members at the Time of Approval 🧠

The IAB members at the time this memo was approved were (in alphabetical order):

  • Jari Arkko
  • Ralph Droms
  • Ted Hardie
  • Joe Hildebrand
  • Russ Housley
  • Lee Howard
  • Erik Nordmark
  • Robert Sparks
  • Andrew Sullivan
  • Dave Thaler
  • Martin Thomson
  • Brian Trammell
  • Suzanne Woolf

Acknowledgements 🫢

With many thanks to the RFC Format Design Team for their efforts in making this transition successful πŸ‘‘: Nevil Brownlee (ISE), Tony Hansen, Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, Alice Russo, Robert Sparks (Tools Team liaison), and Dave Thaler.

Additional thanks to Arlen Johnson of Spherical Cow Group, LLC, for his assistance in clarifying the requirements in more CSS-designer-friendly language πŸ’–.

Author's Address βœ‰οΈ

Heather Flanagan RFC Editor

Email: rse@rfc-editor.org URI: http://orcid.org/0000-0002-2647-2220

πŸ“¦ where this page comes from