False error on custom tags.

[TZubiri]

Consider the following lines in a document:
<employee > <name><p> Tomás Zubiri </p></name <salary><p> 0$ </p></salary> </employee>

This will trigger the following errors:
Error: is not recognized!
Warning: discarding unexpected

However, if one adds css to the tag like so:
employee { display:none}

Then the block dissappears, showing that the tag was recognized and not discarded.

Tidy supports the addition of custom tags by configuration, but this is not an appropriate fix, since the browser does not require such configuration and liberally accepts all custom tags. #204 #586 #569

My version of tidy is 5.2.0 Apologies if this was already fixed in later versions.

Thank you for reading

[TZubiri]

Here's an interesting position supporting custom tags:
https://stackoverflow.com/questions/37622348/is-it-bad-practice-to-define-a-custom-html-tag

[geoffmcl]

@TZubiri thank you for your issue...

Maybe you seem to be confusing XML, with HTML, or something...

Fix the closing </name, to </name>, in your sample, then use an -xml config... Does this fix your problem?

Tidy supports the addition of custom tags by configuration, but this is not an appropriate fix, since the browser...

Tidy is not a browser... Tidy supports tags approved by the W3C REC... as best it can... always WIP...

And Tidy allows you to configure others... even some that may, or may not, be in the W3C REC pipeline, but not yet in tidy... see pending #848... this process will hopefully continue...

Why is it not an appropriate fix, at this time?

Did you fully read #204 #586 #569, #225 #119... and maybe others... these are about custom tags, mainly, and <employee > is not likely to be one of those... read up on Custom Elements, follow Web Components... et al...

And also try to update your tidy version... 5.2 is circa Apr, 2016... but I tested with 5.7.28...

At this time, do not understand what tidy fix you want! Please clarify... thanks...

[TZubiri]

Hello Geoff, thank you for your response. After some research, it seems that the behaviour of undeclared custom/unknown tags/elements is specified in both the w3 recommendation and living standards. The behaviour is called HTMLUnknownElement.

Sources:
https://developer.mozilla.org/en-US/docs/Web/API/HTMLUnknownElement
https://html.spec.whatwg.org/multipage/dom.html#htmlunknownelement
https://www.w3.org/TR/html52/dom.html#htmlunknownelement

The following browsers support it:
Chrome, edge, firefox, IE, safari,opera, android webview,chrome for android,firefox for android, samsung internet, opera for android, safari on ios

I downloaded version 5.7.28 and I found the following changes:

If the unknown tag follows the custom element naming conventions a recommendation to use an option is recommended:

Error: is not recognized! Did you mean to enable the custom-tags option?

This is great! According to the spec, these unknown elements are internally defined as HTMLElement objects. While non conforming unknown elements are HTMLUnknownElements. HTMLUnkownElement is just an object that applies the HTMLElement interface, so it's the same. The only difference is that HTMLElement has the guarantee of non-collision with a native element. The portion of the element before the hyphen is supposed to be a namespace, not a space between two words, in my case it would be or , etc..

There's still the problem defined in the first post but it's a great sign that this feature was looked upon.

1- The user still has to define the Custom element for the validator (in order to use the custom-tag) while they don't have to define it in the HTML. This assymmetry is not elegant and ruins the definition-less property of custom elements.
2- Currently properly named HTMLElements and HTMLUnknownElements are both errors, they should be downgraded to warnings or disappear. Using an HTMLUnknownElement should annoy the user more because of the lack of future guarantee in compatibility, but the user should still be able to disregard the warning/error if they feel that their tag has no risk of a collision, like in the case of employee.

There's many ways to accomplish number 2. a specific implementation could be:
HTMLElement, issue warning, recommend --custom-tag (or its version without parameters),
HTMLUnknownElement, issue warning, recommend --custom-tag. If this is encountered in --custom-tag mode, notify user of naming conventions, the benefit of complying, and possibly recommend --no-namespaces, a link to

The objective of making Custom elements opt-in is to avoid false negatives (as in no errors) for regular users. The objective of only showing the no-namespace warning when in --custom-tag mode is again, to avoid confusing regular users with custom-tag internals..

I'm recommending that both of these cases be warnings because the standard defines both of these behaviours and they define them to behave as empty elements.

Let me know what you think of this. Regards.

[geoffmcl]

@TZubiri thank you for the further feedback... but..

But I am sorry, I still do not know exactly what you are asking... what is to be changed, fixed, enhanced, ...

Tidy C code, as it stands, has no definitions for HTMLElements and HTMLUnknownElements... an element, a tag, is either in the Dict tag_def table, or it is NOT... very simple... or...

