-
-
Notifications
You must be signed in to change notification settings - Fork 314
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
Question about attribute names #714
Comments
Block HTML rules are a bit different, yes -- that's partly because we want to parse line-by-line, but may not have a complete tag on a line.
I honestly don't remember, but presumably we were targeting the old XML rules? |
That's a good point, and I probably should have just started with the reason I was asking. Essentially, I've been using an MDX binding for the frontend JS framework Svelte, and one useful Svelte feature is passing CSS variables to components. Using components in Svelte is just like using a tag in HTML, and passing CSS variables is like adding an attribute. It looks like so: <Component --var="val" /> Since the spec doesn't support attributes starting with I'm not too experienced with writing such bindings, so there may be a better way to go about fixing this in the binding itself. That said, after looking at this sentence in the spec,
It seems like it would make sense to support more forms of attribute names. Perhaps names starting with |
This isn’t MDX btw. This is a different language. I don’t understand what CommonMark has to do with this. You are using |
That's a great point, and yes MDsveX does have its own parser, which is built upon the unified js pipeline and incorporates |
The problem, compared to MDX, is that remark itself doesn’t understand Now, I am not sure your problems are solved by changing commonmark. I presume that there are many more changes needed. Probably changes that other people that do use commonmark but don’t use mdsvex wouldn’t agree with. There is definitely something to say for improved HTML parsing here. Though there are downsides with relaxing things as John points out above. |
From what I can tell, my specific issue is fixed by just making the small change to the spec/implementations I've noted above. I tested on MDsveX with its current
That's a good point, and I wouldn't argue for supporting 100% of the HTML spec. That would certainly take a lot of work on other people's parts because I wouldn't know where to start. This change, however, would fix an issue of mine, is quite a small addition (from what I can tell), and would reduce work on other people's parts (MDsveX, and anyone else trying to do use attributes starting with
To me, this seems to be the primary blocker for any work here being valuable. MDsveX will need to update a lot to even obtain any changes to micromark, and in doing so it could just create one of those remark plugins anyway. Thank you for your explanation on this system by the way, as I didn't grasp it completely. I guess all of this boils down to a tradeoff here, if I've even convinced you that changing the spec to support attribute names starting with To avoid dragging on this issue any further, I'll close it since my question was certainly answered. If there's reason to change the spec another issue can be opened. Thank you both for your time and advice. |
I do recommend that By the way, you could use MDX itself with svelte: https://mdxjs.com/docs/getting-started/#jsx. I still don’t really grasp your root problem so I am not sure how to best help you with what you want. Adding this change, I am personally in favor of improving alignment of HTML in markdown here (see e.g., #713). But I think that should be disconnected from custom markdown flavors and be solely focussed on improving HTML support while not breaking folks. |
From the spec, an attribute name must start with an ASCII letter,
_
, or:
.The way this is implemented can lead to different results in parsing (as far as I can tell, though I may be wrong). Take two
p
tags with invalid attributes named--foo
, one inline and one as a block:Inline: https://spec.commonmark.org/dingus/?text=inline%3A%20%3Cp%20--q%3D%22hi%22%20%2F%3E
Block: https://spec.commonmark.org/dingus/?text=%3Cp%20--q%3D%22hi%22%20%2F%3E
The inline example parses as text, presumably(?) because the attribute name isn't valid. The block example, on the other hand, parses as an HTML block with the attribute intact.
Regardless of all this, I was just wondering why attribute names can only start with those specific characters.
The text was updated successfully, but these errors were encountered: