Source reformatting: switch to no line-breaking

[zcorpan]

See https://github.com/zcorpan/reformahtml

---

/acknowledgements.html ( diff )
/browsers.html ( diff )
/browsing-the-web.html ( diff )
/canvas.html ( diff )
/common-dom-interfaces.html ( diff )
/common-microsyntaxes.html ( diff )
/comms.html ( diff )
/custom-elements.html ( diff )
/dnd.html ( diff )
/document-lifecycle.html ( diff )
/document-sequences.html ( diff )
/dom.html ( diff )
/dynamic-markup-insertion.html ( diff )
/edits.html ( diff )
/embedded-content-other.html ( diff )
/embedded-content.html ( diff )
/form-control-infrastructure.html ( diff )
/form-elements.html ( diff )
/forms.html ( diff )
/grouping-content.html ( diff )
/iana.html ( diff )
/iframe-embed-object.html ( diff )
/image-maps.html ( diff )
/imagebitmap-and-animations.html ( diff )
/images.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/input.html ( diff )
/interaction.html ( diff )
/interactive-elements.html ( diff )
/introduction.html ( diff )
/links.html ( diff )
/media.html ( diff )
/microdata.html ( diff )
/named-characters.html ( diff )
/nav-history-apis.html ( diff )
/obsolete.html ( diff )
/parsing.html ( diff )
/popover.html ( diff )
/references.html ( diff )
/rendering.html ( diff )
/scripting.html ( diff )
/sections.html ( diff )
/semantics-other.html ( diff )
/semantics.html ( diff )
/server-sent-events.html ( diff )
/speculative-loading.html ( diff )
/structured-data.html ( diff )
/syntax.html ( diff )
/system-state.html ( diff )
/tables.html ( diff )
/text-level-semantics.html ( diff )
/timers-and-user-prompts.html ( diff )
/urls-and-fetching.html ( diff )
/web-messaging.html ( diff )
/webappapis.html ( diff )
/webstorage.html ( diff )
/workers.html ( diff )
/worklets.html ( diff )
/xhtml.html ( diff )

[zcorpan]

The reformatting tool supports opting out for specific elements with a data-noreformat attribute. I haven't added such an attribute yet, but some things should probably have it, e.g. the Dependencies section.

[domenic]

Very cool!

The other major section to not reformat is the acknowledgements section.

Is there any way to do some sort of programmatic check that only whitespace has changed, to rule out any content-deleting bugs in the reformatter? Maybe just the htmldiff tool would work?

[jmdyck]

In the paragraph that begins "Here is an example of color space conversion", the status quo:
... <code data-x=\n "dom-....
is converted to:
... <code data-x= "dom-...
but that space after the = probably shouldn't be there.

(This is the only case where the status quo has a line-break after an attribute's =.)

[annevk]

Arguably that's a bug in the status quo since you're supposed to only wrap on where whitespace would "naturally" occur.

[zcorpan]

@jmdyck fixed the = issue, thanks!

@domenic

Very cool!

Thanks!

The other major section to not reformat is the acknowledgements section.

I've marked elements I found with custom indentation with data-noreformat now in a separate commit.

Is there any way to do some sort of programmatic check that only whitespace has changed, to rule out any content-deleting bugs in the reformatter? Maybe just the htmldiff tool would work?

file=source                
a=$(git show HEAD:"$file" | tr -d '[:space:]' | git hash-object --stdin)
b=$(tr -d '[:space:]' < "$file" | git hash-object --stdin)

if [ "$a" = "$b" ]; then
  echo "Only whitespace differences"
else
  echo "Real changes"
fi

Shows "Only whitespaces differences" after running the script.

[zcorpan]

I think I'm happy with the output now. LMK if there are more elements that should have data-noreformat or if there are bugs in reformahtml.py.

[jmdyck]

Arguably that's a bug in the status quo since you're supposed to only wrap on where whitespace would "naturally" occur.

Would you prefer a separate PR to fix such bugs?

[annevk]

As far as I can tell we only have one instance. We could fix it separately or incorporate it in a random PR. I don't think it matters much?

[zcorpan]

No need to fix = since the issue goes away with the reformatting.

[jmdyck]

As far as I can tell we only have one instance.

There's only one instance of 'newline after equals', yes, but there's more than one instance of 'newline where whitespace wouldn't "naturally" occur'.

[jmdyck]

In this PR, there are many cases where, if the first non-blank on a line is an element, it isn't joined up with the previous line, but presumably should be. (If you're looking for examples, searching for /^ *<\(var\|code\|ref\|span\)/ in vim will find a lot of them.)

[zcorpan]

@jmdyck, thanks, fixed now.

[annevk]

@zcorpan it seems this branch still has conflicts?

[annevk]

Rubber stamp, assuming this is going to be followed up with a "Meta:" commit to fix blame and hoping that this doesn't introduce new issues.

[jmdyck]

• A lot of the <ref> tags are preceded by 2-10 spaces, where it should presumably be only 1.
• Sometimes a <ref> isn't joined to the previous line (e.g. lines 3170, 6087), but probably should be.
• Sometimes a </div> tag is joined to the previous line (e.g. line 1289), but should probably stay on its own line.
• The treatment of comments seems inconsistent: sometimes joined up, sometimes not. Is there a rule?

[zcorpan]

• A lot of the <ref> tags are preceded by 2-10 spaces, where it should presumably be only 1.

• Sometimes a <ref> isn't joined to the previous line (e.g. lines 3170, 6087), but probably should be.

• Sometimes a </div> tag is joined to the previous line (e.g. line 1289), but should probably stay on its own line.

Thanks, these should be fixed now.

• The treatment of comments seems inconsistent: sometimes joined up, sometimes not. Is there a rule?

Yes, comments that are preceded with a newline and followed by a newline are considered structural and left alone (including internal linebreaks). Other comments are reflowed inline.

This means some comments still have internal linebreaks that could arguably have internal linebreaks removed, but I think we can leave them as-is.