Skip to content

fix URLs and typo nits #9

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.

Sign up for GitHub

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

Closed
wants to merge 1 commit into from
Closed

fix URLs and typo nits #9

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 13 additions & 13 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,38 +5,38 @@ We—the undersigned—advocate a change to the approach that web standards comm

Our primary goal is to tighten the feedback loop between the editors of web standards and web developers. We prefer an evolutionary model of standardization, driven by the vast army of web developers, to a top-down model of progress driven by standardization.

Browser vendors should provide new low-level capabilities that expose the possibilities of the underlying platform as closely as possible. They should seed the discussion of high-level APIs through JavaScript implementations of new features (as done in the cases of [Mozilla’s X-Tags](http://www.x-tags.org/) and [Google’s Polymer](http://www.polymer-project.org/)). This involves web developers in the process and by iterating outside of the browser, avoids the platform getting stuck with bad APIs.
Browser vendors should provide new low-level capabilities that expose the possibilities of the underlying platform as closely as possible. They should seed the discussion of high-level APIs through JavaScript implementations of new features (as done in the cases of [Microsoft’s X-Tags](https://x-tag.github.io/) and [Google’s Polymer](https://www.polymer-project.org/)). This involves web developers in the process, and, by iterating outside of the browser, the platform avoids getting stuck with bad APIs.

Specifically, we offer the following design principles for an Extensible Web Platform:
* The standards process should focus on adding ***_new low-level capabilities_*** to the web platform that are secure and efficient.
* The web platform should expose low-level capabilities that ***_explain existing features_***, such as HTML and CSS, allowing authors to understand and replicate them.
* The web platform should develop, describe and test new high-level features in JavaScript, and allow web developers to iterate on them before they become standardized. This creates a ***_virtuous cycle_*** between standards and developers.
* The standards process should ***_prioritize efforts_*** that follow these recommendations and deprioritize and refocus those which do not.
* The web platform should develop, describe, and test new high-level features in JavaScript, while allowing web developers to iterate on them before they become standardized. This creates a ***_virtuous cycle_*** between standards and developers.
* The standards process should ***_prioritize efforts_*** that follow these recommendations; efforts that do not should be deprioritized and refocused.

------

By focusing on standardizing ***_new low-level capabilities_***, and building new features in terms of them, we:
* Contain new security surface area.
* Allow optimizations in browser engines to focus on the stable core, which affects more APIs as they are added. This leads to better performance with less implementation effort.
* Allow optimizations in browser engines to focus on the stable core, which during implementation can positively affect other APIs', leading to better performance with less implementation effort.
* Allow browser vendors and library authors to iterate on libraries that provide developer-friendly, high-level APIs.

By explaining existing and new features ***_in terms of low-level capabilities_***, we:
* Reduce the rate of growth in complexity, and therefore bugs, in implementations.
* Make it possible to polyfill more of the platform's new features.
* Require less developer education for new features. Educational materials can build off of concepts that are already in the platform.
* Require less developer education for new features. Educational materials can build off of concepts already present in the platform.

Making new features easy to understand and polyfill introduces a ***_virtuous cycle_***:
* Developers can ramp up more quickly on new APIs, providing quicker feedback to the platform while the APIs are still the most malleable.
* Mistakes in APIs can be corrected quickly by the developers who use them, and library authors who serve them, providing high-fidelity, critical feedback to browser vendors and platform designers.
* Library authors can experiment with new APIs and create more cow-paths for the platform to pave.
* Mistakes in APIs can be corrected quickly by the developers who use them and library authors who serve them, providing high-fidelity, critical feedback to browser vendors and platform designers.
* Library authors can experiment with new APIs and create more ["cow paths"](https://en.wikipedia.org/wiki/Desire_path) for the platform to pave.
Copy link
Author

@cvan cvan Sep 13, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

using en prefix because Wikipedia can possibly show a 404 if the doc is not localised (to my knowledge): https://wikipedia.org/wiki/Desire_path


By ***_prioritizing efforts_*** that follow these principles, we:
* Free up the standards process (especially in the short-term) to focus on features with security or performance concerns, and features that can only be added at the platform level, such as new hardware.
* Free up the standards process (especially in the short term) to focus on features with security or performance concerns and features that can be added at only the platform level, such as new hardware.
* Allow web developers and browser-initiated libraries to take the lead in costly explorations.
* Simplify and streamline the longer-term process of standardizing new APIs, which will already have implementations and significant real-world usage.


We want web developers to write more declarative code, not less. This calls for eliminating the standards bottleneck to introducing new declarative forms, and giving library and framework authors the tools to create them.
We want web developers to write more declarative code, not less. This calls for eliminating the standards bottleneck to introducing new declarative forms, giving library and framework authors the tools to create them.


In order for the open web to compete with its walled competitors, there must be a clear path for good ideas by web developers to become part of the infrastructure of the web. We must enable web developers to build the future web.
Expand Down Expand Up @@ -100,8 +100,8 @@ Member, CSS WG; Google

-----

**Related reading**
* [Extend the Web Forward](http://yehudakatz.com/2013/05/21/extend-the-web-forward/), by Yehuda Katz, which fleshes out these ideas more.
* [An Extensible Approach to Browser Security Policy](http://yehudakatz.com/2013/05/24/an-extensible-approach-to-browser-security-policy/), by Yehuda Katz, which presents a practical application of these principles to the problem of designing an API for the browser's Content Security Policy.
**Related Reading**
* [Extend the Web Forward](http://yehudakatz.com/2013/05/21/extend-the-web-forward/), by Yehuda Katz, which fleshes out more these ideas more.
* [An Extensible Approach to Browser Security Policy](http://yehudakatz.com/2013/05/24/an-extensible-approach-to-browser-security-policy/), by Yehuda Katz, which presents a practical application of these principles to the problem of designing an API for the browser's [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/Security/CSP).
Copy link
Author

@cvan cvan Sep 13, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again, using an English URL because of a bug with the site.

* [Dropping the F-Bomb on Web Standards](https://briankardell.wordpress.com/2013/05/17/dropping-the-f-bomb/), by Brian Kardell, a practical discussion of how ideas and language from the developer community can be integrated back into interoperable standards.
* [Bedrock](http://infrequently.org/2012/04/bedrock/), by Alex Russell, a 2012 post that explores, in-depth, the philosophy and practice of designing the platform in an extensible ("layered") way.
* [Bedrock](https://infrequently.org/2012/04/bedrock/), by Alex Russell, a 2012 post that explores in depth the philosophy and practice of designing the platform in an extensible ("layered") way.