Title goes here.

Disclaimer: This is merely an exercise to improve my knowledge and gain a better understanding of dudes and dudettes, the English language and what Louis Armstrong was on (about) when he wrote, sang and maybe hummed "What a wonderful world".

Thought I'd reflect some more on online publishing. The following is also very much based on the hard work of many craftspeople in the broadest possible sense, a lot of them ‘ordinary’ people working together, pushing the boundaries, not seldom accomplishing astonishing things (sure, by all means, clap hands or do a little dance). A few thoughts on meaningful websites or rather sets of web pages stringed together. Let’s not call them websites. Pages do not reside on one single location, much like in real life. A site is a specific location separated from other locations and that goes against the very concept of the world wide web.

Not too short

The tag names, as conceived initially were/are presumably kept short in an effort to avoid tedious repetition when handcoding using spartan tools was pretty much the only option. Soon after that enthusiasm and ambition most probably took the upper hand and somehow a few very important rounds of serious thinking were skipped. Intentionally or unintentionally, benefit of the doubt.

Nothing wrong with keeping things sweet, simple and concise in itself. However, by simply shortening and abbreviating tags things actually become less clear and complicate things in many other ways. With today’s bandwidth and the miracle of code completion or intellisense (let’s just call it code completion) I don’t think an extra few characters make a difference. By adding more meaningful tags to offset or slightly differentiate certain elements from others we will finally be able to get rid of the majority of the vague-generic tags whose sole purpose is to provide hooks for styling or “behaviour”. There is no way we can imagine (at this time) how information will be absorbed over the next few decades. Segmenting seems natural. If for instance you want to get a list of keywords used in a vast number of publications on a specific topic you might not want to leave that in the hands of one single party. You want to make sure those are easily accessible and become standard gear, preferably very much in the same way HTML and CSS are now. When you want to add other parameters you should be able to do so without any restriction whatsoever.

Having a go at some of that dough, bro!

Despite many attempts by very bright altruists making a living developing real world applications to weigh in on important decisions with a - irreversible if not addressed very soon now - direct (irreversible *and* undesirable) impact on the way information ideally will be stored and made available in the future it appears a handful of people are able to *#!k up our !##!. People who want to express themselves should not be hindered. Nobody wants to be a tech "wizz" to be able to do whatever it is they would like to do. Just a nice place to do cool "stuff".

Bye bye, cruft! I’m off to Simpleland

Let's just be honest. Today's content management systems are not at all user friendly. In order to publish something rather simple on the web these days people are very often being forced to use an application packed with all kinds of features they don't need; encouraged to pick one of a the few dozen templates it contains stuffed with pretty colours, meaningless dingbats and pre-structured layouts. Today people who are offered such rubbish are led to believe they get some sort of magic tool they can use to create whatever they dream up, while in fact they get handed something that pushes them in a specific direction by (for instance) having to pick one of the available layout templates, that probably features way too much cruft. Bloated in this case because sometimes they might merely want to publish an article containing nothing but one title and a few paragraphs.

Back to basics. Real basic, this time

Structure

<html type="publication, simplified"> <!-- General 
        type and specific type. In this case it could indicate the 
        document requires only a limited set of tags. -->
        <title>Title</title> <!-- The title of the article. -->
        The quick dark chocolate pudding bucket contained <emphasis>white 
        chocolate</emphasis> and Kevin cried for weeks and weeks. China had
        to manufacture 923 extra handkerchiefs because on weekdays they 
        had to blow their noses more often. That very night they all had 
        to read <citation>Das Kapital</citation> and so did Kevin. 
        The actual carriage return, the very purpose of one of the 
        largest keys on a keyboard could mark the start of the next 
        paragraph.
        The idea is that everyone should be able to write for the web 
        without having to worry about technicalities.
    </html>
A simple markup editor for editors?
A simple editor for editors.

Expectations, high hopes? Nope. Just some musings.

