How do I preserve casing (lower/upper case of letters?)

[NullVoxPopuli]

I have this demo here: https://jsbin.com/juxanirera/10/edit?html,output

I'm trying to emit PascalCase elements, but everything is .toLowerCase()d, which isn't what I want.

[wooorm]

You don’t. Casing doesn’t exist in HTML. XY problem.

Lots of code, lots of moving parts. I see ember in there even?
Anyway, looks like you are using remark/rehype (HTML! So lowercase) but also XML/MDX (so components)? I dunno what you’re trying to do here?
And, don’t build html nodes. Build ASTs!

[NullVoxPopuli]

I just added an inspector to the unified pipeline, https://jsbin.com/juxanirera/10/edit?html,output

It seeems before rehypeRaw and rehypeStringify, casing is preserved. Both raw and stringify downcase everything.

I see ember in there even?

🤷

Lots of code, lots of moving parts.

I tried to comment where to look

(so components)?

yeah

I dunno what you’re trying to do here?

does it matter, exactly? 🤔 I want casing preserved, because I am using components.

MDX is only for React, and they have a shit load of complicated code to read. Very overwhelming, and I haven't at all figured out how anything ties together.

And, don’t build html nodes. Build ASTs!

can you expand on this? how do you mean?

[ChristianMurphy]

It seeems before rehypeRaw and rehypeStringify, casing is preserved. Both raw and stringify downcase everything.

Yes, because both also act as formatters, see https://github.com/orgs/unifiedjs/discussions/213#discussioncomment-4760791

I see ember in there even?

🤷

It matters because we've had this same conversation 2-4 times before.
Ember is not HTML, they're incompatible.
rehype, an HTML parser, is not able to parse or stringify Ember syntax.
An Ember parser could be created, but that's would be its own project and its own AST.

I dunno what you’re trying to do here?

does it matter, exactly? 🤔

Potentially not.
The short answer to you direct question is, no, it is not currently possible, and there are no plans to add an option.
If you'd like guidance or suggestions on alternatives to help you move forward, yes, what your end goal is does matter.

MDX is only for React

MDX is for any framework which has a hyperscript/JSX renderer.
This list currently includes:

• React
• Vue
• Svelte
• Preact
• Ink
• Solid

https://mdxjs.com/docs/getting-started/#jsx-runtimes
It may be possible to create a JSX automatic runtime in/from ember as well.

[NullVoxPopuli]

It matters because we've had this same conversation 2-4 times before.

