Using custom rules in modules

[Kirill Maltsev]

In #73 @SebastianNiemann suggested extending removeComments module to support custom filter rules.

It made me think if such custom rules could come in handy in other modules. For example, to pass additional attributes or complex rules to removeRedundantAttributes module. In that case, I think we'd be better off creating some general API or approach applicable to all modules, which might be different from RegExp you suggested.

@SebastianNiemann, do you have any thoughts about this idea?

[Sebastian Niemann]

I think whenever a rule is implemented with any assumption about the actual DOM (or keywords as in #73) in mind, a custom filter would be useful to support extensions (like MathML) or additional keywords.

At best, this would not only allow to extend the current assumptions (like adding further boolean attributes to collapseBooleanAttributes by setting amphtml), but also to replace them if needed.

Looking through the existing rules, this would concern:

• collapseAttributeWhitespace
  To specify other list-like attributes beside class, reland ping.

• collapseBooleanAttributes
  To specify other boolean attributes.

• collapseWhitespace
  To specify other tags which should be skipped.

• deduplicateAttributeValues
  To specify other list-like attributes beside class, reland ping.

  On a side note, is there a copy&pase error? I was wondering about export default function collapseAttributeWhitespace instead of export default function deduplicateAttributeValues. Not that it really matters due to the default export.

• removeComments (see #73)

• removeEmptyAttributes
  To specify other safe-to-remove attributes.

• removeRedundantAttributes
  To specify other redundant attributes

To go all the way, the rules regarding Javascript, CSS, SVG and JSON could also be extended (to allow other tags for example), but I am unsure if any user of htmlnano has a use case for this -- wherefore I would skip these for now. However, {type: /(\/|\+)json/} could be extended to {type: /(\/|\+|-)json/} to support fancy */x-json mime types.

---

For nearly all cases, this would just mean to add an option to provide a custom list of strings, as only tags or attributes are specified.

Only removeComments differs from this, as it supports to keep any conditional comment (or some kind of code), which does not seem to be satisfactorily representable as a finite list of strings. For this single case, I would stick to a regex.

---

I am unsure how a general API should look like. Do you already have something in mind?

[Kirill Maltsev]

Thanks for posting your ideas!

Do you already have something in mind?

No, not yet. But I'll definitely think about it.