First, I apologize for this TLDR; and that it’s so messy text. It’s also not real proposal or anything like that. I would just like to discuss this because it’s of great interest of mine…
I wanted to utilize [attr: ibutes]
for some specific cases extensively, especially when the Lua support is on it’s way to us. So I dug into the documentation and found out that:
Attribute syntax can contribute additional Metadata to various Objects, including:
- Pages
- Items
- Tasks
I have some questions…
What does “items” in fact mean here? The list items? I assigned some attributes to a paragraph and failed to iterate them in template/query (if you know how to, show me, please). But it worked for list items. So, this is quite confusing. I would assume that attributes would belong to the document node they are within. If somewhere inside a paragraph, then it should belong to the paragraph. If inside an emphasized text inside some paragraph, then it should belong there. So, I think the “items” means “list items” exclusively, or something similar. This should be clarified in the documentation, because it is not clear what “items” mean there.
Second question is somewhat related. Attributes can contain arrays, like [foo: [1, 2, 3]]
. But if I do: [foo: 1] [foo: 2] and [foo: 3]
there is just the last value 3
of the foo
attribute present (perhaps I did wrong, again, please tell me how to iterate correctly). I guess it’s because it just got overwritten, right? Will [foo: [1]]
[foo: [2]]
and [foo: [3]]
work? Will that result in the [foo: [1,2,3]]
? (This came to my mind right now when writing this, I had no chance to test that, sorry.).
All this seems to me very counter-intuitive and non-ergonomical. I do not want to remember where some rule applies and there should also be no need to (although I certainly can, it’s not a good UX). Once given attributes (and tags), I would like to assign attributes (or tags) to anything I like to. It feels very natural to me to collect some values in an attribute while, for example, writing some long text with many many paragraphs etc. Therefor this second question is somewhat connected with the first one.
From my point of view, I would like SB let us assign attributes anywhere, or at least also to paragraphs, quotes and other “container”/block objects (header, paragraph, quotation, table row/cell, list, list item) where it can be clearly “contained”. Attributes (as well as tags, of course) should have also parent field to get content of object they reside in. The queried parents should expose children fields accessible to the scripts as well. It would be nice to have the possibility to list attributes (or tags) filtered with specific criterior and then to construct, e.g., a page with all close surroundings up/down to any level rendered using some live scripting on the data (template, query, LUA, plug, …).
There are some edge cases too, the objects like images (etc.), horizontal line, and fenced code blocks… There is no issue with embedding attribute inside **bold [a: 1] text**
but it is unclear which of the two whitespaces is actually the attribute separator and which is not, i.e. how to do indexing here, but it is certainly undoable for code
inline blocks, for obvious reason. There is also no problem in placing an attribute inside a paragraph but it’s bad idea to try to place it inside fenced code block. In all the described edge cases the solution may be to let attach the attributes (and tags) in some special way.
For vertical containers, such as the fenced code block, if the attribute (or tag) would be right before or after the object, it would belong to it, e.g.,
[a: 1]
```sh
for i in 1 2 3; do echo $i; done
```
[b: foo] [c: bar]
The same rules would apply to any inlined object:
Some paragraph with **bold text**[a:foo] and [a: 123]`code`[b: bar][c: quux]
Notice, that there is no white space between the attribute and the object as well as between the attributes (and the same would apply to tags as well). Much nicer would be if we could group them in single one like [b: bar, c: quux]
(much clearer and feel quite intuitively… at least to me.
There is one last edge case I can imagine. If an attribute (or a tag) is placed in separated paragraph consisting of only the attributes (and tags) it would belong to the page section (divided by h1-6
). (Not really sure here.)
Single document can be generalized as a tree-ish structure and no matter what are the leafs kind of similar rules should apply to all of them, without any exception. Then, in the hypothetical documentation, you could say something like “Hey, here you are some attributes and tags, place them anywhere you like. Oh, and there are only two rules to follow and are indeed intuitive”. : That would be the best UX I can imagine (of course, SB is for hackers, and this approach may perhaps feel far too holistic in some way).
This was no way critique of SB in neither way. I use it on daily basis and I love it. I just wanted to share my ideas on some details and perhaps inspire some further discussion. Thanks for you patience.