And very little has been done, at present, concerning, the so called Custom Elements, aka web components... ie those tags with a -... but here you must enable custom-tags, or more, in config...

Any tag not in the above table, and custom-tags, is not set... will be an ERROR condition...

I'm recommending that both of these cases be warnings ...

Can you give small sample(s), config used, output, and expected output... show what error should be a warning...

After correcting your given sample, for what I assume to be typos, and run it with a config --show-body-only yes --new-blocklevel-tags employee,name,salary, I get the no errors... success?

line 1 column 1 - Warning: <employee> is not approved by W3C
line 2 column 1 - Warning: <name> is not approved by W3C
line 3 column 1 - Warning: <salary> is not approved by W3C
<employee>
<name>
<p>Tomas Zubiri</p>
</name>
<salary>
<p>0$</p>
</salary>
</employee>

Is that what you want, to be like that, by default? somehow? confused...

But how can that be right? As stated, in general, tidy must show an error for any un-listed tag... unless you teach it, tell tidy, through your config, to add new things...

As stated, at this time, do not understand what tidy fix you want! Please clarify... preferably with html samples... thanks...

PS: Please read https://guides.github.com/features/mastering-markdown/ - to be able to show html code, in these github issues, you must add back-ticks I think they are called... like your text Error: <custom-tag> is... does not display correctly...

[TZubiri]

Hello Geoff, thank you for taking the time guiding me with this issue/proposal.

But I am sorry, I still do not know exactly what you are asking... what is to be changed, fixed, enhanced, ...
Can you give small sample(s), config used, output, and expected output... show what error should be a warning...
As stated, at this time, do not understand what tidy fix you want! Please clarify... preferably with html samples... thanks...

I'm working on a repo with a sample of HTML I'd write along with the current outputs and the expected outputs. In doing so I'm etching specific details of a proposal.
https://github.com/TZubiri/tidy-custom-tags-mcve , work in progress.

Tidy C code, as it stands, has no definitions for HTMLElements and HTMLUnknownElements... an element

HTMLElement and HTMLUnknownElement are the names defined by the w3 standards and implemented by browsers. I can confirm that tidy at least partially implements these definitions.
You can find a longer explanation here

Is that what you want, to be like that, by default? somehow? confused...

But how can that be right? As stated, in general, tidy must show an error for any un-listed tag... unless you teach it, tell tidy, through your config, to add new things...

I don't need to teach tidy about the classes I use, I hope the same can be achieved for my tags. I feel that just deleting these errors would be worth it, but I know not every user will agree, so I have a couple of suggestions to minimize impact. TZubiri/tidy-custom-tags-mcve#4
TZubiri/tidy-custom-tags-mcve#5
TZubiri/tidy-custom-tags-mcve#7
TZubiri/tidy-custom-tags-mcve#6

Users of classes could benefit from importing definitions from css and spell checks because these would allow the creation of a warning on empty classes.

[geoffmcl]

@TZubiri lol, thank you for your enthusiasm, ideas, time, etc, but...

If you have a feature request, bug, etc ..., any enhancement of tidy, then present it/them here... or in a new issue... some of which you have already done... thanks...

It is maybe ok, sometimes good, to enhance your ideas with external links, to your repo, or W3C doc, or ..., to add to the issue, thanks ... but...

But the basic idea(s) must be presented, discussed, agreed, modified, compromised, etc... here ...

Please give a summery, of your couple of suggestions... very welcome... and maybe we can discuss, explore, decide, ...

And for each, it would be good if you could add a small, simple, sample html, config, current output, suggested output...

BTW: Just expanding your original sample, using <employee>... etc, can not be considered a new sample... just a bigger sample ... lol...

And from some things that I read, I do not thing tidy reading css, will fly... and, if I am reading correctly, a tag like <anything>, should be treated as a custom-tag, will also be a difficult sell...

But agree custom-tags option could be enhanced... to what, ideas, def, spec, ... etc

Yes, I am trying to guide you... I too want results... what is the problem?

As always, look forward to further feedback... thanks..

[laoshaw]

Would be nice to either support all custom tags(i.e. not err on them), these days custom-tag is everywhere(bootstrap, vue, react), just ignore them as the browser does. or tiday checks with some keyword file(i.e. putting all bootstrap custom tag in that file) and ignore them. I'm using tidy for bootstrap html linter, there are so many errors I have to disable it.

[wikked1]

As laoshow mentions, custom tags are extremely common nowadays due to frameworks like Angular, Vue, React, etc. and the fact that the W3C specs now allow them.

