Replies: 7 comments 1 reply
-
I like Propositions 3 and 4. I agree that it would be nice to fill these gaps, and this would seem a natural way to fill them. Perhaps submit these as separate issues so we can track them better? I am sympathetic to Proposition 1, but I'm on the fence. I agree that it's a presentational matter, but I like being able to toggle this presentational feature without using an ugly attribute. I'd be curious how many people would miss the tight/loose distinction. It's true that implementing it properly is a mess. Re Proposition 2: the djot syntax description says:
Your proposal is almost the same, if I understand it correctly; it just omits the "or between blocks inside an item." Correct? Then the point of the change is to free the parser of the task of tracking those inner blank lines? I like the idea, I think. @matklad comments welcome |
Beta Was this translation helpful? Give feedback.
-
By the way, I'm also writing a new parser -- a fast one in Haskell using the new |
Beta Was this translation helpful? Give feedback.
-
It also omits the part about blank lines before and after an inner list. Instead embedded lists are considered as any other block element, making the syntax more homogeneous. So the point is both parser simplification by not tracking inner blank lines, and syntax independence by not making blank lines meaningful inside the list item (e.g. before embedded block elements) have a secondary impact on tightness. For example:
Admittedly, having two paragraphs inside a tight list item is a bit weird to map into the
That sounds interesting, I don't know Haskell at all, I might have a look at it when it's done. Thanks for the heads-up! |
Beta Was this translation helpful? Give feedback.
-
You mean "Blank lines at the start or end of a list do not count against tightness."? This is just necessary to say because all inner lists must have preceding blank lines. It doesn't require the parser to track anything. [EDIT: Well, I guess it does require the parser to distinguish between inner blank lines between (other) blocks and those that start or end a list.] I think this
is probably the reason I didn't go for the simpler rule you suggest. In an HTML renderer, which essentially strips p tags around paragraphs in a tight list, the first list would appear in a browser as
You could say, "well, it's the author's fault; they should have put in a blank line." I'm somewhat sympathetic to that. |
Beta Was this translation helpful? Give feedback.
-
That's exactly what I would say, especially in the light of the following examples:
So I feel that the homogeneity between all block-constructions (i.e. making all examples above as tight as each other), the fixing of many expressive blindspots, the syntax simplification, and the parser simplification, together are worth more than the author wanting a loose list and missing a well-placed blank line (especially with the syntax simplification of having tightness directly linked only to lines between items, lowering significantly the cognitive overhead of parsing source in one's head). And maybe the HTML renderer could add hard breaks between paragraphs of tight list items, to preserve the source layout while enforcing the tightness. That being said, my second choice would be favoring the author missing the blank line before the link item, the visual tightness in the source, the homogeneity between all block-constructions, the syntax simplification, and the parser simplification, at the cost of more expressive blindspots, by considering as tight only lists which do not contain a blank line (thereby preventing any tight list from containing a list). I would be more comfortable with this solution than the current situation. |
Beta Was this translation helpful? Give feedback.
-
The most salient consideration for me is that I think >99% of markdown users don’t realize that the tight/loose distinction exists at all. To me, this points strongly towards removal of tight/loose distinction. Another consideration is that seems to be really HTML-specific, as it really is about just li/p, and not some more general tightness. At the same time, I don’t think “it’s presentation” is a good argument for removal — djot source code resembles rendered output, so in this sense the feature is natural. But, really, I don’t think this is about presentation at all — presentation is about css, but here the difference is the actual HTML structure. I think my preferred solution would be:
(I do think we should have some built-in way to omit p in the HTML renderer, as usually that creates too much spacing. While this can be fixed with clever CSS, I think “looks nice out of the box” is sufficiently important feature to add a work-around, even if it is something inelegant, like a heuristic in the renderer) attributes on list items obviously feel good! |
Beta Was this translation helpful? Give feedback.
-
I'm not sure how we could know this. And supposing it's true, why would it move us to remove the distinction in djot? I think we need to focus on whether the distinction is a useful one, and whether its value justifies the extra complexity.
Pandoc can produce tight lists in LaTeX, too; it's just a matter of adjusting list spacing in the renderer, though it's not built into the standard LaTeX macros. An interesting comparison is reStructuredText, which doesn't seem to have the distinction. rst2html.py produces a list without p tags when none of the list items contain multiple paragraphs. So this does create a tight/loose distinction in the output, but solely based on the content, without giving the writer a say. (Actually, this seems to be identical with the proposal you go on to make.) I'm leaning towards just getting rid of the distinction, but it would be nice to hear other views. |
Beta Was this translation helpful? Give feedback.
-
Hello,
I'm coming to the list part of my parser, and I had sort-of hoped that you had neatly solved the tight/loose mess from markdown, just like the other syntax elements, but this time I was a bit disappointed.
I've read #201 and #138 and I mostly agree with the sentiment there that tight/loose distinction could be removed from djot altogether. That's my Proposition 1, and the rationale is that being tight or loose is not a semantic distinction, it's rather like being blue or sans serif: a presentational element that should be left to the render, maybe hinted by an attribute (assuming that the renderer can be more acceptably be English-bound than djot itself).
To be fair, being left-aligned or right-aligned is also presentational and not semantic at all, and indeed djot doesn't have such syntax elements in regular text, but their usefulness in table outweigh the abstraction leakage.
Edited to add: with the Proposition 1 and settling on the current "loose" syntax, i.e. forcing a blank line between list item, would also help a lot with compositional uniformity (rationale goal 7 and an existing ticket I can't find anymore) and parser simplicity, at the cost of a worse-looking source for simple lists (which are probably the majority of lists).
So assuming my Proposition 1 is not acceptable, e.g. because tight/loose distinction is relevant to some use cases I haven't encountered yet, I've been trying to find a way to keep it while reducing the abstraction leakage and keeping as much djot neatness as possible.
As far as I can tell, the semantics of tightness is to make the whole list feel like a single block, while looseness is making each list item it's own sub-block, like a paragraph in a section.
This feeling can be readily rendered in the source through blank lines between list items: a canonical tight list would have no blank line between list items, while a canonical loose list would have a blank line between each list item.
Proposition 2: the presence or absence of a blank-line before each list-item except the first one determines whether the list is tight or loose. When this is not consistent within a list, I'm open to decaying to tight, or decaying to loose, or splitting into several consistent lists, or being renderer-defined.
This is motivated by the following facts:
The only drawback I can see with this proposition is that lists with a single item are ambiguous, which makes sense since the concept of tightness and looseness is meaningless with a single element. However, I have the feeling that tightness and looseness (in markdown) are actually a kludge to let people choose having a
p
in theirli
s or not, and that is relevant to single-element lists too.To help with this and a few other situations, here is my Proposition 3: allow attributes for each list item, independently from the list attributes, with the usual syntax between the marker punctuation and the following whitespace, like this:
This would cover all cases of attribute-based
p
-in-li
, and I'd say people thinking aboutp
-in-li
really should do that in the render and leave djot of it.This is getting really tangential, but while I'm here, I'm submitting Proposition 4 to similarly allow attributes for table cells, using the usual syntax right after the preceding
|
, and for table rows using the usual syntax after the last|
(I guess before the first|
would work as well, but I'm afraid of syntax ambiguities and of visually-displeasing tables).Together the Propositions 3 and 4 would fill the gaps I found between the current djot and the rationale goal 9 of having attributes for all containers.
Beta Was this translation helpful? Give feedback.
All reactions