Textile was the driving markup behind Textpattern (https://textpattern.com/), one of the better publishing/CMS tools out there on PHP. It had a nice object oriented approach that was less painful than Wordpress, and gave great flexibility to design aspects in ways that were easier to work with than Wordpress... but Wordpress won the popular marketshare, and TP was relegated to some diehards. Those diehards still pump out fixes and features, and it's worth a look at https://github.com/textpattern/textpattern/ if you want to see something a bit different.
Oh no, I think I may qualify as a diehard now. Or at least a long time diehard user of a diehard CMS. xD Funny to see that word.
I still use TXP at [1] and others. Back in the day when I didn't know how to code, and yet too much reliance on Joomla and WordPress plugins was often disastrous (one of those small plugin vendors sold customer data to a very specific type of telemarketing firm, as a funny example), TXP tags absolutely saved the day. You could use them to write web apps with CRUD interfaces, with the help of the admin theme being utterly simple to style away using CSS.
You could create a new section within seconds, an instant /whatever endpoint with a blank textarea where you could place any content type or any code you wanted.
For example the smd_xml plugin (thanks Stef) where you could write e.g. <tag query="SQL query here" wraptag="p">{title}</tag> to show a quick list of favorite book titles from the DB or whatever content you wanted really. Combine that with another tag for getting GET and POST variables and voila, a lot was possible without leaving the admin interface.
Toward the end of my business-oriented TXP days, I was running a network of food and drink distribution & marketing websites which spoke to each other on the back end, hosted a sales material database (labels, product shots, PDFs) along with custom PDF creation tools for salespeople which drew on that database. All without learning to do web coding...and when I was ready to code I was _really_ ready because I had already made some minor fixes to plugins, which were editable via the admin panel directly.
(Did I mention that you install plugins by copying and pasting a plain text bundle into the admin? This clipboard install method is pretty amusing and easy on the brain)
To this day I enjoy using TXP. It's very lightweight, it has a learning curve, but it works great for blogging and lots of other things. Textile and Markdown both live comfortably in the same mind and it's nice to be able to work with both.
I meant more broadly, the header level number should be derived from its nesting level without you specifying it explicitly. This gives you more freedom to re-arrange (refactor?) the text without having to mass-edit header levels.
This is what annoys me the most when developing web components. You never know which context your component might be used in, and your <hX> element might be just plain wrong.
I prefer not using them and fall back to using <header> elements inside sections, but styling them globally makes it rather difficult and ugly to work with. What's other people's solution to this? Or am I just picky when it comes to semantics?
If it's super broken or critical, maybe a slot to let the user provide their desired header level would be an option? Or maybe even a simple prop would be enough. If your component is itself header-like, perhaps making 6 versions, fun-header-1, fun-header-2, etc. that are explicitly scoped to that level header would make sense too.
You could define a recursion depth parameter for your component. Or a specific header level parameter. I tend to think of spitting out HTML as something with recursive context. The CSS grid and even flex layouts come to mind as well.
Specifically, this is the document outline algorithm. But it’s not so much “not always implemented properly” as “not implemented at all”. No user agent has implemented it or seems likely to, and I don’t know of anything other than conformance checkers that implements it. https://github.com/whatwg/html/issues/83 shows a bit of the discussion that’s gone on; whether to remove it, simplify it drastically to the point that it’s actually sanely implementable, &c.
Yes, this has also been something I've missed from mostly all markup languages, but the renderer also has to make a distinction between paragraphs inside and outside of a section. To better illustrate:
@section {
@title: This is my section title
Text, paragraph, etc.
@section {
@title: Subsection Title
Text, text, text.
}
More text that belongs to the parent section. But how will the reader know that? Indentation? Blocks with background color maybe?
}
No that is how the system works today. I would like, and have always wanted a way to disambiguate without creating a new title. There should be some sort of visual indicator that we are going up to the parent level without creating a sibling to the parent.
title: ships
p: ships travel on water
p: they are like cars but on water
title: motors
p: ships have motors
p: spin around
p: very powerful
p: ships can be used for many things
title: fishing
p: fish are in water, so the incentives are super-aligned
I've been hacking now and then on a document preprocessor that uses a similar syntax, e.g. this code
@Section[name=quickstart]{@Title{Quickstart}
@P{ The official documentation is very sparse, but as a quickstart here is what you need to do: }
@List{
@Item{Create a fullscreen window to render into}
@Item{Initialize the library with @FuncRef{S3DTK_InitLib}.}
@Item{Create a renderer with @FuncRef{S3DTK_CreateRenderer}.}
@Item{Create an IDirectDraw instance - DirectDraw is mainly used to manage video memory.}
@Item{Setup exclusive and fullscreen cooperative level and set the video mode to 640x480x16bpp or whatever.}
@Item{Obtain the base of the framebuffer (see below) to use for calculating surface offsets.}
@Item{Create a primary surface with a secondary buffer attached to it to act as a swap chain.}
@Item{Create two @TypeRef{TS3DTK_SURFACE} variables to hold info about the surfaces. S3D actually needs very little info about a surface: its size, pixel/texel format and the offset in video memory from the framebuffer. This bit is the trickiest one.}
@Item{Optionally create a 16bit surface to hold a z buffer - again you need to do this via DirectDraw and @TypeRef{TS3DTK_SURFACE}.}
}
@P{ And that is about it. Beyond that it is mainly setting state and drawing triangles. In terms of memory management, S3D relies on DirectDraw to do the video memory allocation/etc so in general the process is allocating a DirectDraw surface and filling a @TypeRef{TS3DTK_SURFACE} variable with info about it. The S3D API itself does not actually know about DirectDraw, it is only used indirectly to obtain the memory offsets and to perform surface flipping. In theory it might be possible to allocate a big surface and chop it to smaller pieces with multiple @TypeRef{TS3DTK_SURFACE}s. }
produces the list at the top of [0]. The main difference in the syntax is that instead of "@title: blah" you type "@title{blah}" because "blah" is just the content for the "title" node and the parser doesn't treat any nodes in a special way, it just creates a tree and then passes it to a script for doing whatever it wants to do (to produce the linked HTML document it is passed to a script that generates HTML in a variety of formats - e.g. single file, multiple files, using HTML5 elements or sticking to "basic" HTML that works in a bunch of primitive viewers, etc).
The "Section" node above uses "P" but strictly speaking it isn't necessary as any text after the } will create text nodes for the parent node (in this case the "Section" node). I did it this way mainly for consistency, but a script could just use the node's own text (which is basically what nodes like "FuncRef", "TypeRef", etc are doing).
(i do not have any releases for the processor yet since i'm still -slowly- tweaking it as i -very slowly- write various documents using it)
Not really since i'm still tweaking it. The base processor is mostly done (though i also add some minor stuff here and there) but the scripts are incomplete. Of course one can use their own scripts instead, but i want to have a default set that works for most manual-style uses.
The way I see it, Markdown is great for outputting simple text and readily used for that reason in the Wordpress blog space. Once you start needing more complex styling and formatting then i'd go for either Latex or HTML, both feature rich markup languages.
I use markdown for my everyday notes right now, and love it. The syntax is simple, fast to type either on mobile or desktop and pretty easy to read. Looking over the tag based syntax of Textile i'm not sure i'd have as easy a time using it for fast output... and if i'm wanting more style and moving to tags, I might as well use HTML... so what's the use case?
May I introduce Texti (Markup Language) - Text with Instructions (.texti) - Structured Documents in Text with Formatting Conventions - that tries to offer the best of all worlds - that is - markdown / textile / mediawiki markup/down / latex and more. See https://texti.github.io PS: An "important" building block missing in markdown / textile is built-in templates a la mediawiki markup/down. Lets you add "macros" for images or figures and so on (and much more). Extension and evolution is key - as always - and wins out in the long run.
FYI: New ideas first presented are always very confusing. Let it sink in. Note: The page is public - thus, if I may return the favor - change the confusing private to public in your sentence (or is that "knee jerk private commentary?").
PS: Let me add more context - The top-linked Textile Markup Language is a documentation website. Textile markup/down is history and FAILED - thus - the next step is what can we learn from the fail - what are the good, bad and ugly parts? what was missing and so on. Now how do you "fix" textile (or markdown)?
For more context let me add / point out the side-by-side samples (texti vs markdown vs latex vs wikipedia markup), see https://github.com/texti/texti.github.io/tree/master/samples using the Wikipedia article on markup as an real-world sample.
a) awesome. b) please increase the default font size of that doc. c) please consider moving the exposition to the end and just jump into the good stuff about how it works and what's different. Perhaps a short intro like "Texti is modern markup. Think Markdown and Wikimedia markup had a baby. Here's how to do all the things..."
Thanks. Note this text is not a commercial or ad. My philosophy is function over form wins. Period. Comments and critique always welcome. If I may return the favor - do NOT use the word modern - as in say 5 or 10 years - that may read different. Do NOT upcase markdown - it is today a generic term / word. The had a baby "idea" is stupid. The idea is about evolution and adding AND yes, deleting and forever changing and so on. Anyways, here's the source (w/ public domain - no rights reserved dedication) - https://raw.githubusercontent.com/texti/texti.github.io/mast... you are more than welcome to publish your own teaser / promo / analysis / opinion.
Bit of a non sequitur but my first job was at an industrial embroidery company (did T-Shirts, hats, etc for big companies... sewed logos on thousands of shirts a day).
I was kind of hoping based on the name it would be for that. That industry is woefully lacking good open source and DIY tools for telling the machines what to sew.
But back on topic: I'm not sure what in this language would encourage me to move off of markdown at this point. It seems nice but the friction to use yet another markdown language (even if this one is older by 2 years it seems) is high.
I adopted this years ago for writing app “help” content, for roughly the same reasons Markdown was invented (e.g. it was annoying to have to mark up almost every word in text that was largely plain content, and the ability to drop in HTML as needed was super convenient). Although .md files “won”, I still use .textile today.
Every time I look at markdown flavors I come up with this question: Why not latex? Granted, I rarely need markdown or latex so this might be just my ignorance.
I've tried doing my CV and some presentations in markdown cause I just didn't want to put the time to learn latex. I went markdown -> html -> pdf. I just couldn't get something satisfactory. The pains: pagination, centering, columns, image positioning, colors.
And then I took a day to learn enough latex - https://latex-beamer.com/quick-start/ - to create a presentation for work. It was a lot easier than I thought and it came out looking great. Here is the skeleton of it so you can judge how complex it is:
Markdown simply isn't meant for that kind of content.
The idea of markdown, is that you end up with a text that is readable by itself, and renderable in more simple graphical environments.
No one should ever ask themselves "how do I do image positioning" or "how do I add pagination" when dealing with markdown. That's just not what it's good for.
Imagine having to write comments on HN using LaTeX.
> Markdown simply isn't meant for that kind of content. The idea of markdown, is that you end up with a text that is readable by itself, and renderable in more simple graphical environments.
Also renderable safely and in bounded time (TeX is turing complete).
> No one should ever ask themselves "how do I do image positioning" or "how do I add pagination" when dealing with markdown. That's just not what it's good for.
Meh. This is a common question for table extensions, and the full-blown image commonmark spec is a bit of a mess.
> Imagine having to write comments on HN using LaTeX.
That would be an improvement over the current state of affairs at least, though probably a tad overdone on the other side of proper complexity.
Latex is way harder to master than markdown. While it offers also way more features, it mixes (to a certain degree) semantic information with styling information. And at least to me Latex code looks just ugly.
And have you ever tried to write complex tables with Latex? A nightmare!
The best approach to write structured documents in a non-WYSIWYG way is AsciiDoc. You get a clean separation between content with its semantics and styling and you have a all the features you need for the biggest technical or scientific books.
I had a textdrive account and used textile for my sites back in 2002 or 2003. I don't think markdown was around then. Textile was easy to work with at the time. I took the trouble to learn LaTeX in 2008 or 2009. I like it a lot, and I switched my resume/CV over to it. It's work, but you can get such nice results.
Why not Rmarkdown [0], in which you can also write LaTeX code, and if you want presentation with beamer, you just have to change a single line, so you could generate beamer presentation, html, pdf and doc from the same file. I don't even use RStudio, I just have a keybind in vim [1].
Why not latex? Why not the best of both worlds? Anyways, see latext and markdown compared - https://github.com/mundimark/markdown-vs-latex In evolution simpler wins. The beauty of the paragraph syntax is an empty line, for example! And yeah for sure - the image syntax in markdown is a big FAIL and there are easier alternatives upcoming (out there waiting for the big time) - see https://texti.github.io - and image and figure "macros" - that is - built-in templates, for example.
Next time I have to update my CV, I'm gonna use Inkscape. I'm done with trying to trick various markup languages into placing text where I want it on the page.
I'd make a simple word doc to PDF version as a backup. A lot of application portals parse out the text from a word doc or PDF and look for explicit keywords, employers, etc. for a first round of automatic filtering (before it even gets to recruiter inboxes). It would not be good if your beautifully readable and typeset SVG just looks blank to the machines.
You're counting on inkscape and some unknowable backend pdf/doc processing backend to all do the right thing and preserve semantic text. There are so many places it could break and fall back to rasterizing or simple vector paths, and you'd have no way to know other than never getting an email back. Save everyone in your hiring loop the pain and make a resume with bone stock formatting, text sizes, etc. Any extra work they have to do to interpret your experience and skills is just working against you--these folks see hundreds of resumes a day and if one makes them have to stop and spend time to figure it out, it's faster to bin it.
The only thing I dislike about Textile is that it treats line breaks in the source code as <br> when it renders, which makes it annoying to edit in vim. Markdown is nicer in that one aspect. Otherwise, Textile is better (so of course it lost the popularity contest).
I’ve got bad news for you. Textile is close to 20 years old, it’s one of the “cambrian explosion” of lightweight markup languages from the early-to-mid aughts which got choked out by Markdown’s rise to prominence.
That's the only time I ever came across it, and it was always frustrating to switch between markdown and textile depending on which application/site I was using.
I don't love markdown, but I am pleased that it "won" in the sense that I can use it everywhere. There's nothing worse than having to use three+ different markup languages during the course of a day.
