Add Configuration List for SuppressEmptyTags

[diomedtmc]

• Are you running the latest version?
• Have you included sample input, output, error, and expected output?
• Have you checked if you are using correct configuration?
• Did you try online tool?

Description

We often need to parse/build HTML and not traditional XML with this tool. However, in HTML world, blunt force on the empty tags is not good. We would like to see an empty div, span, p, etc...remain in tact with a close and open tag. However, for say a br or hr, we would rather suppress it. Would love to see a configurable list for which tags we suppress in the XmlBuilder instead of a global boolean.

Input

1. Create a simple XML string with an empty tag you DO NOT want to suppress and one you do want to supress.
2. Use XmlParser
3. Use an XmlBuilder to regenerate the XML from the output in step 2

Code

const sample = '<article><div style="padding: 20px"></div><br/></article>';
const sharedFastXmlConfiguration = {};

const parser = new XmlParser(sharedFastXmlConfiguration);
const builder = new XmlBuilder(sharedFastXmlConfiguration);
const elements = parser.parse(sample);
const sampleAfterFastXmlParser = builder.build(elements);

expect(sampleAfterFastXmlParser).to.equal(sample);

Output

Depending on how you configure it, you end up with either (suppress empty tags true):

const sampleAfterFastXmlParser = '<article><div style="padding: 20px"/><br/></article>';

Or(suppress empty tags true):

const sampleAfterFastXmlParser = '<article><div style="padding: 20px"></div><br><br/></article>';

expected data

Instead, I should be able to get closer to proper HTML (and conceivably match my input):

const sampleAfterFastXmlParser = '<article><div style="padding: 20px"></div><br/></article>';

Would you like to work on this issue?

• Yes
• No

Bookmark this repository for further updates.

[amitguptagwl]

Have you tried unpairedTags: ["hr", "br", "link", "meta"] with suppressEmptyNode: false?

Ref: HTML Parsing with FXP

[diomedtmc]

It does not work. If I pass unpairedTags: ["hr", "br", "link", "meta"] in on parse (docs say it is not available on build, same with the TypeScript), it has no affect for me, as our XML/HTML is at least validated to be valid against HTML. If I use suppressEmptyNode: false on builder with the same parsed input JSON Object, my br tags are rendered <br></br>. If I bypass the documentation/TypeScript and pass unpairedTags: ["hr", "br", "link", "meta"] into builder, I get even worse results - just <br> - now I am missing close tags.

[amitguptagwl]

hmm, got you. So basically you don't want unpaired tags in the built XML/HTML. However, you want some empty tags to be suppressed and some not.

Now my question is, some tags that you want to be suppressed, are the unpaired tags only? like br, hr, link, meta etc? Or can they be anything?

[diomedtmc]

I think if you do decided to do the feature, I might just give the interface an array or something and let us decide. I think then we can deal with the headache of maintaining the specific list ourselves (which in our case, would generally be HTML content tags that are rendered as self closing - br/hr mostly, link/meta are not an issue for us, but for others they may be or may have other requirements). If an array parameter, you never have to worry about it and consumers of your package would be happy.

[amitguptagwl]

Property unpairedTags was created with the same motive where the users can provide the list of tags. It was included in the builder so that a <br></br> tag can be parsed to <br> not <br/>. Hence, it is necessary to know if you need that feature for unpaired tags only or it can have any tag!!

Similar looking feature needs to be avoided.

[diomedtmc]

Not sure I follow that last statement entirely - but I think you are trying to say that managing a package with such high use requires careful decision :-)

Let me step back a little bit further - our purpose for this library is to try and take non-normalized xml/html input and normalize the output. The treatment of empty tags is not symmetrical for us. The current framework you have would give us complete control if we could only submit an array on build/output of which tags we suppress to a closed empty tag.

[amitguptagwl]

There are 2 types of tags in HTML.

1. paired: div, body etc.
2. unpaired: Eg br, hr etc.

paired tags may or may not be empty and can be represented as <div></div> or <div/>. Whereas, unpaired tags are always empty and can be represented as <br> or <br/>. Irrespective of whether suppressEmptyNode: true is set or not, unpaired tags are always rendered as <br> by this library. But this is what you don't want.

So What we can do;

1. When suppressEmptyNode: true && unpairedTags: ["br"] then
   a. paired empty tags: <div/>
   b. unpaired tags: <br>
2. When suppressEmptyNode: false && unpairedTags: ["br"] then
   a. paired empty tags: <div></div>
   b. unpaired tags: <br/>
3. When suppressEmptyNode: true && unpairedTags are not given in builder then
   a. paired empty tags: <div/>
   b. unpaired tags: <br/>
4. When suppressEmptyNode: false && unpairedTags are not given in builder then
   a. paired empty tags: <div></div>
   b. unpaired tags: <br></br>

I believe this will cover all the possibilities what a user may look for. Tell me if it satisfies your requirement.

[diomedtmc]

I could achieve the normalization I want with example #2. I am skeptical about the interaction of the two parameters; however, as a consumer could not produce <div></div> <br> if he/she wanted to (I don't, but I feel like the less opinionated your package is about the XML, the more use it will get). Examples #3 and #4 make perfect sense. I'd say ice it and think about it a bit; maybe there is a better solution long term for parse->builder XML normalization scenarios.

[amitguptagwl]

Yes, it is quite difficult to achieve all the combinations. So introducing "suppressUnpairedNode" properties to the builder.