I'm currently writing html/xhtml by hand, and that's fine to me, but I would like to ease things a little bit, especially for writing footnotes.
Today, here is how I write footnotes:
<p>Here is a footnote<a id="ref1b" href="#ref1">[1]</a>.</p>
<!-- And at the end of the document -->
<div class="footnotes">
<h2>Notes</h2>
<p id="ref1">[1] But this one isn't very helpful.
<!-- Let's add a go-back-to-the-text arrow -->
↩
</p>
</div>
The idea would be to make things automatic, and potentially done on the client side (by the browser), so that I could write something like that:
<p>Here is a footnote<ref id="1"/>.</p>
<!-- And at the end of the document -->
<div class="footnotes">
<h2>Notes</h2>
<ref-def id="1">But this one isn't very helpful.</ref-def>
</div>
So ref and ref-def would simply be evaluated on the fly by the browser.
Is this possible only using html/xhtml and css?
For completeness purpose. As of today there is a footnote tag in HTML.
https://www.w3.org/MarkUp/html3/footnotes.html
How it is presented to clients is left to implementors. Yo can use more html or css for a better formatting.
<DL>
<DT>Hamlet: <DD>You should not have believed me, for virtue cannot so inoculate our old stock but we shall relish of it. I loved you not.
<DT>Ophelia: <DD> I was the more deceived.
<DT>Hamlet: <DD>Get thee to a nunnery. Why wouldst thou be a breeder of sinners? I am myself indifferent honest ...
</DL>
<fn id=fn1><i>inoculate</i> - graft</fn>
<fn id=fn2><i>relish of it</i> - smack of it (our old sinful nature)</fn>
<fn id=fn3><i>indifferent honest</i> - moderately virtuous</fn>
the way you're doing this now has the advantage of being accessible and standards compliant - it will work with any browser - even with javascript disabled. Also search engines will be able to make sense out of this.
So there are some benefits in doing it this way.
if you decided to go for a shorter alternative, then there's plenty of jQuery plugins that will make your task more comfortable. e.g. look at https://github.com/nicholascloud/footnote.js
If you go for that approach please also note, that your site speed will suffer as users will have to download plenty of javascript to get your footnotes working.
Related
What are people's opinions on semantic HTML for confirmation, error and warnings messages?
Currently I have something simple like:
<div class="message message-warning">
<h3>Message Title</h3>
<p>Message text</p>
</div>
Whereby the message-warning class gets replaced by message-confirmation or message-error if the message is a different type.
Is there a more semantic way of marking this up?
May I suggest <figure>?
Excerpt from HTML5 Doctor (and they, from W3C):
The figure element represents a unit of content, optionally with a caption, that is self-contained, that is typically referenced as a single unit from the main flow of the document, and that can be moved away from the main flow of the document without affecting the document’s meaning.
Lets answer the questions first:
Is such a dialog a single unit? Yes
Is such a dialog self-contained? Yes
Can such a dialog be moved away from the document without affect the document meaning? Yes
Yes, it fits a <figure> perfectly.
And, the <figcaption> is especially good for title bars / headings.
So, I'd go with <figure> without even trying to look further:
<figure id="dialog-box" class="warning">
<figcaption>Message Title</figcaption>
<p>Message text</p>
</figure>
Use the <dialog> element, and call .show() instead of .showModal(), or give it the open attribute if rendering server-side.
As long as it’s not shown modally, it won’t block interactions with other page content.
Old answer (before <dialog> was a thing):
Alerts are one of the semantics that ARIA added to HTML, because there's no straightforward way of doing in "pure" HTML. Hence:
<aside role="alert">
<h2>Message Title<h2>
<p>Message Text</p>
</aside>
I personally like to use <aside> as the element to slap the role on — it's technically not part of the page content, as described by Jeff Lindblom's answer.
Having a "semantic" CSS selector for this is easy enough:
[role="alert"] {
font-size: 2em; /* or what have you */
}
The <figure> idea is interesting, but I don't think it fits here. What it's missing is the actual content to justify use of the tag. According to the spec, <figure> represents a "unit of content" - meaning an image, diagram, code block, etc. that may optionally have a caption for this content (<figcaption>). It would be a stretch to say that the message outside the <figcaption> represents an appropriate unit of content.
We should also be cautious of using <h#> tags in this instance, as the message is secondary content, and should probably not be part of the document outline.
One could argue, under the revised spec, that an <aside> would be appropriate. It's now considered "tangential content" when used outside an <article>.
<strong> would be appropriate for the "title" of the message, since it's a semantically more important part of the message, but not a document header. So the code might look so:
<aside class="warning-or-whatever">
<strong>Message Title</strong>
<p>Message Text</p>
</aside>
One could also argue, since there's nothing specifically created for such a feature, that a good old-fashioned, semantically meaningless <div> might be the best element. I guess it comes down to how "tangential" you feel your messages are.
Thanks,
Jeff
No. There is no element in HTML that denotes a confirmation, error, or warning message.
Technically, the samp element has been defined as “sample output from programs, scripts, etc.” in HTML 4.01 and in HTML 3.2, though originally in HTML 2.0 as “sequence of literal characters, typically rendered in a mono-spaced font” and being somewhat redefined in HTML5 as “(sample) output from a program or computing system”. So its meaning is rather vague, and it’s not used much, so there is no real point in using it. But it might be argued that it is acceptable to use samp markup for any message from a program. It is a text-level element, so you would need to use it separately inside h3 and inside (any) p, more or less breaking the structure.
It might also be said that the messages are quotations from an external source, so they could be wrapped inside blockquote.
The use of h3 vs. some other markup isn’t really a semantic question, but structural: is this a heading for some content at the 3rd level of nesting?
I think the strong element is an appropriate element for such messages.
You could use several strong elements to indicate the importance of the message:
<strong>Login successfully.</strong> <!-- confirmation -->
<strong><strong>Wrong login data.</strong></strong> <!-- warning/error -->
If it’s stand-alone message for which a heading is warranted, use a section element instead of a div. In case of serious errors that apply to the whole page, it should be the first element on the page.
Various variants are possible:
<section class="message message-error">
<h1><strong><strong>Error:</strong> Wrong login data.</strong></h1>
<p>The username and/or password is wrong. Try …</p>
</section>
<section class="message message-error">
<h1>Error</h1>
<p><strong><strong>Wrong login data.</strong></strong></p>
<p>The username and/or password is wrong. Try …</p>
</section>
<section class="message message-error">
<strong><strong>Wrong login data.</strong></strong>
</section>
<section class="message message-error">
<p><strong><strong>Wrong login data.</strong></strong> Try …</p>
</section>
Which one to use depends on the kind of message, if the exact error is know, if additional help text is provided, and if several message could come up at the same time.
Note that you probably don't want to use a heading for messages that apply to a single input element (e.g. when the user didn't fill out a required field or entered wrong content etc.), as these error messages should be in the corresponding label or directly next to the input element.
For accessibility, you should have a look at WAI-ARIA. Maybe aria-live="assertive" might be an appropriate way to mark error messages.
If you want to go semantic, you can use a semantic-web approach by making an ontology for messages and warnings and use RDFa to embed it in your HTML.
Have got the following HAML code, combined with Markdown:
%h2.slogan.align-center
:markdown
No more big words. Enough of the abbreviations.
**Project management for the rest of us.**
Which generates HTML:
<h2 class='slogan align-center'>
<p>No more big words. Enough of the abbreviations.<br/>
<strong>Project management for the rest of us.</strong></p>
</h2>
I'd like the HTML to look like (omitting surrounding <p> tags):
<h2 class='slogan align-center'>
No more big words. Enough of the abbreviations.<br/>
<strong>Project management for the rest of us.</strong>
</h2>
What's the HAML/Markdown to create that HTML?
Well it is easy to do with only haml:
%h2.slogan.align-center
No more big words. Enough of the abbreviations.
%br/
%strong Project management for the rest of us.
It seems like the markdown plugin of haml adds the p tag. According to the documentation this is accomplished by using one of 4 different markdown processors. I guess the result may differ depending on which one you are using.
Take these two pieces of markup:
<div id="header">
<img src="/img/logo.png" alt="MyLogo" />
<ul id="misc-nav">
<li>..</li>
</ul>
<header>
<h1>Welcome to Bob's Website of Fantastical Conbobulations</h1>
<p>The smell of invention awaits you...</p>
</header>
</div>
and
<header>
<img src="/img/logo.png" alt="MyLogo" />
<ul id="misc-nav">
<li>..</li>
</ul>
<h1>Welcome to Bob's Website of Fantastical Conbobulations</h1>
<p>The smell of invention awaits you...</p>
</header>
My example may not be perfect, but I'd like to know if the purpose of the tag is for semantic definition of the content, or is it block level structural definition with CSS?
It is my understanding from the spec itself, that the first example is the correct interpretation, yet I see the second being touted as the right way.
Can you offer any clarity on it?
Both are fine. But what exactly do you mean by "structural" vs "semantic"?
It's your first method (semantically).
The < header> tag defines an
introduction to the document.
<header>
<h1>Welcome to my homepage</h1>
<p>My name is Donald Duck</p>
</header>
<p>The rest of my home page...</p>
http://www.w3schools.com/html5/tag_header.asp
Spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-header-element
The header tag purely semantic.
However, in fact all HTML tags are to provide a context to the content (= semantics).
Use CSS to style your content approperiately.
I would advocate the following combination of markup and CSS:
In your CSS:
header {
background: #fff url(/img/logo.png) top left no-repeat;
padding-left: 64px; /* or whatever required to display margin correctly */
}
/* if you REALLY want your navigation to appear as a bulleted list */
nav a {
display: list-item;
}
In your page markup:
<nav>
<a>...</a>
<a>...</a>
</nav>
<header>
<h1>Welcome to Bob's Website of Fantastical Conbobulations</h1>
<p>The smell of invention awaits you...</p>
</header>
This way you're using the semantic <header /> and <nav /> tags to mark up text content, and then using CSS to enhance the presentation with display formatting, logo images, etc.
I recall - although alas I can't find the sources now - that the proposed new elements in HTML5 (header, nav, footer, aside, article, etc.) were chosen based on analysis of Google's database of websites to identify the most commonly-used ID attributes assigned to DIV elements, figuring that those represented the most common scenarios where developers were using DIVs to wrap meaningful elements of their page structure.
HTML5 actually does away with block/inline distinction in favour of a more nuanced content model. The header element is flow content, which is like the default state for HTML5 elements. Semantically it should be considered as introductory information for its nearest section content or sectioning root ancestor.
I think both your examples are valid uses of the element, though I personally would probably markup your first one this way:
<header>
<img src="/img/logo.png" alt="MyLogo" />
<nav>
<ul>
<li>..</li>
</ul>
</nav>
<hgroup>
<h1>Welcome to Bob's Website of Fantastical Conbobulations</h1>
<h2>The smell of invention awaits you...</h2>
</hgroup>
</header>
I used to think that the first method is the proper way to use the element, as it is intended to provide relevant information for a given section it is included in, not being a section itself, besides we already have elements for structuring the content, but for what i've seen in some pages, the reason many people includes also a header element at root level is to provide that same information considering the whole page as a big section, so i've changed my mind to think both of the examples can be considered correct.
If you read the W3C HTML5 specification you will find that every html page should have only one H1 tag, so if you use h1 then h2 then h3 you might see some weird styling. That is because the browser expect one h1 on every html page when it parses it.
So you can instead use h1 h2 h3 tags and style them any way you want.
The point of using semantic html elements is because your website will be 'read' not only by web browsers but also by web crawlers, tools that read the page with voice, braile tools and many more applications and physical tools.
So when those applications read your website they don't read css, only html and might read some javascript. So when they see lang="en" they know to read the contents in the element in english etc. When they see "section" they know it's section element and when they see "aside" they know it is some aside element etc.
We can easy see the page and know what is what, but visually impaired and other people can't do that so for them this will be of great help. Think about that when you make your websites, think about all the people that will access it and how easy will be for them to do that.
That is the whole point of the new awesome html5 elements. You can make the same webpage just with one element - "div" for example, and with a whole range of new html5 semantic elements - article, section, header, footer, aside etc. The webpage will look the same in web browsers, but smart applications like search engine robots will crawl the page better and some applications that read web pages will parse the page more easily.
The point of web is to be open to all people and free, and I agree to that.
In the future, the web will evolve without doubt, new tools will be made that will parse web pages, and using new html5 semantic elements will make your webpages future proof, so these new tools will read our pages in smart way.
Hope this helped someone :)
This is a community wiki that asks the question, "Just how semantic can our HTML markup get thanks to HTML 5?" Below You can find the source code of a sample HTML 5 page. The object is to make a very usable, accessible, style-able webpage using as few classes and IDs as possible.
Also, when do you plan to start implementing HTML 5? Are you going to wait 10+ years until the draft is finalized, or are you going to be an "early adopter" now that browser support is rapidly growing?
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<title>Site Name • Page Title</title>
</head>
<body>
<nav>
<h1>Site Name</h1>
<ul>
<li>Nav Link</li>
<li>Nav Link</li>
<li>Nav Link</li>
</ul>
</nav>
<header>
<p>Welcome to the site!</p>
Call to action!
</header>
<section>
<aside>
<!-- Sidebar -->
</aside>
<article>
<header>
<h2>Article Name</h2>
<p>Posted by <cite>Kerrick Long</cite> on <time datetime="2009-06-21">June 21</time>.</p>
</header>
<p>Lorem ipsum dolor sit amet...Aliquam erat volutpat.</p>
<figure>
<img src="/images/eclipse.jpg" width="640" height="480" alt="Solar Eclipse" />
<label>Here we can see the solar eclipse that happened <time datetime="2009-05-28">recently</time>.</label>
</figure>
<p>Lorem ipsum dolor...</p>
</article>
</section>
<footer>
<p>© <time datetime="2009-01-01">2009</time>, <cite>Site Owner</cite></p>
</footer>
</body>
</html>
It won't be 10+ years. That time period is for "final completion", all browsers support all parts of the spec. It's due to become a candidate late this year, early next, and hopefully approved by 2011/2.
I'm phasing it it in where I can, right now. How much I use depends on audience, but since IE share has been falling constantly, what they don't support is no longer a killer, especially as John Resig's "HTML5 shiv" lets the semantic tags play even in IE6 with js turned on.
More importantly, I'm starting to shift my thinking into HTML5 lines, using classes today for what will become HTML5 tags tomorrow (div class="nav"). That way I'll be more used to thinking in HTML5 terms when the opportunity arises.
Although I take great happiness in seeing new capabilities, the truth still remains that my clients use IE6 (and similar browsers). As much as I would like to see everybody using a modern browser, the fact that they aren't means I have to work with technologies that don't require them to upgrade.
I'm going to use it as soon as browsers support it. The sites I make are mainly hobby projects mostly visited by Firefox users. (80% of my traffic uses the latest version of FF).
Keep in mind that the cite element is not appropriate for a person's name: HTML5 states "A person's name is not the title of a work — even if people call that person a piece of work — and the element must therefore not be used to mark up people's names." Also, the trailing slash in <meta charset="UTF-8" /> isn't necessary.
The main driver for people adopting HTML 5 would be better search engine placement, without that, I'm not seeing a huge reason to adopt.
(Maybe if people could somehow convince me that the web might be more data-like and therefore interoperability would improve, then I might be somewhat convinced, but that sounds a bit overly optimistic)
I'll echo jonothan sampson. As long as a reasonable number of people are still using older browsers, it's hard to make that jump.
On the other hand, it's probably sensible to detect browsers and send a version that makes good sense. Since the differences between the two languages will be moderate, it will probably be feasable to transform an HTML5 page to HTML4 with additonal class and styles depending on user agent, perhaps with a little server side xslt. That said, I doubt I'd be the one to invent that technology, although I'd use it if or when it becomes available.
People keep mentioning a javascript solution for older browsers such as ie6 but what if they do not support javascript?
Sorry not an answer but more a ????? As this is the point I just don't get about semantic html5 and IE support.
You could always go belt and braces for older browsers
<nav><div id="nav"> some nav stuff</div></nav>
But that feels dirty to me?
I'm making a small web-chat utility and am looking for advice on which elements to use for messages.
Here's what I'm thinking of using at the moment:
<p id="message-1">
<span class="timestamp" id="2009-03-10T12:04:01+00:00">
12:04
</span>
<cite class="admin">
Ross
</cite>
Lorem ipsum dolor sit amet.
</p>
I'd take advantage of CSS here to add brackets around the timestamp, icons for the cited user etc. I figured it would be silly (and incorrect) to use a blockquote for each message, although I consider the cite correct as it's referring to the user that posted the message.
I know this isn't a) an exact science and b) entirely essential but I'd prefer to use meaningful elements rather than spans throughout. Are there any other elements I should consider? Any microformats?
HTML isn't very semantic in a customizable way. Nevertheless your format should be understandable in any browser (with proper CSS, as you have pointed out).
What I see in the code example above is very similar to XML. It might be cumbersome and overkill for your needs, but I'd like to point out that you can use XML with XSLT as a substitute to both (X)HTML. This way you can get your tags as semantic as possible, and don't need to compromise with the limitations of the HTML tags.
w3schools has an article about the topic. I could swear that I saw a webpage in sun.com that was done in XML, but I can't find it anymore.
If you don't intend this to be interpreted or parsed by third party software, I'd nevertheless advise against this method, and stick with the proven HTML.
Seems reasonable to me, except that the ‘id’ is invalid. NAME tokens can't start with a number or contain ‘+’.
Plus if two people spoke at once you'd have non-unique IDs. Perhaps that data should go in another attribute, such as ‘title’ (so you can hover to see the exact timestamp).
If you're going for semantic HTML, you'll probably want to know that HTML5 doesn't consider your use of the <cite> element correct anymore.
A person's name is not the title of a work — even if people call that person a piece of work — and the element must therefore not be used to mark up people's names.
<ol>
<li class="message" value="1">
<span class="timestamp" id="2009-03-10T12:04:01+00:00">
12:04
</span>
<cite class="admin">
<address class="email">
<a href="mailto:ross#email.com">
Ross
</a>
</address>
</cite>
Lorem ipsum dolor sit amet.
</li>
</ol>
I would try something like the above. Notice I have placed everything in an Ordered list, as comments can be construed in the linear manner fitting an ordered list. Also, I have embedded, inside your Cite tag, an Address tag with an Anchor element. The unfortunately named Address element is actually meant to convey contact information for an Author, so you would probably want to link to the author's email address there.
What you suggested is already very good. If you want to take it a step further and be able to allow tons of different presentation options with the same markup (at the expense of heavier html) you may want to do something like:
<dl class="message" id="message-1">
<dt class="datetime">Datetime</dt>
<dd class="datetime">
<span class="day">Wed</span>
<span class="dayOfMonth">11</span>
<span class="month">Mar</span>
<span class="year">2009</span>
<span class="hourMin">17:34</span>
<span class="sec">33</span>
</dd>
<dt class="author">Author</dt>
<dd class="author">Ross</dd>
<dt class="message">Message</dt>
<dd class="message">Lorem ipsum dolor sit amet</dd>
</dl>
Since you mention microformats in the question, you are no doubt already familiar with the microformats wiki. It contains a good number of examples for different situations.
Another possibility would be to borrow parts of SIOC, which among other things is an ontology for forums - pretty similar to chat.
By re-using existing formats, you can take advantage of plugins and tools like Operator and maybe get more out of your app for free.
I'd use XML with XSLT to transform (style) the data.
It makes sense semantically here, but you also have the conversations in a suitable format for archiving (i.e. XML) - I assume you will have some sort of log or 'history'.
As #bobince said, the id="2009-03-10T12:04:01+00:00" is invalid.
You should change this:
<span class="timestamp" id="2009-03-10T12:04:01+00:00">
12:04
</span>
To this:
<time class="timestamp" datetime="2009-03-10T12:04:01+00:00">
12:04
</time>
You can get more information about the time tag at HTML5 Doctor and W3C:
The time tag on HTML5 offers a new element for unambiguously encoding dates and times for machines while still displaying them in a human-readable way.
The time element represents either a time on a 24 hour clock, or a precise date in the proleptic Gregorian calendar, optionally with a time and a time-zone offset.
...
I agree with the ordered list (ol) solution posted by #Robotsu, except by the time tag I just posted and the incorrect address inside cite tag!