引用块与callout在带标题下的写法习惯

第一组投票 (非callout语法的引用块写法)

问题如上图,欢迎根据你自己平时的写作习惯或倾向进行投票,若混合使用可多选并给出场景

  • 方案一:单独引用标题
  • 方案二:传统引用
  • 方案三:卡片式引用

之前放闲聊区,完全没人投票QAQ。搬过来疑问区,这边感觉多人逛点 [doge],并将标题修改成疑问类(其实也没毛病,调研不知道的东西,也算得上一种疑问hhhh)等投票的多了,再移回闲聊或经验分享区

标题V1 :【投票】引用块用法习惯

标题V2:大佬们,引用块应该使用哪种写法习惯好啊?标题应该放引用块里还是外面啊?

过了一周时间了,还是没啥人参与……给个统计结果、在后续层中给个结论,然后转回经验分享区吧

标题V3:引用块与callout在带标题下的写法习惯

2 个赞

2. 第二组投票 (callout语法的引用块写法)

前面是通用引用块的投票

此外还有在使用callout的前提下的用法习惯投票:

方案一:ob callout 卡片式:

方案二:通用 callout 卡片式:

在github和vueprss等博客平台上,[!note] 后面不能接标题。否则:

图片

(并且感觉后续大概率不会添加这个特性。考量是在其他平台上这种语法不叫callout,而是叫alert块。即标准是只允许强调块的 “笔记”、“警告”、“错误” 属性,而开放自由标题可能会导致管理混乱。毕竟md的特点就是样式统一和语法少)

这种更适合没有标题的情况,如果有标题的话,要么这样:

方案三:通用 callout + 外标题

要么这样:

1 个赞

上面一共有两组投票

  • 第一组是无callout的用法习惯,三个选项
  • 第二组是有callout的用法习惯,也是三个选项

欢迎投票。两组都要投,例如:无callout情况下选择方案几,有callout的情况下选择方案几

1 个赞

第一种+1

从来不用tab引用,callout只在需要整段引用的时候用,因为实时预览下编辑需要多点一下

发贴目的

有很多:

  1. 插件开发我后续可能用得上
    (主要是我设计的是多软件平台的通用语法,不能只考虑ob,这就导致了要想的繁琐了很多)
  2. 跨平台的语法统一,主要是想知道这方面有没有什么标准,其实每种我都看有人用,并且根据不同平台倾向不同
    (不过软件平台导致写法差异的例子其实也很多,例如我以前用ty经常写嵌套,在ob里的嵌套有点烂就少写了很多)

投票统计

这层楼会持续更新投票情况:(包括Q群内的投票,现在是20240911-21:50)

  • 无callout语法组
    • 头部 >:0.3(ob人基本不用,但这个主要是很多在线博客在用)
    • 传统引用:3.3
    • 卡片式:1.3
  • 有callout语法组
    • ob callout 标题:5.5
    • 通用 callout 内标题/外标题:1.5 (ob人基本不用,几乎只有有发布博客需求的才会有意选择)

其中:

  • 为什么两组的总数不同,因为老有人只投了callout的用法,另一个不投……当弃权了。但其实我主要目的要的是第一组的投票,第二组其实没什么悬念,需要考虑兼容性的人太少了
  • 为什么有0.5人?表示不太确定……感觉某方面A语法会更好,但又感觉在某个方面B语法会更好,即要又要的情况。或者视具体情况而定的都用的

一个结构的问题

无callout组的方案三,明明最贴近于callout组的方案一,这两者的结构是一样的 —— 都是将标题放于引用块的首行。但是前者却很少人使用(原因有可能是标题和内容无区分度,当然也可以将标题进行加粗等,但也有些别扭)

但事实上,很多人的用法却趋近于:有callout的情况下用callout组方案一,无callout的情况下无callout组的方案二。而这两者一个将标题放于引用块的首行,一个将标题放于引用块外的前一行,按理来说是两种不同的结构。

这种结构的不一致性,是正常的吗?还是应该消除。通用的alert语法 (通用版的callout块一般应该称为alert块,在其他平台是这样的) 其实并没有导致这种结构的不一致性的产生,是ob对首行进行了允许标题的扩展导致了这一问题。优点显而易见,这种写法非常便捷,缺点在于修改了原有的结构 (虽说普通用户怎么方便怎么来,也不考虑这个)

