- From: Larry Masinter <masinter@adobe.com>
- Date: Sun, 29 Apr 2012 09:44:07 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>, Marcos Caceres <w3c@marcosc.com>
- CC: Doug Schepers <schepers@w3.org>, "spec-prod@w3.org" <spec-prod@w3.org>
> 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. 40 year old RFCs are still pretty universally usable. There is less document success with other formats. Promises of future support because of widespread deployment aren't worth much more than a "gopher:" URL. Many in the IETF use simple text tools like grep and diff on their personal copies of all RFCs and even editor drafts. RFCs are single-file. If you allow images in HTML, then do you change that or package them together? 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. 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.) 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ɐ┴? There are more; my point is that I think these are important considerations that W3C (and spec-prod) should consider as benefits not yet attained. Larry -- http://larry.masinter.net
Received on Sunday, 29 April 2012 16:44:36 UTC