Mustache Div / Span syntax discussion from Gitter

[calculuschild]

Just copying over some discussion on the Div / Span syntax to keep track of it:

Trevor Buckner @calculuschild Jan 15 23:00
Why haven't we considered ; as a separator?

I don't know. I might be coming around to that idea. It does look a little more "cluttered" than just a comma or |, but it also somewhat matches the syntax for normal HTML inline styles, and might clear up confusion for the inline styling which already needs a comma. Also removes the need for quotes... What does everyone think? I can code this up to play with and see what it feels like.

{{.class1;.class2;#id3;font-family=times,georgia;margin=10px 5px content}}

Trevor Buckner @calculuschild Jan 15 23:09
Ooh, except... spaces are still a problem. that margin=10px 5px would need another semicolon after to distinguish from the content. Do we then enforce a semicolon after each statement?
{{.class1; content}} doesn't look too bad, but I kind of liked just {{.class1 content}}. Maybe it's more clear having a divider like that though.
Any proposals? Even if we don't support inline styling from the start, I want to include it in our specifications so we have the flexibility to add it later in a way that makes sense.

Gazook89 @Gazook89 Jan 15 23:11
I think it is more clear to have a divider from content
I thought it was weird when i was playing with it that it wasn't clear where my class name ended and where content started...However, in the same vain, i think pipes | are better
Or, a pipe only used to divide classes and content
so {{.class1; .class2; #id1 | here is content}}
This would allow spaces not only within inline styles, but also for more clear formatting (notice I added a space after each semi-colon) which makes it easier to read.

Trevor Buckner @calculuschild Jan 15 23:16
So side-by-side comparison:
{{.class1,.class2,#id3,font-family="times,georgia",margin="10px 5px" content}} -- current

{{.class1;.class2;#id3;font-family=times,georgia;margin=10px 5px; content}} -- semicolons, with ; divider

{{.class1|.class2|#id3|font-family=times,georgia|margin=10px 5px| content}} -- pipes, with | divider

{{.class1; .class2; #id3; font-family=times, georgia; margin=10px 5px | content}} -- semicolons, with | divider
Yeah... having freedom to put whitespace in there might make it more legible...

Gazook89 @Gazook89 Jan 15 23:18
But do pipes cause issues with tables inside blocks......?
Maybe not, if only counting the first pipe as part of the block syntax....and any further pipes being read as part of tables

Trevor Buckner @calculuschild Jan 15 23:19
I don't think they would... but it would be good to check. The pipe would only show up in an inline span, and you can't put a table on one line.
If we use the pipe as a divider and semicolons as the delimiter
I think tables also don't appear if they have any other (non-space) characters before the first pipe anyway

Gazook89 @Gazook89 Jan 15 23:21
ah okay...and yeah, i think they require the |--| part too

Trevor Buckner @calculuschild Jan 15 23:22
Right

Gazook89 @Gazook89 Jan 15 23:27

### here is a note Here is some text

{{.note; .wide; font-family:comic sans;

here is a note

Here is some text
}}
So this is what a DIV will look like?
(with the previous regular HTML shown as comparison)
or are no changes being made to non-inline styling?

Trevor Buckner @calculuschild Jan 15 23:28
that or something close to that.

Gazook89 @Gazook89 Jan 15 23:30
k. I think if the inline & block styling can be as similar as possible, that'd make things easier. So in my example above, even including a pipe at the end of the first line (of the second example).
The only difference is one is literally just one line, and the other is multi-line.

Trevor Buckner @calculuschild Jan 15 23:31
Yes I would like spans and divs to have the same syntax, but the div maybe just doesn't need the | at the end. This looks a little weird to me with the pipe just hanging out:
{{.note; .wide; font-family:comic sans |

here is a note

Here is some text
}}
We could allow it, but just not require it, since you can't have content on that line with a div anway.

Gazook89 @Gazook89 Jan 15 23:34
We could allow it, but just not require it, since you can't have content on that line with a div anway.

Yeah, i like this option

Trevor Buckner @calculuschild Jan 15 23:37
Ok. Let's see if we can get some consensus on this from the others, and then I'll code that up. In the mean time we can keep building up snippets using the current syntax and then replace it later.

Trevor Buckner @calculuschild Jan 15 23:47
Hm... So what do you think about this. On the homepage, they have this nice footnote div:

PART 1 | FANCINESS

. We can currently make this into an inline span that works just fine: {{footnote PART 1 | FANCINESS}} and that looks ok (especially with the code hilighting), but notice the pipe in there. It starts to get confusing when we do this: {{.footnote | PART 1 | FANCINESS}}. I guess we would want that "divider" pipeline to also be highlighted...?

Gazook89 @Gazook89 Jan 15 23:50
yeah I don't think it's really THAT confusing, but it could be...if possible to give the divider a color, we could. Maybe the same color as the brackets.
To indicate that the divider is a structural component of the DIV or SPAN.

Trevor Buckner @calculuschild Jan 15 23:51

Does that look legible?
Without the highlight it was weirding me out.

Gazook89 @Gazook89 Jan 15 23:52
Yeah, highlight it. I still don't think it looks GREAT, but i think using pipes is an edge case for most people (even if it's used on every page)
especially if it's being generated by a snippet.

Trevor Buckner @calculuschild Jan 15 23:53
Yeah. There's always going to be some character that will conflict...

Trevor Buckner @calculuschild Jan 16 00:01
Gah. I still like the previous look though. It's just so clean without needing a divider... :/

vs this

Ok, I'm gonna sleep on this. We'll see if anyone else has a thought.

Gazook89 @Gazook89 Jan 16 00:17
This probably gets too cluttery, but maybe a background Highlight that stretches from opening brackets to pipe. Like a real light red.
In fact, maybe a similar light background that goes from style tag to style tag. Green.

Eric Scheid @ericscheid_twitter Jan 16 01:22
Wait .. {{.class | .foo | #bar }” .. is foo a class? is bar an id?
Or are they parts of the content, like in a footnote?
Also, what happens when a table cell contains {{ .. | .. }} of some form? How do we guard against marked.js seeing that as a divider?

Eric Scheid @ericscheid_twitter Jan 16 01:28
{{div-or-span-attributes{content}}} ??

Trevor Buckner @calculuschild Jan 16 01:44
@Gazook89 Possible background highlighting of span/div

what happens when a table cell contains {{ .. | .. }} of some form?
This is a good point. It would probably confuse the Table Markdown.
{{.class | .foo | #bar }}

Yeah... If we allow spaces like this, then any property/content divider would probably need to be a different character than the property delimiter. If we don't have a property/content divider, then we rely on spaces like the current build does, which means we need " (or something like more curly brackets as you did above) for the inline styles. Tradeoffs.

Trevor Buckner @calculuschild Jan 16 01:51
Yeah, even something like {{.class1 | margin=10px 5px | content}} becomes ambigious, because we can't tell if "margin=10px 5px" is meant to be part of the properties or the content.

Eric Scheid @ericscheid_twitter Jan 16 02:54
We could generalise by requiring any | in the content be escaped | .. though that’s obnoxious (plus tables exist)

Gazook89 @Gazook89 Jan 16 10:30
Why doesnt {{.class1; .class2; #id3; font-family=times, georgia; margin=10px 5px | content}} -- semicolons, with | divider
Work? The different characters for property separators and property/content separator wont have those issues right?

Trevor Buckner @calculuschild Jan 16 14:11
@Gazook89 eric pointed out that | would not play well if used inside a table. If you wanted to color a word in a table cell the table would think you are starting a new cell.
So the general idea I think is fine, but we might need a different character that isn't already used by Markdown.

Gazook89 @Gazook89 Jan 16 15:28
I don't know enough about programming to know, but is it possible to ignore the first pipe inside brackets?

Trevor Buckner @calculuschild Jan 16 16:33
Not in the way our Markdown parser works. All of the "container" elements (blockquotes, tables, code blocks, etc.) are identified and processed, and then any internal styles on the internal text are processed (italics, bold, etc.). By the time the contents of table cells are ready to process, all of the | will already have been consumed as part of the outer table container.
Let's see... what other alternative characters could we use. A plain colon :? Or \ / ! > ~ ( ) +
Something that won't be used as part of inline styling either.
{{.footnote; #p1 : PART 1 | FANCINESS}}
{{.footnote; #p1 \ PART 1 | FANCINESS}}
{{.footnote; #p1 ~ PART 1 | FANCINESS}}
{{.footnote; #p1 ! PART 1 | FANCINESS}}

Trevor Buckner @calculuschild Jan 16 16:40
Just ... two spaces?
{{.footnote; margin=10px 5px　PART 1 | FANCINESS}}

Gazook89 @Gazook89 Jan 16 16:41
pretty sure ~ is strikethrough
well, strikethrough is

Trevor Buckner @calculuschild Jan 16 16:42
Hm. It's more awkward to type too.

Gazook89 @Gazook89 Jan 16 16:42
forward and black slashes are I think too commonly used, and would be weird, imho. the only one I kind of like is !
I don't love exclamation point, but it's similar in visuals to a pipe, and is memorable.

Trevor Buckner @calculuschild Jan 16 16:43
Underscore?
{{.footnote; #p1 _ PART 1 | FANCINESS}}

Gazook89 @Gazook89 Jan 16 16:43
I don't think underscore serves well as a divider, since it's not vertical
][
but that would be a pain to write maybe
and likely would get screwy with hyperlinks.

Trevor Buckner @calculuschild Jan 16 16:45
hm.

What about just two spaces? And we can highlight the background so it's clear.

Gazook89 @Gazook89 Jan 16 16:54
I personally don't like just using spaces. I'm happy to adopt whatever option (especially since a. I'm not programming it and b. I don't actually use Homebrewery for anything) but sometimes it's frustrating to figure out what the heck is going on with spaces as-is....example being adding 2 spaces at the end of a line to add or remove paragraphs
It's easier to communicate code to others if we aren't counting spaces, too.

Trevor Buckner @calculuschild Jan 16 16:56

Or a tab

Trevor Buckner @calculuschild Jan 16 17:01
Well, you do like to fiddle with the custom styling a lot, so I think you have valuable input. I personally kind of like just double-space though... I think if the code editor highlights automatically as you type it would handle some of the confusion.

Gazook89 @Gazook89 Jan 16 17:02
if going with double spaces, maybe try to make the highlight a tiny bit darker.

Gazook89 @Gazook89 Jan 16 17:19

Made a new frame...realizing only now that it looks like...erm...male...parts
something something freud.

Trevor Buckner @calculuschild Jan 16 17:25
Even got some hair on there and an "eye". Very nice.

Gazook89 @Gazook89 Jan 16 18:31
Would it be a good idea to include this little bit into the general stylesheet?
.phb p:empty {
display:none;
}
empty paragraph tags are usually unwanted and annoying

Trevor Buckner @calculuschild Jan 16 18:34
Sure. But we should also try to hunt down the source of empty paragraphs.

Gazook89 @Gazook89 Jan 16 18:38
I notice them when doing divs. Line breaks before or after div tags make a difference

Trevor Buckner @calculuschild Jan 16 19:47
Is this just on the new Divs or does it show up on old ones too?

Gazook89 @Gazook89 Jan 16 19:47
legacy

Trevor Buckner @calculuschild Jan 16 19:53
Ok. I did notice the empty paragraphs showing up in v3 as well but I thought I had figured out a way to prevent those, so v3 is hopefully past that problem.

Alexey Sachkov @AlexeySachkov Jan 17 01:59
I personally kind of like just double-space though... I think if the code editor highlights automatically as you type it would handle some of the confusion.

The highlighting should be really good and visible - otherwise it could be really hard to spot the error. Also, what about colorblind people? I don't know how many of them are using the Homebrewery and what types of colorblindness they have, but such trick with two spaces (they are basically invisible unless you look really intently) and highlighting can be a pain for them

{{.footnote; #p1 : PART 1 | FANCINESS}}

Personally, I like this option

It is like "description of the content: content"

Eric Scheid @ericscheid_twitter Jan 17 03:47
Does a double-space-at-line-end survive the markdown conversion though?

Gazook89 @Gazook89 Jan 17 09:38
I think color blindness will still show the highlight, just as a different color or as a grey.
And double space at the end of a line isn’t necessary if doing a block div. The double space separator is only needed for inline spans (if that’s the route we go for a separator)

Eric Scheid @ericscheid_twitter Jan 17 09:43
using : means style rules need writing as {{ thing=value.

Also, whatever we use we’ll need to ignore escaped separators.

(I’m still of the opinion that including style rules is an unnecessary complication .. but do keep bashing away at it)

Trevor Buckner @calculuschild Jan 18 00:18
Man... I just keep going back and forth on this. I have the double-space option working, but the semicolons in addition to the periods for classes... It starts looking so cluttered in my eyes, even with spaces added in. The original style just looked so... clean. After playing with this for a bit I almost want to go back to:

1. No period for classes
2. Commas as delimiters
3. No spaces allowed
4. Quotes for the inline-style (commas and spaces allowed in here)

I'm thinking not just the cleanliness, but also, which is going to be easiest to pick up for a non-code person?

I was able to get both of these work:

But for whatever reason, the top one looks easier to read to me (Italics aside).
Especially on shorter Spans. I prefer the top to the bottom of these:

Trevor Buckner @calculuschild Jan 18 00:26
Just thinking... I want to permit the maximum amount of functionality, with minimum syntax complexity. After sitting and thinking on it, I just don't like the need to have so many separate symbols going on. All we need is # for an ID, and ="style" for inline, and commas. No "separator" symbol, and no need for the "class" ., because a class won't have quotes.

Eric Scheid @ericscheid_twitter Jan 18 00:27
Yup, so much cleaner. And custom styles can always be applied via targeting a custom class or id.
A class won’t have quotes, commas, or spaces. technically also should have colons or other selector syntax characters. Should allow unicode. Should allow \ escapes.

Trevor Buckner @calculuschild Jan 18 00:30
It's so easy to talk about all these cool potential syntaxes but it wasn't until I actually implemented it and played around that I realized it was just too cluttered and complicated. I can do everything I want with less "debris", which also meshes better with the Markdown philosophy that the code should still look like text, not code, as much as possible.

Eric Scheid @ericscheid_twitter Jan 18 00:30
Anyone using \ escapes to form funky class names containing awkward characters should be soundly whipped though.
👍

Trevor Buckner @calculuschild Jan 18 00:32
colons or other selector syntax characters

What do you mean?

Eric Scheid @ericscheid_twitter Jan 18 00:36
a class name of foo: is technically valid ..
in html it is

, but in CSS you have to write .foo: {...} .. so css can distinguish from .foo:meta-selector {...}

Trevor Buckner @calculuschild Jan 18 00:37
Ok I gotcha.

Eric Scheid @ericscheid_twitter Jan 18 00:38
(though .. we only talking about style-attribute names, not class selectors .. i.e. what goes into style=“...”)
^property names

Trevor Buckner @calculuschild Jan 18 00:40
So I think the style="inside" has only style=[a-zA-Z@] and inside=[\s\w],
As far as existing CSS properties go https://www.w3schools.com/cssref/
But I can allow the weird characters for peoples custom class names

Eric Scheid @ericscheid_twitter Jan 18 02:08
a-zA-Z-@ - i.e. property name can include -

Trevor Buckner @calculuschild Jan 18 02:59
Ok, uploaded a new version of the {{ syntax. Please fiddle around with it and try to break it.
https://homebrewery-stage.herokuapp.com/edit/BaQUxOzQG9ZW
https://homebrewery-stage.herokuapp.com/share/AFsL463ZnoQi
https://homebrewery-stage.herokuapp.com/source/AFsL463ZnoQi
Not fully supporting all characters yet, but this should give you a good idea of how it works. I'm fairly happy with this result.
Also fixed highlighting on nested spans.

Trevor Buckner @calculuschild Jan 18 03:06
I think this is in a good spot where I can leave it alone and work on filling in the rest of the snippets. @Gazook89 if you want to take a crack at any more let me know. I've got your Monster Blocks and I'll paste those in next.

Eric Scheid @ericscheid_twitter Jan 18 03:16
FOO {{ bar }} QAZ produces ..

FOO

.
Was expecting

FOO bar QAZ

FOO {{ bar }} QAZ
FOO {{ bar }} QAZ
produces

FOO TIK TOK

Eric Scheid @ericscheid_twitter Jan 18 03:22
So the regex isn't tolerant of a missing class/id for the block.
Note also the missing terminating " in the first class attribute, and the =" embedded in the second class attribute

Eric Scheid @ericscheid_twitter Jan 18 03:48
Børk: {{class,#id,cl\ASS wut?}} → <div class="block class cl" id="id" style="" "="">\ASS wut?}}

What's up with that style attribute even existing?? And that trailing bit of "=""??

Trevor Buckner @calculuschild Jan 18 08:51
Good job breaking stuff lol. I will fix these.

Trevor Buckner @calculuschild Jan 18 14:17
@ericscheid_twitter I fixed the issues with "FOO {{ bar }} QAZ" and other blocks that have no tags at all. (Which at least no longer "eats content" if it doesn't recognize the character like the emojis)
What behavior would you expect from {{class,#id,cl\ASS wut?}} ?

Eric Scheid @ericscheid_twitter Jan 18 18:27
The \ should act as an escape and should be stripped from the html.
cl\ASS → <div class=“clASS”
cl: → <div class=“cl:”
cl, → <div class=“cl,”

The latter will be extra tricky.

In the CSS that the user will write to target those classes they’d need to escape them there too. Which serves them right for being idiots.

I’d be happy not supporting \ in terms of doing something smart or useful [but would want to not break rendering horribly like eating content or spewing weird attributes]

Eric Scheid @ericscheid_twitter Jan 19 01:48

Eric Scheid @ericscheid_twitter Jan 19 01:57

Eric Scheid @ericscheid_twitter Jan 19 02:15
I'm looking at function processStyleTags on lines 169:178, and I'm not seeing why that shouldn't work.
Nevermind .. that function never gets to see the unicode text because lines 27:29 are stricter regex:
const blockRegex = /^ {{(?:[\w,#-]|="[\w, ]")$|^ }}$/gm;
const inlineFullRegex = /{{[^\n]}}/g;
const inlineRegex = /{{(?:[\w,#-]|="[\w, ]")\s|}}/g;
i.e. the code breaks at the first unexpected character.
\w is [a-zA-Z0-9], right?

Eric Scheid @ericscheid_twitter Jan 19 02:20
I'll meditate on what the flipped regex would look like (ie. blacklist, not whitelist)

Trevor Buckner @calculuschild Jan 19 09:09
Not fully supporting all characters yet, but this should give you a good idea of how it works.

As I mentioned earlier, I haven't added in the support for other unicode characters yet (I was just trying to get the general syntax to work), so don't be surprised these aren't functioning. The blacklist shouldn't be too tricky though. For starters we need [^"\s'] but if you think of others I can add them to the list.

\w is [a-zA-Z0-9_].

Trevor Buckner @calculuschild Jan 19 23:39
There is a bug on the Marked.js for backslashes currently, so getting escapes to work is going to have to wait. It divides the string at the \ into two separate text tokens, so the {{ parser only sees one half of {{cl\ASS}} at a time. This is also something that can't really be worked around on our end since it's fairly deep in the marked pipeline before it is exposed to us. I submitted a bug report to them and might provide a PR because I'm pretty sure I know where the error is.
Blacklist is set up now just using [^"\s'] for now. Had to rearrange the regex a bit to make it work but all your emoji things seem fine now @ericscheid_twitter

Eric Scheid @ericscheid_twitter Jan 19 23:50
Neat. Will check =)