感觉你说的方案一是选第二组的方案一,烦请大佬给第一组也投个票,第一组的投票其实才是目的。

其实也不太算标题欺诈吧,参见上一层楼,疑虑确实是存在的。

这里额外给一些没什么人气的投票选项找点补

无callout组的方案一,仅头部引用方案

博客多见,其实这个我也用过,特别是很久之前我还在用有道笔记时

无callout组的方案一,仅头部引用方案(嵌套heading版)

我现在也有用,不过我现在的用法是作为一种 “伪标题” 来用(非合法用法),例如这样:

> #### 伪标题/藏标题

这种写法可以拥有标题的样式,并且能让标题不置于大纲列表中。

我们知道,通常如果你不想让标题显示在大纲列表中:

  1. 要么全局设置大纲的最大显示级别
  2. 要么局部在文章的元数据中写上最大的可用标题level(发布博客通常用这种方案)
  3. 要么就是像我这种写一种 “伪标题”。不仅引用块,列表块其实也可以用这种方式 (好处是灵活,缺点是引用块包标题在ob的实时模式下无法完全适配 (就这个特殊情况不正常。列表包标题正常,ob阅读模式正常,typora中正常))

这也算是一种我折腾的无callout组方案一的衍生用法

有callout组的方案二、三

这个感觉几乎不会有人选的了,主要是没几个考虑平台情况下的callout支持

图片

不过感觉哪怕知道了兼容性的这个问题,可能也会选方案一,毕竟callout语法的支持:

  1. 完全不支持 (例如这个论坛)
  2. 支持alert语法 (github、使用 markdown-it-alert 的博客平台)
  3. 支持callout语法 (obsidian、使用 markdown-it-obsidian-callout 的博客平台、一些ob人魔改的博客系统,如pkmer、nolebase)

如果真有人考虑兼容性,可能会更倾向于彻底的做法是完全不用callout语法了……

启发与语法设计 —— 智能callout

(暂无短时间开发计划,只是设计)

以下判断为 [!note] 块,触发条件为代码块前一行以 :__:_ 结尾

这是一个知识点: 

> a
> b

警告/异常:在前面的基础上,固定引用块前一行为某些关键字:(或者将冒号改成感叹号)

警告/异常: 

> xxxx

以下判断为 [!quote] 块,触发为引用块头尾的引号,或仅头部的引号

鲁迅曾说过: 

> "...
> ..."

或尾行以 —— 开头(不建议,破坏结构的一致性)

> ...
> ...
> —— 鲁迅

以下判断为 [!question],触发为引用块上一行的末尾为 ?_

这是一个问题X? 

> 这是回答Y

优缺点

  • 优点
    • 比callout入侵式语法还少
    • 触发相对可控,引用块前一行的结尾为半角符号+双空格 / 全角符号+单空格(建议冒号感叹号问号)
    • 环境不支持插件时,美观性有保证
  • 缺点
    • 语法情景上来说,其实语法是更多的,虽然一般不需要去记,是智能判断的
    • 在纯文本环境下,标识弱是优点,但这个标识有点过于弱,很难看出来可能也不是什么好事

开发、结构

在尝试为传统引用块(非callout)添加 ”标题“ 这一过程中,我反复地思考应该像 callout 语法那种将标题放在里面,还是根据更多人的习惯那样放在外面?最终选定了后者,并且其实后者是也更符合AnyBlock的用法的。

做这个之前有个前提操作:

AnyBlock 后面计划可以在不使用 [xxx] 语法的情况下智能触发,将触发情况分两种:

  1. 主动触发,显式声明语句。此时会自动选择范围并自动渲染
  2. 隐式触发,引式声明语句/智能判断为这可能是一个AnyBlock块。此时并不会选择范围并自动渲染(节省资源和性能+避免误触)。泛是隐式声明的都会在可能的头部加一个不怎么显眼的按钮,你去按了那个按钮才会去渲染当前那一个局部块。

然后这章设计的语法,其实就属于引用块的智能选择中的一个语法设计