Skip to content

Commit bb2cb26

Browse files
balthisarbalthisar
committed
Update README documents with information for the upcoming 5.4.0 release.
1 parent d071341 commit bb2cb26

15 files changed

+318
-296
lines changed

‎README.md

+93-6
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,96 @@
1-
# HTML Tidy with HTML5 support
1+
# HTACG HTML Tidy
22

3-
All READMEs and related materials can be found in [README/][1].
3+
All other READMEs and related materials can be found in [README/][100]. Although all of our materials should be linked in this README, be sure to check this directory for documents we’ve not yet added to this document.
44

5-
For build instructions please see [README/README.md][2].
5+
## Building HTML Tidy
66

7-
[1]: https://github.com/htacg/tidy-html5/tree/master/README
8-
[2]: https://github.com/htacg/tidy-html5/blob/master/README/README.md
9-
7+
- For build instructions please see [README/BUILD.md][115].
8+
9+
## Branches and Versions
10+
11+
Learn about which branches are available, which branch you should use, and how HTML Tidy’s versioning scheme works.
12+
13+
- Learn about version numbering in [README/VERSION.md][160].
14+
- Learn about our repository branches in [README/BRANCHES.md][110].
15+
16+
## Contributing and Development Guides
17+
18+
We gladly accept PRs! Read about some of our contribution guidelines, and check out some of the additional explanatory documents that will aid your understanding of how to accomplish certain things in HTML Tidy.
19+
20+
### General Contribution Guidelines
21+
22+
These are some general guidelines that will help you help us when it comes to making your own contributions to HTML Tidy.
23+
24+
- Learn about our contributing guidelines in [README/CONTRIBUTING.md][125].
25+
- Understand HTML Tidy’s source code style in [README/CODESTYLE.md][120].
26+
27+
### Adding Features Guides
28+
29+
When you’re ready to add a great new feature, these write-ups may be useful.
30+
31+
- Learn how to add new element attributes to HTML Tidy by reading [README/ATTRIBUTES.md][105].
32+
- Discover how to add new tags to Tidy in [README/TAGS.md][130].
33+
- If you want to add new messages to Tidy, read [README/MESSAGE.md][150].
34+
- Configuration options can be added according to [README/OPTIONS.md][155].
35+
36+
### Language Localization Guides
37+
38+
Tidy supports localization, and welcomes translations into various languages. Please read up on how to localize HTML Tidy.
39+
40+
- The general README for localizing can be found in [/README/LOCALIZE.md][140].
41+
- And [/localize/README.md][145] contains specific instructions for localizing.
42+
43+
44+
## Other Important Links
45+
46+
- site: [http://www.html-tidy.org/][4]
47+
- source: [https://github.com/htacg/tidy-html5][5]
48+
- binaries: [http://binaries.html-tidy.org][6]
49+
- bugs: [https://github.com/htacg/tidy-html5/issues][7]
50+
- list: [https://lists.w3.org/Archives/Public/html-tidy/][8]
51+
- api and quickref: [http://api.html-tidy.org/][9]
52+
53+
[4]: http://www.html-tidy.org/
54+
[5]: https://github.com/htacg/tidy-html5
55+
[6]: http://binaries.html-tidy.org
56+
[7]: https://github.com/htacg/tidy-html5/issues
57+
[8]: https://lists.w3.org/Archives/Public/html-tidy/
58+
[9]: http://api.html-tidy.org/
59+
60+
61+
## History
62+
63+
This repository should be considered canonical for HTML Tidy as of 2015-January-15.
64+
65+
- This repository originally transferred from [w3c.github.com/tidy-html5][20], now redirected to the current site.
66+
67+
- First moved to Github from [tidy.sourceforge.net][21]. Note, this site is kept only for historic reasons, and is not now well maintained.
68+
69+
**Tidy is the granddaddy of HTML tools, with support for modern standards.** Have fun...
70+
71+
[20]: http://w3c.github.com/tidy-html5/
72+
[21]: http://tidy.sourceforge.net
73+
74+
75+
## License
76+
77+
HTML Tidy and LibTidy are free and open source software with a permissive license.
78+
79+
- You can read the complete license in [README/LICENSE.md][135].
80+
81+
82+
83+
[100]: README/
84+
[105]: README/ATTRIBUTES.md
85+
[110]: README/BRANCHES.md
86+
[115]: README/BUILD.md
87+
[120]: README/CODESTYLE.md
88+
[125]: README/CONTRIBUTING.md
89+
[130]: README/TAGS.md
90+
[135]: README/LICENSE.md
91+
[140]: /README/LOCALIZE.md
92+
[145]: /localize/README.md
93+
[150]: README/MESSAGE.md
94+
[155]: README/OPTIONS.md
95+
[160]: README/VERSION.md
96+

‎README/ATTRIBUTES.md

+12-7
Original file line numberDiff line numberDiff line change
@@ -1,21 +1,26 @@
11
# Tidy Element Attributes
22

3-
This is about adding a **new** `attribute=value` for one or more html `element`, here called `tags`.
3+
This is about adding a **new** HTML attribute to one or more HTML tags, i.e., a new attribute such as `attribute=value`.
44

5-
Tidy supports a large number of `attributes`, first defined in `tidyenum.h`, to give it a value, then defined in `attrs.c` to give it a unique **string** name, and a `function` to verify the atrribute **value**. Then in `attrdict.c` the attribute is defined, giving what version(s) of html support this attribute. Finally, what tags support this attrinute, is done in `tags.c`, where each attribute is allowed on that tag, or not, in the `tag_defs[]` table.
5+
Tidy’s large number of attributes are supported via number of files:
6+
7+
- `tidyenum.h` is where you first define a new attribute in order to give it an internal value.
8+
- `attrs.c` is where you give a unique **string** name to the attribute, as well as a **function** to verify the **value**.
9+
- `attrdict.c` further refines the definition of your attribute, specifying which version(s) of HTML support this attribute.
10+
- `tags.c`, finally, determines which tags support the attribute, in the `tag_defs[]` table.
611

712
So, to add a new `attribute=value`, on one or more existing tags, consists of the following simple steps -
813

9-
1. tidyenum.h - Give the attribute an internal name, like `TidyAttr_XXXX`, and thus a value. While there were some initial steps to keep this `TidyAttrId` enumeration alphabetic, now just add the new `TidyAttr_XXXX` just before the last entry 'N_TIDY_ATTRIBS'.
14+
1. `tidyenum.h` - Give the attribute an internal name, like `TidyAttr_XXXX`, and thus a value. While there were some initial steps to keep this `TidyAttrId` enumeration alphabetic, now just add the new `TidyAttr_XXXX` just before the last entry `N_TIDY_ATTRIBS`.
1015

11-
2. attrs.c - Assign the string value of the attribute. Of course this must be unique. And then assign a `function` to verify the attribute value. There are already a considerable number of defined functions to verify specific attribute values, but maybe this new attribute requires a new function, so that should be written, and defined.
16+
2. `attrs.c` - Assign the string value of the attribute. Of course this must be unique. And then assign a `function` to verify the attribute value. There are already a considerable number of defined functions to verify specific attribute values, but maybe this new attribute requires a new function, so that should be written, and defined.
1217

13-
3. attrdict.c - If this attribute only relates to specific `tags`, then it should be added to their list. There are some `general` attributes that are allowed on every, or most tags, so this new attribute and value should be added accordingly.
18+
3. `attrdict.c` - If this attribute only relates to specific tags, then it should be added to their list. There are some general attributes that are allowed on every, or most tags, so this new attribute and value should be added accordingly.
1419

15-
4. tags.c - Now the new attribute will be verified for each tag it is associate with in the `tag_defs[]` table. Like for example the `<button ...>`, `{ TidyTag_BUTTON, ...` has `&TY_(W3CAttrsFor_BUTTON)[0]` assigned.
20+
4. `tags.c` - Now the new attribute will be verified for each tag it is associate with in the `tag_defs[]` table. Like for example the `<button ...>`, `{ TidyTag_BUTTON, ...` has `&TY_(W3CAttrsFor_BUTTON)[0]` assigned.
1621

1722
So, normally, just changing 3 files, `tidyenum.h`, `attrs.c`, and `attrdict.c`, will already adjust `tags.c` to accept a new `attribute=value` for any tag, or all tags. Simple...
1823

19-
Now, one could argue that this is not the **best** way to verify every attribute and value, for every tag, but that is a mute point - that is how tidy does it!
24+
Now, one could argue that this is not the **best** way to verify every attribute and value, for every tag, but that is a moot point - that is how Tidy does it!
2025

2126
; eof 20170205

‎README/BRANCHES.md

+28
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
# HTML Tidy Branches
2+
3+
## About Branches
4+
5+
Starting with **HTML Tidy** 5.4.0, HTACG will adopt a new branch management strategy utilizing **master** as the _release branch_, and **next** as the active development branch.
6+
7+
As described thoroughly in our [VERSION.md](VERSION.md) document, this means that **master** will always consist of an even-numbered minor version, and activity will remain relatively quiet unless we backport a critical bug fix from **next**.
8+
9+
The **next** branch, then will host the majority of our development activity, and any contributions and PR’s should be again this branch. This means that **next** will always consist of an odd minor version number.
10+
11+
12+
## About Versioning
13+
14+
You can read the specifics about version numbers in our [VERSION.md](VERSION.md) document.
15+
16+
17+
## FAQs
18+
19+
### Which version or branch should I choose?
20+
21+
As described above, the branch is very strongly correlated with the version. If you require a stable API and relatively stable output and don’t require the features and enhancements of an odd-numbered **next** version, then you should stick to **master**, even-numbered versions.
22+
23+
On the other hand if you are primarily a console application user, then the API isn’t likely as important to you, and you probably want the latest and greatest. If this describes you, you probably want to at least try out **next**.
24+
25+
If you are developing for Tidy, then you _definitely_ want to stick to **next**, even for bug fixes meant for **master**. If it’s a critical enough bug fix, then one of our friendly team will back-port the fix to **master**.
26+
27+
28+

‎README/BUILD.md

+66
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
# HTACG HTML Tidy
2+
3+
## Prerequisites
4+
5+
1. git - [http://git-scm.com/book/en/v2/Getting-Started-Installing-Git][1]
6+
7+
2. cmake - [http://www.cmake.org/download/][2]
8+
9+
3. appropriate build tools for the platform
10+
11+
4. the [xsltproc][3] tool is required to build and install the `tidy.1` man page on Unix-like platforms.
12+
13+
CMake comes in two forms - command line and GUI. Some installations only install one or the other, but sometimes both. The build commands below are only for command line use.
14+
15+
Also the actual build tools vary for each platform. But that is one of the great features of CMake, it can generate variuous 'native' build files. Running `cmake --help` should list the generators available on that platform. For sure one of the common ones is "Unix Makefiles", which needs autotools make installed, but many other generators are supported.
16+
17+
In Windows CMake offers various versions for MSVC. Again below only the command line use of MSVC is shown, but the tidy solution (*.sln) file can be loaded into the MSVC IDE, and the building done in there.
18+
19+
20+
## Build the tidy library and command line tool
21+
22+
1. `cd build/cmake`
23+
24+
2. `cmake ../.. -DCMAKE_BUILD_TYPE=Release [-DCMAKE_INSTALL_PREFIX=/path/for/install]`
25+
26+
3. Windows: `cmake --build . --config Release`
27+
Unix/OS X: `make`
28+
29+
4. Install, if desired:
30+
Windows: `cmake --build . --config Release --target INSTALL`
31+
Unix/OS X: `[sudo] make install`
32+
33+
By default cmake sets the install path to `/usr/local/bin` in Unix. If you wanted the binary in say `/usr/bin` instead, then in 2. above use `-DCMAKE_INSTALL_PREFIX=/usr`.
34+
35+
Also, in Unix if you want to build the release library without any debug `assert` in the code then add `-DCMAKE_BUILD_TYPE=Release` in step 2. This adds a `-DNDEBUG` macro to the compile switches. This is normally added in windows build for the `Release` config.
36+
37+
In Windows the default install is to `C:\Program Files\tidy`, or `C:/Program Files (x86)/tidy`, which is not very useful. After the build the `tidy.exe` is in the `Release` directory, and can be copied to any directory in your `PATH` environment variable for global use.
38+
39+
If you do **not** need the tidy library built as a 'shared' (DLL) library, then in 2. add the command `-DBUILD_SHARED_LIB:BOOL=OFF`. This option is **ON** by default. The static library is always built and linked with the command line tool for convenience in Windows, and so the binary can be run as part of the man page build without the shared library being installed in unix.
40+
41+
See the `CMakeLists.txt` file for other CMake **options** offered.
42+
43+
## Build PHP with the tidy-html5 library
44+
45+
Due to API changes in the PHP source, `buffio.h` needs to be renamed to `tidybuffio.h` in the file `ext/tidy/tidy.c` in PHP's source.
46+
47+
That is - prior to configuring PHP run this in the PHP source directory:
48+
```
49+
sed -i 's/buffio.h/tidybuffio.h/' ext/tidy/*.c
50+
```
51+
52+
And then continue with (just an example here, use your own PHP config options):
53+
54+
```
55+
./configure --with-tidy=/usr/local
56+
make
57+
make test
58+
make install
59+
```
60+
61+
[1]: http://git-scm.com/book/en/v2/Getting-Started-Installing-Git
62+
[2]: http://www.cmake.org/download/
63+
[3]: http://xmlsoft.org/XSLT/xsltproc2.html
64+
65+
66+
; eof

‎README/CODESTYLE.md

+6-6
Original file line numberDiff line numberDiff line change
@@ -1,18 +1,18 @@
11
# HTML Tidy Code Style
22

3-
The source code of **libTidy**, and console app **tidy**, follow the preferences of the original maintainers. Perhaps some of these decisions were arbitrary and based on their sense of aesthetics at the time, but it is good to have all the code looking the same even if it is not exactly what everyone would prefer.
3+
The source code of **libTidy** and console app **tidy** mostly follow the preferences of the original maintainers. Perhaps some of these decisions were arbitrary and based on their sense of aesthetics at the time, but it is good to have all the code looking the same even if it is not exactly what everyone would prefer.
44

5-
Developers adding code to **Tidy!** are urged to try to follow the existing code style. Code that does not follow these conventions may be accepted, but may be modified as time goes by to best fit the `Tidy Style`.
5+
Developers adding code to HTML Tidy are urged to try to follow the existing code style. Code that does not follow these conventions may be accepted, but may be modified as time goes by to best fit the “Tidy Style.”
66

7-
There has been a suggestion of using available utilities to make the style consistent, like [Uncrusty](https://github/bengardener/uncrusty) - see [issue #245](https://github.com/htacg/tidy-html5/issues/245), and maybe others...
7+
There has been a suggestion of using available utilities to make the style consistent, like [Uncrustify](https://github.com/uncrustify/uncrustify) - see [issue #245](https://github.com/htacg/tidy-html5/issues/245), and maybe others.
88

9-
Others have suggested the [AStyle](http://astyle.sourceforge.net/) formatting program with say '-taOHUKk3 -M8' arguments, to conform, but there are a few bugs in AStyle.
9+
Others have suggested the [AStyle](http://astyle.sourceforge.net/) formatting program with say `-taOHUKk3 -M8` arguments, to conform, but there are a few bugs in AStyle.
1010

11-
But again these, and other tools, may not produce code that everybody agrees with... and are presently not formally used in Tidy!
11+
But again, these and other tools may not produce code that everybody agrees with, and are presently not formally used in Tidy!
1212

1313
#### Known Conventions
1414

15-
From reading of the Tidy source, some things are self evident... in no particular order...
15+
From reading of the Tidy source, some things are self evident, in no particular order...
1616

1717
- Use of 4-space indenting, and no tabs.
1818
- No C++ single line comments using `//`.

0 commit comments

Comments
 (0)