-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Text formats are for people #505
base: main
Are you sure you want to change the base?
Conversation
Draft Closes #453.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
|
||
People expect some amount of flexibility in terms of how their edits are processed. | ||
Allowing flexibility in whitespace, quoting, delimiters, and other syntactic elements ensures | ||
that content is still comprehensible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not about comprehensibility, but ease of editing / error prevention.
Might be good to link to the robustness principle somewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I literally wrote an RFC that says that the robustness principle harms interoperability: https://www.rfc-editor.org/rfc/rfc9413.html
I have friends who like to troll me with the phrase "Postel was wrong", but I'm guessing that didn't know :)
Either way, I think that this would be a mistake for the reasons stated in that document (see this bit). I think that your point about this being an example is a good one though. I've suggested something below.
People expect some amount of flexibility in terms of how their edits are processed. | ||
Allowing flexibility in whitespace, quoting, delimiters, and other syntactic elements ensures | ||
that content is still comprehensible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
People expect some amount of flexibility in terms of how their edits are processed. | |
Allowing flexibility in whitespace, quoting, delimiters, and other syntactic elements ensures | |
that content is still comprehensible. | |
Syntactic [robustness](https://en.wikipedia.org/wiki/Robustness_principle) | |
typically improves the usability of textual formats. | |
If user intent is unambiguous, flexibility in whitespace, quoting, delimiters, and other syntactic elements | |
makes the syntax less error-prone and creates a more pleasant editing experience. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
People expect some amount of flexibility in terms of how their edits are processed. | |
Allowing flexibility in whitespace, quoting, delimiters, and other syntactic elements ensures | |
that content is still comprehensible. | |
People expect some amount of flexibility in terms of how their edits are processed. | |
Clearly defining syntactic flexibility-- | |
such as in white space, quoting, or delimiters-- | |
could ensure that content is both easy to edit and produces consistent results. |
I think it might be worth adding a sentence linking this principle to EWP §2.10 The web is transparent. Something along the lines of this old blog post from Edd Dumbill:
That is to say, we operationalize 2.10's |
I was just reminded of this PR after reading this comment in the csswg repo. I think we should actually remove the specific guidance this currently has like:
Adding specific guidance in there muddles the core point of the principle, which is to consider human users and not design syntaxes that you expect to be consumed entirely by tooling. WRT what to do to make the syntax easier for humans, that is literally what the whole Design Principles document is for! Specific guidance implies scope, it implies that if you do these things mentioned here, you've complied with the principle. This is a higher level principle, we can't possibly list all the ways that a syntax is human-unfriendly in there. That said, we could perhaps list syntax flexibility as an example. But it's far from the only one, or even a core one. E.g. the SVG path syntax is actually quite flexible syntactically, but is dreadful for humans. |
Co-authored-by: Lea Verou <[email protected]>
|
||
People expect some amount of flexibility in terms of how their edits are processed. | ||
Allowing flexibility in whitespace, quoting, delimiters, and other syntactic elements ensures | ||
that content is still comprehensible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I literally wrote an RFC that says that the robustness principle harms interoperability: https://www.rfc-editor.org/rfc/rfc9413.html
I have friends who like to troll me with the phrase "Postel was wrong", but I'm guessing that didn't know :)
Either way, I think that this would be a mistake for the reasons stated in that document (see this bit). I think that your point about this being an example is a good one though. I've suggested something below.
People expect some amount of flexibility in terms of how their edits are processed. | ||
Allowing flexibility in whitespace, quoting, delimiters, and other syntactic elements ensures | ||
that content is still comprehensible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
People expect some amount of flexibility in terms of how their edits are processed. | |
Allowing flexibility in whitespace, quoting, delimiters, and other syntactic elements ensures | |
that content is still comprehensible. | |
People expect some amount of flexibility in terms of how their edits are processed. | |
Clearly defining syntactic flexibility-- | |
such as in white space, quoting, or delimiters-- | |
could ensure that content is both easy to edit and produces consistent results. |
Co-authored-by: Martin Thomson <[email protected]>
Co-authored-by: Martin Thomson <[email protected]>
Co-authored-by: Martin Thomson <[email protected]>
<h3 id=text-formats>Design textual formats for people</h3> | ||
|
||
Design textual formats that can be easily produced and consumed by people. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Textual formats also improve [transparency](https://www.w3.org/TR/ethical-web-principles/#transparent). | |
Co-authored-by: Lea Verou <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
whoops, this was just a review of a one-line change mt proposed. |
Draft
Closes #453.
Preview | Diff