> [John Fraser:] Being able to wrap Markdown text in divs and spans ...I find div and span tags quite useful. Here is an example of the syntax I'm presently using. [[ {#orchard} Contents of div here. And ~this{.plum}~ is how I do spans. ]] becomes <div id="orchard"> <p>Contents of div here. And <span class="plum">this</span> is how I do spans.</p> </div> Whatever characters one chooses to use (I imagine some resistance to ~), I think div and span support is essential. I also place the attribute group inside element delimiters, which is more consistent, easier to read, and offers greater utility, as it appears to me (in contrast to placing it outside element delimiters). Anyway, more on that some other time. --Dick
* Richard Taytor <dick at gutz.com> [2007-03-05 00:05]:> Whatever characters one chooses to use (I imagine some > resistance to ~), I think div and span support is essential.I don?t know about <div>, but <span> is an inline element so you can just type it literally. Markdown doesn?t have to have support for *every* HTML tag ? that will just lead to unreadable line noise as you end up with lots of funny squiggles with some kind of meaning that you have no chance at all of guessing. I?d also say that if you need <span> tags so much that writing them literally doesn?t cut it, then you?re writing a lot of semantically meaningless markup; which means *something* is wrong. (I almost never use <span>; usually it?s <b>, sometimes <i>, and I undo the default bold/italic style as necessary in the stylesheet. These tags are just as meaningless as <span>, but at least they do have a default presentation, so if the stylesheet is not in effect, there?s still an indication that I wanted to convey *something*. As a bonus, they?re easier to type and, if relevant, also easier on the filesize.) Regards, -- Aristotle Pagaltzis // <plasmasturm.org>
On 3/5/07, Richard Taytor <dick at gutz.com> wrote:> > [John Fraser:] Being able to wrap Markdown text in divs and spans ... > > I find div and span tags quite useful. Here is an example of the syntax I'm presently using. > > [[ {#orchard} > Contents of div here. And ~this{.plum}~ is how I do spans. > ]]I also need DIVs and I will implement them in Maruku. I will be glad to hear suggestions for the syntax. Here is another hypothesis: +================ {#id} nested div: +======================= inside nested DIV -======================= -============= I like the fact that the line of `=` separates well the DIV's content from the rest of the document. -- Andrea Censi "Life is too important to be taken seriously" (Oscar Wilde) Web: dis.uniroma1.it/~censi
I don't think Markdown needs its own syntax for div elements; however you write it, a div is only going to make sense to someone who knows what a div is. And those people can already read and write `<div id="title">` easily enough -- without learning new syntax. If a reader doesn't happen to know what a div is, they can at least tell that there's something called a div, and it's got the word title in it, and it seems to contain something that looks like it might be a title. I don't think any syntactic changes you can make are going to improve much on that. On the contrary: they'll just take the word "div" away, leaving people with nothing to google if they don't know what they're looking at. I really feel like the best approach is to get Markdown working inside normal HTML divs, just like it works inside spans right now. -John
Richard Taytor wrote:> > [John Fraser:] Being able to wrap Markdown text in divs and spans ... > > I find div and span tags quite useful. Here is an example of the syntax I'm presently using. > > [[ {#orchard} > Contents of div here. And ~this{.plum}~ is how I do spans. > ]]On [Markdown syntax], you can find the following statement:> Markdown is intended to be as easy-to-read and easy-to-write as is > feasible. > > Readability, however, is emphasized above all else. A > Markdown-formatted document should be publishable as-is, as plain > text, without looking like it?s been marked up with tags or formatting > instructions.I don't think that you suggestions increase the legibility of Markdown for people that don't know HTML. I agree with John Fraser: divs and spans might only be necessary for people who already know the concept. I'd like to see that future enhancements to the syntax are not be a simple mapping of possible HTML tags but rather concepts that might be helpful for text writing. Examples are * Text anchors (sorry, I'm not sure whether this is the approptiate english word) - it seems like this was your goal by defining a div. In my opinion, the possibility to define header ids in [Markdown Extra] is good, although the feature breaks as soon as users define an invalid id (containing spaces or symbols). * Foreign words. I don't know if this would really be useful. Foreign words could, for instance, be defined as follows: > I have been to the [[de: Oktoberfest]] in Munich last year. which would map to: <span lang="de" xml:lang="de">Oktoberfest</span> Ideally, [[es: *Paella*]] _and_ *[[es: Paella]]* would map to <em lang="es" xml:lang="es">Paella</em>. Maybe it makes things more complicated than necessary... * Tables. This is a mapping to HTML elements, but also a concept useful when writing certain types of text. The same applies to definition lists. - David Aurelio [Markdown syntax]: <daringfireball.net/projects/markdown/syntax#philosophy> [Markdown Extra]: <michelf.com/projects/php-markdown/extra>
"Markdown is a text-to-HTML conversion tool for web writers."* I have no interest in mapping more HTML tags to Markdown; however, div and span are simply fundamental if one needs to address multiple blocks as a unit and string segments which should not be otherwise formatted. Attribute support is also essential to my purposes. I have no interest in threatening the Markdown community or defending/proving my perspective; I merely wish to cooperate with those who also find reason to extend it (if that's not you, then don't worry), and I do remain interested to engage in creative/constructive/useful discussion, critical or otherwise. * I also understand its "overriding design goal". --D