apologies, I couldn't find the links from our previous discussions -- even in my email -- you found them though!
But I had thought they were deleted :(
or "cleaned up due to age" or something. :(
I'm glad they exist! and I would have continued discussion there or regained context, if I could have found those links.

It may be possible to create a JSX automatic runtime in/from ember as well.

I don't think the JSX folks would like me adding syntax additions (for which JSX does not presently have existing features) for ember -- JSX is a lossy format, so even if I pretend to compile to JSX, I can't actually convert back to Ember. I can do Ember -> JSX, but not the other way around.

[ChristianMurphy]

I don't think the JSX folks would like me adding syntax additions (for which JSX does not presently have existing features) for ember -- JSX is a lossy format, so even if I pretend to compile to JSX, I can't actually convert back to Ember. I can do Ember -> JSX, but not the other way around.

I was more suggesting the reverse.
Starting with Markdown + JSX files, since those can be parsed/supported by mdx and/or remark-mdx, and turning that output into Ember templates.

Yes it would potentially be a less rich syntax, yes it is a bit different from Glimmer, but most of the tools around MDX are already built out.

And, don’t build html nodes. Build ASTs!

can you expand on this? how do you mean?

Expanding on what I suspect @wooorm is getting at.
Glimmer already has an AST which is somewhat unist like https://github.com/glimmerjs/glimmer-vm/blob/8e11b91167d55995c7400135460a0d4c8b2a4164/packages/%40glimmer/syntax/lib/v1/nodes-v1.ts

What several unified project do are wrap the outside syntax tree in something unist compatible
For example:

• esast is a flavor of estree which is compatible with unified https://github.com/syntax-tree/esast
• hast (used by rehype) often acts as a wrapper for https://github.com/inikulin/parse5 to make it unified compatible

A similar AST to AST transformation could likely be made for Glimmer.

[ChristianMurphy]

Heya @NullVoxPopuli! 👋
Sorry you ran into a spot of trouble.
The answer is largely the same as rehypejs/rehype#88 and https://github.com/orgs/remarkjs/discussions/922
rehype is an HTML parser and formatter/stringifier.
HTML is case insensitive, and as such it applies formatting rules which are case insensitive as well.

You are trying to process content, ember templates, which break HTML rules (and by extension rehype) in a number of ways.
If you want ember specific parsing, you'll want an ember specific parser and stringifier which produces a unist compatible AST https://github.com/syntax-tree/unist to gaurantee if follows all the ember rules.

[NullVoxPopuli]

ah thanks! I couldn't find those links.

you'll want an ember specific parser and stringifier

it's been hard to grok how everything fits together. the whole ecosystem is full of 1 file libraries 😅
and then there is MDX, which is a complicated mess that I'm too dumb to figure out 😢

which produces a unist compatible AST

This would be in place of remark-parse, I preseme?
or consume the text and html nodes after?
I'm using inspect, and see the following:

Parsed Markdown
root[5] (1:1-21:1, 0-232)
├─0 heading[1] (2:1-2:8, 5-12)
│   │ depth: 1
│   └─0 text "Title" (2:3-2:8, 7-12)
├─1 paragraph[5] (4:1-4:31, 14-44)
│   ├─0 text "some " (4:1-4:6, 14-19)
│   ├─1 emphasis[1] (4:6-4:12, 19-25)
│   │   └─0 text "bold" (4:7-4:11, 20-24)
│   ├─2 text " and " (4:12-4:17, 25-30)
│   ├─3 emphasis[1] (4:17-4:25, 30-38)
│   │   └─0 text "italic" (4:18-4:24, 31-37)
│   └─4 text " text." (4:25-4:31, 38-44)
├─2 html "<AComponent />" (6:1-6:15, 46-60) 
├─3 paragraph[6] (8:1-14:8, 62-167)
│   ├─0 text "<With as |a|>\n" (8:1-9:1, 62-76)
│   ├─1 html "<a data-not-an-anchor>" (9:3-9:25, 78-100)
│   ├─2 text "\n<:block>\nblock content here\n</:block>\n" (9:25-13:1, 100-153)
│   ├─3 html "</a>" (13:3-13:7, 155-159)
│   ├─4 text "\n" (13:7-14:1, 159-160)
│   └─5 html "</With>" (14:1-14:8, 160-167)
└─4 code "<template>\n  {{log \"hello world\"}}\n</template>" (16:1-20:4, 169-231)
     lang: "gjs"
     meta: "live"

so I think text + html would cover it.

oh! but then I'd also need to replace / re-implement stringifying.

So instead of:

let withRehypeRaw = await unified()
        .use(remarkParse)
        .use(liveCodeExtraction, liveCodeConfig)
        .use(remarkRehype, {allowDangerousHtml: true})
        .use(rehypeRaw)
        .use(rehypeStringify)
        .process(example)

I'd have:

let withRehypeRaw = await unified() // or would I still add .use(remarkParse) ?
        .use(myCustomParse) // how do I ensure compatibility with the rest of the remark ecosystem?
        .use(liveCodeExtraction, liveCodeConfig)
        .use(myCustomStringify) // how would I expect HTML stringification, and provide stringification for my own nodes?
        .process(example)

The language I'm working with is a superset of HTML, so if there were a way to extend the language, that'd be ideal 🤔

[ChristianMurphy]

then there is MDX, which is a complicated mess

MDX is also part of the unified ecosystem.
If you have specific questions and concerns, feel free to ask them here or at https://github.com/mdx-js/mdx/discussions

MDX is a bit more complex, we've reduced some of that complexity in version 2.
But having full component support and embedded JS support is inherently a bit more complex.

This would be in place of remark-parse, I preseme?

Potentially?
Again still missing context on what your end goal is.
If you want to parse Ember content and do transformations on it directly, it would take the place of rehype in your examples.
If you want a mix of Markdown and Glimmer, essentially creating a brand new language, it would likely be a remark parser plugin/extension, and could probably use @glimmer/syntax for part of that parsing.

https://github.com/micromark/micromark#creating-a-micromark-extension introduces extending the tokenizer, which would be the first and lowest level step towards creating a Markdown and Glimmer fusion.

[NullVoxPopuli]

Potentially?
Again still missing context on what your end goal is.

Markdown + Glimmer is my end goal -- been calling it "glimdown" 😅
Made a tracking issue here: NullVoxPopuli/limber#630
And a repo from over a year ago here: https://github.com/nullvoxpopuli/glimdown
(where, if I can figure anything out, will release packages from there)

it would take the place of rehype in your examples.

this maybe sounds better? because then I could not force markdown, and maybe unified could be used on non-markdown documents as well 🤔
but maybe both would use the Glimmer parser? idk.
I suppose I should revive the glimdown repo / PR with @glimmer/syntax, and see where I get.
Maybe @glimmer/syntax can be used here, too? https://github.com/micromark/micromark#creating-a-micromark-extension idk yet.

Thanks for your help tho <3

[wooorm]

and then there is MDX, which is […] complicated

Markdown + Glimmer is my end goal

You want to build an alternative to MDX (changing JSX for Glimmer).
You don’t understand MDX (which is understandable).
MDX is complex because the end goal it solves is incredibly complex.
What you want to do is incredibly complex.

It’s going to take you months of full time work. You’ll have to get an understanding of how MDX and the rest of unified works. And how @glimmer/syntax etc works (which seems undocumented and unstable).