Markdown development

Sherwood Botsford sgbotsford at gmail.com
Sun Mar 21 11:28:16 EDT 2010



>

> Position Team P GD PTS

> 1 Man Utd 31 46 67

> 2 Arsenal 31 40 67

> 3 Chelsea 29 42 64

> 4 Tottenham 30 26 55

> 5 Liverpool 31 19 52

> 6 Man City 28 17 50

> 7 Aston Villa 29 17 50

> 8 Everton 30 6 45

> 9 Birmingham 30 -3 44

> 10 Fulham 29 0 38

> 11 Stoke 30 -6 36

> 12 Sunderland 30 -6 34

> 13 Blackburn 29 -17 34

> 14 Bolton 31 -20 32

> 15 Wigan 31 -30 31

> 16 Wolves 30 -24 28

> 17 West Ham 30 -14 27

> 18 Burnley 31 -33 24

> 19 Hull 30 -35 24

> 20 Portsmouth 30 -25 13

>

> It should be possible to do without having to use html. For more complex

> tables (eg multiple lines in spanning cells, tables within tables) you are

> getting into a different kettle of fish - I can see requiring html for that.

>




Agreed. This is the sort of thing that I do right now with MMD's tables.
Doing nested tables in HTML by hand is awful. My response to nested tables
is "Please don't" I know some layout mavins use this to control
presentation. I prefer <div> + CSS. I often use this construct to add
illustration to an article <div class="picture_right_40" which contains an
image, a caption, and a ruler line. It floats right, and is sized to 40% of
the width of the containing div. This allows me to still have text that is
readable, without having to remember opening and closing tags beyond the
<div> and </div>

A colleague of mine used tabs for programming indents, and commented that
once the indents got the the point where there wasn't enough line left to
work, it was time to abstract. Pull a chunk out as a subroutine or
function.

HTML generally, and in tables in particular, can have too many open tags.
In general I find that not being able to see the close on the same page as
the open makes for error prone writing.
Unfortunately there is no good way in html to do the equivalent of a
subroutine, to abstract it out. We have a plethora of CMS systems to enable
us to try to keep the content separate from the presentation, so that we
have to do the difficult stuff less often.

MD is a device for enabling the content to be less cluttered. It's not full
separationg from presentation, but it's good enough.

Different people have different itches. And so MD forks in a multitude of
ways.

If someone wants order they have to *want* it enough to put a fair amount of
work on it.

They would have to document the edge cases, badger each developer to fix the
bugs, and nudge toward concensus. Possibly write dialect transform programs
to make moving stuff between one dialect and another.

One objection to configuration has been document portability. Alas we don't
have that now because of the multiple forks. Mind you adding configuration
could well make this problem worse, unless there is an umbrella organization
to use configurations to make forks more compatible instead of more
different.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20100321/8070eadb/attachment.html>


More information about the Markdown-Discuss mailing list