Even better might be to port - at least the most commonly used - content managing related tasks to the browser. Most people will probably only need the most basic features anyway. Another argument to keep everything small and modular. And after all I think it's much easier to optimise smaller chunks of code and everybody loves it when kids play together nicely.

Get inline!

When it comes to inline elements the currently available set of tags seems to be both deficient and confusing. In fact, some elements are duplicates or don't have any real value in terms of semantics and the naming convention - no disrespect here - has mainly been thought up by academics working in the field of information technology. Time to send in the lingo troops. More thought should have gone into making things comprehensible, easier and intuitive for non tech savvy authors (basically everybody eventually) *and* for the developers who rely upon the very language as a basis to add to it and build (often groundbreaking) applications, available for all to interlard today.

Strong, bold, stark, steak, kosher killing, emphasis, oblique, italic and yoghurt. Why yes indeed, a little more trivial.

A lot of controversy and dander on the reclassification of those tags. I think this comes as no surprise since they're all somewhat tied to the presentational layer. With the introduction of a new set of tags a few of the previously deprecated ones somehow made it back into the specs, “strangely” enough they featured rather prominently in those new specifications. When I write “strangely”, you might want to take into account that at the heart of what you call HTML5 today (fancy, that version number that came out of nowhere and makes no sense at all) there's a fair amount of BS to satisfy the real stakeholders.

Maybe we have to take a step back and question the need of certain tags. And even more bees in May, we might just want to revise the use of those in general, not fearing to address this at the lingo level if that would improve the way information is conveyed. For both offline and online publishing (Moi aussi, I do purchase the odd hardcopy or quality syllable every now and then). It might prove to be a good idea given the fact that we don't know how publishing will evolve over time. We can only hope some of the yummy snacks we can enjoy today will still be available in the near future. I know I do.

Current conventions on the use of italics

Current conventions on the use of bold typesetting

Don’t use bold type when all you do is stress

Luckily we can rely on the internet to find cosy places like the one where David McMurrey does a great job explaining the fundamentals of highlighting and emphasising. Some “pretty darn good arguments” in my humble opinion (and somehow I don’t think he pulled that one out of a hat ;). In the aforementioned article he states: A carefully planned functional relationship must exist between the text that is emphasized and the emphasis technique that is used. Emphasis techniques must be used consistently to prevent readers from becoming confused..

Separating meaning and conventional presentation and focussing on the former we actually only need either:

One more time

When we port (or elevate should you prefer) these conventions to the web we “might as well” take a look at how this works best in a more open and accessible environment. Imho we can even merge a few medium-specific properties.

  <title>Jenn and Ken get some chow</title>
      Langzaam verkeer. <citation language="French">à la carte</citation>. <link to=“url”>a link to another location</link>
                
<html type="publication, book"> <!-- General type and specific type. Control mechanism. -->
    
      <includes location="file-location.json" /> <!-- Link to a file containing all the tech specs and links to related files. -->
        
      <publication> <!-- General term for the parent element, container of the publication, the viewport perhaps. -->
      
        <topics>comma seperated keywords perhaps</topics> <!-- Conventions would be nice, think about scientific publications. -->
      
        <title>Title</title> <!-- The title of the publication is not necessarily bound to its cover (if there is any at all) so the title will remain a direct descendant of the publication. -->
      
        <author>Daffy <!-- The author is not necessarily bound to its cover (if there is any at all) so the author will remain a direct descendant of the publication. -->
        </author>
        
        <cover> <!-- Separate tag for the cover. A cover is a general term. E.g. cover of a music album, cover of a book, magazine, etc... -->
          <illustration> <!-- Illustration is a better term to indicate the content given the fact one can insert a various types of images (e.g. photographs, drawings, charts, etches, mathematical equations). -->
        </cover>
      
        <dedication>...</dedication>
      
        <foreword>...</foreword>
      
        <intro>...</intro>
            
        <list type="toc"> <!-- Table of contents / list of links / small clips of audio or video -->
            <link to="url">The first link</link> <!-- The carriage return seperates the list items/entries. -->
            <link to="url">The second link</link>
            <link to="url">A third one just because we can</link>
        </list>
      
        <chapter>
            <heading>Jen</heading>
            He told Jenn he considered ordering <citation language="French">à la carte</citation>. He sent her <link to=“http://en.wikipedia.org/wiki/Location”>a link</link>. <!-- carriage return before list doesn’t render a new paragraph -->
            <list>
                List item one  <!-- carriage return seperates the list entries. Spaces at the start of the list item get removed by default. -->
                List item two
                List item three
            </list> 
            <grid type="data">
                <row type="header">
                Rowing
                Parking
                Porting
                </row>
                <row>
                Row, row, wow your boat! Gently down the stream
                Park, park, park your car gently by the side of the road
                Port, port, port your bike gently across the street
                </row>
                <row type="footer">
                15
                75
                10
                <row>
            </grid>
        </chapter>
      
      </publication>
      
    </html>

