HTML reference for story posting 

HTML/CSS Quick Guide

Updating this reference has made it clear that it is now so long that some information is hard to find. The site capabilities also change and improve over time, so there is a need for a quick reference guide listing simply the HTML tags we allow, whether they may or may not be classed, and the basic CSS preset classes we provide.

For more specific information, see the full reference below. Hopefully this will make debugging story HTML for pioneer authors using these features easier!

Allowed HTML tags

Tags you may add classing to are shown in bold in this list. Tags that are repurposed and have a different display style or usage here from the standard default W3C meaning are highlighted in red – please ensure you read the full reference document carefully to understand the changes.

Preset CSS classes

HTML in MMSA

What is HTML?

HTML is the acronym for Hypertext Markup Language, the format for all web pages on the Internet. It is what gets sent to your web browser by a website server, and is decoded to show the webpage you see. You are reading HTML right now!

Because of the way the World Wide Web was cleverly added as a layer on top of the much older, very basic text-based Internet, which only used to handle newsgroups and email, HTML is restricted to a quite small number of US keyboard characters, numbers and symbols. As a Markup Language, it uses a simple system of different tags to surround content describing (or marking up) what that content is – a heading, a paragraph, a table, or content within one of those elements that should perhaps be highlighted or treated differently in some way. Because those tags are short words or abbreviations, an HTML document is usually easily human-readable, desite being designed for a computer browser to interpret.

HTML was never designed as a language that had fine visual formatting options – it came from a point in computer history where the GUI or Graphical User Interface was still relatively new. Simple style changes like bold or italic were available, but there were few standards and how they were interpreted was left up to the browser and the whims of the browser writers, who were competing for dominance without much co-operation on consistency.

To fix this, a supporting standard has grown up and become embedded: Cascading Style Sheets or CSS. This allows almost every HTML tag to have how it is displayed defined in a way that is entirely separate from the HTML in the webpage, and in an independent way that should match in any browser. This deliberate separation of form and function, and the complex new features in CSS, have been critical for the recent growth and jump in quality of the World Wide Web.

What you have to be aware of is that this site must convert all stories into HTML, so that we can then display them by sending them to a reader’s web browser. We do not keep the original file or format of your story, whether it was RTF or text. Additionally, if you submit stories in HTML then we validate and possibly reformat it to check that you have not used any tags that are unsuitable for simple formatting of your story on the site.

There are thousands of excellent HTML tutorials on the web if you want to learn more, such as the W3Schools HTML Tutorial site.

Do I need to think about HTML when writing?

In general, no. If you are used to writing in a word processor and getting all the features that offers, like grammar- and spell-checking, smart quotes and auto-correct, then there’s no need to worry about HTML. Just upload and the site parsers will do the work of converting everything. Our goal is to make your story appear as close as possible to what you originally wrote, within the limits of the overall design skin for this website. Some formatting and writing errors can also be fixed by the parsers.

However, since parsing is an automatic process and writers are free to write in very idiosyncratic ways, sometimes some manual intervention is required to edit the parsed results into a better rendition of the original. That is perfectly normal and we are always happy to help out if asked, if you are unable to edit the HTML yourself.

The main problem some authors may have, that requires a little knowledge of HTML now, is the way the parsers convert quotemarks to HTML tags, instead of them being merely text symbols. This means that quotemarks have to be written in a standardised way for the parsers to understand them clearly and tag them correctly. It also requires that typing errors such as missing quotes and incorrect punctuation/spacing around quotemarks must be robustly checked by us, so we may prevent posting if errors cannot be automatically corrected due to the broken HTML that this would produce.

For more information on the way quotes are handled by this site, read the discussion below: Quotes in MMSA.

I am familiar with HTML. Can I upload in this format directly?

Yes! Use the upload browser, and make sure that your file is saved with a .TXT suffix. Do NOT try to upload whole web pages enclosed in <html> and <body> tags, just the story text split normally into paragraphs using <p> and header tags. You can also copy/paste your HTML source directly into the edit box at the bottom of the new story upload page. When previewing, the box there contains the current source for your story which you can continue to edit until you are happy with the results.

Writing directly in HTML with CSS means you can be more specific about the look and layout of your story, and you can make sure that the correct entities are used for unusual characters and symbols. There are many restrictions on tags, however, which are necessary to ensure stories do not break the site page display, and a few style tags may not work as you’d normally expect. This is explained in the next section.

Remember that we have to validate your HTML and fix any obvious errors, and that process may cosmetically reformat the code in style slightly, even if the original code was valid.

What tags can I use?

Most simple formatting and layout tags are allowed. For basic text style changes you can use <b>, <i>, <s> and <u> tags:

Text can be bold, italic, strikethru and underlined.

Note that the tags <strong> and <em>, which are often used to create bold and italic effects, have a different stylistic purpose on this site and will NOT appear with those styles here. The repurposing of <em> on this site is explained below in the section on writing quotes in your stories.

More unusual styles are subscripts and superscripts, created with <sub> and <sup>, and changing the size of text. Since this site is now aiming to be HTML5 compliant, the <big> tag which used to be matched with <small> cannot be used, so for this purpose you should use <strong> instead. For monospaced (teletype or quasi-digital output) use <code>:

H₂O has a subscript, 20^th Century has a superscript.
This is big, this is small, this is monospaced.

There are two other important non-structural markup tags allowed: the use of <q> and <em> to mark up dialogue and emphasis respectively, which is rather complex and goes far beyond a matter of visual style, is discussed in the main section below on writing quotes in your stories.

Paragraphs (enclosed by <p> tags) are the most common structural markup tags you will use. They are a special kind of HTML element: they are containers for enclosing/grouping content. Their tags do not need to be explicitly closed if followed by other containers or section elements, like horizontal rules, lists, tables, headers and <div> tags. (Leaving off closing </p> tags is W3C recommended coding practice as it makes the HTML smaller and simpler – our parser will validate the necessary tagging for you in a code style that we hope you will find readable and easy to debug.) They have spacing/indentation rules defined by your author preferences. Unless contained in a list, table cell, header or a <pre> section, ALL text content must be explicitly coded within paragraph tags.

