In recent years I have been thinking a lot more about tools vs. conventions. Once upon a time, the ubiquitous means of transferring arbitrary data structures was XML. It was a perfectly fine...
In recent years I have been thinking a lot more about tools vs. conventions.
Once upon a time, the ubiquitous means of transferring arbitrary data structures was XML. It was a perfectly fine standard; a bit verbose, but you could do so much interesting things with them. It was an important early web technology with many interesting add-ons like DTDs and XSL-T.
But it absolutely sucked to write out. And so the web decided to go with the barely-a-standard JSON instead. Nowadays there are many projects that think that even that is too hard and we have things like YAML. And I was all for it because it was easy to adopt those conventions.
And then a short while ago I learned that XML wasn’t something you were supposed to write. It was something that was supposed to be written for you with tools. Looking into enterprise Java applications, I could see there were plenty of tools to deal with exporting and importing XML data; doing so was very commonplace and there were parts of Java that were dedicated specifically to making the creation of those tools as easy as possible.
Looking at document markup languages makes me wonder about the tools versus conventions idea again. We already have a ton of very mature tools for writing HTML - the usual endpoint of these markup languages. Not only do you have the ability to write directly in HTML markup very quickly with tools built into most code editors, but you also have the ability to use a multitude of WYSIWYG editors and avoid actually needing to touch any code.
But of course if you’re trying to have multiple endpoints, or in some cases if HTML doesn’t work for you, that is when new conventions make sense. Documentation in code makes more sense because of this.
Both tools and conventions have their own sets of strengths and limitations. Tools are rigid in what they can do for you, and conventions force you to do things in particular manners. That’s what got me down this train of thought, in a way; Djot would not exist if the conventions of other text markup systems made sense for the people who work on it. Heck, that’s part of why there are so many different variations of markdown to begin with.
… Well, I don’t think I said anything productive here. Goodnight everyone.
I gotta agree with random quoted guy, sublist newlines make this project dead to me. Weird design decision — I wonder what they did that for.
Exactly, the sublist newline stuff is a total nonstarter for me. Sorry, I guess I’ll run a markdown parser that takes an extra second or whatever to run.
I gotta agree with random quoted guy, sublist newlines make this project dead to me. Weird design decision — I wonder what they did that for.
You don't even need hard-wrapping to want a blank line preceding lists. Your editor can soft-wrap a piece of text to look like the above example and now it looks all ambiguous if you don't require...
You don't even need hard-wrapping to want a blank line preceding lists. Your editor can soft-wrap a piece of text to look like the above example and now it looks all ambiguous if you don't require a blank line to precede a list. In general, I feel that block-level elements should be preceded by a blank line, with the exception of list items (which are even occasionally used as span-level elements in old-timey texts!)
My beef is probably with the tight/loose list distinction, where I don't see how you can specify whether a list with a single list item should be tight or loose. My first thought is that list items should be tight by default unless they contain multiple paragraphs or block-level elements, in which case that item is necessarily loose.
In recent years I have been thinking a lot more about tools vs. conventions.
Once upon a time, the ubiquitous means of transferring arbitrary data structures was XML. It was a perfectly fine standard; a bit verbose, but you could do so much interesting things with them. It was an important early web technology with many interesting add-ons like DTDs and XSL-T.
But it absolutely sucked to write out. And so the web decided to go with the barely-a-standard JSON instead. Nowadays there are many projects that think that even that is too hard and we have things like YAML. And I was all for it because it was easy to adopt those conventions.
And then a short while ago I learned that XML wasn’t something you were supposed to write. It was something that was supposed to be written for you with tools. Looking into enterprise Java applications, I could see there were plenty of tools to deal with exporting and importing XML data; doing so was very commonplace and there were parts of Java that were dedicated specifically to making the creation of those tools as easy as possible.
Looking at document markup languages makes me wonder about the tools versus conventions idea again. We already have a ton of very mature tools for writing HTML - the usual endpoint of these markup languages. Not only do you have the ability to write directly in HTML markup very quickly with tools built into most code editors, but you also have the ability to use a multitude of WYSIWYG editors and avoid actually needing to touch any code.
But of course if you’re trying to have multiple endpoints, or in some cases if HTML doesn’t work for you, that is when new conventions make sense. Documentation in code makes more sense because of this.
Both tools and conventions have their own sets of strengths and limitations. Tools are rigid in what they can do for you, and conventions force you to do things in particular manners. That’s what got me down this train of thought, in a way; Djot would not exist if the conventions of other text markup systems made sense for the people who work on it. Heck, that’s part of why there are so many different variations of markdown to begin with.
… Well, I don’t think I said anything productive here. Goodnight everyone.
I gotta agree with random quoted guy, sublist newlines make this project dead to me. Weird design decision — I wonder what they did that for.
What kind of editor is this guy using for this to be an issue? I struggle to think of what environment this is an issue for.
You don't even need hard-wrapping to want a blank line preceding lists. Your editor can soft-wrap a piece of text to look like the above example and now it looks all ambiguous if you don't require a blank line to precede a list. In general, I feel that block-level elements should be preceded by a blank line, with the exception of list items (which are even occasionally used as span-level elements in old-timey texts!)
My beef is probably with the tight/loose list distinction, where I don't see how you can specify whether a list with a single list item should be tight or loose. My first thought is that list items should be tight by default unless they contain multiple paragraphs or block-level elements, in which case that item is necessarily loose.