Skip to content

Commit

Permalink
Make some light fixups to /faq
Browse files Browse the repository at this point in the history 
* Use “quotes” and ’s (like /working-mode)
* Remove Code of Conduct question, it's linked from the top of the page
* Remove broken showModalDialog() link.
* Remove bold and italics where it seems out of place.
  • Loading branch information
@foolip
foolip committed Aug 11, 2017
1 parent 9fd8c73 commit 9876c38
Showing 1 changed file with 33 additions and 38 deletions.
71 changes: 33 additions & 38 deletions src/faq
View file
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,7 @@

<h4 id="what-is-the-whatwg-working-on">What is the WHATWG working on?<a class="self-link" href="#what-is-the-whatwg-working-on"></a></h4>

<p>The WHATWG's main focus is Web standards, specifically:
<p>The WHATWG’s main focus is Web standards, specifically:

<ul>
<li><p><a href="https://html.spec.whatwg.org/multipage/">HTML</a>, which also includes Web
Expand All @@ -66,22 +66,18 @@
<h4 id="get-involved">How can I get involved?<a class="self-link" href="#get-involved"></a></h4>

<p>There are lots of ways you can get involved, take a look and see
<i><a href="https://wiki.whatwg.org/wiki/What_you_can_do">What you can do</a></i>!
<a href="https://wiki.whatwg.org/wiki/What_you_can_do">What you can do</a>!

<p><a href="https://www.youtube.com/watch?v=hneN6aW-d9w">This video from Domenic Denicola</a> is a
good introduction to working with standards bodies.

<h4 id="is-participation-free">Is participation free?<a class="self-link" href="#is-participation-free"></a></h4>

<p>Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You
<p>Yes, everyone can contribute. There are no memberships fees involved, it’s an open process. You
may easily <a href="https://github.com/whatwg">participate on GitHub</a> or subscribe to the
<a href="/mailing-list">WHATWG mailing lists</a>. There are no meetings, since meetings prevent
people with limited time or money from participating.

<h4 id="code-of-conduct">Is there a Code of Conduct?<a class="self-link" href="#code-of-conduct"></a></h4>

<p>Yes, see <a href="/code-of-conduct">Code of Conduct</a>. Please read it and respect it.

<h3 id="process">The WHATWG Process<a class="self-link" href="#process"></a></h3>

<h4 id="how-does-the-whatwg-work">How does the WHATWG work?<a class="self-link" href="#how-does-the-whatwg-work"></a></h4>
Expand All @@ -92,7 +88,7 @@
<p>Each standard has one or more editors, who are responsible for dealing with feedback for that
document. Those editors read all the feedback, and, taking it into account along with research,
studies, and feedback from many other sources (blogs, forums, IRC, etc.) make language design
decisions intended to address everyone's needs as well as possible while keeping the languages and
decisions intended to address everyone’s needs as well as possible while keeping the languages and
APIs consistent.

<p>This continues, with people sending more feedback, until nobody is able to convince the
Expand All @@ -107,9 +103,9 @@
that we can avoid the spec containing material which implementors are later found to disagree
with.