Header tags (<h2>, <h3>, <h4> and <h5>) are used for section breaks and titling. These tags must ALWAYS be closed. The largest is <h2>, while <h5> is the size of body text (equivalent to a whole paragraph marked in bold). They are always displayed in bold, so you do not need to add <b> or <strong> tags in them (which will be stripped out anyway). If you set whole paragraphs with <strong> tags they will be converted directly to <h4> headers. <h1> and <h2> headers are generally reserved for the overall webpage titling, so we recommend you do not use any larger than <h3> in your stories.

We previously allowed the use of <blockquote> to indent content, but that tag is reserved in HTML5 for setting actual quoted text, and the indentation is a trivial piece of style for which we now provide other means of setting, so the tag is no longer accepted and will be converted instead to paragraph classing. You may though add indented horizontal rules between story sections with the <hr> tag, like this one:

Recently added to our HTML permitted tags is the <span> tag. It is used identically to the allowed style tags but has no intrinsic style of its own: it just groups text characters or other elements so that a CSS style can be applied through it. It can ONLY be used INSIDE containers – to group or style whole containers you should use the <div> tag. We now allow a user CSS style block to be added to stories, so you can add your own named style to <span> tags directly if the basic style tags are not sufficient (see the section below: CSS in MMSA).

You can also use the lang attribute on <span> tags (and only those) to set the language correctly on exceptional phrases or sentences (or perhaps dialogue) within a SINGLE paragraph or other container. This is described fully in the next section. This is one of the few circumstances where we allow tag attributes or parameters other than classing, as most HTML tag attributes are legacy additions to the language now superceded by better and more comprehensive CSS options.

Another newly allowed tag is <div> which defines a document division or section. You can place any type or number of elements (paragraphs, headers, lists, tables or rules) within <div> tags, and then apply an overall style to the section, such as indenting it or putting a border around it. Without a specific user style set, this will not otherwise display anything. We provide a helpful preset style for you, which centres and puts a neat black outline around content – you could change the outline colour and thickness, or make it dotted or dashed, by adding your own user style to this particular named style (demonstrated further below):

You may now use ordered/unordered lists, set with <ol>, <ul> and <li> tags. An unordered list is used where all list items have the same priority, and any ordering or numbering is unnecessary. Ordered lists are ALWAYS numbered in some way. How they display can be changed using optional tag parameters: reversed which makes the list numbering count backwards; start="n" where n is an integer, setting the number to start counting from; and type="x" where x can be one of a/A/i/I to change the numbering style from decimals to abc/ABC or Roman numerals in lower or upper case. Note carefully below the default list styling: automatic indentation and numbering/bulleting, and the alignment of any text added inside the list after the opening tag but BEFORE any of the list elements, acting like a list heading. By using CSS (discussed later) all this including the bullet style of unordered lists can be altered.

Lists cannot be contained within other kinds of containers like paragraphs. (These may all be contained in <div> blocks, though.) Lists can normally be nested or appear in table cells, and even have paragraphs or headers inside, but we do NOT allow this as the nesting would confuse our HTML parser. The HTML fragment above illustrates that it is not necessary to close the internal <li> tags as they are implicitly closed either by following list items or the list’s closing tag. (This is the W3C recommendation for HTML coding style which the site follows, as it makes for simpler, cleaner HTML.)

The <pre> tag creates a very special kind of container, one with monospaced output that retains all white-space (where HTML normally discards any white-space characters past the first it encounters) – in other words, the browser displays the HTML code EXACTLY as written (apart from processing tags/entities). If you need to set monospaced, tabular output with specific numbers of spaces between columns so that they line up horizontally, or computer code that requires correct indentation, this is the tag you should use, NOT <code>, because despite the tag name that will still have spacing automatically condensed by the browser (it is treated as just a monospaced style tag). Please avoid setting long widths of text this way, however! By preventing text from wrapping inside the browser window, it forces narrow browsers (like smartphones in portrait mode) to provide horizontal scrollbars, which are annoying for readers since they cannot see the full content width.

Within all containers you can break text lines with the <br> tag (although within <pre> sections all code line-spacing/breaks are honoured so the tag is not necessary). You can also use <wbr> which allows browsers to optionally split a long line of text at the tag if needed to wrap it within the window, where there are no hyphens or white space to do this. It would be MUCH better practise to avoid the need for this, however. Without this tag, very long text words would force a narrow browser to provide a horizontal scrollbar, which is annoying for readers. Note that <wbr> tags cannot affect the non-wrapping behaviour of <pre> sections. If your browser width is narrow, you may even see the tag in action in the code example below, allowing the line to wrap:

If you need to do the opposite – PREVENT important phrases or any text from breaking across lines, leaving parts widowed or orphaned – there are two methods you can use. The first is to replace spaces in the text segment with the non-breaking space entity &nbsp; which is treated as a character rather than whitespace. (The site parsers always do this for dashes, to keep the dash connected to the word it follows so it does not end up orphaned on the following line.) However, this does not stop the browser from line-breaking at other characters like hyphens and slashes, and can be cumbersome for more than a few words in sequence. The better (and more code-legible) option is to use CSS, so we provide a helpful preset style class NW that can be added to <span> tags, which simply styles anything within the tag as white-space: nowrap:

NEW: HTML tables can now be coded and styled directly.

Most recently, we have added support for HTML tables. While these traditionally present tabular information with headings, they can also be used to set up grids of text, perhaps with images, for very interesting story layouts. In fact, some recent stories requiring unconventional layouts inspired the addition! Tables can be rather complex because in almost all cases they require significant additional styling to improve the design from the site-default settings. We strongly advise that you familiarise yourself with CSS before attempting to use them, as the results will otherwise be sub-optimal. We will provide assistance and advice on design, however.

