You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: editor/index.md
+25-26Lines changed: 25 additions & 26 deletions
Original file line number
Diff line number
Diff line change
@@ -13,26 +13,26 @@ This page tries to gather resources that can help editors do their job: document
13
13
14
14
If you are a newly appointed editor in your Working Group, here is some advice that should be useful to get you started.
15
15
16
-
- Get an [idea of the role of an editor](role.html) at W3C
16
+
- Get an [idea of the role of an editor](role.md) at W3C
17
17
- Check the most popular editing tools: [Bikeshed](https://speced.github.io/bikeshed/), [respec](https://github.com/speced/respec/wiki)
18
-
- Read the [W3C Publication Rules](/pubrules/doc/) (often referred as pubrules) and ask advice on the points that are unclear; if your document doesn't comply with these rules, it cannot be published as a W3C technical report.
19
-
-[How to Organize a Recommendation Track Transition](/Guide/transitions) explains the process to get a document published as a technical report.
20
-
- The [Pubrules Checker](/pubrules) is a tool that can help you assess whether or not your document complies with pubrules.
21
-
- Review [WCAG](/TR/WCAG/)
22
-
- All W3C editors are invited to join the [publicly archived mailing list <[email protected]>](http://lists.w3.org/Archives/Public/spec-prod/) to share and discuss the techniques and tools used to produce W3C specifications.
18
+
- Read the [W3C Publication Rules](https://www.w3.org/pubrules/doc/) (often referred as pubrules) and ask advice on the points that are unclear; if your document doesn't comply with these rules, it cannot be published as a W3C technical report.
19
+
-[How to Organize a Recommendation Track Transition](../transitions/) explains the process to get a document published as a technical report.
20
+
- The [Pubrules Checker](https://www.w3.org/pubrules/) is a tool that can help you assess whether or not your document complies with pubrules.
21
+
- Review [WCAG](https://www.w3.org/TR/WCAG/)
22
+
- All W3C editors are invited to join the [publicly archived mailing list <[email protected]>](https://lists.w3.org/Archives/Public/spec-prod/) to share and discuss the techniques and tools used to produce W3C specifications.
23
23
24
24
## Guidelines on W3C specifications editing {#quality}
25
25
26
26
W3C has developed a set of resources giving advices and guidelines on editing W3C specifications in varous domains:
27
27
28
28
- The [W3C Manual of Style](../manual-of-style/) is a collection of rules you're invited to follow to make your document clearer and adapted to the common style at W3C.
29
-
- Begun in 1992 and only a little out of date, the [Style Guide for online hypertext](../../Provider/Style/) by Tim Berners-Lee is a good start on writing for the Web; see also Jakob Nielsen's [How Users Read on the Web](http://www.useit.com/alertbox/9710a.html)
30
-
- The [QA Framework: Specification Guidelines](../../TR/qaframe-spec/) from the W3C Quality Assurance Activity are a work in progress that became a Candidate Recommendation in November 2003.
31
-
- The Team has guidelines for a [style for group-internal drafts](editors-draft.html) to avoid confusion with documents published on the [TR page](/TR). Please also review the related [Working Group Heartbeat Requirement](/policies/process/#revising-wd) of the W3C Process.
29
+
- Begun in 1992 and only a little out of date, the [Style Guide for online hypertext](https://www.w3.org/Provider/Style/) by Tim Berners-Lee is a good start on writing for the Web; see also Jakob Nielsen's [How Users Read on the Web](https://www.nngroup.com/articles/how-users-read-on-the-web/)
30
+
- The [QA Framework: Specification Guidelines](https://www.w3.org/TR/qaframe-spec/) from the W3C Quality Assurance Activity are a work in progress that became a Candidate Recommendation in November 2003.
31
+
- The Team has guidelines for a [style for group-internal drafts](editors-draft.md) to avoid confusion with documents published on the [TR page](https://www.w3.org/TR/). Please also review the related [Working Group Heartbeat Requirement](https://www.w3.org/policies/process/#revising-wd) of the W3C Process.
32
32
33
-
[Bert Bos's essay on W3C's design principles](http://www.w3.org/People/Bos/DesignGuide/introduction) and [Tim Berners-Lee's essentials of a specification](http://www.w3.org/1999/09/specification) may also be a useful reading.
33
+
[Bert Bos's essay on W3C's design principles](https://www.w3.org/People/Bos/DesignGuide/introduction) and [Tim Berners-Lee's essentials of a specification](https://www.w3.org/1999/09/specification) may also be a useful reading.
34
34
35
-
During the internal development of a specification, make sure to distinguish official drafts from internal ones using the [style for Group-internal Drafts](editors-draft.html).
35
+
During the internal development of a specification, make sure to distinguish official drafts from internal ones using the [style for Group-internal Drafts](editors-draft.md).
36
36
37
37
## Grammars {#grammars}
38
38
@@ -41,31 +41,30 @@ W3C editors have developed several types of HTML and XML based grammars to make
41
41
## Authoring tools {#authoring}
42
42
43
43
- Check the most popular editing tools: [Bikeshed](https://speced.github.io/bikeshed/), [respec](https://github.com/speced/respec/wiki)
44
-
-[BlueGriffon](http://www.bluegriffon.org/) is a WYSIWYG HTML editor.
45
-
- Some [tips and tricks for API architecture design](http://scriptlib-cg.github.com/api-design-cookbook/)
46
-
- Some [WhatWG conventions](http://wiki.whatwg.org/wiki/Howto_spec).
44
+
- Some tips and tricks for API architecture design: [Web API Design Cookbook](https://www.w3.org/TR/api-design/)
45
+
- Some [WhatWG conventions](https://wiki.whatwg.org/wiki/Specs/howto).
47
46
48
47
## Tools {#tools}
49
48
50
49
Here are tools that can prove to be useful when developing your specification.
51
50
52
-
- The [Pubrules Checker](http://www.w3.org/pubrules) provides a convenient interface to check the conformance of a document to pubrules (see [pubrules issues and tracking](http://github.com/w3c/specberus/issues))
53
-
- The [Technical Reports shopping list](http://www.w3.org/2000/06/webdata/xslt?xslfile=http%3A%2F%2Fwww.w3.org%2F2005%2F06%2Ftr-shopping.xsl&xmlfile=http%3A%2F%2Fwww.w3.org%2F2002%2F01%2Ftr-automation%2Ftr.rdf) and the [Bibliography Extractor](http://www.w3.org/2002/01/tr-automation/tr-biblio-ui) help building bibliographies based on other W3C Technical Reports; there is a [similar mechansim](http://lists.w3.org/Archives/Public/spec-prod/2003OctDec/0002.html) for XMLSpec
54
-
- The [TR references checker](/2004/07/references-checker-ui) may help maintain your references list up to date. See also the [IETF references checker](/2007/05/ietf-references-checker).
55
-
- The [W3C Glossary](/2003/glossary/) is a repository of all the terms defined in W3C specifications (and more); a good source to find which terms have already been defined and where
56
-
- The [on-line Spell Checker](http://www.w3.org/2002/01/spellchecker) helps spot misspellings and typos; the [W3C on-line Stylistic Checker](/2002/08/diction) helps find the most usual errors identified by the [W3C Manual of Style](/2001/06/manual/)
57
-
-[different tools](http://esw.w3.org/topic/HtmlDiff) are available to produce a `diff` between 2 HTML versions of a document; W3C offers an [on-line HTMLDiff service](http://www.w3.org/2007/10/htmldiff)
58
-
- The [MarkUp Validator](http://validator.w3.org/) can help you assess whether your documents are valid HTML, MathML or SVG.
59
-
- The [CSS Validator](http://jigsaw.w3.org/css-validator/) tells you if your use of CSS is correct.
60
-
- The [Link Checker](http://validator.w3.org/checklink) catches all the broken links that may have popped up in your document.
61
-
- The [Namespace checker](http://www.w3.org/2003/09/nschecker) finds potential namespaces URIs in the documents, and makes a few checks on them
62
-
-[HTML Tidy](http://tidy.sourceforge.net/), originally by Dave Raggett and now maintained at SourceForge.net, is a lint that cleans up but does not validate HTML and XHTML. With indent off, Tidy can sometimes shave 10% or more off file size.
51
+
- The [Pubrules Checker](https://www.w3.org/pubrules/) provides a convenient interface to check the conformance of a document to pubrules (see [pubrules issues and tracking](https://github.com/w3c/specberus/issues))
52
+
- The [Technical Reports shopping list](https://www.w3.org/2000/06/webdata/xslt?xslfile=http%3A%2F%2Fwww.w3.org%2F2005%2F06%2Ftr-shopping.xsl&xmlfile=http%3A%2F%2Fwww.w3.org%2F2002%2F01%2Ftr-automation%2Ftr.rdf) and the [Bibliography Extractor](https://www.w3.org/2002/01/tr-automation/tr-biblio-ui) help building bibliographies based on other W3C Technical Reports; there is a [similar mechansim](https://lists.w3.org/Archives/Public/spec-prod/2003OctDec/0002.html) for XMLSpec
53
+
- The [TR references checker](https://www.w3.org/2004/07/references-checker-ui) may help maintain your references list up to date. See also the [IETF references checker](https://www.w3.org/2007/05/ietf-references-checker).
54
+
- The [W3C Glossary](https://www.w3.org/2003/glossary/) is a repository of all the terms defined in W3C specifications (and more); a good source to find which terms have already been defined and where
55
+
- The [on-line Spell Checker](https://www.w3.org/2002/01/spellchecker) helps spot misspellings and typos; the [W3C on-line Stylistic Checker](https://www.w3.org/2002/08/diction) helps find the most usual errors identified by the [W3C Manual of Style](../manual-of-style/)
56
+
-[different tools](https://esw.w3.org/topic/HtmlDiff) are available to produce a `diff` between 2 HTML versions of a document; W3C offers an [on-line HTMLDiff service](https://www.w3.org/2007/10/htmldiff)
57
+
- The [MarkUp Validator](https://validator.w3.org/) can help you assess whether your documents are valid HTML, MathML or SVG.
58
+
- The [CSS Validator](https://jigsaw.w3.org/css-validator/) tells you if your use of CSS is correct.
59
+
- The [Link Checker](https://validator.w3.org/checklink) catches all the broken links that may have popped up in your document.
60
+
- The [Namespace checker](https://www.w3.org/2003/09/nschecker) finds potential namespaces URIs in the documents, and makes a few checks on them
61
+
-[HTML Tidy](https://www.html-tidy.org/), originally by Dave Raggett and now maintained at SourceForge.net, is a lint that cleans up but does not validate HTML and XHTML. With indent off, Tidy can sometimes shave 10% or more off file size.
63
62
64
63
Most of these tools can be quickly accessed using the so called **[`,tools`](./,tools)** interface: appending **`,keyword`** to a www.w3.org URI triggers a certain tool on this URI; for instance, appending **[`,validate`](,validate)** to this page's URI will send it to the HTML validator.
65
64
66
65
## Central JavaScript repository {#javascript}
67
66
68
-
Specifications should, of course, be device-independent. But, with care, you can still include certain kinds of scripts. If the script you want is in W3C's [repository of common JavaScript libraries,](../../scripts/) you're recommended to link to that repository, rather than make a copy of the script. (Note that, together with the common style sheets, these scripts are the *only* resources that may be outside the specification's own directory.)
67
+
Specifications should, of course, be device-independent. But, with care, you can still include certain kinds of scripts. If the script you want is in W3C's [repository of common JavaScript libraries,](https://www.w3.org/scripts/) you're recommended to link to that repository, rather than make a copy of the script. (Note that, together with the common style sheets, these scripts are the *only* resources that may be outside the specification's own directory.)
69
68
70
69
There is no documentation for now (except for [MathJax](https://www.w3.org/scripts/MathJax/)).
0 commit comments