So I'm trying to do a pretty simple contenteditable list with HTML that looks like this:
<article contenteditable="true">
<p>Text in doc</p>
<ol>
<li><p>Text in first LI</p><p>Has another para</p>
<ol>
<li><p>Text in nested LI</p></li>
<li><p>Text in nested LI2</p><p>And then some</p></li>
</ol>
</li>
<li><p>Text in second LI</p></li>
</ol>
</article>
In Webkit based browsers if you have a play around with it you find that it works pretty reasonably, inserting paragraphs when you hit enter, deleting list items if you hit backspace on them and things like that.
However if you try and delete the first item in the list (whilst there are still other things in the list), things get weird. You pretty much can't do it. And in fact what it does is move the text to the previous paragraph and leave you with an empty list item that you can no longer get to.
Maybe this is a defect in Webkit, but Firefox works the same way... In any case, can anyone suggest a workaround? I was thinking if I had some javascript that detected if it was the first character of the list then it would at least stop some of the unintuitive behaviour but you can still highlight across the item and hit del and still have an unreachable 1.
I have also tried making them divs and using the bleeding edge chrome, same behaviour.
See http://jsfiddle.net/2Unmz/14/ though it does act differently there than it does in my browser directly.
Despite it being the recommended method of nesting lists (http://developer.mozilla.org/en/HTML/Element/ol), it seems that you should end the list item before embedding another list inside it. This HTML works much more how I'd expect:
<p>Text in doc</p>
<ol>
<li><p>Text in first LI</p><p>Has another para</p></li><!-- Ending the LI now -->
<ol>
<li><p>Text in nested LI</p></li>
<li><p>Text in nested LI2</p><p>And then some</p></li>
</ol>
<!-- This is where it used to be -->
<li><p>Text in second LI</p></li>
</ol>
</article>
So looks like it's not a good idea to do nested lists as mozilla.org suggests if you want contentEditable to do logical things with your document.
Related
I was creating an un-ordered list and came to a point where I wanted to insert another list, that is, nest the lists. I'm using MS Expression Web (very good free tool) and it allows me to indent an <li> in the list by using the tab key. It puts another <ul> in and then puts in an <li> for the nested list.
However, when I switch to code view (which I use most of the time) the nested <ul> is flagged as not being allowed inside a <ul> by HTML 5.
If I view the page in FF, the nested list looks just as I would expect it to look. The bullets on the main list are black dots, the nested list is indented, and the bullets are circles.
If I change the <ul> tags to <ol> the nested list is numbered starting at zero.
So, I did a search to find out what tags can be included inside a <ul> or <ol> and came up with a lot of contradictory information - even here.
So, if HTML 5 does no allow almost any other tags inside a list (I've tried a lot of them to see what the parser says and they were flagged also such as <p>, <div>. etc.) - is there a tag with which I can create a classic outline with multiple levels?
Such as:
1 - Chapter One
a - Setting:
i - The City
ii - etc.
b - etc.
When I search on html outline -- I get references to the outline property to create outlines around elements - so there are borders and outlines??
Is there a "legal" way to produce an outline such as show above?
I can't believe there is no way of creating such an outline (legally)- I mean, outlines are a mainstay in documentation. Heck, table of contents are very often, if not just about always, nested outlines.
Is there a way to do it?
I have not found any way to create an outline except using nested lists.
I ran the following through a couple of validators and there were no errors or warnings.
So, I guess this answers my question.
<ul> <!--beginning of outer list -->
<li>
First line of outline, outer list
</li>
<li>
Second line of outline, outer list
<ul> <!--beginning of first nested list-->
<li>
First line of first nested list
</li>
<li>
Second line of 1st nested list
<ul> <!-- beginning 2nd nested list -->
<li>
First line of 2nd nested list
</li>
</ul> <!-- end of 2nd nested list -->
</li> <!-- end of list item in which 2nd nested list exists
</ul> <!-- end of 1st nested list-->
</li> <!-- end of of list item which contains 1st nested list -->
<li>
Third line of Outline, non nested
</li>
<ul> <!-- end outer list -->
Produces the following:
First line of outline, outer list
Second line of outline, outer list
First line of first nested list
Second line of 1st nested list
First line of 2nd nested list
Third line of Outline, non nested
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>
I'm validating my website using the W3C HTML validation, and I'm getting errors for adding a line break in an ordered list.
E.g.:
<ol>
<li>Stuff</li><br/>
<li>Stuff2</li><br/>
</ol>
with successful validation would print
Stuff Stuff2
but it should be
Stuff
Stuff2
Without the line breaks it validates fine, but the list elements aren't on individual lines.
Is there a way that the site validates WHILE line breaking each stuff element?
I feel WOW on <br/> between <li>. <li> itself puts things in next line always..and you don't have anything in <ol> except <li>,
If you want some extra gap between <li>'s than use margin in CSS.
And how you say that:
with successful validation would print
Stuff Stuff2
This will not going to happen with <li> though.
You cannot have anything other than <li> inside a <ol> or <ul>. Something in your CSS may be messing up your lists.
I'm currently trying to come up with a good and accessible way to format a status indicator which should be rendered within a set of wizard-like pages on a website. The website should provide a multipage form with a status indicator on top of it as demonstrated in the wireframe below:
Given the new progress-tag in HTML my first thought was to do something like this:
<progress value="2" max="3">
<ul>
<li>Beginning</li>
<li class="now">Right now</li>
<li>End</li>
</ul>
</progress>
... but since <progress> only accepts phrasing content using a list is not really an option. So right now I would probably go with something like this, integratinng the ARIA progressbar-role:
<ul aria-role="progressbar" aria-valuenow="2" aria-valuemin="1" aria-valuemax="3" aria-describedby="state2" aria-valuetext="Right now">
<li id="state1">Beginning</li>
<li id="state2" class="now">Right now</li>
<li id="state3">End</li>
</ul>
But again, I'm not really sure if the progressbar role can be applied in such a way to a list.
Another problem is, that <progress> is rendered as progress bar in Opera, for instance, so >progress> itself is probably not really a viable solution altogether :-(
Can anyone perhaps recommend an accessible status bar that does not only rely on using a single image?
Current solution
For now I will go with following markup:
<section class="progress">
<h1 class="supportive">Your current progress</h1>
<ol>
<li><span class="supportive">Completed step:</span> Login</li>
<li class="now"><span class="supportive">Current step:</span> Right now</li>
<li><span class="supportive">Future step:</span> End</li>
</ol>
</section>
All elements of the class "supportive" will be positioned off-screen. IMO this way we should have a nice compromise of semantic markup (the state succession is in my opinion really an ordered list ;-)) and accessibility thanks to the additional header and status text for each step.
According to whatwg, you're not supposed to assign progressbar role to <ul> elements.
I'd just ditch <ul> and describe progress using (surprise) phrasing content:
<section role="status">
<h2>Task Progress</h2>
<p>You're now at <progress value=2 max=3>"Right now" step</progress>.
</section>
Update: You're right, progress doesn't suit here, it's more like an interactive form widget. I should've checked first, before taking it from your first example. But anyway, the point is there's no need to use a list (even more so, unordered list), when you can just describe what's going on in plain text. In the case that the list of past and future steps is necessary, I'd just add two more paragraphs, one before the status (‘You've completed the "Beginning" step’), and one after (‘Next step will be the "End" step’).
However, I admit that this isn't a complete answer to your question.
Also, I'd say some aria attributes look redundant to me. For example, aria-valuetext perhaps would make more sense in the context of interactive widget, when there's no other human-friendly description of its state. Though I may be wrong here.
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 :)