php-markdown-extra-extended - my humble attempt at extending php-markdown

[David Parsons]

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

> contact at 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 at six.pairlist.net

>> http://six.pairlist.net/mailman/listinfo/markdown-discuss

>

> _______________________________________________

> Markdown-Discuss mailing list

> Markdown-Discuss at six.pairlist.net

> http://six.pairlist.net/mailman/listinfo/markdown-discuss