Table coding requires three elements: the outer <table> tag is the crucial container, then within the container all content must be held in cells arranged in rows. Anything outside cells will NOT be displayed! Each row is defined by a <tr> tag and cells within the row are defined either by <th> or <td> tags – these names display their semantic difference as intended either for headings or data. Generally, <th> header cells have a different styling to match their intended usage – for this site their default text styling is bold and slightly larger than <td> data cells. By default, tables have no gridlines. Cells (and the containing table) can have borders added on each side independently to create any variation of grids, but this must be done with CSS.

Apart from the cell tags and rows, the outer <table> tag can also be styled with CSS, perhaps to add a border, force no wrapping of all contents in cells, or to change the overall width/position within the story page. There are two important tag attributes for cells which we support: colspan and rowspan. By setting these, a cell can take the width of any number of cells normally in a row (spanning multiple columns) and/or cross multiple rows vertically down. This is a powerful feature that can allow very complex tabular layouts. In the simple example below, note how the cell spanning multiple rows is ONLY defined in the first row it appears in. For clarity here, a light blue border has been added to all cells to better display their extent and the default alignment (left) and padding (none) of any contents:

There are other legacy cell tag attributes which we do NOT support as they are now better handled through CSS: valign and halign (the old pre-CSS ways to set vertical and horizontal alignment) and those for cell padding and spacing. By default in this site, cell text is all aligned to the top of the cell, which means text in different sizes (like bigger headings) will not line up vertically in adjacent cells. This can be fixed by setting the CSS property vertical-align: baseline instead on cells, or the whole table. Vertical centering with vertical-align: middle can also be useful. Basic text alignment (left/right, justified or centred) is similarly changed with the CSS text-align property. Cell padding (the CSS padding property) adds a margin around cell contents so that they do not butt up to borders or cell edges (something definitely needed given the default shown above is none!), while cell spacing separates the cells themselves within the table (meaning gaps between borders if added).

There is one thing that you must always be aware of when designing HTML tables: browsers will seek to compress them to the narrowest possible width. This is actually good, since a user may have a narrow browser screen like a smartphone in portrait mode, but means that text will wrap down to single word widths in cells if allowed, and you cannot be sure how your grid will appear unless you design for it carefully. If you want some text not to wrap, you will need to force that using non-breaking space entities or CSS (perhaps with our preset no-wrap NW class). Where you want cells to take up a particular proportion of the overall table width (especially similar data columns that should appear with the same width if possible) it is advisable to force this with CSS: min-width: 20% (note the use of a percentage value).

Using and styling tables effectively is a bigger subject than can be covered here, so check online guides for help. But do consider them for creating unusual layouts and ask for advice if you need help building them. We may actively assist anyway by tweaking sub-optimal designs for you before stories are approved.

Are tag attributes/parameters allowed?

Generally, NO. Other than for enabling <span> tags to indicate language (described below), the only exceptions are the parameters noted above for the ordered list tag <ol> and the row/column spanning attributes for table cells. All other legacy attributes are covered by CSS styling.

But importantly, we do NOT allow direct styling of ANY tags (using a tag’s style attribute). Any/all styling MUST be applied with pre-defined named classes (using the class attribute). Classing is only allowed on <span> and <div> tags and most container tags and subtags EXCEPT <li> tags. It is NOT allowed on individual style tags, although there is a method available for a user style to be applied to ALL instances of a particular tag in your story.

We provide basic classing for paragraphs and headers to allow simple text alignment (centering, left and right justification, full justification and indenting) and to help with one quoting situation with <q> tags, covered below. You can also use our preset OUTL outlining class described above, and the modifier class ROUND for rounded corners, if only a single paragraph/header or other container needs setting this way:

This is indented (both sides).

This is centred.

You can set text
right-justified too.

Single paragraph outlining!

And with a rounded border...

Apart from those named classes shown above (and the NW no-wrap class already mentioned which simply styles content as white-space: nowrap), you can define your own specially named classes to apply to these allowed tags, or style other tags generally, using a CSS definition block at the start of your story. Doing it this way allows style definitions to be given ONCE and not be littered through your story text, which makes the story code far harder to read, debug and parse for validity. The section below on adding a user CSS block to your story explains how to define and use named classes in your story text.

NEW: setting language markup on a word, phrase or sentence.

We have now added the ability for <span> tags to be used to markup language changes that are entirely within a SINGLE paragraph or other container. (For longer story sections there is a non-HTML method using a special embed mechanism as described in our main submission FAQ).

This uses the standard lang attribute on the tag, but you CANNOT set this on any other tag, you MUST mark up your segment in a <span>. The format must be followed strictly, using standard ASCII double quotemarks, or the offending HTML will be reduced to displayable text for safety. If you use a <span> tag to set language this way, you cannot ALSO use it to directly set a special named CSS class on the tagged segment, although if you have set a style affecting all <span> tags in a story (using the CSS support described below) that will still work, or you can simply nest this <span> in another that can have a class applied.

Note that this does not by itself make any visual change to the tagged text, it is purely informational to the renderer (web browser or device such as a text-to-speech machine) which may choose to handle this language differently if appropriate. It should probably be used SPARINGLY to mark phrases or sentences, rather than single well-known words which might commonly be used across many languages (such as café or Schadenfreude).

Further, note that it is absolutely WRONG to include quotemarks INSIDE these language change tags. While it might at first glance seem correct to put French quotemarks around a sentence spoken in French by a character, the convention is that the written language of the CONTAINING story (or paragraph at least) is used as the correct form for ALL dialogue quotemarks in that story, WHATEVER language is being spoken. So if you want to mark up the language of a line of dialogue specially, make sure these <span> tags are INSIDE the quotemarks, not outside.

What about entities?

Use them freely. They are the only way to describe reliably many symbols and non-English characters in HTML. Keep in mind that it is far easier to debug and edit named entities than numbered ones, however.

A few you should probably become familiar with are &nbsp; the non-breaking space (very useful for keeping two words or numbers joined when you do not want them split across lines), &ndash; the long dash or en-dash and its longer brother &mdash; the em-dash (both of which should be used with the non-breaking space after words to ensure the dash is never orphaned to the next line). Short hyphens are only used to link words, so these dashes should be used in all other text situations.

