Colon (:) & semicolon (;) shouldn't output as HTML definition list when used for indentation, boldfacing
OpenPublic

Description

Author: roac

Description:
Wikipedians often use lines starting with one or more colons to indent a line:
e.g.
: this line is indented
:: double indented

I recently noticed that the generated HTML contains a definition list (<dl/>).
Obviously this is not a good means to indent text. (http://www.w3.org/TR/html401/struct/lists.html#h-10.3)
Apparently, the mediawiki-syntax for defintion lists (;term : def) is being abused for visual effects.

I suggest that a <div style="margin-left: 2em"></div> is used instead of <dl><dd></dd></dl>, whenever
a colon is found without a preceding semicolon.

keywords: indentation colon semicolon dl dt dd definition list abuse parser


Version: 1.6.x
Severity: minor
URL: http://en.wikipedia.org/wiki/User:Joris_Gillis/SF
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=31146

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz4521.
bzimport created this task.Via LegacyJan 7 2006, 6:24 PM
brion added a comment.Via ConduitJan 7 2006, 7:03 PM
  • Bug 4522 has been marked as a duplicate of this bug. ***
hashar added a comment.Via ConduitJan 17 2006, 7:26 PM

well we can either:

  • add a new syntax token like '>'
  • accept using <dd> for indentation

this is indented text of some sort
also used in email for quoting!

brion added a comment.Via ConduitJan 17 2006, 7:39 PM

Lowering priority; the system works fine, it's just arguably not "semantically
correct".

bzimport added a comment.Via ConduitJan 17 2006, 7:59 PM

roac wrote:

I oppose the suggested new syntax. The ':' syntax is way too wide-spread.
Neither will accept <dd> for indentation.

I think there's an another option: just let the wiki-syntax interpreter logically seperate
cases A) when ':' is used together with ';' and B) when ':' serves indentation purposes.

bzimport added a comment.Via ConduitJan 19 2006, 12:38 PM

gangleri wrote:

Hallo!

Please remember
Bug 2020: BiDi related issues to ";", ":", "#", and "*", monobook skin etc.

Only some of the identation variants can be used at RTL projects
([[meta:BiDi_workgroup]]) by modifying MediaWiki:Monobook.css manualy.

