Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#13 2016-03-16 13:31:10

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,058
Website

Re: Markup language flavours

Bloke – ship it! Lots of pretty, logical simplifications on markdown. I prefer the @ for inline code though. That is more visible.


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#14 2016-03-16 13:33:33

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Markup language flavours

Destry wrote #298312:

Textup[T↑] — would be one better

Awesome!

Please create hr(.class)

Okay. I’d planned on horizontal rules being done like Markdown, but an hr analog makes sense too.

Please create dl(.class)

In the list above.

Please create a table of contents mark; e.g., toc(.n)

Interesting. I did read on one of the markup systems that it had ToC support. Should be pretty easy to build as it just has to collect together all heading elements while parsing and then spit them out in place of the toc tag. Not sure how to specify the levels though, as your example contravenes the class dot rule. Ideas welcome.

Don’t lose footnotes. ;)

No chance! Both fixed- and auto-numbered footnotes are brilliant.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#15 2016-03-16 13:42:07

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Markup language flavours

phiw13 wrote #298313:

I prefer the @ for inline code though. That is more visible.

Yes it is. It may be possible to support both backtick and @. Probably won’t impact the regexes for inline email references and language refs inside parentheses.

Dunno yet, this is all just “in my head” stuff right now. Hoping Ruud might join me in implementing it since his regex and optimisation knowledge is off the charts awesome.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#16 2016-03-16 13:57:31

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: Markup language flavours

Bloke wrote #298314:

I’d planned on horizontal rules being done like Markdown, but an hr analog makes sense too.

Ah. That’s cool. As long as a class can be applied, I don’t really mind either way. I’d like to be able to manipulate the crap out of an hr without having to use a different semantic element for the purpose. I’m a big proponent of gradient lines and asterisms, for example.

But beyond myself, I think there’s an argument for consistency and ease of learning for those who already understand something about HTML.

That type of audience, in fact, might be how you want to approach thinking of this. It would be the right audience, IMO; people who have a modest understand of the basic types of HTML 1.0 elements.

Everyone else can just use Markdown. ;)

Offline

#17 2016-03-16 14:37:04

sacripant
Plugin Author
From: Rhône — France
Registered: 2008-06-01
Posts: 479
Website

Re: Markup language flavours

Bloke wrote #298301:

Regarding the Hacker News quote. Yes, precisely. But it goes beyond that. Who wants to write content full stop these days? How many times has someone approached you and said, “Can you make me a website?” to which you reply: “Sure, where’s your content?” to which the reply is “We’ll worry about that later, just show me a design. Here’s some Lorem Ipsum for the time being.” Noooooooo!

+1000
I have the same feeling

Typically: you start project with Markdown, you provide a manual to writers and after 1 month or 1 year you are inundated by issues :

  • “How to make a float picture in right, or left ?”
  • “How to add a responsive Youtube player” ?
  • “How to add footnotes” ?
  • etc.

And after you try to implement requirements with some custom fields and/or smd-macros, etc, your documentation gets too complicated and users are lost.
Basic Markdown is very cool for writing simple article, simple blog. But he is too limited in the reality of the needs of our clients.
I’m happy that Textpattern now support Markdown via a plugin. I can propose if project is compatible.

If Txp has the ambition to become a cms and not only a flexible blogging platform, I think textpattern should impose nothing but offer all solutions.

Textup

Yeah! Good idea and good luck for this project. It’s a Textpattern aside project and can be adopted by other projects. And if you want that other langages make a compiler : write directly a specification.
But please, can you first, spend the time you have to release Txp 4.6? :)

Offline

#18 2016-03-16 15:12:07

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Markup language flavours

Textup would be great, even it seems to be a Txp aside project which should be adopt by others as said above.
Also, could I suggest you to add a <cite> tag?

Last edited by NicolasGraph (2016-03-16 15:36:28)


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

#19 2016-03-16 16:05:38

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: Markup language flavours

Textup ;) is a side project, yes, but it’s an exciting and worthwhile one that could be used as marketing to give Textpattern TREMENDOUS exposure. Huge exposure! Like when an earthquake rolls through the city.

Count me in on working on the docs, spec, whatever…

Oh, Bloke, big one…. if you can figure something out for figures and figcaptions in relation, that would be something. An impossible challenge, I’m sure.

But maybe the scope on this one is just Txp, for the time being. So the assumption for use in this case is that an image is uploaded and the caption field has content. The alt field is conditional. For example:

For existing image with caption field content only (no alt) where “n” is image ID number…

fig(.foo /n)

Outputs:

<figure class="foo"><img src="path/to/n.tld" alt="">
<figcaption>field output</figcaption></figure>

And if alt field also has content, then by some hidden conditional magic the output is:

<figure class="foo"><img src="path/to/n.tld" alt="field output">
<figcaption>field output</figcaption></figure>

And I suppose if you needed more than one class, as I usually do with figures, then…

fig(.foo bar /n) 

With an output:

<figure class="foo bar"><img src="path/to/n.tld" alt="field output">
<figcaption>field output</figcaption></figure>

Yes, betting on the Euro lottery. ;)

Offline

#20 2016-03-16 16:08:48

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Markup language flavours

sacripant wrote #298318:

can you first, spend the time you have to release Txp 4.6? :)

Yes, Sir! Textup is just a Google-style skunkworks project that I jotted down on the back of beermat the other day. Got a way to go before it even gets near code.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#21 2016-03-16 16:24:50

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Markup language flavours

Destry wrote #298322:

Textup ;)

I edited everyone’s posts :-)

Count me in on working on the docs, spec, whatever…

Brilliant, thanks.

if you can figure something out for figures and figcaptions in relation, that would be something.

Yeah, that’d be grand. You’ll note in the loose spec above that image is noted as “tbd”. That’s because all image notations thus far have left me cold. Inspiration required. Anyone?

maybe the scope on this one is just Txp

‘zackly. Now this is where the extensibility comes in. Your basic Textup image might do what you suggest, using image URLs like Textile and Markdown do now.

But what if Textpattern as a project (or a benevolent plugin) embeds Textup as a filter? Now, said plugin / core knows that the filter is part of Textpattern and thus has access to a wealth of content, a-priori, such as image IDs, alt text and stuff in the database. So it could define a new tag fig() exactly as you suggest to be added to Textup’s internals. That could read the ID and associated metadata from the database for the given image ID and populate the output. Job done. Like smd_macros at a markup-language level.

Textpattern as a project might decide that the base image implementation in Textup needs bolstering instead to do captions. I’m not saying this is the best way, but it could just redefine the image tag as above. Might cause a bit of confusion, so we’d need some way to also update docs that might be embedded in the core, but that’s detail.

Or maybe it’s best to keep core tag implementation static, for sanity’s sake, and only allow new tags to be added (or existing ones extended, with a new name). Details, details.

I can’t see any impediment to implementing a callback system inside the Textup parser to permit tag extensions. It’s just code, right?! Hopefully nobody steps in and says it’s impossible… (that’s not a challenge, btw. I’d rather someone stepped up and said “yeah, I’ll code this for you!”)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#22 2016-03-16 16:33:59

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: Markup language flavours

Bloke wrote #298324:

But what if …

Yes, you have me there. Better to stick to smd_macro, perhaps.

Offline

Board footer

Powered by FluxBB