Open faelys opened 10 months ago
This is the grammar in the comments in attributes.ts:
* syntax:
*
* attributes <- '{' whitespace* attribute (whitespace attribute)* whitespace* '}'
* attribute <- identifier | class | keyval
* identifier <- '#' name
* class <- '.' name
* name <- (nonspace, nonpunctuation other than ':', '_', '-')+
* keyval <- key '=' val
* key <- (ASCII_ALPHANUM | ':' | '_' | '-')+
* val <- bareval | quotedval
* bareval <- (ASCII_ALPHANUM | ':' | '_' | '-')+
* quotedval <- '"' ([^"] | '\"') '"'
I see the issue with allowing _
and -
at the beginning of a key name, given the syntactic roles of {_
and {-
. I'm open to tightening up the syntax here.
@matklad any thoughts?
Thoughts:
word{_key
is a garden path syntax which might change the meaning depending on what follows, and that's bad for humans.key
starts with _
and value ends with _
is contrived, only the first condition is enough. In particular, the following two examples parse differently: span{_key=val}
vs span{ _key=val}
._
in keys, we should make sure it actually works!_
, :
, -
in bare keys, attributes often have a hierarchical structure to them, and these chars separate parts. .
as a symbol supported in keys. Eg, TOML allows
fruit.name = "banana"
Allowing .
would conflict with the class syntax though
_
and -
also seem useful, they are sometimes used to namesapce "private" attributesI am torn about what's the best solution here. Given that we already assign special meaning to .ident
and #ident
, it seems safest to require keys and values to start with ASCII_ALPHANUM
(and then also allow .
in the middle)
Actually, did something change? I can no longer reproduce the original example on the playground.
Here's what I get
word{_key=value_}
<p>word<em>key=value</em></p>
word{_key=value}
<p>word{_key=value}</p>
So that it seems that we just never parse {_
as attribute, and { _
is required for disambiguating.
I never did check the actual behavior. Nonetheless, this is a parsing ambiguity. We should at the very least document that the emphasis interpretation takes precedence, and maybe go further and disallow _
at the beginning of keys.
As for .
inside keys, I'm open to that.
I think it's safer to disallow underscores at the start of keys, as it removes any ambiguity. I have a feeling that this will be a recurrent issue otherwise.
Does HTML allow underscores at the start of attribute names? Not that djot should be as bound to HTML as Pandoc's element types still largely are.
Hello,
I'm still discovering the syntax and trying to understand the existing parser, please let me know if I missed something.
As far as I understand, attribute keys and bare value allow
_
,:
, and-
anywhere, including in the first character of a key and the last character of the value.Therefore:
word{_key=value_}
would mean<span _key="_value">word</span>
,word{_keyvalue_}
would meanword<em>keyvalue</em>
,word<em>key=value</em>
would require something likeword{_key\=value_}
?I find it not very satisfying, that
=
having a potentially very long range, and the overall (admittedly contrieved) construct being hard to disambiguate with the brain.The samething happens with
-
instead of_
, replacingem
withdel
.Wouldn't it be simpler for both humans and parsers to forbid punctuation at the beginning of an attribute key? (Or would it break too much existing text?)