Add README for new 'attributes' and 'elements', 'tags'
This commit is contained in:
parent
10fd44d101
commit
6a83918d33
21
README/ATTRIBUTES.md
Normal file
21
README/ATTRIBUTES.md
Normal file
|
@ -0,0 +1,21 @@
|
||||||
|
# Tidy Element Attributes
|
||||||
|
|
||||||
|
This is about adding a **new** `attribute=value` for one or more html `element`, here called `tags`.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
So, to add a new `attribute=value`, on one or more existing tags, consists of the following simple steps -
|
||||||
|
|
||||||
|
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'.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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...
|
||||||
|
|
||||||
|
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!
|
||||||
|
|
||||||
|
; eof 20170205
|
19
README/ELEMENTS.md
Normal file
19
README/ELEMENTS.md
Normal file
|
@ -0,0 +1,19 @@
|
||||||
|
# Tidy HTML Elements
|
||||||
|
|
||||||
|
This is about adding a new html **element**, or **tag**.
|
||||||
|
|
||||||
|
Tidy tries to support all **elements** supported by the W3C. To add a new supported **element**, the defintion begins in `tidyenum.h`, to give it a value. Then it is added to the `tag_defs[]` table in `tags.c`, where it is given a unique string, supported html versions, attributes support, and a bit `type`.
|
||||||
|
|
||||||
|
Note, there are a group of configuration options to add **elements** not yet approved by the W3C. These are [new-blocklevel-tags](http://api.html-tidy.org/tidy/quickref_5.2.0.html#new-blocklevel-tags), [new-empty-tags](http://api.html-tidy.org/tidy/quickref_5.2.0.html#new-empty-tags), [new-inline-tags](http://api.html-tidy.org/tidy/quickref_5.2.0.html#new-inline-tags). and [new-pre-tags](http://api.html-tidy.org/tidy/quickref_5.2.0.html#new-pre-tags). This provides a way to extend the `tag_defs[]` table just for that tidy session.
|
||||||
|
|
||||||
|
So, to add a new html `element`, consists of the following simple steps -
|
||||||
|
|
||||||
|
1. tidyenum.h - Give the element an internal name, like `TidyTag_XXXX`, and thus a value. While there were some initial steps to keep this `TidyTagId` enumeration alphabetic, now just add the new `TidyTag_XXXX` just before the last entry 'N_TIDY_TAGS'.
|
||||||
|
|
||||||
|
2. tags.c - Add a line to the `tag_defs[]` table. This assigns the unique string value of the element. Then the html versions that support the element, a pointer to the attributes supported by that elelment, and a bit field of the elements characteristics, inline, block, etc.
|
||||||
|
|
||||||
|
So, just changing 2 files, `tidyenum.h` and `tags.c`, and libTidy will now support that element, tag, as W3C approved. Simple... And at times, there is some case for adding **element** that are still in the `Working Draft` stage, especially when there has bee wide spread support in the community, even before it reaches `REC` stage.
|
||||||
|
|
||||||
|
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!
|
||||||
|
|
||||||
|
; eof 20170205
|
Loading…
Reference in a new issue