New Rule: attributeChain

[panoply]

Description

This is a Liquid specific beautification option and will controls how Liquid tags contained within HTML attributed should be formatted. The rule requires some considerable thought and does not want do too much handling.

Goals

Attribute chaining needs to respect the defined wrap limit but override forceAttributeon inner contents when using inline. In cases where wrap is defined and the option is using inline with the correct rule enabled (ie: true), then Prettify should apply whitespace dashes to surrounding tag delimiters of the inner content it newlined in the chain that exceeded the wrap length. Chaining should also respect preservation and input defined structures.

Context

This option requires refactors and multiple augmentation and patches be applied in the Sparer lexing algorithm. New token types will be introduced here in order to know what type of token we are dealing with. The tokenization of attribute values will also undergo overhauls to ensure we are capturing connected Liquid and HTML type expression.

It's hard to predict the structure a user will employ. Because Liquid is novice appealing due to its simplicity, developers can be utterly fucking insufferable when infusing template logics into HTML attributes and as such this beautification rule will likely need to undergo edge-case testing in order to provide the best possible outcomes when reasoning with shitty code.

Sparser Types

This option will introduce new token type reference into Sparser. The new types will behave nearly identically to the standard lexing of Template tokens with differencing being the actual tokens pushed into the data structures. These new types will allow for tokens like data-{{ some.object }} to passed.

template_attribute_start

A template tag within a HTML attribute that is not a singleton. When the attributeChain option is enabled and Prettify executes the beautification process this type value is used as a stack reference point to produce a chained result.

Example

The {% if x %} token in the below example would be marked as a template_attribute_start because it can be identified as a start type token given an ender exists.

<div
 id="foo"
 {% if x %}data-x{% else %}data-y{% endif %}></div>

template_attribute_else

A template tag within a HTML attribute that can be identified as an else type conditional.

Example

The {% elsif %} and {% else %} tokens in the below example would be marked as a template_attribute_else because they can be identified as a else type tokens given they are contained within conditional types if and unless tags. This type value is important for beautification handling as depending on defined options like attributeChain, forceAttribute, wrap and/or correct then a token type value of template_attribute_else may be used to separate contents onto newlines.

<div
 {% unless x %}class="foo"{% else %}class="bar"{% endunless %}
 id="some-id"
 {% if x %}data-x{% elsif y %}data-y{% endif %}></div>

template_attribute_end

A template tag within a HTML attribute that can be identified as an ender type.

Example

The {% endif %} token in the below example would be marked as a template_attribute_end because it can be identified as a ender type token given that a start type exists.

<div
 id="some-id"
 {% if x %}data-x{% endif %}></div>

Ruleset

The option will provide multiple beautification style choices. The initial rollout will include the following:

• preserve
• collapse
• inline

There is consideration and room for advancement here, so the potential to extends these choices is likely.

Definition

The option will be available to markup and can be defined as followed:

prettify.options({
  markup: {
    attributeChain: 'preserve' | 'collapse' | 'inline'
  }
})

Examples

Preserve (default)

Preserve strips extraneous whitespace and newlines if they exceed the defined preserveLine limit but it will leave the overall structure intact. Notice how in the below example, the only difference before and after formatting is the extraneous whitespace.

<!-- Before formatting -->
<div
  class="x"
  {% if x %} id="{{ foo }}"
  {% else %}  data-x="xx"    {% endif %}>
</div>

<!-- After formatting -->
<div
  class="x"
  {% if x %}id="{{ foo }}"
  {% else %}data-x="xx"{% endif %}>
</div>

Inline

Notice how before formatting the contents of the tag block are separated onto new lines whereas after formatting the contents are chained together.

<!-- Before formatting -->
<div
  class="x"
  {% if x %}
  id="{{ foo }}"
  {% else %}
  data-x="xx"{% endif %}>
</div>

<!-- After formatting -->
<div
  class="x"
  {% if x %}id="{{ foo }}"{% else %}data-x="xx"{% endif %}>
</div>

Collapse

Collapse will newline the contents of the tag block. Notice how before formatting contents are expressed on a single line, whereas after formatting content is forced onto new lines.

<!-- Before formatting -->
<div
  class="x"
  {% if x %}id="{{ foo }}"{% else %}data-x="xx"{% endif %}>
</div>

<!-- After formatting -->
<div
  class="x"
  {% if x %}
  id="{{ foo }}"
  {% else %}
  data-x="xx"{% endif %}>
</div>

[panoply]

Thinking about this option more and more and have decided to not go ahead. The intended default of preserve does a very efficient job and correctly handling Liquid defined attributes. Instead, users should control the structures themselves and have Prettify merely respect the structures.

When using forceAttribute or wrap based attribute forcing then the rule will behave in accordance, forcing only structures which are not chained, (ie: no whitespace). The pre-release will not expose this ruleset and instead the default preservation will be used.