Avoid using the &hellip; entity (ellipsis), as it often looks strange (and is code-wasteful) compared to just writing three full stops. The site parsers ALWAYS remove and replace this with three dots. Writing quotemarks with named entities is also strongly discouraged. For the best results you should be using the <q> and <em> tags to define your quotes, and all Latin quote entities (even international ones like guillemets or chevrons and European lower-9/upper-9 quotemarks) will be converted to those. (See the main section below on writing quotes in your stories for more information.)

The only quasi-quote entities that will be left, and converted to where possible from single apostrophes and quote symbols next to numbers, are the &prime; and &Prime; symbols, meant for marking feet and inches or minutes/seconds, which we strongly recommend you use:

I am 5′6″ tall.
I am holding a 12″ ruler.

What about hyperlinks?

For site safety, we do not allow hyperlinks in stories. We cannot guarantee the content on the end of any link that goes outside this web domain, and even if the link is valid and the content acceptable when we approve a story, it could be inadvertently or even maliciously changed to illegal or dangerous content without our knowledge later.

However, we now implement a system that allows links WITHIN our domain to series listings and other stories to be embedded safely in stories. Other links with <a> tags will be safely neutralised so that readers cannot click through them. We do encourage providing URLs to acceptable images, websites or specific webpages (where they are pertinent to your story) in a non-clickable form though. As this does not now require any knowledge of HTML, or story submission in HTML format, these new embeds are explained in the main story submission guide in the section on special archive features.

The off-site URL tagging we are implementing does bear close relation to the underlying HTML, though, and could conceivably be user-styled, so here’s a repeat of that information. To help both us and readers, we would prefer you to enclose any URLs you provide in your story in square-bracketted pseudo-tags as shown below. When the story is displayed, the pseudo-tags will be replaced by proper HTML <span> tags that will provide a neat, site-consistent style for these URLs: bold text, a subtle mouse-over background change and some added spacing.

This will help readers pick out the URL clearly from the surrounding text and the extra spacing provided through CSS may also make the URL easier to copy and paste without picking up extraneous characters (especially punctuation) accidentally. If the CSS style needs altering to suit your story better, you will be able to over-ride it as shown in the next section. Adding the pseudo-tag bracketing will also help us in future, if we need or choose to handle links differently, as these URLs are then already picked out clearly for further processing.

The new system of embeds will also allow displaying images in stories, but only those approved and served from our own server, where we can guarantee they cannot be altered later. External images will not be linkable: you would have to supply a direct URL in your story and trust that the image will not be moved or altered on the external site. This feature is still in development, but special styling of any image display should also be possible by arrangement. Contact us directly or ask in the Forum for more information on embedding images.

CSS in MMSA

adding user styles to your stories

As described above, CSS, or Cascading Style Sheets, is the specification that your web browser uses to decide how to display a web page to you. The HTML defines what everything on the page IS (a table, a paragraph, an input button or a few words of text that need special emphasis), but the CSS defines how it appears or behaves in your browser.

Being a web story archive implies some basic rules, just like any other library. If you walked into your local library you would expect to find some consistency – fairly normally sized books displayed on relatively same-spaced shelves, books mostly containing black type on white pages, all following normal typographic rules so that they are easily readable etc.. Therefore, this website has a style sheet that makes all our pages display in a consistent way, by defining the appearance of all the tags and elements we use and that can be used in your stories.

That consistency is great for readers, but sometimes authors want more effects than can be created with basic HTML and simple tags: a special outline round some words, or a special colour, or a different method of bulleting lists. Within some sensible limits, we want to give flexibility without opening the site to abuse or complicating the site code handling by having to validate every possible variation of classed and unclassed tags. We have written special HTML on request for authors in the past, but that creates problems later as stories cannot easily be updated, because our HTML validator strips out anything unusual or normally disallowed. So we are now implementing a simple general system for adding a few user styles to your stories for those technically able or interested in experimenting.

Please note: this section is NOT going to be a primer on CSS. It assumes you understand the basic concepts and have an idea of how you want to change a specific style, or that you are willing to read some of the many web tutorials for better grounding. CSS is complex and often hard to debug, and integrating user styles safely into our site so they do not accidentally break our pages is critical. We will provide basic boilerplate solutions and examples that you can add to a story to tweak some of our existing tags or add new styling, but any use will of necessity be carefully moderated and discussion with us of the effects you want is STRONGLY encouraged.

Remember: we cannot allow raw styling on tags, or classing outside a very few exceptions, so creating a special named class style and applying it through a <span>, <div> or other container tag, or restyling ALL the tags of a specific type in your story, is the only way to get a CSS effect that we do not normally provide.

For the technically curious, here’s how it works: CSS styles are overlaid (or cascade) with three priorities. The first/lowest layer is any external CSS file linked to a webpage. We provide that for all site pages, defining the archive’s overall design. The next layer is any set of styles defined directly in the page, in the HTML headers. Anything defined there over-rides the site CSS file definitions only on that page. The highest priority layer, that over-rides all the others, is any style written within the HTML body in the style attribute of a specific tag. That last layer is the one that is hard to validate and debug, and is highly code-wasteful if definitions are repeated on multiple tags, so we are disallowing that entirely in stories.

What we CAN allow is special classing, defined once, that can be applied to a limited set of (mostly) container tags. Therefore, any user styles have to be validated and inserted into the page headers, where we already set up an author’s language-specific quote and paragraph style preferences for their stories through CSS.

To do that, you need to set up a style block at the top of your story. It MUST be the very first thing in it: any text in front will be deleted! The block is extracted when a story is viewed and combined into the story page headers, so readers will not see any code as text. This is NOT standard HTML, but a format similar to the text embeds we already support for story and series links and language setting. The format is very simple, using square bracket pseudo-tags to contain your standard CSS code:

This green text will not wrap.