Modules

Sounds good to me!

I do not think this is something that needs to be addressed right away, although it would be great if one could just import a recording and the browser would simply take care of the rendering according to the type of document you define using the html tag.

<html type="publication, sheet music, lines"> <!-- General type and specific type. In this case sheet music, displayed using note bars. This could trigger a specific part of the rendering engine. -->
    
      <includes location="file-location.json" /> <!-- Link to a file containing all the tech specs and links to related files (stylesheets, scripts, fonts, etc.). -->
        
        <title>Title</title> <!-- The title of the song. You probably want this to appear “on screen”. -->
        <author>Author</author> <!-- The author of the song. -->
        <tempo>4/4</tempo> <!-- The tempo of the song. -->
        <dynamics>pp</dynamics> <!-- The dynamics of the song. -->
        <emotion>Con Fuocco</emotion> <!-- The character of the song. -->
        ...
    </html>

Structuring

<html type="publication, book"> <!-- General type and specific type. Control mechanism. -->
    
      <includes location="file-location.json" /> <!-- Link to a file containing all the tech specs and links to related files. -->
        
      <publication> <!-- General term for the parent element, container of the publication, the viewport perhaps. -->
      
        <topics>comma seperated keywords perhaps</topics> <!-- Conventions would be nice, think about scientific publications. -->
      
        <title>Title</title> <!-- The title of the publication is not necessarily bound to its cover (if there is any at all) so the title will remain a direct descendant of the publication. -->
      
        <author>Daffy <!-- The author is not necessarily bound to its cover (if there is any at all) so the author will remain a direct descendant of the publication. -->
        </author>
        
        <cover> <!-- Separate tag for the cover. A cover is a general term. E.g. cover of a music album, cover of a book, magazine, etc... -->
          <illustration> <!-- Illustration is a better term to indicate the content given the fact one can insert a variety of images (e.g. photographs, drawings, charts, etches, mathematical equations) -->
        </cover>
      
        <dedication>...</dedication>
      
        <foreword>...</foreword>
      
        <intro>...</intro>
            
        <list type="links"> <!-- Table of contents / list of links / small clips of audio or video -->
            <item>...</item> <!-- item -->
        </list>
      
        <chapter>
          <paragraph>He told Jenn he considered ordering <citation language="French">à la carte</citation>. <link to=“url”>a link to another location</link>
          </paragraph>
        </chapter>
      
      </publication>
      
    </html>

How inconvenient!

Random musings on stuff that made writing code unnecessarily tedious and on misconceptions in regard to semantics. Some of the thoughts on technical issues arrose while handcoding mainly in Adobe Dreamweaver, Microsoft Visual Studio and Panic’s Coda. Some issues might be related to limitations of the authoring software. Some of those might already (2014-8-4) have been addressed.

In general

Punctuation and special characters

Some minor issues or only slightly annoying behaviour I encounter(ed) using wysiwyg editors