-
-
Notifications
You must be signed in to change notification settings - Fork 13
Support camelCased source properties #6
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
Comments
Related syntax-tree/hast-util-to-html#5 |
My thoughts are these:
|
And for the spec, you can see it in the property name section! |
But even with the use of a less strict html parser we would break the HAST specification right? Currently, I solve it by forking the relevant projects and make them case-sensitive aware but this breaks HAST :( Do you plan to change the specs for exactly that case or only for proper svg support ? |
I’m not really sure how to do it otherwise. HAST is for HTML. And in JS and plugins you’d like to use Also, is this really a problem here, or in |
It's a problem in many places
Do you see a way to modify attributes only when known html attributes are used plus maybe a check for camelCased svg elements? e.g for Hastscript
A possible solution would be to add this information here https://github.com/wooorm/property-information/blob/master/index.js#L231 and propoagate it through all relevant packages. |
In this way, we are still compatible but don't interfere in how a parser provide it's attributes. WDYT? |
Would you also say that:
? |
yes and for unknown attributes it's passed as it was received from the parser. |
Alright! In which cases should
(these options should also work for e.g., |
Good question. I propose
|
You could use this map |
@wooorm do you have concrete ideas on how we can implement it? Would you accept a PR? |
Hey @StarpTech! I thought about it a bit and I’d like to work on this now. For starters, this issue is now first tracked in wooorm/property-information#6. When that is done, we can work on updating it throughout the ecosystem. I’ll close this now, if you have any further comments please post them there! P.S. thanks for offering to help. I’ve spent today thinking and working on it, and I have a clear idea of where this should go. I’ll try to get a MVP working soon and will let you know if I need help! |
Hi @woorm, thanks for the update. Great, that my proposal found acceptance! |
Related to wooorm/property-information#6. Related to GH-6. Related to GH-4.
Hi,
I would like to use the hype ecosystem to build my own html formatter but I'm facing with a big issue. I use a fork of parse5 in order to handle element attributes case-sensitive for web frameworks like Angular, VueJs.
hastscript doesn't respect (in my case parse5 tree) as the source of truth (https://github.com/syntax-tree/hastscript/blob/master/index.js#L144) because it converts all attributes to camelCases, which I think is wrong from the point of view of a parser tool. But anyway I understand the reasons and my project isn't html5 compliant but it would be very great to have that flexibility in rehype precisely because rehype serve as a general interface between html parsers.
Thank you!
The text was updated successfully, but these errors were encountered: