Js-beautify: HTML: Proposal to organize the attribute-wrapping settings

Created on 31 May 2018  ·  9Comments  ·  Source: beautify-web/js-beautify

Extracted from #1297.

What we have

wrap_attributes:

  • auto - enables wrapping of attributes.
  • force - first attribute stays, others wrapped with "wrap_attributes_indent_size"
  • force-aligned - the first attribute stays, others wrapped and aligned with the first one
  • force-expand-multiline - If there are more than 1 atribute, ALL attributes are wrapped no matter what and indented with "wrap_attributes_indent_size". AND: the closing '>' of the opening tag is also on the new line. This mode is currently broken, produces wrongly indented files :(

There are also multiple effort to provide some additional modes that deal with wrapping of long html elements with multiple attributes: #1285 and #1262.

I think that there are multiple (orthogonal) concerns here and putting them all into single value would create more confusion and weird option names explosion if we are to handle all cases.

So, let's separate wrapping, aligning and number of attributes per line, etc.

Proposal

wrap_attributes_mode:

  • none - We just don't wrap attributes, period. (needed?)
  • auto - Normal attribute wrapping, this should be the default, probably, as the most logical case. When the line is too big, we wrap. If all attributes can fit into a single line, they stay on the single line, no wrapping. (Default.)
  • force - We forcefully wrap if there are more than 1 attribute present, otherwise auto.

When the wrapping is in action, the following properties are in play. If no wrapping happens, they don't play any role.

wrapped_attributes_per_line:

  • multiple - Soft wrapping, default. Fit as many attrs per line as allowed.
  • single - The first attribute stays on the first line, others are on separate lines.
  • single-all - All attributes, including the first one, placed on separate lines. So, every attribute is on a separate line, and the element/tag line has no attributes left.

wrapped_attributes_indent:

  1. auto -- Uses wrap_attributes_indent_size, default.
  2. aligned -- All attribute lines start aligned with the first attribute. If the first attribute is on a new line ("single-all" mode of wrapped_attributes_per_line), then we use wrap_attributes_indent_size to calculate the indent.

wrapped_attributes_end:

  • auto - default
  • multiline - the closing > is on the separate line.

Examples

  1. DEFAULT case: We soft wrap and try to fit as many attributes per line as possible, but within the line length limit.
wrap_attributes_mode = auto
wrapped_attributes_per_line = multiple
wrapped_attributes_indent = auto
wrapped_attributes_end = auto
  1. #1285 case. Very similar to default case, but we align the wrapped attributes to be on the same indent level as the first attribute.
wrap_attributes_mode = auto
wrapped_attributes_per_line = multiple
wrapped_attributes_indent = aligned
wrapped_attributes_end = auto
  1. #1262 case. When we wrap, we want one attribute per line, aligned with the first one.
wrap_attributes_mode = auto
wrapped_attributes_per_line = single
wrapped_attributes_indent = aligned
wrapped_attributes_end = auto
  1. Current force-expand-multiline case: Force wrapping if there are more than 1 attribute, with one attribute per line, and with multi-line ending, placing the closing > on the new line.
wrap_attributes_mode = force
wrapped_attributes_per_line = single-all
wrapped_attributes_indent = auto
wrapped_attributes_end = multiline
javascript discussion enhancement

Most helpful comment

I like your proposal, and I think an even simpler implementation that could solve a lot of problems for some people, would be the option to configure the point at which "force" uses auto. For example, being able to say, if it has less than X attributes, use auto, otherwise, force wrap.

All 9 comments

@vvs
Awesome thanks!

It looks like there's an overlap between force and multiple, but some conflict is probably inevitable with the complexity of the settings

As I said, I like the value names you've chosen in general. I think I'd change wrapped_attributes_end to expand-multiline - because it only expands when the element is a multiline element.

It sounds like you'd be opposed to using a comma-separated value list the way brace-style does ([collapse|expand|end-expand|none][,preserve-inline]). I ask only because I don't love having more option fields when a single one can work.

Hi @bitwiseman. Yeah, there is a bit of overlap between force and multiple. Basically, "forcing" the multiple attributes equals auto :)

I am also OK with expand-multiline.

It sounds like you'd be opposed to using a comma-separated value

Personally, I can live with anything, even if the settings are BASE64 encoded values! The main thing is that I am able to adjust the formatting behavior to my/team needs (which currently are in line with #1262).

But as a matter of preference, having separate "option groups" is better so that I could modify them independently and think about different (orthogonal) concerns independently. And, most of all, it makes much easier to document the settings separately as compared to a huge list of all possible combinations.

@vvs
Good point about having separate settings for distinct behaviors.

I like your proposal, and I think an even simpler implementation that could solve a lot of problems for some people, would be the option to configure the point at which "force" uses auto. For example, being able to say, if it has less than X attributes, use auto, otherwise, force wrap.

I'd like to use "aligned-multiple" if using <= 3 attributes, otherwise "force-aligned". Is this possible at the moment?

@otonielguajardo

It does not exist currently.

What you're asking for is similar to #1262, which is basically "Allow attributes one line unless they are going to wrap, in which case align them."
It looks like @Adondriel requested something like what you want (based on attribute count) in that issue as well.

any advances?

Any plans to revisit this?

@notiv-nt @Drumstix42
With my limited available time, I've been fixing other bugs.
This is still worth doing, but requires someone to take the time to finish the design and implement it.

Was this page helpful?
0 / 5 - 0 ratings