第一组投票 (非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只在需要整段引用的时候用,因为实时预览下编辑需要多点一下
发贴目的
有很多:
- 插件开发我后续可能用得上
(主要是我设计的是多软件平台的通用语法,不能只考虑ob,这就导致了要想的繁琐了很多)
- 跨平台的语法统一,主要是想知道这方面有没有什么标准,其实每种我都看有人用,并且根据不同平台倾向不同
(不过软件平台导致写法差异的例子其实也很多,例如我以前用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版)
我现在也有用,不过我现在的用法是作为一种 “伪标题” 来用(非合法用法),例如这样:
> #### 伪标题/藏标题
这种写法可以拥有标题的样式,并且能让标题不置于大纲列表中。
我们知道,通常如果你不想让标题显示在大纲列表中:
- 要么全局设置大纲的最大显示级别
- 要么局部在文章的元数据中写上最大的可用标题level(发布博客通常用这种方案)
- 要么就是像我这种写一种 “伪标题”。不仅引用块,列表块其实也可以用这种方式 (好处是灵活,缺点是引用块包标题在ob的实时模式下无法完全适配 (就这个特殊情况不正常。列表包标题正常,ob阅读模式正常,typora中正常))
这也算是一种我折腾的无callout组方案一的衍生用法
有callout组的方案二、三
这个感觉几乎不会有人选的了,主要是没几个考虑平台情况下的callout支持
不过感觉哪怕知道了兼容性的这个问题,可能也会选方案一,毕竟callout语法的支持:
- 完全不支持 (例如这个论坛)
- 支持alert语法 (github、使用 markdown-it-alert 的博客平台)
- 支持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]
语法的情况下智能触发,将触发情况分两种:
- 主动触发,显式声明语句。此时会自动选择范围并自动渲染
- 隐式触发,引式声明语句/智能判断为这可能是一个AnyBlock块。此时并不会选择范围并自动渲染(节省资源和性能+避免误触)。泛是隐式声明的都会在可能的头部加一个不怎么显眼的按钮,你去按了那个按钮才会去渲染当前那一个局部块。
然后这章设计的语法,其实就属于引用块的智能选择中的一个语法设计