Support camelCased source properties

[StarpTech]

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.

• I couldn't find in the specification that attributes are handled case-insensitive.

Thank you!

[StarpTech]

Related syntax-tree/hast-util-to-html#5

[wooorm]

My thoughts are these:

• For HTML, we need proper SVG support. I’m planning on working that in the future. But this may also need a change to the syntax tree
• For non-HTML things, like angular and vue, we could create a new XML-based parser/stringifier. Maybe something based on this.

[wooorm]

And for the spec, you can see it in the property name section!

[StarpTech]

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 ?

[wooorm]

I’m not really sure how to do it otherwise. HAST is for HTML. And in JS and plugins you’d like to use .className instead of .class.

Also, is this really a problem here, or in hast-util-to-html?

[StarpTech]

It's a problem in many places

• hastscript https://github.com/syntax-tree/hastscript/blob/master/index.js#L144
• hast-util-to-html https://github.com/syntax-tree/hast-util-to-html/blob/master/lib/element.js#L132

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

title => 'title' //known
FOO => 'FOO' // unknown
viewBox => 'viewBox' //known but svg
tab-index => 'tabIndex' //known
class => 'className' //known

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.

[StarpTech]

In this way, we are still compatible but don't interfere in how a parser provide it's attributes. WDYT?

[wooorm]

Would you also say that:

tITLE => 'title' //known
VIEWBOX => 'viewBox' //known but svg
Class => 'className' //known

?

[StarpTech]

yes and for unknown attributes it's passed as it was received from the parser.

[wooorm]

Alright!

In which cases should viewBox be known (treated case-insensitively)?

• always
• when processing a know SVG element?
• when processing a know SVG / HTML / MathML element?
• when processing a (sub)tree as SVG?
• Only on the svg element

(these options should also work for e.g., muted on HTMLs audio)

[StarpTech]

In which cases should viewBox be known (treated case-insensitively)?

Good question. I propose

• case-insensitively, only when processing an SVG viewport.

[StarpTech]

You could use this map

[StarpTech]

@wooorm do you have concrete ideas on how we can implement it? Would you accept a PR?

[wooorm]

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!

[StarpTech]

Hi @woorm, thanks for the update. Great, that my proposal found acceptance!