If you are tidying a lot of HTML that you didn't write and don't know much about (e.g. cleaning up a codebase or tidying a wget mirror) then it is tedious hand-crafting a list of custom tags so that you can convince tidy to not refuse to process a bunch of documents where you don't know the list of custom tags ahead of time.

My personal experience using tidy with custom tags

Please note this is not a complaint or criticism of tidy. I love tidy. I'm just trying to help the conversation and [maybe] make something better. :)

I expected --custom-tags blocklevel to put tidy into a mode where it automatically allows all unrecognized tags to be processed (and also processed as blocklevel), e.g. <employee>. This didn't work for me (Error: <employee> is not recognized!). so I added --new-blocklevel-tags employee, which did work. But that left me wondering what in the world --custom-tags blocklevel was even for? My thought process:

If I have to tell tidy the list of custom tags ahead of time, and the only way to tell it the list of tags is by one of new-blocklevel-tags, new-empty-tags, new-inline-tags, or new-pre-tags, then there seemed to be no possible scenario where the display-type value passed to --custom-tags would ever be used by the program. Another thing I wondered about: what if I set --custom-tags no and --new-blocklevel-tags employee? Answer: tidy still processed <employee> correctly.

Doing a bit more reading, I see in tidy's docs the example tag given is <flag-icon>. Seeing some of the other chatter about future-proofing your custom tags from colliding with hypothetical new W3C specced tags, people recommend using a hyphen in the name of your custom tags, since W3C has promised not to specify core HTML tags with hyphens in their name. So then I switched all <employee> to <my-employee> in the HTML and magically --custom-tags blocklevel started working without any further options (e.g. I didn't have to tell tidy that my-employee is a custom tag).

This led me to the following guess about the internals of tidy:

1. --custom-tags <blocklevel|empty|inline|pre> will put tidy into a mode where it will process any custom tag it encounters without complaint and without having to predeclare the custom tags but only if the custom tag has a hyphen in the name.

2. If you want to convince tidy to process custom tags that do not have a hyphen in the name, you must predeclare each of those tags using a comma separated list of tags passed to any one of new-blocklevel-tags, new-empty-tags, new-inline-tags, or new-pre-tags.

Moving Forward

1.e) If nothing else is changed, the documentation for --custom-tags should make it much clearer that this option only works against custom tags with hyphens in their name. This might be "obvious" if you read the W3C specs, but let's help users (like me) out and make this more clear in the docs.

2.e) As of the existing versions of tidy, the only way to process custom tags without a hyphen in their name is to pre-generate a whitelist of custom tag names and pass them to tidy using any of the --new-...-tags options. For certain use-cases this is tedious and inconvenient. There are many possible imaginable ways to put tidy into a mode where it will accept all custom tags without hyphens without predeclaring them (including not implementing this feature at all), but I think it would be a nice feature to have. Here are some ideas:

Proposed Enhancement 1 - more complexity, but more power

New tidy configuration option:
--unrecognized-tags <error|custom>

error (default) - If tidy encounters a tag whose name is valid (in the SGML/XML sense) but not recognized it will generate an error [this is the same behavior as today]. By default tidy will recognize a tag iff:

• The tag name is specified by the W3C HTML spec; or
• The tag name contains a hyphen and --custom-tags is not no; or
• The tag name has been supplied to tidy via any of new-blocklevel-tags, new-empty-tags, new-inline-tags, or new-pre-tags.

custom - If tidy encounters an opening tag whose name is valid but unrecognized (as defined above), the tag will automatically be registered as a custom tag. The default display-type of tags defined this way is blocklevel unless configured elsewise using --custom-tags.

Proposed Enhancement 2 - easier to use and understand, less complex, less powerful, possibly easier to implement:

Unconfigurable: modify the behavior of --custom-tags to allow custom tags without hyphens in their name.

Proposed Enhancement 3

I noticed that TZubiri suggested the ability to use wildcards with new-blocklevel-tags, new-empty-tags, new-inline-tags, or new-pre-tags. This would work, but seems harder to implement.

--new-blocklevel-tags employee* allows <employee> and <employees> to be treated as custom tags.
--new-blocklevel-tags * allows any unrecognized tag to be a custom blocklevel tag.

Note that under the existing tidy behavior --new-blocklevel-tags span (for example) does not emit a warning or modify the display type of the to blocklevel. This leads me to believe that tidy ignores requests to redeclare specced HTML tags as custom. This is totally reasonable. I mention it because you might wonder what --new-blocklevel-tags * would do since it matches the name of in-built HTML tags. Following the precedent of the behavior of e.g. --new-blocklevel-tags span, it would simply ignore the fact that '*' matches the name of in-built HTML tags and not modify the treatment thereof.