Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
On Jul 13, 2011, at 8:33 PM, Alan Hogan wrote:
On Wednesday, July 13, 2011 at 8:00 PM, David Parsons wrote:
You're looking at markdown like some sort of intermediate
language that's not designed for writing; I'm trying to
use existing constructs to add marginally useful features
without introducing too much extraneous noise.
-david parsons
1) I certainly _do_ view Markdown (and all these derivatives) as
"designed for writing." Specifically, as designed for authoring --
the distinction in my mind is that the W3C always calls web page
document creators "authors." Markdown was created by someone who
wanted to use it to author web pages (specifically, content or blog
posts, as opposed to full documents), while retaining maximum plain-
text readability. Authoring content for the Web has still got to be
far and away the #1 use of Markdown (and derivatives).
The rule of thumb I try to follow when doing extensions can be
found
at the very top of the Markdown project page (http://daringfireball.net/projects/markdown
):
"Markdown is a text-to-HTML conversion tool for web writers. Markdown
allows you to write using an easy-to-read, easy-to-write plain text
format, then convert it to structurally valid XHTML (or HTML)."
I do not think that the :{ words } extension is easy to read or
write. And I can't see how claiming it's the Latest Craze in Port
Royal (tm Capt Bogg & Salty) addresses those concerns. If I want
power, why shouldn't I just write a chunk of raw html? Markdown
supports that natively and it's no less readable than :{ words } is.
-david parsons
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
To be clear, I am 100% focused on this syntax in this email (and probably the last email or two): [span contents here](class:someClass) On Wednesday, July 13, 2011 at 8:00 PM, David Parsons wrote: > You're looking at markdown like some sort of intermediate > language that's not designed for writing; I'm trying to > use existing constructs to add marginally useful features > without introducing too much extraneous noise. > > -david parsons 1) I certainly _do_ view Markdown (and all these derivatives) as "designed for writing." Specifically, as designed for authoring -- the distinction in my mind is that the W3C always calls web page document creators "authors." Markdown was created by someone who wanted to use it to author web pages (specifically, content or blog posts, as opposed to full documents), while retaining maximum plain-text readability. Authoring content for the Web has still got to be far and away the #1 use of Markdown (and derivatives). Is it some sort of intermediate language? Well, "intermediate" would mean it is a middle step between two other languages, whereas Markdown is the first step -- and yes, you are right to imply it can be the "only" step in many cases, but of **course** Markdown text can be thought of a "source" of an output language (typically HTML). Otherwise, we'd all just write in plain text and leave it at that -- no need to build all these converters, right? 2) I can certainly appreciate the desire to keep Markdown text looking as good as possible in the source. Again, that's the point. But I would argue your span syntax is less "[using] existing constructs" so much as creating a new construct that overlaps existing syntax. I cannot see this being any less noisy than competing syntaxes for the stated purpose. But I definitely can imagine documents authored to your flavor of markdown subtly failing in other converters which, completely reasonably, assume that the link syntax defines links, not spans with classes or IDs. (Which are patently HTML-specific -- I have no problem with that, but it is puzzling you accuse me of considering Markdown an "intermediate language" as if that were a bad thing as you support 100% HTML-specific features.) The . se other parsers will create hyperlinks to some non-existing "class" protocol. A cursory glance at the converted document will show nothing wrong. But consider the Maruku-style syntax for adding classes/IDs/attributes to inline elements: Since it invents a completely new syntax with curly braces and a colon, any failures to convert documents authored to such a syntax will be immediately noticeable because of the extra crap/punctuation in the output document. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
On Jul 13, 2011, at 6:50 PM, Alan Hogan wrote:
It seems to me that your syntax, compared to Maruku's attribute
lists, is less powerful, less commonly implemented, and more
ambiguous; and that its only upshot is looking better to your eyes.
Fair enough?
No.
Or am I missing something?
You're looking at markdown like some sort of intermediate
language that's not designed for writing; I'm trying to
use existing constructs to add marginally useful features
without introducing too much extraneous noise.
-david parsons
Alan Hogan
http://blogic.com
cont...@alanhogan.com
On Wednesday, July 13, 2011 at 6:11 PM, David Parsons wrote:
On Jul 13, 2011, at 1:12 PM, Alan Hogan wrote:
On Wednesday, July 13, 2011 at 12:54 PM, David Parsons wrote:
Adding classes & ids are kind of hideous. What I did with discount
was to extend the []() syntax to allow class: and id: pseudo-
classes
(like [postoffice](class:caps) or version [2.1.0](id:v2.1.0) on
spans
I can’t say I am a fan of this syntax, simply because it uses the
same exact syntax for hyperlinks as it does for attributes.
Yes, that's by design.
The only way to tell about a `mailto:` link and a `class:` attribute
is by whitelisting either attributes or protocols (I'm guessing
attributes, as protocols are more "unbounded" in quantity). But what
about obscure attributes? Or `data-foo-bar` attributes? Would (are)
they be supported in this syntax?
Personally, I've not found much use for passing arbitrary
attributes
into spans or divs, and, at least to the best of my knowledge, no
user
has ever asked for that capacity. So it's never been an issue. And
even if it was, I worry about supporting the thing making markdown
into
an unreadable mess -- I chose pseudo-protocols for spans because
it's a
syntax we've already got, and it makes it no more messy.
More seriously, what if a new technology takes off that uses a
protocol designated `id` or similar? Say, a standards-based personal
identity URL, e.g. id:alanhogan? Then the two sets of meanings would
overlap.
But it hasn't. And if it does, there's certainly nothing stopping
me from depreciating the pseudo-protocol in future releases of the
code;
the nice thing about syntax extensions is that they're understood
to be
somewhat experimental and may change to reflect changes in the
underlying
standards.
That said, the ability to apply attributes to spans is pretty cool.
Naïvely, I would think a syntax like
blah blah [postoffice]{: .caps}
One advantage of using pseudo-protocols is that you can use them
for
the traditional footnote-style link:
[postoffice][caps]
[caps]: class:caps 'ALL UPPER CASE, ALL THE TIME'
You could, of course, subvert the (markdown extra?)-style
abbreviation
syntax to do it silently:
postoffice
%[postoffice]: [postoffice](class:caps)
(or %[postoffice]: [postoffice]{:.caps}, if squiggle-parens are
your thing)
-david parsons
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Code blocks in blockquotes
According to John Gruber's syntax page
http://daringfireball.net/projects/markdown/syntax#blockquote
it is possible to nest a code block in a blockquote.
But Markdown.pl 1.0.1 shows some strange behavior in this respect.
Let me take the following text example (I use `***BEGIN**` and `***END***`
as delimiters for the examples):
***BEGIN***
This is a block of code in a blockquote:
> function hello = {
> begin
> begin
> begin
> return "Hello world";
> end
> end
> end
> };
Thank you for your attention.
***END***
A Markdown.pl conversion returns this:
***BEGIN***
This is a block of code in a blockquote:
function hello = {
begin
begin
begin
return "Hello world";
end
end
end
};
Thank you for your attention.
***END***
But the `begin...end` blocks should be indented by two more spaces, each.
The result should have been this:
***BEGIN***
This is a block of code in a blockquote:
function hello = {
begin
begin
begin
return "Hello world";
end
end
end
};
Thank you for your attention.
***END***
This last result is in fact, what I obtain with Pandoc 1.8.1.1.
There is also a weakness in the syntax explanation for these blockquotes,
which left me puzzled for a while and caused some trouble in a program I am
working on. The definition says that `>` is the blockquote symbol, where in
fact, it is `> `, i.e. a greater-than plus a space.
For the nested code this means, that we have to start the line with `>` and
5 spaces, at least. 4 spaces are not sufficient, although this is what the
definition suggests.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
It seems to me that your syntax, compared to Maruku's attribute lists, is less
powerful, less commonly implemented, and more ambiguous; and that its only
upshot is looking better to your eyes.
Fair enough? Or am I missing something?
Alan Hogan
http://blogic.com
cont...@alanhogan.com
On Wednesday, July 13, 2011 at 6:11 PM, David Parsons wrote:
>
> On Jul 13, 2011, at 1:12 PM, Alan Hogan wrote:
>
> >
> > On Wednesday, July 13, 2011 at 12:54 PM, David Parsons wrote:
> >
> > > Adding classes & ids are kind of hideous. What I did with discount
> > > was to extend the []() syntax to allow class: and id: pseudo-classes
> > > (like [postoffice](class:caps) or version [2.1.0](id:v2.1.0) on spans
>
> > I can’t say I am a fan of this syntax, simply because it uses the
> > same exact syntax for hyperlinks as it does for attributes.
>
> Yes, that's by design.
>
> > The only way to tell about a `mailto:` link and a `class:` attribute
> > is by whitelisting either attributes or protocols (I'm guessing
> > attributes, as protocols are more "unbounded" in quantity). But what
> > about obscure attributes? Or `data-foo-bar` attributes? Would (are)
> > they be supported in this syntax?
>
> Personally, I've not found much use for passing arbitrary
> attributes
> into spans or divs, and, at least to the best of my knowledge, no user
> has ever asked for that capacity. So it's never been an issue. And
> even if it was, I worry about supporting the thing making markdown into
> an unreadable mess -- I chose pseudo-protocols for spans because it's a
> syntax we've already got, and it makes it no more messy.
>
>
> > More seriously, what if a new technology takes off that uses a
> > protocol designated `id` or similar? Say, a standards-based personal
> > identity URL, e.g. id:alanhogan? Then the two sets of meanings would
> > overlap.
>
> But it hasn't. And if it does, there's certainly nothing stopping
> me from depreciating the pseudo-protocol in future releases of the code;
> the nice thing about syntax extensions is that they're understood to be
> somewhat experimental and may change to reflect changes in the
> underlying
> standards.
>
> >
> > That said, the ability to apply attributes to spans is pretty cool.
> > Naïvely, I would think a syntax like
> >
> > blah blah [postoffice]{: .caps}
>
> One advantage of using pseudo-protocols is that you can use them
> for
> the traditional footnote-style link:
>
> [postoffice][caps]
>
> [caps]: class:caps 'ALL UPPER CASE, ALL THE TIME'
>
> You could, of course, subvert the (markdown extra?)-style
> abbreviation
> syntax to do it silently:
>
> postoffice
>
> %[postoffice]: [postoffice](class:caps)
>
> (or %[postoffice]: [postoffice]{:.caps}, if squiggle-parens are
> your thing)
>
>
> -david parsons
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net (mailto:Markdown-Discuss@six.pairlist.net)
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
On Jul 13, 2011, at 1:12 PM, Alan Hogan wrote:
On Wednesday, July 13, 2011 at 12:54 PM, David Parsons wrote:
Adding classes & ids are kind of hideous. What I did with discount
was to extend the []() syntax to allow class: and id: pseudo-classes
(like [postoffice](class:caps) or version [2.1.0](id:v2.1.0) on spans
I can’t say I am a fan of this syntax, simply because it uses the
same exact syntax for hyperlinks as it does for attributes.
Yes, that's by design.
The only way to tell about a `mailto:` link and a `class:` attribute
is by whitelisting either attributes or protocols (I'm guessing
attributes, as protocols are more "unbounded" in quantity). But what
about obscure attributes? Or `data-foo-bar` attributes? Would (are)
they be supported in this syntax?
Personally, I've not found much use for passing arbitrary
attributes
into spans or divs, and, at least to the best of my knowledge, no user
has ever asked for that capacity. So it's never been an issue. And
even if it was, I worry about supporting the thing making markdown into
an unreadable mess -- I chose pseudo-protocols for spans because it's a
syntax we've already got, and it makes it no more messy.
More seriously, what if a new technology takes off that uses a
protocol designated `id` or similar? Say, a standards-based personal
identity URL, e.g. id:alanhogan? Then the two sets of meanings would
overlap.
But it hasn't. And if it does, there's certainly nothing stopping
me from depreciating the pseudo-protocol in future releases of the code;
the nice thing about syntax extensions is that they're understood to be
somewhat experimental and may change to reflect changes in the
underlying
standards.
That said, the ability to apply attributes to spans is pretty cool.
Naïvely, I would think a syntax like
blah blah [postoffice]{: .caps}
One advantage of using pseudo-protocols is that you can use them
for
the traditional footnote-style link:
[postoffice][caps]
[caps]: class:caps 'ALL UPPER CASE, ALL THE TIME'
You could, of course, subvert the (markdown extra?)-style
abbreviation
syntax to do it silently:
postoffice
%[postoffice]: [postoffice](class:caps)
(or %[postoffice]: [postoffice]{:.caps}, if squiggle-parens are
your thing)
-david parsons
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: writing tools that use light-markup
One more Markdown editor: Brett Terpstra's plugin for Wordpress, "Markdown Quicktags." http://brettterpstra.com/project/markdown-quicktags/ (He also just released Marked, basically a standalone, auto-refreshing Markdown preview window, in the Mac App Store.) ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
On Wednesday, July 13, 2011 at 12:54 PM, David Parsons wrote:
> Adding classes & ids are kind of hideous. What I did with discount
> was to extend the []() syntax to allow class: and id: pseudo-classes
> (like [postoffice](class:caps) or version [2.1.0](id:v2.1.0) on spans
I can’t say I am a fan of this syntax, simply because it uses the same exact
syntax for hyperlinks as it does for attributes. The only way to tell about a
`mailto:` link and a `class:` attribute is by whitelisting either attributes or
protocols (I'm guessing attributes, as protocols are more "unbounded" in
quantity). But what about obscure attributes? Or `data-foo-bar` attributes?
Would (are) they be supported in this syntax?
More seriously, what if a new technology takes off that uses a protocol
designated `id` or similar? Say, a standards-based personal identity URL, e.g.
id:alanhogan? Then the two sets of meanings would overlap.
(I also appreciate syntaxes that allow the terseness of # and . for IDs and
classes, so familiar to anyone who has ever done CSS or library-assisted
JavaScript.)
That said, the ability to apply attributes to spans is pretty cool. Naïvely, I
would think a syntax like
blah blah [postoffice]{: .caps}
would make more sense (that is, appropriating inline attribute lists along with
the core link text syntax). I don’t see any real ambiguities there, and no need
to maintain a whitelist of attributes or protocols, and no possibility to be
broken in the future by tech changes outside the realm of Markdown parsers'
control.
Alan Hogan
http://blogic.com
cont...@alanhogan.com
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
On Jul 13, 2011, at 1:12 AM, Egil Hansen wrote:
Dear all,
I have used Markdown via Drupal a few months now, with a customer site
and my currently my own blog and based on that practical experience I
wanted to add some extra functionality to PHP Markdown Extra, so out
of this grow my (extended) weekend project
https://github.com/egil/php-markdown-extra-extended
The big missing item right now that I would like to implement is the
ability to add classes to block and span elements. My basic idea is to
use a syntax like this: {some class}
Adding classes & ids are kind of hideous. What I did with discount
was to extend the []() syntax to allow class: and id: pseudo-classes
(like [postoffice](class:caps) or version [2.1.0](id:v2.1.0) on spans,
and then extended the blockquote syntax to allow them as well, via
>%class:smaller%
>stuff
or
>%id:label%
>more stuff
I tried to make up extensions that are visually not very obvious
(the other alternative -- floating {: words } after a block -- seems
a little too cluttery for me)
-david parsons
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
I was not aware of Kramdown before.
I'm delighted to see that it refuses to merge unordered and ordered lists
(which I was complaining about a month ago on this list).
http://kramdown.rubyforge.org/syntax.html#ordered-and-unordered-lists
Alan Hogan
http://blogic.com
cont...@alanhogan.com (mailto:cont...@alanhogan.com)
On Wednesday, July 13, 2011 at 12:34 PM, Waylan Limberg wrote:
> Yes, I implemented an extension to Python-Markdown a few weeks back
> which should be available in a release real soon now. Docs are here:
> https://github.com/waylan/Python-Markdown/blob/master/docs/extensions/attr_list.txt
>
> The other implementation is
> http://kramdown.rubyforge.org/syntax.html#inline-attribute-lists
>
> On Wed, Jul 13, 2011 at 2:53 PM, Alan Hogan (mailto:cont...@alanhogan.com)> wrote:
> > Waylan, out of curiosity, which implementations are those? Is yours one?
> >
> > Alan Hogan
> > http://blogic.com
> > cont...@alanhogan.com (mailto:cont...@alanhogan.com)
> >
> > On Wednesday, July 13, 2011 at 6:02 AM, Waylan Limberg wrote:
> >
> > On Wed, Jul 13, 2011 at 4:12 AM, Egil Hansen > (mailto:e...@assimilated.dk)> wrote:
> >
> > Dear all,
> >
> > I have used Markdown via Drupal a few months now, with a customer site
> > and my currently my own blog and based on that practical experience I
> > wanted to add some extra functionality to PHP Markdown Extra, so out
> > of this grow my (extended) weekend project
> > https://github.com/egil/php-markdown-extra-extended
> >
> > The big missing item right now that I would like to implement is the
> > ability to add classes to block and span elements. My basic idea is to
> > use a syntax like this: {some class}
> >
> > If you're looking for prior art, I'd suggest Maruku's attribute lists
> > [1]. I'm aware of at least two other markdown implementations which
> > have adopted this.
> >
> > [1]: http://maruku.rubyforge.org/proposal.html#attribute_lists
> >
> >
> > --
> >
> > \X/ /-\ `/ |_ /-\ |\|
> > Waylan Limberg
> > ___
> > Markdown-Discuss mailing list
> > Markdown-Discuss@six.pairlist.net (mailto:Markdown-Discuss@six.pairlist.net)
> > http://six.pairlist.net/mailman/listinfo/markdown-discuss
> >
> >
> > ___
> > Markdown-Discuss mailing list
> > Markdown-Discuss@six.pairlist.net (mailto:Markdown-Discuss@six.pairlist.net)
> > http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
>
>
> --
>
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net (mailto:Markdown-Discuss@six.pairlist.net)
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
Yes, I implemented an extension to Python-Markdown a few weeks back
which should be available in a release real soon now. Docs are here:
https://github.com/waylan/Python-Markdown/blob/master/docs/extensions/attr_list.txt
The other implementation is
http://kramdown.rubyforge.org/syntax.html#inline-attribute-lists
On Wed, Jul 13, 2011 at 2:53 PM, Alan Hogan wrote:
> Waylan, out of curiosity, which implementations are those? Is yours one?
>
> Alan Hogan
> http://blogic.com
> cont...@alanhogan.com
>
> On Wednesday, July 13, 2011 at 6:02 AM, Waylan Limberg wrote:
>
> On Wed, Jul 13, 2011 at 4:12 AM, Egil Hansen wrote:
>
> Dear all,
>
> I have used Markdown via Drupal a few months now, with a customer site
> and my currently my own blog and based on that practical experience I
> wanted to add some extra functionality to PHP Markdown Extra, so out
> of this grow my (extended) weekend project
> https://github.com/egil/php-markdown-extra-extended
>
> The big missing item right now that I would like to implement is the
> ability to add classes to block and span elements. My basic idea is to
> use a syntax like this: {some class}
>
> If you're looking for prior art, I'd suggest Maruku's attribute lists
> [1]. I'm aware of at least two other markdown implementations which
> have adopted this.
>
> [1]: http://maruku.rubyforge.org/proposal.html#attribute_lists
>
>
> --
>
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
>
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
Waylan, out of curiosity, which implementations are those? Is yours one?
Alan Hogan
http://blogic.com
cont...@alanhogan.com
On Wednesday, July 13, 2011 at 6:02 AM, Waylan Limberg wrote:
> On Wed, Jul 13, 2011 at 4:12 AM, Egil Hansen (mailto:e...@assimilated.dk)> wrote:
> > Dear all,
> >
> > I have used Markdown via Drupal a few months now, with a customer site
> > and my currently my own blog and based on that practical experience I
> > wanted to add some extra functionality to PHP Markdown Extra, so out
> > of this grow my (extended) weekend project
> > https://github.com/egil/php-markdown-extra-extended
> >
> > The big missing item right now that I would like to implement is the
> > ability to add classes to block and span elements. My basic idea is to
> > use a syntax like this: {some class}
>
> If you're looking for prior art, I'd suggest Maruku's attribute lists
> [1]. I'm aware of at least two other markdown implementations which
> have adopted this.
>
> [1]: http://maruku.rubyforge.org/proposal.html#attribute_lists
>
>
> --
>
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net (mailto:Markdown-Discuss@six.pairlist.net)
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
On Wed, Jul 13, 2011 at 4:12 AM, Egil Hansen wrote:
> Dear all,
>
> I have used Markdown via Drupal a few months now, with a customer site
> and my currently my own blog and based on that practical experience I
> wanted to add some extra functionality to PHP Markdown Extra, so out
> of this grow my (extended) weekend project
> https://github.com/egil/php-markdown-extra-extended
>
> The big missing item right now that I would like to implement is the
> ability to add classes to block and span elements. My basic idea is to
> use a syntax like this: {some class}
If you're looking for prior art, I'd suggest Maruku's attribute lists
[1]. I'm aware of at least two other markdown implementations which
have adopted this.
[1]: http://maruku.rubyforge.org/proposal.html#attribute_lists
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
php-markdown-extra-extended - my humble attempt at extending php-markdown
Dear all,
I have used Markdown via Drupal a few months now, with a customer site
and my currently my own blog and based on that practical experience I
wanted to add some extra functionality to PHP Markdown Extra, so out
of this grow my (extended) weekend project
https://github.com/egil/php-markdown-extra-extended
The big missing item right now that I would like to implement is the
ability to add classes to block and span elements. My basic idea is to
use a syntax like this: {some class}
I have been playing with some basic ideas for the syntax in this file
but it is far from done:
https://github.com/egil/php-markdown-extra-extended/blob/master/demo/notes/class-syntax-tests.txt
I have looked through some of the archives on the mailing list, and
have not seen this discussed before, so would love some input.
In general, any input on my extension to PHP Markdown is welcome. This
project is also a chance for me to practice regex (my regex-fu is
weak), so please keep the regex-mocking to a minimum; I know it will
be hard :)
Thanks, Egil.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