<p>This is not a consensus-based approach — there's no guarantee that everyone will be happy!
There is also no voting. There is a small oversight committee (known historically as the "WHATWG
members", from the name that the original <a href="/charter">charter</a> used, though that
<p>This is not a consensus-based approach — there’s no guarantee that everyone will be happy!
There is also no voting. There is a small oversight committee (known historically as the “WHATWG
members”, from the name that the original <a href="/charter">charter</a> used, though that
terminology is misleading) who have the authority to override or replace editors if they start
making bad decisions, but so far that has never happened in over ten years. This committee has a
private mailing list, but it receives very few messages, usually going years with no emails at
Expand All @@ -122,15 +118,15 @@
evaluate the various positions that have been put forward in a discussion, and figure out which
one is strongest (or find another position that strikes a better balance between all of them).

<p>The purpose of debate at the WHATWG therefore isn't to convince everyone; it is to put forward
<p>The purpose of debate at the WHATWG therefore isn’t to convince everyone; it is to put forward
the arguments that exist, so that the relevant editor can make a well-informed decision. As a
corollary: If some points are made, rebutted, and not further defended, then maybe the person
making the arguments is hoping that the relevant editor will consider the rebuttals weak, or
thinks that the argument they have presented is strong despite the rebuttals. If you find someone
is not making good arguments, or is ignoring your arguments, your best bet is to stop responding.
Repeating previously-stated arguments doesn't help, since the editors will see all the arguments
Repeating previously-stated arguments doesn’t help, since the editors will see all the arguments
when they look at the thread. Similarly, as soon as threads start being meta-threads about
people's argumentation behaviour, we stop making any kind of useful progress, since that isn't
people’s argumentation behaviour, we stop making any kind of useful progress, since that isn’t
input that can help the decision-making process later.

<h4 id="how-to-interact">How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG?<a class="self-link" href="#how-to-interact"></a></h4>
Expand All @@ -139,11 +135,11 @@
the top of that standard. All feedback is supposed to be addressed in due course. You are also
welcome to take a stab at addressing the problem yourself through a GitHub pull request.

<p><b>If you want feedback to be dealt with faster than "eventually", e.g., because you are about
to work on that feature and need the spec to be updated to take into account all previous
feedback, let the editors know</b> by either emailing them, or contacting them on
<p>If you want feedback to be dealt with faster than “eventually”, e.g., because you are about to
work on that feature and need the spec to be updated to take into account all previous feedback,
let the editors know by either emailing them, or contacting them on
<a href="https://wiki.whatwg.org/wiki/IRC">IRC</a>. Requests for priority feedback handling are
handled confidentially if desired so other implementers won't know that you are working on that
handled confidentially if desired so other implementers won’t know that you are working on that
feature.

<h4 id="removing-bad-ideas">Is there a process for removing bad ideas from a specification?<a class="self-link" href="#removing-bad-ideas"></a></h4>
Expand All @@ -157,14 +153,13 @@
features, then they eventually are removed altogether.

<li><p>Anyone can ask for a feature to be removed; such feedback is considered like all other
feedback and is based on the merits of the arguments put forward. If it's been a few years and
there's no implementation, and no vendor is showing any interest in eventually implementing that
section; or if it's a section that browsers previously implemented but where the momentum shows
feedback and is based on the merits of the arguments put forward. If it’s been a few years and
there’s no implementation, and no vendor is showing any interest in eventually implementing that
section; or if it’s a section that browsers previously implemented but where the momentum shows
that browsers are actually removing support, then it is highly likely that the request to remove
the section will be honoured. (Sometimes, a warning is first placed in the spec, as
with <a href="https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents">showModalDialog()</a>.)
the section will be honoured. (Sometimes, a warning is first placed in the spec.)

<li><p>If browsers don't widely implement a feature, or if authors don't use a feature, or if the
<li><p>If browsers don’t widely implement a feature, or if authors don’t use a feature, or if the
uses of the feature are inconsequential or fundamentally wrong or damaging, then, after due
consideration, features will be removed.
</ul>
Expand All @@ -178,7 +173,7 @@
<ol>
<li><p>Forget about the particular solution you have in mind! Solution time is later!

<li><p>Write down a description of the underlying problem you're trying to solve. What are the
<li><p>Write down a description of the underlying problem you’re trying to solve. What are the
use cases? A use case is an actual user wanting to do something. Then list requirements for each
use case. For a good example of how to do this, see
<a href="http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html">this email</a>.
Expand All @@ -196,21 +191,21 @@

<li><p>Research existing solutions. Come up with new solutions. Try to keep the solutions as
simple as possible, maybe only addressing the important use cases and leaving the nice to have
use cases for later (when there's implementation experience). Send this list of solutions, old
and new, as a comment on the feature's issue. Ask browser vendors for feedback. Maybe some
particular solutions don't fit with the browser's architecture, optimizations, etc., and just are
not going to be implemented no matter how much you like them. Strike those solutions and don't
use cases for later (when there’s implementation experience). Send this list of solutions, old
and new, as a comment on the feature’s issue. Ask browser vendors for feedback. Maybe some
particular solutions don’t fit with the browser’s architecture, optimizations, etc., and just are
not going to be implemented no matter how much you like them. Strike those solutions and don’t
grieve about the loss!

<li><p>Evaluate how well each of the remaining solutions address each use case and how well they
meet the requirements. This step should show which solution is the technically best fit (might
turn out to be someone else's solution).
turn out to be someone else’s solution).

<li><p>Ask the spec's editor to put that solution in the spec, or create a pull request on GitHub
yourself. Possibly your text won't be taken verbatim but will be written in a style that is more
<li><p>Ask the spec’s editor to put that solution in the spec, or create a pull request on GitHub
yourself. Possibly your text won’t be taken verbatim but will be written in a style that is more
suitable for implementors or better hooks in to the rest of the spec, etc.

<li><p>Ask browser vendors to implement the newly specified solution, even if it's just an
<li><p>Ask browser vendors to implement the newly specified solution, even if it’s just an
experimental implementation. This implementation experience usually means that new problems are
found with the solution that need to be addressed, or that a different solution is actually
better.
Expand All @@ -224,7 +219,7 @@
</ol>

<p>If the idea survives the above design process, the spec will be eventually updated to reflect
the new design. Implementations will then be updated to reflect the new design (if they aren't,
the new design. Implementations will then be updated to reflect the new design (if they aren’t,
that indicates the new design is not good, and it will be reworked or removed). The spec will be
updated to fix the many problems discovered by authors and implementors, over a period of several
years, as more authors and implementors are exposed to the design. Eventually, a number of
Expand All @@ -244,7 +239,7 @@
new proposed text are intentional or not (and should be fixed or not), or whether stylistic
differences are intentional or not, etc.

<h4 id="living-standard">What does "Living Standard" mean?<a class="self-link" href="#living-standard"></a></h4>
<h4 id="living-standard">What does “Living Standard” mean?<a class="self-link" href="#living-standard"></a></h4>

<p>The WHATWG specifications are described as Living Standards. This means that they are standards
that are continuously updated as they receive feedback, either from Web designers, browser
Expand All @@ -269,7 +264,7 @@
specification mature, and implementations ship, the spec cannot be changed in
backwards-incompatible ways (because the implementors would never agree to break compatibility
unless for security reasons). The specifications are never complete, since the Web is continuously
evolving. The last time HTML was described as "complete" was after HTML4, when development stopped
evolving. The last time HTML was described as “complete” was after HTML4, when development stopped
for several years, leading to stagnation. (If the Web is replaced by something better and dies,
the HTML spec will die with it.)

Expand All @@ -280,7 +275,7 @@
<p>These snapshots are published as historical references. The WHATWG intends to keep these frozen
snapshots available at their published URL permanently.

<h4 id="patent-policy">What's the patent story for WHATWG standards?<a class="self-link" href="#patent-policy"></a></h4>
<h4 id="patent-policy">What’s the patent story for WHATWG standards?<a class="self-link" href="#patent-policy"></a></h4>

<p>The WHATWG operates as a W3C Community Group and thus uses the W3C Community Group patent
policies. So far we have published one FSA with
Expand All @@ -302,7 +297,7 @@
<a href="https://streams.spec.whatwg.org/">https://streams.spec.whatwg.org/</a>.

<p>Such translations are not normative (i.e., implementations should be sure to consult the
original). Due to the nature of living standards, which can change often, it's possible for
original). Due to the nature of living standards, which can change often, it’s possible for
translations to become out of date compared to the original standard. If the translation shows
signs of no longer being maintained, or has other quality problems, community members are
encouraged to provide feedback to the maintainers of the standard, so that any links to the
Expand Down

0 comments on commit 9876c38

Please sign in to comment.