Please note that many of the RTL or BiDi projets do not have sysops at this moment
([[meta:BiDi_workgroup/To-do#BiDi_projects_without_sysop]]).

If there is a posibility to use another implementation / coding of the page
output this would be a great help. The page source / the wiki syntax should
preserve.

It might not be easy to find the solution imediately because varius bugs in
different browsers. This has to checked in adition to the compliance to one or
another standard / specification.

*if this does not relate here please open another bug*
I am not familiar in what MediaWiki php file Monobook.css clases are defined. In
my opinion both the LTR and the RTL clases should be available by default
because BiDi projects as thouse in Kurdhish, Ladino etc. would need to use both
"environments" / would contain pages both with LTR and RTL sections. This
applies also to commons:, meta: and to any wiki.

best regards reinhardt [[user:gangleri]]

P.S. I am not shure if bug 2020 is depending on this bug. If this is the case
please add it to "blocks".

bzimport added a comment.Via ConduitFeb 1 2006, 10:12 PM

michael wrote:

It should also be mentioned that colons are widely misused to format block quotations in articles.

If there were ever some major rehabilitation of wikitext syntax, definition lists should be reformatted to display
without any indentation (bold text sufficing to reflect the intended use), and new syntax introduced for block quotes
and nested discussion.

Alternately, definition lists could be made to display differently in articles and discussion pages.

bzimport added a comment.Via ConduitMay 30 2006, 6:05 AM

ayg wrote:

I would suggest that

:foo

translate to

<div style="left: 2em;">

foo

</div>

(obviously the exact distance is negotiable). "::foo" would obviously just be
the same thing, only nested:

<div style="left: 2em;">

<div style="left: 2em;">
  foo
</div>

</div>

:foo
::bar

should be

<div style="left: 2em;">

foo
<div style="left: 2em;">
  bar
</div>

</div>

And

::foo
::bar

should be

<div style="left: 2em;">

<p>foo</p>
<p>bar</p>

</div>

From observation, this last is pretty universally what people want when they
enter two things on the same line; they don't want a simple line break (which is
what UAs would probably render for two successive <div>s, and what they
certainly render with the present <dl>), they want a paragraph break.

bzimport added a comment.Via ConduitMay 30 2006, 6:07 AM

ayg wrote:

Sorry for the double-post, just to say: I'm not sure if that "left" should
actually be "left-margin", but whichever, you get the point.

bzimport added a comment.Via ConduitMay 31 2006, 4:35 PM

michael wrote:

A couple of potential problems with rendering colons as DIVs:

  1. There are many articles where colons are actually used as definition lists, using

semicolons and colons.

  1. The HTML should somehow reflect the nested structure of a discussion page, for the

sake of non-visual or text-only browsers. Nested definition lists is actually not so bad at
this (the lack of definition terms is odd but valid, but unfortunately wikitext usually
screws it all up by closing and reopening the list after each item) -- alternatively,
discussion could be seen as an unordered (ordered?) list of statements.

bzimport added a comment.Via ConduitJun 1 2006, 2:18 AM

ayg wrote:

(In reply to comment #10)

  1. There are many articles where colons are actually used as definition lists,

using

semicolons and colons.

Certainly, any solution will have to handle that.

  1. The HTML should somehow reflect the nested structure of a discussion page,

for the

sake of non-visual or text-only browsers. Nested definition lists is actually

not so bad at

this (the lack of definition terms is odd but valid, but unfortunately

wikitext usually

screws it all up by closing and reopening the list after each item) --

alternatively,

discussion could be seen as an unordered (ordered?) list of statements.

Well, nested <div>s represent it as nested just as well as nested <dl>s do,
don't they? Compare (* used for indentation purposes only, it wouldn't be in
the actual HTML):

<div style="left: 2em;">
foo
<div style="left: 2em;">
**bar
</div>
**baz
</div>

<dl>
<dd>foo</dd>
<dl>
**<dd>bar</dd>
</dl>
**<dd>baz</dd>
</dl>

bzimport added a comment.Via ConduitJun 1 2006, 5:40 AM

michael wrote:

Well, div elements are semantically void, and are used for grouping other elements only. Definition lists imply a
semantic meaning and relationship between their parts.

bzimport added a comment.Via ConduitJun 1 2006, 5:59 AM

ayg wrote:

(In reply to comment #12)

Well, div elements are semantically void, and are used for grouping other

elements only. Definition lists imply a

semantic meaning and relationship between their parts.

Yes, but a semantic meaning complete different from the actual meaning intended.
That's significantly worse than no meaning at all. Alternatives:

  • <ul> would work. However, it would be redundant with * unless we use

"list-style-type: none;", which has near-zero support at present as far as I can
tell. Or else we could use "list-style-image:" with a blank image; is that
property widely supported?

  • We could use <blockquote>. This is possibly the most sensible, really.

Ultimately, it should be remembered that users *aren't* entering the indentation
with any universal semantic meaning; they're entering them for the indentation.
So semantically speaking, presentational markup is probably the best thing to
translate any wikimarkup into. (Remember when '' used to be <em>, and '''
<strong>?)

bzimport added a comment.Via ConduitJun 1 2006, 6:06 PM

roac wrote:

I totally support the blockquotes.
Since they are block-level containers, they can be nested.

<blockquote>
<p>foo</p>
<blockquote>

		<p>bar</p>
		<blockquote>
			<p>baz</p>
		</blockquote>

</blockquote>
</blockquote>

bzimport added a comment.Via ConduitJun 30 2006, 1:40 PM

omniplex wrote:

The behaviour of colon / semicolon should stay as is.
Div-style hacks won't work without CSS, and each colon
a new paragraph makes no sense, for that effect I can
simply add an empty line:

: indented line
: indented line (same para)

: new indented parahraph. Cheers.

bzimport added a comment.Via ConduitJun 30 2006, 6:21 PM

ayg wrote:

(In reply to comment #15)

The behaviour of colon / semicolon should stay as is.
Div-style hacks won't work without CSS

Which is a problem for all fifty people who don't use CSS . . . how does Lynx
render <dd> anyway?

and each colon
a new paragraph makes no sense, for that effect I can
simply add an empty line:

Which works until you're working on a second-level list, and the underlying list
is a UL or OL. Try the following:

#Number
#:Comment

#:Comment
#Another number

*Bullet
*:Comment

*:Comment
*Another bullet

They don't work too well. Most people, I've observed, just make do with a
linebreak when it's necessary, whereas I pedantically insert <p>s manually to
break my comments into paragraphs. But that issue is minor, I suppose.

bzimport added a comment.Via ConduitJun 30 2006, 9:47 PM

michael wrote:

Div-style hacks won't work without CSS

Which is a problem for all fifty people who don't use CSS

Divs are semantically meaningless. Using divs + css to create so-called
structure on a page is just inadequate, 1999-style markup, unworthy of
open software Wikimedia or a forward-looking project like Wikipedia.

For some perspective, see "level 4" at both:

Levels of CSS knowledge
<http://friendlybit.com/css/levels-of-css-knowledge/>

Levels of HTML knowledge
<http://www.456bereastreet.com/archive/200605/

levels_of_html_knowledge/>

bzimport added a comment.Via ConduitJun 30 2006, 9:56 PM

ayg wrote:

(In reply to comment #17)

Divs are semantically meaningless. Using divs + css to create so-called
structure on a page is just inadequate, 1999-style markup, unworthy of
open software Wikimedia or a forward-looking project like Wikipedia.

I'm well aware of the benefits of semantic markup. The problem is, 95% of our
editors are not, and they're most of the ones who are using things like :. If
you use <dd> or <blockquote> to indent it, you're saying that the item is a
definition or a quote, when nine-tenths of the time it isn't. It's usually a
comment in a discussion, or otherwise just something that someone wants to indent.

To put it another way: users are entering content presentationally, not
semantically, and adding probably-false semantic meaning to their solely
presentational input is much worse from a semantics perspective than admitting
that, in fact, there are no semantics to the input. Genuine semantics is good;
calling all indentation "blockquote" so that you don't have to use the dreaded
meaningless div is pointless from a semantic perspective. <div class="indent">
is much more sensible and honest, because that's what it was entered as.

bzimport added a comment.Via ConduitJun 30 2006, 10:06 PM

michael wrote:

Yes, but this bug and follow-up comments are an attempt to improve the situation in some way, not just throw
up our hands and give up. A definition list may not be perfect for discussions, but at least it expresses the
nested structure. Switching to divs would be discarding even this and turning the page to text soup.

It would be nice if wikitext markup for blockquotes existed. We may be stuck with definitions and discussion
threads being conflated, but maybe we can come up with some bright ideas to fix that.

bzimport added a comment.Via ConduitDec 19 2006, 7:52 PM

ui2t5v002 wrote:

If I remember correctly, the HTML spec for definition lists is pretty loose,
allowing them to be used for plays, for instance. Using them for talk pages is
not semantically wrong.

Using them for indentation is.

bzimport added a comment.Via ConduitDec 20 2006, 12:18 AM

michael wrote:

Dialogues is given as an example of other applications of definition lists in
the specification, but this still implies a term-definition relationship
between the parts. For example:

<dl>
<dd>John</dd><!-- a label for John's statements -->
<dt>Hi, how are you?</dt><!-- defines what John said -->
</dl>

Nested discussion in Wikipedia is a list of definition lists containing
definitions, but no defined terms, so I don't think it really makes semantic
sense as a definition list in the same way as a script. However, the nested
lists do imply a hierarchy, and the default indented formatting of
definitions does imply the same hierarchy in almost any text-only or
graphical web browser (don't know how well it works in screen readers).

Changing this formatting to divs would eliminate both the semantic and
visual relationship completely. This would make things worse, and not
acceptable, even if CSS was added to make it look the same in graphical
browsers.

Technically, the DTD allows a DL to contain only one or more terms, or
only one or more definitions, so there is no problem with validation.

So although using colons for threaded discussion is semantically odd, it
does work visually and semantically. The more I think about it, the more
comfortable I am with it. Since it is easy to type and is firmly entrenched
in Wikipedia talk pages, I suggest closing this bug.


Tangentially-related issue:

However, the indented display of definition lists is actually rather
unsuitable for definition lists in articles—it breaks up the left-hand vertical
line of text and looks sloppy. In countless instances, editors enter
wikitext like the following instead, where a definition list would be a
perfect semantic fit:

'''Term'''<br />
Definition

So, when both Bug 6200 (Linebreaks are mishandled in <blockquote> and
<li>) and Bug 4827 (blockquote support in wikitext) are fixed, so that
there is no longer any incentive to abuse definition lists for block
quotation formatting in articles, then the common style sheet ought to be
updated to not indent definitions, in articles only.


References:

Introduction to lists
http://www.w3.org/TR/html401/struct/lists.html#h-10.1
"Definition lists, created using the DL element, generally consist of a series
of term/definition pairs (although definition lists may have other
applications)."

Definition lists: the DL, DT, and DD elements
http://www.w3.org/TR/html401/struct/lists.html#h-10.3
"Definition lists vary only slightly from other types of lists in that list items
consist of two parts: a term and a description."

In the DTD for XHTML 1.0 transitional
http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-
transitional.dtd_dl
"<!ELEMENT dl (dt|dd)+>"

bzimport added a comment.Via ConduitDec 20 2006, 12:49 AM

ui2t5v002 wrote:

(In reply to comment #21)

Dialogues is given as an example of other applications of definition lists in
the specification, but this still implies a term-definition relationship
between the parts.

They also give an example of a recipe, where the DTs function almost like
headers, and the DD contains another list or paragraph. I think that when they
say "although definition lists may have other applications", they mean it quite
liberally. I don't think using them for threaded discussions is semantically
wrong, regardless of the fact that there are no DTs.

Since it is easy to type and is firmly entrenched
in Wikipedia talk pages, I suggest closing this bug.

That would imply that the bug is only about using definition lists for threaded
discussions, but the title of the bug is about indentation, which *is* still a
problem in articles. Things like indenting math formulas and the like.

However, the indented display of definition lists is actually rather
unsuitable for definition lists in articles—it breaks up the left-hand vertical
line of text and looks sloppy.

I think it looks good. :-) I convert things like the example you gave to
definition lists whenever I see them.

So, when both Bug 6200 (Linebreaks are mishandled in <blockquote> and
<li>) and Bug 4827 (blockquote support in wikitext) are fixed, so that
there is no longer any incentive to abuse definition lists for block
quotation formatting in articles, then the common style sheet ought to be
updated to not indent definitions, in articles only.

I disagree. We should figure out what people are semantically trying to do when
they use DDs for indentation, and provide markup and CSS to provide the same
effect the correct way. They use it for blockquotes, so we have the
<blockquote> tag instead. They use it for indentation of disambig links, so we
should build the indentation into the dablink class and remove the DD from the
template, etc.

bzimport added a comment.Via ConduitAug 20 2008, 12:47 PM

buzz wrote:

This one is really bugging me. I want to use definition lists for their real purpose and have them styled so they are inline and with slightly different default margins etc

Title: Definition
Title: Definition

but this of course messes up everywhere that : has been used for indentation. Having it so : :: ::: is parsed differently would be great. I would be quite happy for it to use <div class="indent"> or so

of course I can wrap my inline definition lists in a div and style it like that, but it seems like overcoming the problem in the wrong way

And it just seems wrong to use definition lists for indentation anyway.

Is it possible to parse

;title:defintion
and
;title
:definition

differently from

:indent
::indent

?

bzimport added a comment.Via ConduitAug 20 2008, 2:47 PM

ayg wrote:

In principle, sure.

bzimport added a comment.Via ConduitSep 5 2008, 8:36 PM

smccandlish wrote:

In response to an older comment, it isn't "arguably" semantically incorrect, it IS semantically incorrect. I don't care which of the proposed solutions is implemented, as long as its use for simple indentation renders as CSS not definition lists by the time it hits the user agent. Web markup semantics are important for accessibility reasons, among others.

brion added a comment.Via ConduitDec 30 2008, 2:07 AM

Changing summary to reflect the direction of attack we would actually follow.

bzimport added a comment.Via ConduitDec 31 2008, 8:45 PM

smccandlish wrote:

Generally I like the way this is heading. My 2 cents:

  1. General-purpose indentation should be done with divs.
  2. Blockquotes should be used for quotations, not general indentation.
  3. Definition lists should be used when the editor is intentionally demonstrating a relationship between the two parts (term + definition, character + dialogue, etc.).
  4. Ul/ol lists should not be used for things that are not actually lists.

And I concur strongly that that the present behavior of using dl/dt/dd lists for presentational indentation IS semantically invalid (not "arguably"), and that this is important to fix for accessibility and other reasons.

bzimport added a comment.Via ConduitJun 12 2010, 9:55 PM

smccandlish wrote:

FYI: While fixing this bug would be very helpful, I have to point out that there are quite a few other definition list problems in MediaWiki, as shown by some simple test cases:

http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_(glossaries)/DD_bug_test_cases

I'll probably file this as another bug (or more - there may be more than one issue here) after further investigation, and notify this Cc loop of the new bug number. But I think this may be something to do with MW's weird handling of lists more generally.

PS: For anyone pulling their hair out with vagaries of ";" and ":" markup, just use the real HTML tags, and the problems melt away. But don't mix-and-match.

bzimport added a comment.Via ConduitJul 25 2010, 9:10 PM

smccandlish wrote:

Updating bug title to reflect related problem. Colon is output as a definition list definition (dd element), and semicolon, often abused for boldfacing and creating pseudo-headings, outputs a definition list term (dt element). Both of these should be replaced with CSS, at least if they are not in an actual definition list. There are three ways to handle this:

  1. Stop connecting this wikimarkup in any way to definition lists (which would have to be HTML-coded manually, like blockquotes and various other things that MediaWiki doesn't have special wikimarkup for).
  1. Have the parser test the conditions of the markup, such that if the material is formatted like:

    ;A1 :A2 ;B1 :B2

it is treated as a definition list, but if it has blank lines between any of these, or a ; without one or more :'s or vice versa, or otherwise doesn't fit this pattern, treat it as CSS-styled, non-list text.

  1. Always treat this markup as CSS-style regular prose, unless it is inside an explicit HTML dl element, in which case always treat it as a definition list (regardless of whitespacing and regardless of missing definitions or terms).
  1. Or some combination of these. I'm marginally against option 1, and feel that 3 should usually apply (always apply in the case of explicit dl markup), but can't see anything wrong with MW doing some very limited guesswork as in option 2.
bzimport added a comment.Via ConduitJul 26 2010, 1:13 PM

ayg wrote:

I'd prefer (2). There are plenty of times I've used this for an actual definition list, and almost all of the abuses I've seen are cases where ";" isn't used at all, which is very easy to detect automatically. We should just treat ":" without accompanying ";" as <div class="indent"> or something, that's enough to fix the large majority of the cases.

bzimport added a comment.Via ConduitJul 28 2010, 9:45 PM

smccandlish wrote:

content hidden as private in Bugzilla

bzimport added a comment.Via ConduitMay 10 2011, 11:40 PM

cogden1970 wrote:

I just want to register my strong agreement with #2. I think there is a need for the association list markup, and that it should not be difficult to separate out sole : lines, or ; lines without one or more corresponding :s, for special treatment as <div>s.

Will this be addressed in Brion Vibber's parser rewrite?

Krinkle added a comment.Via ConduitMay 10 2011, 11:43 PM

(In reply to comment #31)

That would work for me too, provided that the corresponding case of ";" without
accompanying ":" be treated as a div with class="indent boldface" or whatever,
so that both abuses of def. list markup are fixed. PS: If you find that, when
you are actually using ";" and ":" for def. lists, that you can't get the
layout you want, try using explicit dl, dt, dd markup, and the problems go away
(see [[WP:MOSGLOSS]] for details).

(I'm quoting this message by S. McCandlish, posted on 2010-07-28 21:45:46 UTC becuase his original reply contained appended spam, which is the reason I hid the reply from view)

bzimport added a comment.Via ConduitNov 8 2011, 9:45 PM

sumanah wrote:

Will this be addressed in Brion Vibber's parser rewrite?

I'm adding the newparser keyword to bring it to the parser rewriters' attention.

He7d3r added a comment.Via ConduitSep 10 2012, 6:52 PM

The rendering of :'s was improved at least inside of <poem> tags to fix bug 31146 (see gerrit change 13539).

Wouldn't be possible to do something similar here?

EmilJ added a comment.Via ConduitApr 16 2013, 10:26 AM

As was pointed out on http://en.wikipedia.org/wiki/Help_talk:Wiki_markup#semicolon_issue.3F , the <dl> markup currently produced by unpaired ; or : fails validation since the switch to HTML5. Shouldn't the importance of the bug be raised?

Gadget850 added a comment.Via ConduitApr 16 2013, 1:12 PM

Since this is now an HTML5 issue, I have added it to bug 19719.

bzimport added a comment.Via ConduitApr 16 2013, 4:21 PM

frungi wrote:

As long as the software translates colons to definitions, the syntax should absolutely not be used in articles except when a definition list is what is actually desired. But since _everyone_ uses these or *lists for threads on Talk pages, could the HTML conversion be changed specifically for Talk pages?

Kulla awarded a token.Via WebNov 24 2014, 5:44 PM
Kulla added a subscriber: Kulla.
Ricordisamoa added a subscriber: Ricordisamoa.Via WebJan 6 2015, 1:10 PM
SoujaK added a subscriber: SoujaK.Via WebFeb 19 2015, 4:23 PM
SoujaK added a comment.Via WebFeb 19 2015, 5:13 PM

The issue has been recently noticed and deeply discussed also on the Italian wikipedia. For the sake of the open and standard formats (cf. Wikipedia's third pillar), validity and correctness appear to be important also for the copious discussion pages, where indentation in dialogues abound. In the quest for a solution to the problem, on it.wiki we contemplated abandoning the long-established incorrect habit of colon-indentation, or, even more unlikely, suggesting to HTML working groups a revision in the language grammar. Nevertheless, the easiest and place where one can fix such an issue is by a (most probably) small patch to the MediaWiki parser.

I am raising the importance of the this task and looking for a partner in the job.

SoujaK raised the priority of this task from "Low" to "Normal".Via WebFeb 19 2015, 5:14 PM
SoujaK set Security to None.
EmilJ removed a subscriber: EmilJ.Via WebFeb 19 2015, 5:56 PM
Quiddity added a comment.Via WebFeb 19 2015, 10:30 PM

@SoujaK There is also the issue of empty line-breaks between responses (which editors often do, to make it easier to read the wikitext, and to add a slightly larger gap between lines in the rendered output), E.g.

:1st person's comment. ~~~~
[blank line]
:: 2nd person's comment. ~~~~

This creates a 2nd definition list! This is terrible for anyone using some screen-reader software (eg NVDA, but not JAWS). The enwiki guideline cautioning against this habit, is at https://en.wikipedia.org/wiki/Wikipedia:LISTGAP and there have been some frustrating discussions about it at enwiki, over the years (e.g. archives 12 and 13 of [[WT:ACCESSIBILITY]])
(I couldn't see it mentioned in the googletranslation of the itwiki discussion; my apologies if I missed it.)

This is one of the many reasons that I initially applied to work with the team creating Flow. It has a long ways to go, in terms of features to be added and bugs to be fixed - and accessible/standards-compliant output (as you mention at itwiki) is something that needs more work - but in the medium-to-long term, that extension is likely to be the cleanest way to resolve this bug (and many many others).

As for changing the way that the parser interprets the existing :'s and ;'s in the millions of pages .... I'm not a developer, so not qualified to comment.
Hope that helps.

Mattflaschen edited the task description. (Show Details)Via WebFeb 19 2015, 10:48 PM
Kulla added a comment.Via WebFeb 20 2015, 10:56 PM

At the German Wikibooks project there is the following workaround: We have templates such as {{---|...}} for indentation. For example the code

{{---|A paragraph...

* item 1
* item 2
* item 3

Another paragraph.}}

will result in an 3 times indented block with an list inside. With

{{Formel|<math>...</math>}}

we can indent equations ("Formel" is the German word for "equation"). Those templates are mainly used in the project Mathe für Nicht-Freaks and on discussion pages (mostly for long posts because the colons don't need to be repeated for each paragraph of the post).

Technical details

The template Vorlage:Einrücken is used to indent something ("einrücken" means "to indent"). It basically has the definition

<div style="margin: 0.8em 0 0.8em {{#expr: {{{count|1}}} * 1.6 }}em;">
{{{content}}}
</div>

1.6em is the currently defined left indentation of <dd> with the current CSS. So count gives the number of indentation steps which defaults to 1 if this parameter is not defined. Actually it has some additional parameters to define the typ of the indented html block (it might also be <p> for example) and to make the content inline such as

<div style="margin: 0.8em 0 0.8em {{#expr: {{{count|1}}} * 1.6 }}em;">{{{content}}}</div>

Now we can define the templates {{-|...}} to {{-----|...}}. For example the template {{---|...}} has the definition

{{indent
 |count=3
 |html_tag={{{html_tag|div}}}
 |content={{{1}}}
}}

(I translated all variables and template names from German to English so that they are understandable)

For the template {{Equation|<math>...</math>}} one can define

{{indent
 |count=1
 |inline=yes
 |html_tag=p
 |content={{{1}}}
}}

So one can use

{{Equation|<math>1+1=0</math>}}

instead of

:<math>1+1=0</math>

Notes about inline and block content
Sometimes its necessary to control whether content is parsed as line text or not. I define content as "inline text" if you have the definition

<div ...>{{{content}}}</div>

In contrast this is a "block"-content for me:

<div ...>
{{{content}}}
</div>

When you have something like {{indent|content=test}} and we have second "block"-definition an additional <p> is created around the word "test". This is not the case for the first "inline"-definition.

Sometimes it's important to control how the content is rendered. For example

{{indent
 |content=
* item1
* item2
* ...
}}

does not work for an "inline"-definition of the content because the first asterisk is not the first character of the line. Here the content must be rendered as a "block"-content.

Definition of Template:Indent
The template {{indent|...}} might be defined as

<{{{html_tag|div}}} style="margin: 0.8em 0 0.8em {{#expr: {{{count|1}}} * 1.6 }}em;" {{#ifeq: {{{inline|no}}} | yes | >{{{content}}} | >
{{{content}}} }}
</{{{html_tag|div}}}>

with the parameters:

  • html_tag is the typ of the indented html block which defaults to div
  • count is the number of indentation steps of the block
  • content is the main content of the block
  • Unless inline is set to yes the content is rendered as an extra "block". If inline is equal do yes the content is rendered as inline text

This workaround is of course not the best one but it works with the current possibilities of the mediawiki software. Each improvement of this workaround is welcome because those improvements can be migrated to the currently used templates at the German Wikibooks project.

TheDJ added a project: Accessibility.Via WebWed, Mar 11, 8:49 AM
TheDJ added a subscriber: TheDJ.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.