Text Formatting Extensions #12
Conversation
Zomatree
changed the title
| {STYLE BRACE}(CONTENT BRACE) | ||
| ``` | ||
|
|
||
| The STYLE BRACE contains the formatting options, which are separated by semicolons. The formatting options are key-value pairs, with the key and value separated by a colon. The key is the name of the formatting option, and the value is the value of the formatting option. The key is **case-insensitive**, and the value is **case-sensitive**. The key and value are separated by a colon, and the key-value pairs are separated by semicolons. The key is not allowed to contain any characters other than letters and the spe |
There was a problem hiding this comment.
and the spe,
mistake here i assume
|
|
||
| # Security concerns | ||
|
|
||
| As this RFC does not introduce any new security concerns, there are no security concerns to be addressed. |
There was a problem hiding this comment.
Only thing is that (at least web) clients should be careful not to use the colour field verbatim, as it could point to an arbitrary URL (in that case of gradient rendering => it uses background to achieve this).
| STYLE_BRACE ::= "{" STYLE_PAIR "}" | ||
| STYLE_PAIR ::= STYLE_PAIR ";" STYLE_PAIR | STYLE_PAIR | ||
| STYLE_PAIR ::= KEY ":" VALUE | ||
| KEY ::= [a-zA-Z]+ |
There was a problem hiding this comment.
Should this allow dashes? One of the examples has a dash, i-do-not: exist.
| ```bnf | ||
| STYLE_BRACE ::= "{" STYLE_PAIR "}" | ||
| STYLE_PAIR ::= STYLE_PAIR ";" STYLE_PAIR | STYLE_PAIR | ||
| STYLE_PAIR ::= KEY ":" VALUE | ||
| KEY ::= [a-zA-Z]+ | ||
| VALUE ::= [^;]+ | ||
| ``` |
There was a problem hiding this comment.
This doesn't seem to account for the whitespaces here?
{color: red; font: monospace; background: yellow}(red)
^ ^
My current regex looks like this:
/\{([a-zA-Z]+):([^;]+?)(?:;([a-zA-Z]+):([^;]+?))*\}\(/gBased off the spec, but this doesn't match string provided.
For example, one could do:
/\{([a-zA-Z]+):([^;]+?)(?:;\s*([a-zA-Z]+):([^;]+?))*\}\(/gi.e. add any whitespace after ;
|
|
||
| ```markdown | ||
| {} // invalid; the key-value pair is empty and thus redundant | ||
| {color: red; color: blue} // invalid; the key is repeated |
There was a problem hiding this comment.
Parsing code for clients would probably be simpler if we just allowed repetition?
I am working on a PoC remark plugin and I could detect and throw an error and catch it and whatever, or... I could just override the key I already wrote earlier. Makes for cleaner code for this edge case.
3 participants
No description provided.