Support an easy syntax for bigger/smaller text size

[damithc]

Currently we use block quote formatting to show text in bigger size. This is an abuse of syntax. Instead, we should tweak the block quote formatting to actually look like quotes as we do have an actual use case for showing quotes in our eContent.

On the other hand, we could support an easy syntax to indicate whether to make text bigger/smaller relative to the default size. e.g. +++ ---

[acjh]

Hmm, I don't see this being abused in CS2103/T Website — didn't know there were so many quotes!
I used this regex: ^>␣ (unsubstitute ␣ with a whitespace)

Not sure about the use case here. Can we stick to headings for this?

[rachx]

I used <span style="font-size: smaller"> MarkBind </span> (and larger for the next one)

[damithc]

Hmm, I don't see this being abused in CS2103/T Website — didn't know there were so many quotes!

IIRC, the text size was adjusted later to be of normal size, and the abuse stopped :-)

Not sure about the use case here. Can we stick to headings for this?

I thought showing some text larger than normal can be used to indicate more important part of the text e.g., a paragraph that gives a high-level overview of the rest. I've seen some Web articles using that technique. The objective is if the reader is in a hurry, she can only read those bigger text parts.

I used <span style="font-size: smaller"> MarkBind </span> (and larger for the next one)

Yup, we can use that for the time being. It's more convenient if we have a shorter syntax though.

[acjh]

How about <small> (from Bootstrap) and <big> (define as font-size: larger in markbind.css)?

[damithc]

Sure. is something like this possible? <small> <smaller> <large> <larger>

[acjh]

You can nest <big> and <small>:

<big><big>tutorial</big>tutorial</big>tutorial<small>tutorial<small>tutorial</small></small>

[damithc]

Nice. In that case, should they be bigger and smaller, which gives the sense of cumulative effect?

[acjh]

<small> is a standard HTML5 element though.

[damithc]

OK, we'll go with that then.

[damithc]

I'm OK with <big> and <small>. However, <big> is deprecated in HTML5. Should we add a replacement tag?

[damithc]

Removing good first issue tag temporarily as the issue is still under discussion.

[yamgent]

Sure. is something like this possible? <small> <smaller> <large> <larger>

Since CSS's font-size property also uses values such as small and large, we can use <large> and <small>,

[Chng-Zhi-Xuan]

We can add easily support for <large> tags via markbind.css.

large {
  font-weight: 400;
  font-size: 125%;
}

To simplify the syntax, we can either use markdown-It-regex which is already imported, or markdown-it-container.

Suggestion:

• Reserve ++ for placing <large> tags (Remove from underline).
• Reserve -- for placing <small> tags.
• Reserve __ for underline text (Remove from bold + italics)
• Use combination of ** and _ for bold + italics (supported natively)

New syntax:
++Larger text++
--smaller text--
__underline text__
**_bold and italic_**, _**bold and italic**_, ***bold and italics***

[Chng-Zhi-Xuan]

Note that adopting the suggested syntax will disobey the rules defined within commonMark spec.

So far I could only find Discord to break semantics to support underline text.

We might want to break semantics to support underline as it is a common document style. Discussions on underline text can be found here:

• Feature Request: underline text
• Revisting Underline & Healthcare Documents

[damithc]

Unfortunately, I guess we want to preserve compatibility with Markdown syntax.

[ang-zeyu]

How about switching over to $$...$$ for underline text? This is a big deprecation though, so we could aim to support both $$...$$ and ++...++ for underline text till v3.0.

After that, we can adopt the syntax for large / small text suggested above #28 (comment)

++...++ -> large text
--...-- -> small text

[damithc]

How about switching over to $$...$$ for underline text? This is a big deprecation though, so we could aim to support both $$...$$ and ++...++ for underline text till v3.0.

Yes, that is possible.

Will there be any issue because ------- is also used for horizontal lines?

Perhaps we can also support ++++text++++ (i.e., even larger) similar to ****text****?

[ang-zeyu]

Will there be any issue because ------- is also used for horizontal lines?

unlikely, similar to how you can use **...** for bold text but also *** for horizontal lines.

Perhaps we can also support ++++text++++ (i.e., even larger) similar to ****text****?

yes that's possible as well.

Let's go with that then; Also this can be implemented as an independent npm package outside of markbind, there seems to be quite a bit of demand for such a plugin

[fsancho]

Can $$ be in conflict with LATEX notation for math?

[ang-zeyu]

thanks for highlighting this @fsancho

I believe it may conflict with external scripts, but we're providing our own using bracket notations \[...\] \(...\) with this package, which should reduce the need for that.

[fsancho]

Thanks for replying so fast!
It's true that we can use [...] (...) with TeX packages (and indeed, they are more desirable than $$..$$), but there is not direct way to transform a "classic" doc using $$..$$ and $..$ into a new one with these delimiters, and maybe this fact may impair the use of MarkBind for already formatted content.

[ang-zeyu]

Fair point, hmm...

I suggested $$...$$ originally as we've really almost run out of good delimiters for our text styles unfortunately =\

The alternatives I could think of were # & ! @ which don't seem to connote the same 'squiggly' underline feel.

One potential fix is to expose these delimiters to user configuration for such use cases.
Or we could also shift to !!...!! which at least connotes some semantic value for underlining (in this case 'drawing attention to').

any thoughts as well? @damithc

[damithc]

Or we could also shift to !!...!! which at least connotes some semantic value for underlining (in this case 'drawing attention to').

any thoughts as well? @damithc

I'm OK with that notation too.

[wxwxwxwx9]

@ang-zeyu How should we approach this? Should we make the PR for the !!...!! underline syntax change or leave it for now?

[ang-zeyu]

ok, let's go with !!...!! then, if there's no objections.

Thanks for taking a look at this again @wxwxwxwx9

Since $$..$$ is already out there in 2.8, let's do 2 prs, one

• against the hotfix branch, to add a new rule for !!...!!, and deprecate $$...$$ (also warnings) similarly to ++...++
• against the main unreleased branch, a straightforward change of $$...$$ to !!...!!

[fsancho]

Thanks a lot for taking into consideration my comment/needs! I really apreciate your wonderful work with MarkBind!

[ang-zeyu]

No problem. Thanks for the input as well! 😃