Note the dots in the style definition between the tag name and the class name. That is what restricts the style to tags of ONLY that class. If the definition had been DIV.STORY SPAN without the class name then ALL the <span> tags in the story would be in green. This is perfectly valid and could be all that your story requires – maybe you want to style all the <pre> sections in a special way, or add extra styling to all the italic text in <i> tags. Setting a general style on a tag like this is the only way to get around our restriction on containers only being classable.

The naming of the class is important. It MUST be consistent and is case-sensitive. We now allow you to define any name (containing alphanumerics only but starting with an alphabetic character) for complete flexibility, but we STRONGLY suggest you stick to eight specially named user classes: S, T, U, V, W, X, Y and Z. That way there should be little chance of your styles overlapping with other pre-defined classes on the site, which could have strange unwanted effects hard to debug – although YOUR classes will be restricted to the containing story DIV, all general style classes defined in our main CSS file affect EVERYWHERE in the site, including your story, so an overlapping name would already have unwanted styles defined. For simplicity, you need to create fresh and unique named classes of your own.

Classes can be defined for <span> tags as shown above, or for any other tags we allow styling on in exactly the same way. Note that a definition of DIV.STORY SPAN.X will not conflict with another one of DIV.STORY DIV.X in any way, and can be entirely different, because in that case each class definition is tied to a specific tag and ONLY the definitions for style X associated with the relevant tag will be applied. If you wanted a single class X that could be applied to BOTH tags (and indeed any other we allow classing on) then you can define it as a general class not tied to any tag:

Note how the class name still requires a leading dot. Now you could use class="X" in both <span> and <div> tags to get the same effect. This is just an illustrative example, though... making whole <div> sections non-wrapping and large sections of your text coloured isn’t a great idea, and will definitely be discouraged. But this does demonstrate that just eight named classes can be greatly extended by multiplication, as there are many tags which can be styled uniquely with the same class name, as well as having a general named style applicable to any tags not specially defined with it.

To help you out and save you adding user styles for trivial cases, we have provided a few simple classes that you can add to your HTML without even needing a style block. The alignment classing (C/I/L/J/R) you can add without any style block to paragraphs and headers is illustrated fully in the FAQ sections above and below, as is another helpful class you can add directly to our allowed container tags: class="NW" makes any contained text non-wrapping, which is useful for phrases that you do not want split across lines. It is equivalent to adding the style white-space: nowrap and can be especially helpful used with <span> tags when just a few words in a paragraph need to stay linked together and never be split across lines. Where this is added to a container like a table or list, it affects all child tags (eg. table cells or list entries) of that element unless they have specific CSS applied allowing them to wrap.

Another is described and illustrated in the FAQ section above: you can add class="OUTL" to <div> tags, paragraphs, headers and other containers to make them centred within a rectangular black outlined box. If you want to change the thickness of the outline, the box spacing or alignment, or whether the outline is dotted or dashed (or its colour) then you can just add some over-ride CSS into a user style block. For instance, the following style block would add rounded corners, dots and a red colour to our standard outline:

I have a dotted, rounded outline.

Note how this is ADDING extra styles to the EXISTING class, or rather, over-riding the pre-defined ones. This is VERY important to understand when working with CSS, as it demonstrates the way styles cascade from more general definitions (ie. the ones in our site CSS file) down to more specific ones processed at a later stage so with a higher priority. This example does not create a new OUTL class from scratch, but re-defines the existing one. This happens even in a sequence of definitions at the SAME priority level, where a style setting can be immediately modified by a following one on the same class or by a subsequent one defining a more specific class on the same tag, where previous general settings for the tag will be the baseline for any modifications.

This can be made easier by using the HTML facility to combine named classes in a simple additive way. Instead of setting special CSS to add just a simple rounded outline to an outlined DIV or paragraph, or maybe to change its justification (outlined containers are set with centred text by default), you can combine a few preset classes without needing to define anything through a style block. The preset ROUND class adds the 1 em rounded outline defined in the example above, and you can set left, right or full justification using L, R or J classes (to over-ride the default centred alignment). Note how the classes are combined by separating the class names with spaces in a single statement when assigning them to the tags:

I am right-justified
with a rounded outline.

Adding borders will of course be of interest to anyone working with HTML tables, as this is how you achieve ruled grids and heading separators, by adding borders to the individual cells. Table design is one of the most complex CSS challenges you may face, so we will be happy to advise and assist with building tables in HTML/CSS. Since there are many variations of border widths, text colour and even background colours you might need, and different borders perhaps needed on different sides depending on where the cells are in the table, you may require many classes for both heading and data cells to achieve the desired result.

In this example, a few named rules define the text colour and border styles of cells individually, and are combined to create a variety of resulting styles that might eventually require far more design rules and classes for a more complex table. First, though, a basic set of rules (padding and non-wrapping) is usefully provided that affects all table cells. For illustration, the table itself has borders set by a combination of four design rules, although there is a far more efficient way to achieve that with CSS. This method does allow re-use of all these smaller rules in different combinations, however. Note how the class names are again separated by spaces when assigning them to the tags:

This example shows two important things about CSS very clearly. First, by removing all the style complexity out of the HTML and into a central location (in this case the style block, which ends up incorporated into the story page headers) the HTML is MUCH cleaner and easier to read and debug. It doesn't make any visual difference to readers, but you will surely appreciate it while writing and previewing your stories!

Second, CSS is VERY sensitive to the ordering of rules. In this case, while creating this page, it became obvious that the classes re-defining the border colour on the table cells to match their text colour needed to be listed AFTER the setting of the side borders with a grey colour (which would otherwise over-ride that). That is why the rules for classes U and V are defined AFTER those basic border settings. Simply applying the classes to the tag in apparently correct order (setting the border then text/border colour) was not effective. The correct ordering of rules so that they combine as intended is one of the trickiest things to debug in CSS.

Finally, we have added (thanks to the need in a few stories) some font varieties that provide specific display features our main site fonts do not have – currently a Thai font and a monospaced Prestige font that closely mimics old typewriter faces, giving authors the chance to create facsimiles of old typewritten documents. These fonts need to be linked through the user CSS block and applied as user styles to the relevant paragraphs or other containers – you will need to ask us for assistance with that code. We will be happy to consider other special font requests where these can be sourced easily and without copyright issues, while adding worthwhile design value to your stories.

