Skip to content

Commit a99c020

Browse files
Update links
1 parent 57621ea commit a99c020

File tree

1 file changed

+25
-26
lines changed

1 file changed

+25
-26
lines changed

editor/index.md

Lines changed: 25 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -13,26 +13,26 @@ This page tries to gather resources that can help editors do their job: document
1313

1414
If you are a newly appointed editor in your Working Group, here is some advice that should be useful to get you started.
1515

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
1717
- 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.
2323

2424
## Guidelines on W3C specifications editing {#quality}
2525

2626
W3C has developed a set of resources giving advices and guidelines on editing W3C specifications in varous domains:
2727

2828
- 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.
3232

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.
3434

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).
3636

3737
## Grammars {#grammars}
3838

@@ -41,31 +41,30 @@ W3C editors have developed several types of HTML and XML based grammars to make
4141
## Authoring tools {#authoring}
4242

4343
- 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).
4746

4847
## Tools {#tools}
4948

5049
Here are tools that can prove to be useful when developing your specification.
5150

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.
6362

6463
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.
6564

6665
## Central JavaScript repository {#javascript}
6766

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.)
6968

7069
There is no documentation for now (except for [MathJax](https://www.w3.org/scripts/MathJax/)).
7170

0 commit comments

Comments
 (0)