(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

I would like to state here that the categorization of block markup vs. inline markup and it's implications hinder the usability of markup. The basic statement is, that this categorization is not bad, but it should not imply the number of characters we use for a certain element. This should be solely decided by the frequency of usage of the element in practice. Let me explain:

The page Hints On Extending suggests two categories inline and block, and that for inline we should use two characters whereas for block we should use three characters. It is in a sense the same kind of categorization implies writing style that let Germans capitalize every noun. Unfortunately in German speaking countries this is a frequent root of errors, because if you write down your thoughts you don't want to be slowed down thinking about grammatical categorizations.

Every categorization that is not of much use for the user but dictates the amount of handwriting is problematic. In the case of block markup it blows up frequently used code, requiring more handwriting and making the end result harder to read. Consider this example of a wiki page that makes use of "Form" plugins. Also note that it uses the notion of a supposable CSS extension element %%(color:red) xxx %% to show one more example of the issue.

Lets compare a three character approach influenced by the block markup notion vs. a two character approach influenced by the notion of "Less handwriting for frequently used markup". Here's what happens if we use three instead of two markup chars for plugin syntax because of this categorization.

Three characters

%%%noborder
|ID|<<<InputField name='id' size='25'>>>|
|Desc|<<<InputField name='desc' size='50'>>>|
|Birthday|<<<InputField name='birthday' size='25'>>>|
|Faculty|<<<InputField name='faculty' size='10'>>>|
|SSN|<<<InputField name='ssn' size='10'>>>|
|Salary|<<<InputField name='salary' size='10'>>>|
%%%

Two characters Here's an example with two characters, ignoring the block markup categorization:

%%noborder
|ID|<<InputField name='id' size='25'>>|
|Desc|<<InputField name='desc' size='50'>>|
|Birthday|<<InputField name='birthday' size='25'>>|
|Faculty|<<InputField name='faculty' size='10'>>|
|SSN|<<InputField name='ssn' size='10'>>|
|Salary|<<InputField name='salary' size='10'>>|
%%

From our experience, the two character approach is less error prone and easier to read. Three characters over two characters might just seem like a small overhead, but if you consider that you might have to use it quite frequently it quickly becomes annoying. The only reason why we choose three curly braces for nowiki and two for images, was that people, except from programmers maybe, will use images more frequently than nowiki markup. Moreover, if we would like to allow extensibility, the image syntax might fall into the block syntax categorisation as well. Consider this example, where someone extends the image syntax with meta tags:


{{BartSimpson.png|Bart|

Year:1995
Episode:25
}}

Same could be true for link syntax where semantic web meta informations are added. The problem like with every categorization is where to draw the line. Therefore I think this categorization is blurry and makes evolving of our common markup harder then necessary.

For the above mentioned reasons I would like to state that we should not let this categorization influence the choice of markup and instead solely concentrate on the goals and good practices, in this case goals of easy to write and easy to read. Less handwriting in practice should be given priority over making markup consistent based on a blurry categorization of block and inline markup.

-- ChristophSauer, 2007-Jun-03 10:42 (CEST)

Add new attachment

Only authorized users are allowed to upload new attachments.

« This particular version was published on 03-Jun-2007 10:42 by ChristophSauer.