We hope this has given you some ideas. It is not meant to be a comprehensive discussion of what is possible within the limits of what we can allow: for more information and queries about what might be reasonable to add in your stories, you should ask in the site Forum either in the HelpDesk or the Authors Only area.

adding styles for the new dark skin

When we added the new dark skin or viewing mode for the site, we created an unintended consequence for authors. It's simple enough to change automatically black-on-white text to white-on-black, but our additional CSS support allows authors to add arbitrary CSS, including colour changes, into the style block of a story. This means that it is possible (and indeed likely) to create CSS effects that do NOT work well in the dark skin, even making some elements unreadable. We needed to provide some mechanism to allow authors to submit TWO versions of any CSS changes – both for the default skin and the dark one.

As explained above, CSS is applied strictly in sequence, from lowest priority (CSS files linked and downloaded separately from the web pages) to middle priority (CSS added in the HTML <style> headers in a webpage) to highest: CSS actually in the HTML body applied to the tags themselves. We don't allow this last layer in stories to define styles, due to the additional difficulty of verifying the story HTML. But the class definitions listed in the user style block, which is ultimately inserted into the story page headers, are ALSO applied in strict sequence as written, so later rules can therefore over-ride definitions already made if required.

The solution is a simple extra marker in the style block to indicate that some definitions are ONLY meant for the dark skin, and should be applied after the others if the reader is viewing that way, modifying the default rules, or that they should be ignored if the viewer is in the default skin. That means that any style rules that do not work well in the dark skin can get an over-ride with a more suitable style that is triggered by the user changing the skin. The format is this (pseudocode):

Here is a simple example using real code:

If the story is viewed in default skin, everything from/including the [DARK] marker to the end [/STYLE] is removed. Only the CSS before the marker is left. If the story is viewed in dark skin, however, the marker ONLY is removed but the CSS after it is left to immediately over-ride the other. This is the cascading effect in action. Switching to dark skin will fix the colour of anything styled with class X from red to blue, but will leave the other definitions intact, so your X style will STILL be bold and centred.

This is EXTREMELY important to understand: you don't need to repeat the ENTIRE definitions, just any changed parts like colours which work better in the dark skin. That makes this method of switching styles quite efficient. There is a simple way to view your story in dark mode while previewing if you want to check the results of changing your CSS in the different skins.

Quotes in MMSA

handling quotes in multiple languages

This archive has to take written submissions in multiple formats/languages and convert them into correct HTML that follows a very rigidly defined syntax, while providing a good facsimile of what authors originally wrote. Having to convert everything to HTML so it is readable in a web browser creates challenges, but also interesting opportunities that ultimately benefit authors and readers.

One of our goals for a long while has been to standardise the use of quotemarks in the site. What we inherited from the old archive was the use of simple non-typographic or straight quotes which were expected in text and email submissions of the time. Due to the difficulties of deciding algorithmically how to open and close quotes in a paragraph reliably, and nest them, we continued that way for some time. A few years ago we experimented by adding support for smart typographic quotes into our RTF parser, but that was not an unqualified success. It also meant that the quotemarks continued to be hard-coded into the page and story text, which makes them less flexible for the future. After all, they are just another piece of markup that browsers should be able to handle consistently. The actual quote symbols and the way they are nested changes from language to language too, something that has to be considered on a multi-lingual site.

The oldest stories in the archive date from a time in the Internet’s history when HTML was quite rudimentary, but even back then there was support in Markup Language for quotes. Remember, Markup Language (especially so in recent revisions such as HTML5) is not really for defining the stylistic APPEARANCE of content, such as whether it is in bold or italic, etc., it is for marking up text by defining what that content actually IS. That is what makes it so useful. Some of the tags little-used outside academia are the most powerful in this regard, such as <cite>, which defines a source for a quotation. It doesn’t even display anything! It just adds the information silently into the page source for reference, perhaps to be extracted automatically later. This sort of information presentation is called semantic tagging, as opposed to mere stylistic markup.

So HTML does in fact have a quotes tag, defining passages of quoted text. It is simply <q> and is used like most other markup tags, around quoted passages with a matching closing </q> tag. Using it should display the correct quotemarks suggested by the web page language around the tagged text. However, it was virtually ignored by the browser authors for years, and when it did work, you couldn’t guarantee it would display the same in the competing browsers, so actually having it in your web pages was rather pointless and difficult to work around reliably with ubiquitous non-supporting browsers (particularly MS Internet Explorer).

With the advent of CSS or Cascading Style Sheets as a companion to HTML, so that every HTML element can be styled individually, the <q> tag has finally had a little love from the W3C (World Wide Web Consortium, who define web standards including HTML and CSS) and from the major browser manufacturers. It is now a more standardised and supported tag, and most modern browsers display the tag correctly – enough to make a shift and embrace it. The beauty of the tag is that it is more compact and efficient than using hard-coded quote entities, it provides useful information about what it is tagging, it can be multi-level nested so that nested quotemarks are displayed differently and correctly by the browser, but most importantly it can be styled with CSS.

Why is that important? Because by styling with CSS we can provide different quotes solutions for the different languages being used on the site, that more accurately reflect the proper typographic traditions of those countries/languages just as you’d find in a locally printed book, rather than a generic default of US or UK English tradition. It also means that we can provide a mechanism for authors to have some personal control over the quotemark style defaults for their own stories, now provided as a set and forget system through authors’ own account management pages.

What are emphasis quotes?

When we first had the idea of using <q> tags, it seemed very simple: all speech passages should go inside double quotemarks. That’s the international (English) standard. Some writers, however, and many book publishers, prefer that speech passages should appear inside single quotemarks. With the style setting now up to the author this is easy to accommodate, as that is just the appearance of the tag changing (through CSS), NOT the meaning of the tag. Whatever it looked like, we now had speechmark tags.

