- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sun, 29 Apr 2012 19:59:51 +0200
- To: Larry Masinter <masinter@adobe.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Marcos Caceres <w3c@marcosc.com>, Doug Schepers <schepers@w3.org>, "spec-prod@w3.org" <spec-prod@w3.org>
Larry Masinter, Sun, 29 Apr 2012 09:44:07 -0700: >> The fact that they still produce pure-text documents >> formatted for printing 80-column wide is either a travesty or a really >> awesome troll. > > It's more productive to understand the requirements. The most productive part of Tab's message was "RFCs in HTML and utf-8, properly linked up and anchored" ... ... > Email: IETF standards are developed in email, but email archives > commonly used throughout IETF (and W3C) are remarkably poor at > dealing with HTML, or discard the HTML and present an ugly attempt to > translate to ASCII text. It's not clear how to do better; there is no > suitable and implemented HTML profile defined as suitable for email > archives. I find W3's online, HTML versions of their mailing lists better than that of the RFC-Editor.org. It handles Unicode well too. It can even be improved. It is not such an unsolvable problem. > It's possible to for anyone to type an author's name into a search > engine -- allowing arbitrary Unicode might open you up to having to > deal with people who say their name is (╯°□°)╯︵ɹſsuıʞʇ∀qɐ┴. (If I > look at https://twitter.com/#!/tabatkins in my default browser, I get > 3 squares [] in one place, five in another, and one in another; the > characters are not uniformly available in the three fonts I see.) Would it not be possible, in the RFC format, to start with a allowing a subset (that covers more than than US-ASCII ...) of UNICODE? > RFCs are generally accessible. Producing accessible HTML requires > additional considerations not obvious to the typical internet-draft > author. And what do screen readers do with (╯°□°)╯︵ɹſsuıʞʇ∀qɐ┴? One accessibility issue is being able to ignore things. An RFC contains lots of repetitive text - especially at the start. It makes it tedious to start to understand. With links and anchors and CSS, one could start to hide things - or at least allow users to have "landmark links" that allow them to jump to the relevant place. E.g. for the words SHOULD, MUST etc, one could have a link to their definition. -- Leif H Silli
Received on Sunday, 29 April 2012 18:00:28 UTC