Re: Proposed table specification (long!)
On Wed, May 18, 2011 at 08:28:53PM +0200, Chinyoka on Macbook wrote: I am also wondering whether there would be a way to split a document into many pages. I checked with other Markdown implementations and wish they would have a way to split a document into pages: for instance, Cramdown looked like it could if Thomas wanted to make it one of those options you can put between those sharp brackets and colons. I take the view that markdown is really a text processing filter rather than a publishing solution, so this feels very out of scope. Perhaps something like emacs muse-mode (which I think has some limited markdown functionality,) or just the right Makefile could do the processing you want to get multi-page output. In short: it's a good feature but enough depends on the rest of your publishing process/solution, so look there. Currently, I am using PHP Markdown Extra for my web publishing, but want a solid desktop option. I sometimes wish there were a desktop version, whether command line or GUI, that would work like that PHP Markdown Extra. So I hope your solution may be the answer to this. Anyway, it looks like Markdown in 2011 is heading for exciting moments with or without Gruber's blessing. I used PHP Markdown Extra for years with a WordPress site. When I stopped that, I had a bunch of vanilla markdown with footnotes (and maybe images?) in the markdown extra. I continue to write text in the same way, and have been processing this text both on the web and locally using: Maruku (abandoned for speed reasons, but it's good for LaTeX conversions and one-offs,) and MultiMarkdown pretty much without error. I'm given to understand that python markdown and pandoc would also do what you want in terms of the extra syntax... Hope that helps, tycho -- tycho(ish) @ ga...@tychoish.com http://tychoish.com/ http://criticalfutures.com/ don't get it right, get it written -- james thurber pgpcLD5qlwpTo.pgp Description: PGP signature ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: `time` element syntax
Hi folks,
Thanks for your input. I'm pleased to have raised this issue for discussion.
Michel Fortin michel.for...@michelf.com wrote:
Personally, I think if you're going to write a lot of dates like this the
best syntax would be to auto-detect 30 May 2011 as a date. But this might
need to be done at another layer than Markdown since Markdown doesn't know
about your time zone and the date format might depend on your language and
locale.
Rob McBroom mailingli...@skurfer.com wrote:
I don’t have any strong feelings about syntax, but manually entering the
date in two formats doesn’t seem very DRY. I’d prefer to just type one
(probably the machine-readable one, as it contains the time) and let the
toasters do the work of generating the other.
The problem with the approach suggested by Rob and Michel is that it works
for only a subset of cases. A very large subset perhaps, but a subset
nonetheless. The displayed text may be Christmas Day or 7pm tomorrow.
While in many cases it may seem a violation of DRY to include both forms,
it's clearly not possible to go translate from human to machine in all
cases, nor is it necessarily possible to translate in the other direction.
Waylan Limberg way...@gmail.com wrote:
Ok, this looks like it would match a valid date and time, but what about a
date without time or a time without date? According to the spec, all three
should be allowed. Have fun building that regex.
I lifted the regular expression from
jQuery.localizehttps://bitbucket.org/davidchambers/jquery.localizewhich
requires at least date, hours, and minutes. You're right, a few more
optional non-capturing groups are required. :)
Waylan Limberg way...@gmail.com wrote:
That said, I'm going to ignore the 'looks like a link' issue for a moment
and add that I think I would prefer something like a reference syntax with a
datetime label:
Some text [30 May 2011] more text.
[30 May 2011]: datetime: 2011-05-30T15:00-07:00
Heck, Waylan, you've done it again. This is extremely readable and allows
the `pubdate` attribute to be included if desired.
Some text [30 May 2011] more text.
[30 May 2011]: datetime: 2011-05-30T15:00-07:00, pubdate
would become…
time datetime=2011-05-30T15:00-07:00 pubdate=pubdate30 May 2011
/time
Waylan Limberg way...@gmail.com wrote:
Now if you can come up with a clean way to make that look less like a link,
I might be interested in using it myself. Otherwise, I'll stick to raw html
here.
Square brackets are simply the right characters for the job. One could
consider them to serve a broader function: wrapping text which relates to
some other data, be it a web page, an image, a timestamp, or something else.
The resemblance to links is actually a *good* thing in my opinion. It allows
readers to guess (correctly) that the there is accompanying data and that
it likely resides after the current paragraph or at the end of the document.
David Parsons o...@pell.portland.or.us wrote:
That looks like it would be a good place for a pseudo-protocol:
[two days ago](time:2011-05-30T15:00-07:00 May 30th, if you care)
This would have the advantage of being fairly unambiguous, instead of
superimposing a magic time string over the existing linkyformat.
This is definitely less ambiguous, but causes the sentence's flow to be
interrupted. Perhaps I've been writing too much JavaScript and CoffeeScript
lately, but overloading existing syntax—as opposed to introducing new
syntax—seems like the right approach to me.
I'm going to go ahead and see if I can implement Waylan's suggestion in
Showdown http://davidchambers.bitbucket.org/showdown/.
David
On 2 June 2011 11:31, Michel Fortin michel.for...@michelf.com wrote:
Le 2011-06-02 à 5:08, David Chambers a écrit :
Hi folks,
I expect that the response to this post will be we don't need such a
thing, but humour me for a moment by pretending that in fact we do.
HTML5 added a number of new tags to the mix, but arguably the most
significant is the `time` element. It associates a machine-readable
timestamp with a human-readable string (e.g. `time
datetime=2011-05-30T15:00-07:0030 May 2011/time`).
I would love to be able to write something like `[30 May
2011]{2011-05-30T15:00-07:00}`.
`/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d)(?::(\d\d)(?:[.](\d+))?)?([-+]\d\d:\d\d|Z)$/`
could be used to ensure that only valid `datetime` attribute values are
matched. This would avoid false positives and would keep `[foo]{bar}`
available for other functions, potentially.
Are there any reasons not to use `[human]{computer}`? Can anyone suggest
a
better syntax?
Personally, I think if you're going to write a lot of dates like this the
best syntax would be to auto-detect 30 May 2011 as a date. But this might
need to be done at another layer than Markdown since Markdown doesn't know
about your time zone and the date format might depend on your language and
locale.
--
Michel
Re: `time` element syntax
Le 2011-06-05 à 18:23, David Chambers a écrit : Hi folks, Thanks for your input. I'm pleased to have raised this issue for discussion. [...] The problem with the approach suggested by Rob and Michel is that it works for only a subset of cases. A very large subset perhaps, but a subset nonetheless. The displayed text may be Christmas Day or 7pm tomorrow. While in many cases it may seem a violation of DRY to include both forms, it's clearly not possible to go translate from human to machine in all cases, nor is it necessarily possible to translate in the other direction. If I put my mouse pointer over 7pm tomorrow in your email, Apple Mail circles it with a dotted line with a popup menu offering to add a new event to my calendar. Clearly the algorithm can be quite clever. But you're right it will never catch all cases. But for the cases it won't catch, there's HTML. I'm not saying it's the ideal solution. Heck, Waylan, you've done it again. This is extremely readable and allows the `pubdate` attribute to be included if desired. Some text [30 May 2011] more text. [30 May 2011]: datetime: 2011-05-30T15:00-07:00, pubdate would become… time datetime=2011-05-30T15:00-07:00 pubdate=pubdate30 May 2011 /time I'd tend to go for something even simpler: Some text 30 May 2011 more text. *[30 May 2011]: 2011-05-30 15:00 -07:00 Basically, why do we need to force brackets in the text at all? Also, why force the writer to use 'T' as a time separator and strictly follow to the rules of HTML date syntax? It's much more readable without the 'T'. Reformatting it to HTML's liking should be pretty trivial. Also, note that what I have proposed above is simply an extension to PHP Markdown Extra's abbreviation syntax. I'd propose that if the abbreviation looks like an ISO date/time, the Markdown parser would just emit a `time` or `date` element, whatever is most appropriate, instead of `abbr`. I'd rather not add a new Markdown syntax for each and every element in HTML. The resemblance to links is actually a *good* thing in my opinion. It allows readers to guess (correctly) that the there is accompanying data and that it likely resides after the current paragraph or at the end of the document. I disagree. Someone reading the HTML output in the browser is unlikely to notice there's a date/time element here or there on the page with a computer-readable date. And even if you made date time elements flashing red, what would be the point? It has some value if, like in Apple Mail, you can move your pointer to it and do some action. But that's not going to be true in the Markdown text version (unless it gets scanned for common date patterns like Mail does). So why again should the reader know there's a computer-readable version of the date somewhere further in the document? -- Michel Fortin michel.for...@michelf.com http://michelf.com/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: `time` element syntax
So, you like: Waylan Limberg way...@gmail.com wrote: That said, I'm going to ignore the 'looks like a link' issue for a moment and add that I think I would prefer something like a reference syntax with a datetime label: Some text [30 May 2011] more text. [30 May 2011]: datetime: 2011-05-30T15:00-07:00 Heck, Waylan, you've done it again. This is extremely readable and allows the `pubdate` attribute to be included if desired. But you don't like: David Parsons o...@pell.portland.or.us wrote: That looks like it would be a good place for a pseudo-protocol: [two days ago](time:2011-05-30T15:00-07:00 May 30th, if you care) This would have the advantage of being fairly unambiguous, instead of superimposing a magic time string over the existing linkyformat. This is definitely less ambiguous, but causes the sentence's flow to be interrupted. These are *exactly* the same thing, except for the trivial difference of using `datetime:` vs `time:` as the name for the pseudo-protocol. I fail to see how using `time:` interrupts the sentence flow when `datetime:` does not. -david parsons ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: `time` element syntax
Michel Fortin michel.for...@michelf.com wrote: I'd tend to go for something even simpler: Some text 30 May 2011 more text. *[30 May 2011]: 2011-05-30 15:00 -07:00 Basically, why do we need to force brackets in the text at all? Also, why force the writer to use 'T' as a time separator and strictly follow to the rules of HTML date syntax? It's much more readable without the 'T'. Reformatting it to HTML's liking should be pretty trivial. I *love* this idea. I'm unfamiliar with PHP Markdown Extra's abbreviation syntax (I'll read up on it); building upon an established convention sounds very sensible to me. Michel Fortin michel.for...@michelf.com wrote: The resemblance to links is actually a *good* thing in my opinion. It allows readers to guess (correctly) that the there is accompanying data and that it likely resides after the current paragraph or at the end of the document. I disagree. Someone reading the HTML output in the browser is unlikely to notice there's a date/time element here or there on the page with a computer-readable date. And even if you made date time elements flashing red, what would be the point? I was referring to the resemblance to links in the Markdown itself. I agree that the existence of a machine-readable version of a date is likely to be of little interest to readers of the *rendered* document. David Parsons o...@pell.portland.or.us wrote: These are *exactly* the same thing, except for the trivial difference of using `datetime:` vs `time:` as the name for the pseudo-protocol. I fail to see how using `time:` interrupts the sentence flow when `datetime:` does not. I was unclear. I have no strong feelings as to `datetime:` versus `time:`. What I like about the suggestion Waylan put forward is that it allows the machine-readable timestamp to be placed at the end of the document, to avoid having it interrupt sentence flow. Based on your response it appears that I failed to draw to consider… [two days ago](time:2011-05-30T15:00-07:00 May 30th, if you care) to be a placeholder for… [two days ago](time:2011-05-30T15:00-07:00 May 30th, if you care) *or…* [two days ago][1] [1]: time:2011-05-30T15:00-07:00 May 30th, if you care in which case I like this syntax also. I am most enamoured with Michel's proposed bracket-free syntax. What do others think of it? David On 5 June 2011 16:35, David Parsons o...@pell.portland.or.us wrote: So, you like: Waylan Limberg way...@gmail.com wrote: That said, I'm going to ignore the 'looks like a link' issue for a moment and add that I think I would prefer something like a reference syntax with a datetime label: Some text [30 May 2011] more text. [30 May 2011]: datetime: 2011-05-30T15:00-07:00 Heck, Waylan, you've done it again. This is extremely readable and allows the `pubdate` attribute to be included if desired. But you don't like: David Parsons o...@pell.portland.or.us wrote: That looks like it would be a good place for a pseudo-protocol: [two days ago](time:2011-05-30T15:00-07:00 May 30th, if you care) This would have the advantage of being fairly unambiguous, instead of superimposing a magic time string over the existing linkyformat. This is definitely less ambiguous, but causes the sentence's flow to be interrupted. These are *exactly* the same thing, except for the trivial difference of using `datetime:` vs `time:` as the name for the pseudo-protocol. I fail to see how using `time:` interrupts the sentence flow when `datetime:` does not. -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: `time` element syntax
On Sun, Jun 5, 2011 at 8:35 PM, David Chambers david.chambers...@gmail.com wrote: Michel Fortin michel.for...@michelf.com wrote: I'd tend to go for something even simpler: Some text 30 May 2011 more text. *[30 May 2011]: 2011-05-30 15:00 -07:00 Basically, why do we need to force brackets in the text at all? Also, why force the writer to use 'T' as a time separator and strictly follow to the rules of HTML date syntax? It's much more readable without the 'T'. Reformatting it to HTML's liking should be pretty trivial. I love this idea. I'm unfamiliar with PHP Markdown Extra's abbreviation syntax (I'll read up on it); building upon an established convention sounds very sensible to me. I'll have to say I like this as well. It hadn't occurred to me that like the abbreviation syntax, we don't need to mark up the text at all. Regarding the time v. datetime, I picked datetime because that is the name of the html attribute the same value would be assigned to. But time is certainly shorter. Maybe you won't need either as Michel suggests. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: `time` element syntax
Three people on markdown-discuss in agreement? Must be a new record. :) Thanks for weighing in, Waylan. David On 5 June 2011 18:57, Waylan Limberg way...@gmail.com wrote: On Sun, Jun 5, 2011 at 8:35 PM, David Chambers david.chambers...@gmail.com wrote: Michel Fortin michel.for...@michelf.com wrote: I'd tend to go for something even simpler: Some text 30 May 2011 more text. *[30 May 2011]: 2011-05-30 15:00 -07:00 Basically, why do we need to force brackets in the text at all? Also, why force the writer to use 'T' as a time separator and strictly follow to the rules of HTML date syntax? It's much more readable without the 'T'. Reformatting it to HTML's liking should be pretty trivial. I love this idea. I'm unfamiliar with PHP Markdown Extra's abbreviation syntax (I'll read up on it); building upon an established convention sounds very sensible to me. I'll have to say I like this as well. It hadn't occurred to me that like the abbreviation syntax, we don't need to mark up the text at all. Regarding the time v. datetime, I picked datetime because that is the name of the html attribute the same value would be assigned to. But time is certainly shorter. Maybe you won't need either as Michel suggests. -- \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
