VoteOnNestedDivMarkup-Talk


Longer comments about the VoteOnNestedDivMarkup proposals and votes.


Option 1 comments

The use of repeating <<<<<< may make pages unmaintainable and potentially unreadable.
If we already have a block markup that is nestable, viz (:div :), (:div1 :), (:div 2:), ... why do we need another?

It seems to me that markup should have a certain wikiness,

  • it should be concise (but not read like an APL program),
  • it should be easy to pick up, (one theme of complaint I have heard made of wikis is that it is yet another markup/syntax to learn),
  • it should be decipherable, the recent change to removing white space as markup is a good example of this
  • and, like all software it should be easy to maintain, ie if one small change cascades to having to fix a lot of other markup on a page it looses its maintainability


I like PmWikis? convention that most markup has both a character based syntax and an equivalent (although often functionally richer) text based syntax (eg || || and (:table:)). Similarly (or it should be) with styles, eg ''' ''' and >>bold<<.
I'm not sure that repeating characters adds to the ease of use, for example when writing

>>>>><<<<
>>>>>><<<<<<

there is a risk of not getting it right at least three times ! I don't believe (::: :::) is any better.

Use of repeated characters in existing markup

Up until now the use of repeating characters in markup has been restricted to line level markup, eg

-->indent
----<indent
::::term:   and
!!!!heading

although is some instances it can be persuaded to apply to blocks, eg ->[@ .

This repetition it seems to have some meaning, ie repeated characters lead to a change in behaviour.

This isn't the case for blocks, and hence loses some wikiness. If we are adding new markup, and particularly for blocks, where the start and finish tokens may be some distance apart, I am all in favour of keyword based markup that is meaningful, and suggest not using character symbol based syntax.


The missing option... ;) PITS:00887#Proposal2.

A subject near and dear...

Ok, a real world example for me is something like this:

>>>quote<<<
>>>quotefrom<<<
>>><<<
>>>quote2<<<
>>>quotefrom<<<
>>><<<
>>><<<
>>><<<

This is the second proposal of PITS:00887.

Now, without the including text is is a bear to read, but with the contents:

>>>quote<<<
>>>quotefrom<<<
Someone wrote:
>>><<<
>>>quote2<<<
>>>quotefrom<<<
Someone_else wrote:
>>><<<
This is in the quote2 div; (Someone_else's quote)
>>><<<
This is in the quote1 div; (Someones' quote)
>>><<<

Well, it is still a mess. Much like table directives ;)

This style of construct is how this was started for me.

I long ago moved away from the initially proposed style:

1>>quote<<<
2>>quotefrom<<<
2>><<<
2>>quote2<<<
3>>quotefrom<<<
3>><<<
2>><<<
1>><<<

For the simple reason that it is breakable when I include that page in a div (think blog entries and such like; When including pages into already formated areas anything that specifies it's div level is at risk of breaking things and leaving the author wondering what went wrong.

The second proposal is what I use in my private wiki with very good results.

More often than not I have many

>>>quote<<<
Ye olde quoted text.
>>><<<

In my pages, half of them are themselves in divs.

By not having to worry about the div level I can concentrate on writing whatever it is I am working on, With no fear of my divs breaking if I should include it in something else. (Of which I have had happen and why I initially started on trying to solve this little problem)

As such, I would like to suggest that an 'id-less' style be considered for inclusion.

But this said, I shall go vote now...

Feral April 18, 2007, at 10:19 PM
 0: 00.00 00.00 config start
 1: 00.01 00.00 config end
 2: 00.06 00.02 MarkupToHTML begin
 3: 00.11 00.04 MarkupToHTML end
 4: 00.12 00.05 MarkupToHTML begin
 5: 00.14 00.05 ReadApprovedUrls SiteAdmin.ApprovedUrls begin
 6: 00.14 00.06 ReadApprovedUrls SiteAdmin.ApprovedUrls end
 7: 00.16 00.06 MarkupToHTML end
 8: 00.16 00.06 MarkupToHTML begin
 9: 00.17 00.07 MarkupToHTML end
10: 00.17 00.07 now
Peak memory: 3,191,352 bytes