Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Formatting comments #9

Closed
rtm opened this issue Aug 26, 2018 · 3 comments
Closed

Formatting comments #9

rtm opened this issue Aug 26, 2018 · 3 comments
Labels
🗄 area/interface This affects the public interface 💪 phase/solved Post is done 🧑 semver/major This is a change 🦋 type/enhancement This is great to have

Comments

@rtm
Copy link

rtm commented Aug 26, 2018

I want to leave comments on their own lines whenever possible, or at lease respect comments which were on their own lines in the input.

Currently , all newlines around comments seem to be eaten. I also note that whitespace around comments seems to be eaten. For example, <foo> <!-- comment --> </foo> is rendered as <foo><!-- comment --></foo>. Doesn't that change the semantics?

Anyway, is there any easy/obvious way to formats comments onto their own lines (in cases where the semantics would be changed by the new lines and leading space characters), or do I just need to fork rehype-format, or is some filter/plug-in that could handle this?

@wooorm
Copy link
Member

wooorm commented Aug 26, 2018

👍

How this works is to first remove all whitespace, and then to add some back.
I don’t think there’s any real special care for of comments, but for a solution I think just handling them the same as elements would work.

Can you create a PR?

@rtm
Copy link
Author

rtm commented Sep 5, 2018

@wooorm Thanks for replying. I took a look at the code, made some obvious changes, and found myself down a rabbit hole. I'm not convinced that this is a productive direction. I switched over to using a different HTML beautifier. I also need some convincing that the current logic preserves the exact semantics of the input, in cases such as <span>foo</span><span>bar</span>, where the non-existence of white space between the two spans has particular semantics which would be broken by moving them onto separate lines. I also am not convinced that the whole approach of starting off by squashing is the right way to go; among other reasons, it prevents any logic based on some level of preservation of original formatting, which is desirable in some cases, and provided by other HTML formatters.

@wooorm wooorm added 🏡 area/internal This affects the hidden internals 🙆 yes/confirmed This is confirmed and ready to be worked on 🦋 type/enhancement This is great to have 🧑 semver/major This is a change labels Aug 13, 2019
@wooorm wooorm closed this as completed in 5f2eac2 Jun 21, 2020
@wooorm
Copy link
Member

wooorm commented Jun 21, 2020

Well, that was a long time!

fwiw, most of the bugs with the previous approach had to do with rehypejs/rehype-minify#19, which you alluded to as well with “I also am not convinced that the whole approach of starting off by squashing is the right way to go”.

Stay safe!

@wooorm wooorm added ⛵️ status/released 🗄 area/interface This affects the public interface and removed 🙆 yes/confirmed This is confirmed and ready to be worked on 🏡 area/internal This affects the hidden internals labels Jun 21, 2020
@wooorm wooorm added the 💪 phase/solved Post is done label Aug 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🗄 area/interface This affects the public interface 💪 phase/solved Post is done 🧑 semver/major This is a change 🦋 type/enhancement This is great to have
Development

No branches or pull requests

2 participants