Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
(http://daringfireball.net/projects/markdown): Markdown is a text-to-HTML conversion tool [...] That may be its author's vision. In any case, it's a pity that so many seem limited by such. For some, Markdown is (or at least implies) much more than that, and remains useful with or without HTML. askye ___ 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
[1]: http://maruku.rubyforge.org/proposal.html#attribute_lists
I don't understand why the leading colon should be present.
In any case, it seems reasonable to:
- enclose attributes in braces (to indicate text meant for authors/editors
rather than readers)
- append attributes to elements (where they are likely to be somewhat less
hideous)
- use whitespace before the attribute lists for block elements (up to one blank
line)
- use conventional syntax
This paragraph has an attribute list attached by reference.
{ref}
[ref]: #id .class name=value
Am I missing something?
askye
___
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 Thu, Jul 14, 2011 at 12:47 PM, David Chambers
david.chambers...@gmail.com wrote:
Albert Skye mistl...@yahoo.co.uk wrote:
This paragraph has an attribute list attached by reference.
{ref}
[ref]: #id .class name=value
This strikes me as an elegant solution to the problem, askye. Does anyone
know of an extension that uses this syntax?
Maruku does (almost) [1] as a part of there attribute list syntax.
Basically, any single word (not a key=value pair or not starting with
a `#` or `.`) is treated as a reference. I have not implemented this
part in my implementation, mostly because I wasn't convinced that
Maruku's reference syntax was right.
[1]: http://maruku.rubyforge.org/proposal.html#using_tags
--
\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
That's actually what Jonh Gruber proposed a while back when he was
still participating on this list. In his view, only {ref} was
allowed, you couldn't specify attributes directly inline.
Thanks, I couldn't find that thread either and I forgot that he didn't like
inline attributes. I see no reason to forbid them. Writers will find a way to
produce hideous texts without or without such hand holding; better to put
simple assignments inline and use references as appropriate.
askye
___
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 guess it is always a case of keeping Markdown pure or adding
support for attributes/classes when it is practical.
In my scenario, I had a customer who did not like to use any HTML in
their input, but still wanted to be able to tell the CMS back-end that
a specific paragraph was a disclaimer, that a specific paragraph
should be centered, that an image should be left or right floated,
etc. So the solution was to use the syntax {disclaimer} after a
paragraph, or {center}, {left}, {right}.
Its a compromise, that stays true to the Markdown syntax, and don't
introduce a new confusing html syntax in the mix.
That was my original motivation.
- Egil
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
___
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 cont...@alanhogan.com 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 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
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
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 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: 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
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 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
