Standardize choice of <box> types in documentation

[ang-zeyu]

Please confirm that you have searched existing issues in the repo

Yes, I have searched the existing issues

Any related issues?

No response

What is the area that this feature belongs to?

No response

Is your feature request related to a problem? Please describe.

The documentation uses all sorts of <box type=...s currently, making for an inconsistent reading experience.

Describe the solution you'd like

Standardize all the <box type=...s to something. Purely imo, seamless looks the best https://github.com/MarkBind/markbind/pull/1019.

Or, think of a consistent way or guideline to use these different types of alerts in our documentation, and document it clearly in the dev guide.

Describe alternatives you've considered

No response

Additional context

No response

[yucheng11122017]

Hi @ang-zeyu can I check that by "alert" you mean the boxes in the documentation such as the image below?

[ang-zeyu]

Yes, sorry, "boxes" would be more accurate. "alerts" is the bootstrap version.

[yucheng11122017]

Hi @ang-zeyu, is this ok for the standardization?

1. <box type="warning" seamless>: When the lack of this knowledge will likely cause problems for users Eg.

<box type="warning" header="#### Using production build" seamless>
In production build, Vue does not perform hydration check. Any errors resulting from hydration will trigger full CSR without warning. MarkBind **uses the development build by default** when you serve it in development mode (`-d` option).
</box>

2. <box type="tip" seamless>:Good advice for users which will make things easier for them Eg.

<box type="tip" id="markbind-action-tip">

MarkBind provides a helper GitHub Action that you can use to simplify your workflow file. A sample workflow file utilizing the action is as follows:
```yml
name: Deploy MarkBind Site
on:
  push:
    branches: master

jobs: 
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Build & Deploy MarkBind site
        uses: MarkBind/markbind-action@v2
        with:
          token: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
```
Read the [action documentation](https://github.com/MarkBind/markbind-action#readme) to understand the various configuration options.
</box> 

3. <box type="info" seamless>: Other additional information

Eg.

<box type="info" seamless>

Note that `Layout` instances do not generate any output files directly, but rather, they store intermediate processing results to be used in a `Page`.
</box>

[damithc]

Definitely should standardize. Might still want to use different styles for different situations (e.g., some styles are more eye catching than others, and hence suitable for more critical information). So, the standards can be one style that we use by default and a few exceptions in which we use another style. Yes, should document the standard it i.e., which style for which situations

[yucheng11122017]

In that case, since seamless makes the box less obvious (since the box is no longer colored)

1. <box type="warning" />: When the lack of this knowledge will likely cause problems for users
2. <box type="tip" />: Advice that is generally useful Eg. The baseDate follows the format: YYYY-MM-DD
3. <box type="tip" seamless />: Useful advice that is more applicable to specific scenarios Eg. Additional delimiters are possible by enabling the [mathDelimiters](https://markbind.org/userGuide/usingPlugins.html#plugin-mathdelimiters) plugin.
4. <box type="info" />: Additional information
5. <box type="info" seamless />: Additional information that applicable to more specific scenarios or cases

Is this ok? @damithc

[damithc]

@yucheng11122017 Perhaps for all the output boxes we can use the MarkBind brand color. That is,

For all other boxes, we can use seamless:

I wish we can change the info color slightly though, to differentiate it from our brand color.

For really important warnings we can use:

Anyway, this is just one scheme. One needs to apply it to see how it looks. Might not turn out as nice as I see it in my mind now :-p You can try a few different schemes and get inputs from others to see which looks good to most people.