> > 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.
_______________________________________________ Markdown-Discuss mailing list [email protected] http://six.pairlist.net/mailman/listinfo/markdown-discuss
