So, according the W3C spec, the 'start' attribute in an ordered list is deprecated.
If you want to continue a list that's been broken up by a series of heading, you might have:
<ol start="15">
But that would not be allowed. The questions is how else could you/would you do it other than that which works in current browsers? Mission impossible?
The start attribute may be deprecated for HTML4.01, but it has returned for HTML5. Is there a browser compatibility issue?
EDIT: SitePoint says no. So the only real issue is validation. You can use HTML 4.01 Transitional, or HTML5, but not Strict, if you're really concerned about validation.
Otherwise, you're stuck with having the other lines in the HTML and hiding them.
<style type="text/css">.hidden { display: none }</style>
<ol>
<li class="hidden"></li>
<li class="hidden"></li>
<li class="hidden"></li>
<li class="hidden"></li>
<li>Starting at 5</li>
</ol>
You can do it with CSS counters, but they are not supported in all browsers. The start attribute is your best bet after all.
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.
According to the HTML5 Standard:
It is suggested that newlines be inserted after the DOCTYPE, after any comments that are before the root element, after the html element's start tag (if it is not omitted), and after any comments that are inside the html element but before the head element.
What is the reasoning behind this recomendation? Is there a difference between writing
<!DOCTYPE html>
<html>
<head>...
and
<!DOCTYPE html><html><head>...
?
It just helps improve readability, the code is processed exactly the same way.
There are some issues with parsing self-closing tags that can be a bit odd in certain situations.
For example, in HTML5 it is perfectly valid to write an unordered list like so:
<ul>
<li>Hello
<li>World
</ul>
The <li> tag implies </li><li> if there is no closing </li> present immediately before it. What's weird about this is the new lines in your code actually affect the way your list renders to the browser.
Unfortunately you cannot see this in jsfiddle, but you can see how the spacing issues affect a normally written list differently due to spacing, like this:
<ul>
<li>Hello</li><li>World</li>
</ul>
Differs from
<ul>
<li>Hello</li>
<li>World</li>
</ul>
Here's a little demo: http://jsfiddle.net/LGq9k/1/
I would imagine that the weird spacing oddities are the reason they suggest generally-accepted syntactical spacing and line breaks should be used, but who knows?
Just covered out some strage specs regarding ARIA roles. Why does ul have ARIA role menu but menuitem is forbidden for li?
I would like to describe a navigation bar using ul, li and HTML5's nav element in combination with the ARIA roles navigation, menu and menuitem.
<!DOCTYPE html>
<html>
<head><title>ARIA role bug?</title></head>
<body>
<nav role="navigation">
<ul role="menu">
<li role="menuitem">example.com</li>
</ul>
</nav>
</body>
</html>
W3's HTML5 validator nag me here:
Bad value menuitem for attribute role on element li.
Jukka is incorrect here. The W3C validator does not check against the WHATWG LS, instead it checks against the W3C HTML specification. The W3C HTML spec is the authoritative source for conformance checking requirements for the W3C Validator.
In regards to menuitem not being allowed as per the HTML spec, I believe this is a bug. And as such I have filed a bug. It is now in my bug queue to be resolved.
I have filed a bug against the W3C validator and wai-aria in HTML doc as well.
Until such times the validator is fixed, I suggest you use the roles as per the WAI-ARIA spec and ignore the validator.
addendum:
I looked back at history of ARIA integration into HTML could not find any reason why menuitem was not allowed, so believe it was an oversight. I fixed and resolved the bug I referenced above.
The following HTML markup is in the ARIA spec itself (the one you linked), and clearly shows a LI (nested, even) being used as a menuitem. Im guessing the particular markup you are using is forcing it to non-conform but thats just a hunch.
<ul role="menubar">
<!-- Rule 2A: "File" label via aria-labelledby -->
<li role="menuitem" aria-haspopup="true" aria-labelledby="fileLabel"><span id="fileLabel">File</span>
<ul role="menu">
<!-- Rule 2C: "New" label via Namefrom:contents -->
<li role="menuitem">New</li>
<li role="menuitem">Open…</li>
…
</ul>
</li>
…
</ul>
You shouldn't put role="menuitem" on an li element when it contains an a element since a menuitem widget cannot contain any intereactive elements (e.g links).
Take a look at the aria-practices examples for menu.
<li role="none">
<a role="menuitem">my menuitem here</a>
</li>
or
<li role="menuitem">my menuitem here</li>
The W3C validator, when applying HTML5 rules, actually checks against (some version of) the WHATWG “Living HTML standard”, which currently says, in clause 3.2.7 WAI-ARIA, about “li element whose parent is an ol or ul element” the following: “Role must be either listitem, menuitemcheckbox, menuitemradio, option, tab, or treeitem”.
This corresponds to the rules in the “Using WAI-ARIA in HTML” W3C draft, in 2.9 Recommendations Table.
I was using a similar DOM and changing an li submenu's role to presentation made the the page validate. Although perhaps semantically incorrect, in my situation it is inconsequential.
Now according to this post: Start a list from a certain number this has been deprecated, but it has been bought back in HTML5.
I'm not using HTML5, I'm using the transitional XHTML doctype.
So I'm wondering what I can use?
If I just go ahead and use..
<ol start=5>
Will it still work? I know I can just test it, but also want to make sure that all browsers will still show it as I intend?
Edit: I need something that is 100% reliable, not a CSS solution that has limited support.
The XHTML transitional DTD allows <ol> (ordered list) with a start attribute. Maybe you were using the wrong element? (<ul> instead of <ol>).
If the browser follows the XHTML1.0 Transitional rules it should render the list correctly.
The 'start' attribute is fine for XHTML Transitional, but has no effect on unordered lists (ul, for obvious reasons). Just use:
<ol start="5">
<li>My first list item</li>
<li>My second list item</li>
<li>etc.</li>
</ol>
Some may argue that you should be separating the numbering from the markup as it's presentaitonal and use CSS counters instead. Funny how it's valid again in HTML5 though, isn't it?
Looks like you're using an unordered list there. Try this:
<ol start="5">
<li>This is number 5</li>
<li>This is number 6</li>
<li>This is number 7</li>
<li>This is number 8</li>
</ol>
Example.
See that: http://norman.walsh.name/2011/08/12/styleThis
Is it ok to use <li> tags without parent tags?
i.e.
<li> some copy
or must it be..
<ul> (substitute your favorite list type)
<li> some copy
</ul>
Links on the subject:
Spec
XHTML
Validator
If by OK you mean "correct, follows standards and will validate" then no. Per the spec, only OL and UL can contain LI. (MENU and DIR are deprecated)
If by OK you mean "will render" then yes.
Also, to be "OK" by the first definition, you must also close your LI tags. Every tag must either be self-closing (/>) or have a corresponding closing tag. Here's a quick and simple explanation of correct XHTML (and honestly, good HTML should conform to these as well. No reason not to.)
Proper HTML (not to mention strict XHTML) should be:
<ul>
<li>whatever</li>
</ul>
No, using a li element without a parent ul or ol element would be invalid.
No, that would definitely be invalid (X)HTML. I mean, you could, and the browser might render it correctly if you're lucky (IE in particular, as it tends to be especially lenient), but there's far from any guarantee. You should always enclose <li> tags with either <ul> (unordered list) or <ol> (ordered list). Why wouldn't you want to anyway?
No, while it might work in some browsers, it is invalid HTML.
I checked the validation of the code below at Markup Validation Service of W3C :
<li>item 1</li>
<li>item 2</li>
and the result is :
document type does not allow element
"LI" here; missing one of "UL", "OL",
"DIR", "MENU" start-tag
li = list item, if it's without parents where's the list?
http://www.w3schools.com/TAGS/tag_li.asp
http://www.w3.org/TR/html401/struct/lists.html