This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]
TitleSupport superscript/subscript formatting
Date26-Aug-2005 13:05:01 EEST
JSPWiki version2.2.28
SubmitterGregorHagedorn
Idea CategoryMarkupIdea
Reference
Idea StatusNewIdea

In scientific discussions, sub- and superscripts occur relatively frequently, often including letter or even words (x<sub>max</sub>). In consider it highly desirable to add this to the JSPWiki markup rule. Otherwise such communities can use JSPWiki only with html formatting turned on.

Current usage samples:

Both MediaWiki (= Wikipedia) and ~TWiki support xhtml by default and this is used for super/subscripting.

MoinMoin uses ^superscript^ and ,,subscript,,

OpenWiki uses ^^superscript^^ and vvsubscriptvv (the latter seems undesirable to me!).

FlexWiki uses ^superscript^ and ~subscript~

Proposal:

to keep in line with current JSP double-character formatting, ^^superscript^^ and ~}}}subscript{{{~}}} seems to be a good option. The use of tilde should not conflict with existing use of tilde as escape character (no-link or escaping double underscore, double backslash). A triple tilde could be interpreted as literal double tilde, i.e. escaping the subscript rule. (Note: at the moment a double tilde is displayed as single tilde, i.e. tilde escaping tilde, but this could be modified in the engine). ---- Use CSS for %%(vertical-align:super;)superscript%% and why not also for %%(vertical-align:sub;)subscript%% -- JanneJalkanen The examples show differently than I would expect for subscript (the entire text is half-line lower /higher, not formatted as subscript). Also I believe that too much reliance on CSS really goes against the grain of separating semantics from presentation. The latter (incl. for different media, e.g. aural) should be achieved through style-sheets. You cannot define the presentation of inlined CSS commands... I believe basic formatting capabilities should be supported in WIKI notation. -- Gregor Going for real sub and super stuff, you probably also need some smaller font like this: ;:Use CSS for %%(vertical-align:super;font-size:.83em;)superscript%% and why not also for %%(vertical-align:sub;font-size:.83em;)subscript%% Of course, you can always define your own css class so that formatting really becomes easy. Add following to jspwiki.css {{{ span.sup{ vertical-align: super; font-size:.83em; } span.sub{ vertical-align: sub; font-size:.83em; } And following line should do the job. Quite readable I would say - and semantics and presentation are now separated.

   CSS Class for %%sup superscript%% and %%sub subscript%%
resulting in superscript and subscript, i.e. rendered in html:
<span class="sup">superscript</span> and <span class="sub">subscript</span>

--DF

The last proposal is acceptable from a usability standpoint. I still don't like it because it makes the content much less portable and interoperable than using standard xhtml markup for the purpose. For example, indexing engines will know how to treat <sup> or <sub> but not the span classes. Note that I added "span." in front of the CSS, else it will not work (original example defined CSS for sup/sub elements).

-- Gregor Hagedorn.

Hmm... Looking through the XHTML docs and trying to figure out possible use cases, I certainly see the need for super/subscript. However, considering that you're the first one in four years to argue for it more than in passing, it seems valid to say that it has not been exactly in high demand so far ;-).

I don't like the double-hats, because I'm probably going to reserve them for another purpose (reverse headings, it's confusing, don't ask, comes from SocialText, there is a request to mark more than the three kinds of headings with the logic reversed). ~}}} might be fine, though it may be confusing (an escape character should always be an escape character, IMHO.) If we can work out the proper markup, I can take them in 2.3. -- JanneJalkanen idea: {^superscript^} and {_subscript_} -- Daggerbox More ideas: Why not keep the %''''% syntax but let the engine recognise a number of special cases, which are expanded into real xhtml tags instead of SPANs or DIVs. I see readability and ''rememberability'' of wiki markup as a main advantage. {{{ wiki markup for %%sup superscript%% and %%sub subscript%%

--DF

I really like the idea above, it is flexible and extensible. Better in fact than introducing tons of new markup codes. As I would conceive it, the %%token text%% syntax would have two variants:

  1. For an enumerated list of xhtml elements (which might be both block-level and inline elements), token is interpreted as xhtml markup with that element. Proposal for a list:
    • sub, sup, u, em, strong, code, samp, kbd, q, ins, del
    • Perhaps also b, i, tt. This would make the special markup ("__", "''", "{{") basically a shortcut for the general method.
  2. For all other names, token is interpreted as a CSS class name applicable to either span or div elements.

There is one complication to this idea: it would require with to keep a stack of closing elements while rendering. With simple inline rendering, any could be a </span>. However, to support multi-level div tags plus additional inline-span, such a stack would have to be implemented anyways (perhaps already is in the new 2.3 renderer?). Thus when encountering %%sup text%%, the renderer could render "<sup>" and push </sup> on the closeStack.

-- Gregor Hagedorn (2005-8-31).

The 2.3 renderer already has a "span stack". So it would not be such a difficult addition. Another possibility - since we now have the new renderer - would be simply to enable HTML for some particulars like <sub> and <sup>. BTW, <u> is deprecated in XHTML 1.0 (i.e. not supported in xhtml strict, GH), so unlikely to make an appearance.

XHTML would have the advantage of not being fuzzy with spaces, for example.

-- JanneJalkanen

Not sure which I prefer. xhtml is well known and low learning effort for most users. One advantage of the current non-xhtml support is however, that it is easy to discuss about html (and other xml schema, which may incidentially use same-named elements).

Thus when going for more general xhtml support for selected elements, a block-level escaping method that is not tied to the use of xhtml:pre is urgently required. The problem with pre is that where long lines exist (in xml data often several hundred - unlike xhtml most xml data are not mixed content and whitespace matters!) we have no wrapping and the wiki content becomes unreadable. Many pages on this wiki suffer from this problem already.

(In fact - dreaming - it might be desirable to redesign the properties settings into XHtmlAllowed, XHtmlRenderedByDefault, and then have block or inline level markup such as <wiki:RenderHtml></wiki:RenderHtml> and <wiki:VerbatimHtml></wiki:VerbatimHtml>. This would allow to run a wiki where xhtml is allowed, but does not need to be always escaped, but can be turned on in specific places.)

BTW: Perhaps the () for percent-CSS direct styling is unnecessary. Instead of %%(color:red;) text%% JSPWiki could simply support %%color:red; text%% or %%color:red text%%. That is part of the %% syntax is that the first blank ends the markup info, and that a colon indicates direct styling. Second thoughts: some combined CSS commands (font:, margin: require blanks. Although single command alternatives exist for all these, the above may not be such a good idea. A variant might be: if colon exists, CSS styling commands until first semicolon-blank combination...

No. We won't change existing markup, unless absolutely necessary.

BTW2: In regard to deprecation, in xhtml 2 all presentational elements including <i>, <b> and <tt> will be absent - except <sup> and <sub> (sic!). It may be desirable to switch the engine already to use logical markup likee strong and em instead of b and i.

-- Gregor Hagedorn (2005-9-1).

Add new attachment

Only authorized users are allowed to upload new attachments.
« This particular version was published on 02-Sep-2005 23:16 by Administrator.