But that didn’t address the problem of words or phrases that are NOT speech which are often set inside single quotemarks. That might be the text of a sign, note or news article (is the sign speaking?) or, like the word inside those brackets, separated for emphasis or because it is ironic/sarcastic. In your inner voice as you read a story, or this FAQ, you would stress a word emphasised like that. Here are some examples that show usage of this type of non-speech quoting:

Keep off the grass! said the sign.
I read the headline: PM calls for new taxes.
The article definitely spoke to me.
The music was classical in style.
The music was painful to listen to.

In this site, we refer to those as emphasis quotes. Since we needed a unified approach to quotes that allowed support for different national styles, which would also change the quotemarks used around those words, it was obvious that these would need to be handled with tags also.

There is no support in HTML for this idea of secondary quotes, so no official tag we can use for it. However, there is the <em> tag which is specifically designed to markup emphasis. Traditionally, this has been done by showing that emphasis in italics, identically to the <i> tag (which was reviled by HTML purists as being a mere style tag, not useful markup). However, since we are free to style the site any way we wish, and since we already have a simple way to italicise text, we can co-opt the <em> tag for this and change the way it displays by adding quotemarks instead of italics. This is arguably a better use and interpretation of the tag rather than it merely duplicating function, and is fully compatible with the HTML5 guidelines.

Where normal quoted speech appears in double quotemarks (whatever those are for a given language), emphasis quotes will appear in single ones. They will not be styled in any other way (ie. no italics, you would have to add that separately if wanted). If you are used to writing in HTML, remember to use the <i> tag for styling in italics, not the <em> tag. Also be aware that, like <q> tags, <em> tags will be subject to strict parser checking as they MUST be matched (have a closing tag for every opening one in a paragraph) at all times.

While the use of emphasis quotes ought to be clear, and the types of content that demand them obvious (as shown above, anything quoted but not spoken aloud by a person or machine or reported as speech, or otherwise needing quote emphasis), there is a grey area where you could easily use either. If you are re-quoting words that have already been spoken, then you may wish to use full quotemarks around those words to reference the source. Consider the following example:

You’re just a big baby! laughed John.
I didn’t like being called a big baby.
But such a cute boy! agreed Tom.
I reminded them that this boy was nearly thirty.

Although they are being used for emphasis, full quotes there instead of single emphasis quotemarks reminds readers that the words being highlighted were actually spoken. This could be more useful when the reference is made much later in a story. As always, the process of writing is about making meaning clear to the reader, and this subtle reminder of the source of the words you are using might be more powerful than simple emphasis.

What does this mean for me as a writer?

Most authors will not need to do anything special. Where stories are submitted in text or via RTF, and they contain smart quotes added by a word processor, then those will be converted directly to appropriate <q> and <em> tags. The exact form of quotes you may have used will be lost, no longer hard-coded into the story text. The mechanism used to reconstruct your preferred quotemark style and display it in a browser will now rely on the site defaults and your personal preferences, if you choose to set them differently.

Authors who are writing or submitting in HTML should start using these tags now instead of quote entities, and are encouraged to edit their own stories to fix tagging this new way. You will notice that the new <q> and <em> tags will now appear in the HTML edit box when your story is parsed. PLEASE DO NOT TRY TO UNDO THEM OR ALTER THEM IF YOU DO NOT UNDERSTAND THEM. The story preview should show the browser representations of the tags using English language defaults for the story, until the correct language is set for it.

Note that you may now set the story language yourself when you upload it, to help identify it. If you do that, the preview will immediately show the correct national quotemark style.

To help you with proofreading, the story previews will now highlight for you in purple any paragraphs where the parsers have had difficulties identifying quotes. This may be an error in your writing (a quotemark missing, or spaced wrongly, or missing punctuation which misleads the parser in recognising a closing or opening quote) or where there has been some ambiguity and the parser cannot be sure about the decision it has made. The most likely reasons for ambiguity will be paragraphs missing a closing quotemark (correct for quotes spanning a number of paragraphs by the same speaker) and words front-shortened with an opening apostrophe, like ’til for until, or ’em as a patois for them, which appear exactly like opening single quotes. Those front-shortened words are now handled through a whitelisting system, and you will need to inform us of any you have used which are not being passed through correctly.

Note that you can replace the front apostrophe on these types of words (or indeed any apostrophe NOT quotemark that you definitely don’t want altered) with a vertical bar symbol | which will bypass the quotes parser entirely and get converted back to an apostrophe after parsing.

However, some quote errors may be impossible for the parser to guess at or fix automatically, and would produce broken HTML if posted unchanged. These will be highlighted in red, and will prevent story posting until the errors are fixed. If you are familiar with HTML, you can use the HTML box at the bottom of the preview to see how the parser has converted things and correct any mistakes there, otherwise you will need to correct them in your source file and re-upload. If you are really stuck and cannot see why the parser is reporting an error, the Forum Helpdesk will be the place to get advice and ask for fixes in the case of serious problems with any story submission.

Purple highlighting will NOT appear in your final story on-site. It may appear even if there is no actual problem with a paragraph (maybe it has been fixed), as a warning to check the parsed result very carefully. You can safely submit even when there is still purple highlighting showing, although you are strongly advised to check all highlighted paragraphs very carefully for errors. If you cannot see why something is highlighted, ask in the Forum.

Additionally, we have now implemented an extra highlighting system in story previews that shows all the quotes directly. Normal (double, speech) quotes are highlighted in green, single (emphasis) quotes in light red. As the highlighting extends to the edges of the parsed quote, you will easily be able to see if you have missed out closing quotes (where the highlight extends into non-speech text), or you have mistakenly left punctuation outside a quote or included it.

All preview highlighting can be toggled on/off, but is shown automatically for the initial preview.

What are the style defaults for different languages?

The examples below have been set in <div> tags with their language property defined in HTML. This is the same mechanism that this site uses to define the overall language of your stories for the browser. This is also a test of your current browser. If it supports the <q> tag correctly then all the examples below should display with different styles of quotemarks.

