I'm just writing to inquire what would be more correct for xHTML and a CSS question.
For the HTML:
Say I have a list of:
Apples,
Bananas,
and Carrots
Would this be more correct:
<ul> <li> Apples </li> <li> Bananas </li> <li> Carrots </li> </ul>
Or would this be:
<ol> <li> Apples </li> <li> Bananas </li> <li> Carrots </li> </ol>
For CSS, after an element has been floated, which attribute can be used to restore flow to block alignment?
Thank you so much.
The ul element stands for "unordered list" which implies it was ordered to begin with (the proper English approach would be no for non-ordered). The ol element stands for "ordered list". Is this list intentionally ordered or not? If you order them alphabetically then I'd considered using the ul element since it's more of a technicality and not some life-or-death importance.
You can work with display and float together. Generally speaking you should look in to the CSS display property. As flexbox support has improved and the bugs have been ironed out I've migrated to using it and reserving float for neat tricks like applying it to an image nested within a bunch of paragraph elements.
Also something people who make six figures have no idea about: XHTML and HTML5 aren't opposed. My platform uses the XML parser while the code is HTML5. A parser takes text and determines how to interpret it for processing. The XML parser is very strict (though not perfectly strict and each browser engine varies, currently Gecko's has been superior) while the HTML parser doesn't mind if there are hobos all over your front lawn and will likely invite even more while it knows you're watching.
Related
The OneNote API is not returning supported tags in some lists.
It seems to be an issue with complex bulleted lists; we just see OutlineGroupNode is not supported in the returned markup.
The docs give some guidelines on how to write out tags to lists, but there's no mention of the API not returning any supported tags in certain situations.
Please see the below example, what rules is this list breaking?
What constitutes an OutlineGroupNode?
Some clarity over what pre-existing list/tag content is supported would be appreciated please.
Thanks
The resulting markup is:
<snip>
<!-- OutlineGroupNode is not supported --><br>
<ul>
<li>
<p lang="en-GB" style="margin-top:0pt;margin-bottom:0pt">
Top level no tag</p>
<ul>
<li style="list-style-type:circle"><span lang="en-GB"
data-tag="to-do">Sub level with tag</span></li>
<li style="list-style-type:circle"><span lang="en-GB">Sub
level no tag</span></li>
</ul>
</li>
<li style="list-style: none"><br></li>
</ul>
</snip>
4 days later it now works; no code changes on my part.
The complex list is returned correctly. No HTML comment in the markup mentioning OutlineGroupNode.
I can only assume that something has changed under the API hood.
What would the most relevant HTML tags be for a numbered progress bar such as:
(1) Step 1: do something
(2) Step 2: do something else
(3) Step 3: complete
I considered using an <ol> but in this case, the '1', '2', '3', will need styling.
Also to indicate which step the user is currently on.
As you've already decided, an ordered list is the most semantic way to show a progress bar. Unfortunately there isn't a specific HTML element or attribute for "current step" or anything similar (I wish I knew why!). So you'll need to make something yourself. The simplest way I've used before is to use an image of the step number with an alt attribute, e.g.
<li><img src='step1.png' alt='Step 1: Current step'>Do something</li>
But you could use visually-hidden text instead. The image would need to be visually distinct from the other steps so that colour-blind users are informed as well.
Probably nothing more semantic currently than:
<ol>
<li class='currentStep'>
<span>1</span>
<span>do something</span>
</li>
<li>
<span>2</span>
<span>do something else</span>
</li>
</ol>
Semantically I agree with the use of ol but I believe you can achieve the desired effect with a bit of css and use of data-attributes
The markup would look something like this
<ul>
<li data-step="1">Do something</li>
</ul>
Here's a sample of the implementation: http://jsbin.com/gifisireku/edit?html,css,output
The benefit of using this is you can have clean and accessible markup which is great for SEO as well ;)
I would like to use semantic mark-up to emphasise each items importance or priority.
Here is an example of what i mean.
<ul itemscope itemtype="http://schema.org/ItemList">
<h2 itemprop="name">Wish List</h2><br>
<li itemprop="itemListElement">Google glass</li>
<li itemprop="itemListElement">Galaxy S4</li>
<li itemprop="itemListElement">MacBook Pro</li>
</ul>
I was contemplating using heading tags but I am not sure if this is the correct use. e.g
<ul itemscope itemtype="http://schema.org/ItemList">
<li itemprop="itemListElement"><h6>Least Important</h6></li>
<li itemprop="itemListElement"><h1>Most Important</h1></li>
</ul>
I'm just looking for a little advice on whether there is a CORRECT way of doing this? possibly microdata, microformats or RDFa?
You shouldn’t use headings that way. Heading content is important, yes, but that doesn’t mean that important content should be a heading. Your first example is invalid (a list may only contain li elements), your second example messes with the document outline.
The strong element represents "strong importance for its contents". You increase the importance by using several strong elements for the same content:
The relative level of importance of a piece of content is given by its number of ancestor strong elements; each strong element increases the importance of its contents.
The HTML5 spec also has an example for such usage:
<p>
<strong>Warning.</strong> This dungeon is dangerous.
<strong>Avoid the ducks.</strong> Take any gold you find.
<strong><strong>Do not take any of the diamonds</strong>,
they are explosive and <strong>will destroy anything within
ten meters.</strong></strong> You have been warned.
</p>
(note that <strong>Do not take any of the diamonds</strong> is nested in another strong element)
So this is the correct way in HTML5.
Regarding your example: If you have a wishlist that is sorted from least to most important (or the other way around), you should use ol rather than ul, as the order is meaningful and important. So your wishlist could look like:
<ol reversed>
<li><!-- least important item --></li>
<li><!-- another not-soo-very important one --></li>
<li><strong><!-- important --></strong></li>
<li><strong><!-- more important than the previous one, but not that much of a difference --></strong></li>
<li><strong><strong><!-- most important item --></strong></strong></li>
</ol>
(If it’s not sorted in this way, go with ul and use the strong elements accordingly.)
Now, you could enhance this with RDFa or Microdata, of course. Therefore you’d need an appropriate vocabulary. I don’t know any. Maybe you could make use of some sort of rating vocabulary? You could give each item a score/rating, like how much you want to have it.
Theoretical example in Turtle:
myWishlistItems:1 ex:hasImportance 0.9
myWishlistItems:2 ex:hasImportance 0.85
myWishlistItems:3 ex:hasImportance 0.7
myWishlistItems:4 ex:hasImportance 0.7
myWishlistItems:5 ex:hasImportance 0.7
myWishlistItems:6 ex:hasImportance 0.2
Alternative: state the semantics in the content, e.g. group the levels of importance.
You could use a dl, e.g.:
<section>
<h1>My wishlist</h1>
<dl>
<dt>MUST HAVE!</dt>
<dd>…</dd>
<dd>…</dd>
<dt>Would be very cool</dt>
<dd>…</dd>
<dd>…</dd>
<dt>I like that, sometimes</dt>
<dd>…</dd>
<dd>…</dd>
</dl>
</section>
or an ol with section elements, so you can use grouping headings, e.g.:
<section>
<h1>My wishlist</h1>
<ol>
<li>
<section>
<h2>MUST HAVE!</h2>
<ul>
<li>…</li>
<li>…</li>
</ul>
</section>
</li>
<li>
<section>
<h2>Would be very cool</h2>
<ul>
<li>…</li>
<li>…</li>
</ul>
</section>
</li>
<li>
<section>
<h2>I like that, sometimes</h2>
<ul>
<li>…</li>
<li>…</li>
</ul>
</section>
</li>
</ol>
</section>
If you want a scale with several levels of priority, there's no way to do that in html. Using headings would clutter the outline, in a way that's clearly "un-semantic". It's likely not worth trying to express in RDF either. What would consume it? Perhaps you have more details in mind, that would shed more light on this...
Since there's no way to express it in HTML elements or attributes, the data would not be accessible to all readers. You know how to style items with a spectrum of colors, but screen-readers wouldn't read those colors aloud.
You might simplify this to an ordered list - items in order of priority. Or two levels of importance, where a few critical items are highlighted using <strong>.
(If you take the HTML5 spec literally, you can nest <strong> multiple times for higher levels of priority. But it's unlikely to be supported for your use case. Not in current screen-readers, and not in the browser default stylesheet. So I wouldn't consider this a legitimate use).
Is it semantically correct to markup a ul in HTML with another embedded ul that has only one single list item?
For example, I have a ul with several lis, and one of those lis has an embedded ul with a single li:
<ul>
<li>Example LI 1
<ul>
<li>Example LI 1a</li>
</ul>
</li>
<li>Example LI 2</li>
<li>Example LI 3</li>
</ul>
Absolutely. A list is not defined by quantity. It's defined by semantics. So a list can consist of only one element if only one item applies to the list's purpose. For example, I have only crashed one computer today so that list would be only one element long.
Yes, it is semantically correct to have a list with a single item if used correctly, even if it does feel a little strange (it’s not really a list if there is only one item because by definition, a list is, well, a list of items, otherwise it would just be an item).
In the example you provided, the items were placeholders and had no meaning, so it is hard to tell if it applies. Whether it is correct or not depends on why you are putting it in a sub-item. It is perfectly reasonable to have a single-item sub-list if it is indeed a list item, especially if there are other sub-lists with multiple items. In that case, the meaning is clear. For example, the following is fine:
<h1>Auto Insurance Customers</h1>
<ul>
<li>
<strong>#1234</strong>
<ul>
<li>2003 Ford Focus</li>
<li>1998 Ford Escort</li>
<ul>
</li>
<li>
<strong>#2468</strong>
<ul>
<li>1999 Lamborghini Diablo VT Roadster</li>
</ul>
</li>
…
</ul>
There is nothing wrong with this example because it is perfectly reasonable for a customer to have a single car while others may have more.
On the other hand, if the reason that you are making the single-item sub-list is simply to create an indent to offset and highlight part of a list item, then it is incorrect.
For example, say you have a list of paragraphs of text. In one of the paragraphs, you have a passage that needs some sort of attention and you want to indent and offset it. While putting it in a list would work, it is incorrect because you are mixing style with structure.
The correct way to accomplish this would be to wrap the section in another tag (like <blockquote>, styled <div>, etc.) and leave it in the regular flow of that list item. In the following example, there is a part of one of the list items that needs to be highlighted. Putting it in a (single-item) list is the wrong way to do it:
<h1>Blog posts or something…</h1>
<ul>
<li>
<strong>Foo</strong>
<p>Some long paragraph about Foos, what they do, how they work, etc.</p>
<p>More information about Foos and where they originated.</p>
<p>Instructions on care and feeding of Foos.</p>
</li>
<li>
<strong>Bar</strong>
<p>Detailed description of local watering holes for lawyers.</p>
<p>Anecdotes about experiences of drinking & lawyering.</p>
<!-- This section is to be highlighted and offset to draw attention to it from the rest of this list item. -->
<ul>
<li>
<p>Highlighted account of the subsequent problems and what happened that one strange night.</p>
</li>
</ul>
<p>Summary of what to not do when out drinking with lawyers.</p>
</li>
<li>
<strong>Baaz Luhrmann</strong>
<p>A bunch of stuff about a brass-skinned movie director who made a widely-panned film adaptation of a Shakespeare play who turns to stone and traps your sword when he dies.
</li>
</ul>
Instead, you should use the correct tag for this purpose. Not only is it semantically and structurally correct, it is also clearer and even reduces the size of the page a little:
<style…>
p.highlight {
margin : 20px 50px;
width : 150px;
}
</style>
…
<li>
<strong>Bar</strong>
<p>Detailed description of local watering holes for lawyers.</p>
<p>Anecdotes about experiences of drinking and lawyering.</p>
<!-- This section is to be highlighted and offset to draw attention to it from the rest of this list item. -->
<p class="highlight">
Highlighted account of the subsequent problems and what happened that one strange night.
</p>
<p>Summary of what to not do when out drinking with lawyers.</p>
</li>
According to dictionary.com, a list is a meaningfully grouped series of items and a series is a group of similar or related items. (Results are similar at oxforddictionaries.com and thefreedictionary.com.) Anything that contains only one item can't contain meaningful grouping or a similarity or relatedness between its contents. Thus, for a one-item list, the semantics of the markup don't match the semantics of the content.
A single-item list also just doesn't seem to fit with what people mean when they say "list".
(On that note, contemporary dictionaries are more focused on recording common usage than proper usage (which is why "bling" is in the OED).)
Additionally, even if it wasn't technically wrong, there just doesn't seem to be much editorial value in marking up such a simple statement as a list instead of a paragraph. It seems to me that the first of the three following examples would be the easiest for the user to parse and comprehend.
<p>XYZ is the only computer that crashed.</p>
<p>
The computer that crashed:
<ul><li>XYZ</li></ul>
<p>
<ul>
<li>
The computer that crashed:
<ul><li>XYZ</li></ul>
</li>
<ul>
Making a search result list (like in Google) is not very hard, if you just need something that works. Now, however, I want to do it with perfection, using the benefits of HTML5 semantics. The goal is to define the defacto way of marking up a search result list that potentially could be used by any future search engine.
For each hit, I want to
order them by increasing number
display a clickable title
show a short summary
display additional data like categories, publishing date and file size
My first idea is something like this:
<ol>
<li>
<article>
<header>
<h1>
<a href="url-to-the-page.html">
The Title of the Page
</a>
</h1>
</header>
<p>A short summary of the page</p>
<footer>
<dl>
<dt>Categories</dt>
<dd>
<nav>
<ul>
<li>First category</li>
<li>Second category</li>
</ul>
</nav>
</dd>
<dt>File size</dt>
<dd>2 kB</dd>
<dt>Published</dt>
<dd>
<time datetime="2010-07-15T13:15:05-02:00" pubdate>Today</time>
</dd>
</dl>
</footer>
</article>
</li>
<li>
...
</li>
...
</ol>
I am not really happy about the <article/> within the <li/>. First, the search result hit is not an article by itself, but just a very short summary of one. Second, I am not even sure you are allowed to put an article within a list.
Maybe the <details/> and <summary/> tags are more suitable than <article/>, but I don't know if I can add a <footer/> inside that?
All suggestions and opinions are welcome! I really want every single detail to be perfect.
1) I think you should stick with the article element, as
[t]he article element represents a
self-contained composition in a
document, page, application, or site
and that is intended to be
independently distributable or
reusable [source]
You merely have a list of separate documents, so I think this is fully appropriate. The same is true for the front page of a blog, containing several posts with titles and outlines, each in a separate article element. Besides, if you intend to quote a few sentences of the articles (instead of providing summaries), you could even use blockquote elements, like in the example of a forum post showing the original posts a user is replying to.
2) If you're wondering if it's allowed to include article elements inside a li element, just feed it to the validator. As you can see, it is permitted to do so. Moreover, as the Working Draft says:
Contexts in which this element may be
used:
Where flow content is expected.
3) I wouldn't use nav elements for those categories, as those links are not part of the main navigation of the page:
only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases, without a nav element. [source]
4) Do not use the details and/or summary elements, as those are used as part of interactive elements and are not intended for plain documents.
UPDATE: Regarding if it's a good idea to use an (un)ordered list to present search results:
The ul element represents a list of
items, where the order of the items is
not important — that is, where
changing the order would not
materially change the meaning of the
document. [source]
As a list of search results actually is a list, I think this is the appropriate element to use; however, as it seems to me that the order is important (I expect the best matching result to be on top of the list), I think that you should use an ordered list (ol) instead:
The ol element represents a list of
items, where the items have been
intentionally ordered, such that
changing the order would change the
meaning of the document. [source]
Using CSS you can simply hide the numbers.
EDIT: Whoops, I just realized you already use an ol (due to my fatique, I thought you used an ul). I'll leave my ‘update’ as is; after all, it might be useful to someone.
I'd markup it up this way (without using any RDFa/microdata vocabularies or microformats; so only using what the plain HTML5 spec gives):
<ol start="1">
<li id="1">
<article>
<h1>The Title of the Page</h1>
<p>A short summary of the page</p>
<footer>
<dl>
<dt>Categories</dt>
<dd>First category</dd>
<dd>Second category</dd>
<dt>File size</dt>
<dd>2 <abbr title="kilobyte">kB</code></dd>
<dt>Published</dt>
<dd><time datetime="2010-07-15T13:15:05-02:00">Today</time></dd>
</dl>
</footer>
</article>
</li>
<li id="2">
<article>
…
</article>
</li>
</ol>
start attribute for ol
If the search engine uses pagination, you should give the start attribute to the ol, so that each li reflects the correct ranking position.
id for each li
Each li should get id atribute, so that you can link to it. The value should be the rank/position.
One could think that the id should be given to the article instead, but I think this would be wrong: the rank/order could change by time. You are not referring to a specific result but to a result position.
Remove the header
It is not needed if it contains only the heading (h1).
Add rel="external" to the link
The link to each search result is an external link (leading to a different website), so it should get the rel value external.
Remove nav
The category links are not navigation in scope of the article. So remove the nav.
Each category in a dd
You used:
<dt>Categories</dt>
<dd>
<ul>
<li>First category</li>
<li>Second category</li>
</ul>
</dd>
Instead, you should list each category in its own dd and remove the ul:
<dt>Categories</dt>
<dd>First category</dd>
<dd>Second category</dd>
abbr for file size
The unit in "2 kB" should be marked-up with abbr:
2 <abbr title="kilobyte">kB</code>
Remove pubdate attribute
It's not in the spec anymore.
Other things that could be done
give hreflang attribute to the link if the linked result has a different language than the search engine
give lang attribute to the link description and the summary if it is in a different language than the search engine
summary: use blockquote (with cite attribute) instead of p, if the search engine does not create a summary itself but uses the meta-description or a snippet from the page.
title/link description: use q (with cite attribute) if the link description is exactly the title from the linked webpage
Aiming for a 'perfect' HTML5 template is futile because the spec itself is far from perfect, with most of the prescribed use-cases for the new 'semantic' elements obscure at best. As long as your document is structured in a logical fashion, you won't have any problems with search engines (most of the new tags don't have the slightest impact). Indeed, following the HTML5 spec to the letter - for example, using <h1> tags within each new sectioning element - may make your site less accessible (to screen readers, for example). Don't strive for 'perfect' or close-to, because it doesn't exist - HTML5 is not thought-out well enough for that. Just concentrate on keeping your markup logical and uncluttered.
I found a good resource for HTML5 is HTML5Doctor. Check the article archive for practical implementations of the new tags. Not a complete reference mind you, but nice enough to ease into it :)
As shown by the Footer element page, sections can contain footers :)