Note carefully the difference between inner and outer nested quotes. Theoretically there may be unlimited levels of nesting, with the two quote styles alternating ad infinitum, but some browsers may not display this correctly beyond a few levels. It is strongly advised that you do not test this to destruction in your stories – keep your nesting levels LOW. Your readers will appreciate it too...

Where you would use single quotes to delimit something that is NOT dialogue or reported speech, but is emphasis, sarcasm, the text of a note/sign or other non-speech element, this should now be set within <em> tags. On this site, from now on these will not add italic formatting but will instead provide single quotes in language specific versions.

Note that each of these lines, because of the containing <div> tags setting the language, needs just the following simple HTML to display all these different quotemarks:

These have been compiled from checking a number of online references. Italian and Portugese language styles appear to be the same as English. There are a few common alternatives, so this may not be the same as your personal preference, but that will be fixable if you provide us with a reference to a different convention. Also, if you are a native speaker/reader/writer and feel there are errors in these examples, let us know.

Multi-paragraph-spanning quoting

Using <q> tags presents a small problem. They MUST be balanced (opening ones always matched by closing ones) but there is one type of quoting situation where we don’t want to have closing quotemarks on a paragraph. That is where a long quote, or single speaker’s dialogue, spans many paragraphs. In that case the CORRECT way to set the quotemarks is for the first paragraph and all subsequent ones to have only an opening quotemark, and ONLY the final paragraph ends with a closing quotemark.

However, with a clever bit of CSS we can suppress the outer final quotes in the first and intermediate paragraphs from displaying. That means we still have balanced quotes, which is correct HTML, but the browser hides the bits we don’t want to show. Unfortunately, though, you have to write the HTML a little bit differently.

Currently, we allow classing of paragraphs and headers (<p> and <h> tags) to manage alignment. To get an indented, centred or right-justified paragraph you write:

To make the CSS work and suppress the last closing quote in a paragraph, you can use this form:

Note that any nested/embedded quotes in the paragraph will be unaffected. Use these M-classed paragraphs for all except the final one in your multi-paragraph-spanning quote, and a normal one to finish. The result will appear like this:

In this example, paragraph one starts the multi-quote. The final closing quote is hidden.

The second paragraph also has a hidden quotemark at the end, even though the tag is there.

And this is a normal paragraph to finish.

Note that if you are NOT writing in HTML, you should submit your stories this way – with the quotemark (correctly) missing at the end of the first and intermediate paragraphs. The parsers will assume that you want to set the paragraphs as a multi-paragraph quote and will (correctly) add the closing <q> tag with the M classing applied. However, because this could also be the result of an author typo, missing a quotemark that was in fact required, it will flag the paragraph in purple in the preview to show where this has been done. It is up to you to confirm that the parser’s guess was correct and if necessary fix any typo either in your submission file or in the HTML window.

How complex is this problem really?

Just check out this table listing many of the various possible quotemarks (shamelessly borrowed from an excellent but rather old CSS resource, now gone). Where our webpage font does not actually contain some of these admittedly obscure symbols, they may have helpfully been inserted by your browser from its default sans-serif or serif fonts.

Note that even this table does not include the back-tick character ( `, Unicode 0060) which you can type on your keyboard, often mistakenly used as an opening single quote, nor the Prime and Double Prime characters which look like quotemarks (Unicode 2032/2033, HTML &#x2032; and &#x2033;, or &prime; and &Prime;) meant for representing feet and inches or minutes and seconds, usually written incorrectly as apostrophes and double quotes.

It might seem like the tip of a Babel iceberg... but fortunately we only have European (Latin) languages to consider right now.

So what do I do about all this?

For most people, who naturally write dialogue quotes in double quotemarks normally, hopefully nothing. You only need to be aware of the difference between a dialogue quote and an emphasis quote – the latter should ALWAYS be in single quotemarks. And now that is the ONLY thing that should be in single quotemarks in your stories.

If you normally prefer to write dialogue in single quotes only, then we ask that you change to double quotes in order that the parser is not confused. You can easily change the LOOK afterwards. It is the MEANING that the parser has to understand, so that dialogue is recognised explicitly and unambiguously.

A quick test with MS Word for Windows shows that nested quotes using " characters (standard keyboard quotes) are all left as double quotemarks when they are automatically smartened. That suggests that you should NOT try to second-guess the parser by using different quote styles when they are nested, just use double quotes for ALL nest levels. This may of course be different in other versions of Word or in other word processors...

Using text editors, you should also write plain text using normal double quotes for dialogue. Where you want emphasised (non-dialogue) text in single quotes, use single quotes for that ONLY. The parser algorithm will use the spacing and punctuation around all the quotes to decide whether they are opening or closing. Hopefully reliably! It will also automatically convert apostrophes/quotes after numbers to Prime symbols for you (where you wish to write a character’s height: eg. 5′6″).

You may also need to be careful if you are writing dialogue with patois or dialect words that are front-shortened with an apostrophe, like ’til for until and ’em for them. In order that these are not mistaken for single quotemarks, words written this way have to be whitelisted for the parser to ignore them. There are separate whitelists for each language, already set up with some common words, and these are maintained through a topic in the Authors’ area in the MMSA Forum. If you need to commonly add words in your story that are not being recognised correctly, you will have to ask there or contact the site admins directly.

You can also replace the front apostrophe on these types of words (or indeed any apostrophe, but NOT quotemarks, that you definitely don’t want altered) with a vertical bar symbol | which will bypass the quotes parser entirely and get converted back to an apostrophe after parsing. Whitelisting words with us may be a better solution long-term, however.

Otherwise just write your stories and upload them, and the stories should get converted correctly with all the quotemark nesting in place. Our web browsers will do the rest. If you have any problems or queries, ask in the Forum. New stories will get the new <q> and <em> treatment, older ones will be back-converted over time.

Remember that despite the requirement to submit using double quotes, you are now able to control the eventual LOOK of your story by changing the personal quotemark styles on your stories if you are not happy with the typographic defaults above. That is what this change is all about: separating whether something IS a quote (and doing it reliably) from how it actually appears. The end result is better-looking stories with fewer errors, something that benefits both readers and authors.