I'm transforming some XML, which I have no control over, to XHTML. The XML schema defines a <para> tag for paragraphs and <unordered-list> and <ordered-list> for lists.
Frequently in this XML, I find lists nested within paragraphs. So, a straight-forward transformation causes <ul>s to get nested within <p>s, which is illegal in XHTML.
I've created a list of ways to deal with it and here are the most obvious:
Just don't worry about it. The browsers will do fine. Who cares. (I don't like this option, but it's an option!)
Write a fancy-pants component to my transform that makes sure all <para> tags get closed before unordered lists start, and re-opened afterward. (I like this option the most, but it's complicated due to multiple levels of nesting, and we may not have the budget for this)
Just transform <para> to <div> and set the margins on the divs so it looks like a paragraph in the browser. This is the easiest solution that emits valid XHTML, but it takes from the semantic value of the markup.
My questions are:
how much value do I lose if I go with option 3?
Does it really matter?
What is the actual effect on the user experience?
If you can cite references, please do (this is easy to speculate on). For example, I was thinking it might affect search results from a Google Search Appliance that we are using.
If search terms appear in divs, do they carry less weight?
Or is there less of an association between them and preceding header tags?
How can I find this out?
I've come up against this too.
Personally, I consider it a grave mistake on part of the standard that a p cannot contain lists. I think it's typographically legal, so it should be legal in what was originally intended to be a markup for text.
I may be flamed for this, but XHTML has crashed and burned in the real world, regardless of whether it was a good idea or not. The often horrible tag soup that is today's HTML markup will continue to survive for a goodly long time, if only because bad markup and lenient browsers will continue to perpetuate each other forever.
Thus, I tend to go with Option 1.
Option 3 is also viable, in my opinion. While I don't have proof, I'm pretty sure no search engine is crazy enough to actually put any trust in most of the formatting tags we apply to our HTML. meta and a tags are obvious exceptions, of course.
First of all, unless you set every CSS property available now plus every one possibly available in the future, then you can't guarantee your <div> will match up, WRT styles, with <p>. (Though I agree you can get close and this is probably good enough, but read on.) I don't know of any visual browsers or other tools that would seriously treat them differently, but this is just as much an artifact, IMHO, of the current widespread loose interpretation on the web, as it is of them being close in meaning.
Is <ul> the right transformation for every <unordered-list> in your source data? If they are always displayed as block-level content instead of 1) an, 2) inline, 3) list; then that's a safe bet. If so, you can break the paragraph into two (and wrap the whole thing in <div> if you like).
Example input:
<para>Yadda yadda: <unordered-list/> And so fin.</para>
Output:
<div>
<p>Yadda yadda:</p>
<ul/>
<p>And so fin.</p>
</div>
The good news is that any of these 3 options would work.
There are many, many people on SO that will tell you "if it works, forget semantics and do it." So Option 1 would probably be a site favorite if everyone here was asked.
Option 2 is my favorite and would be the best semantically. I would definetely do it if time/budget allows.
However, Option 3 is a close second and hopefully this will answer your question: The <div> element and the <p> element are near-identical. In fact, the biggest difference is semantics. They each have only one rule applied to them in most browsers' CSS specification: display: block.
Related
My question is this – is it still best practice to use certain HTML tags even if you would then need to style them differently to how a browser interprets and displays those tags?
For example – the HTML5 <blockquote> tag will start on its own line, with default margin and padding, and with an indent.
However – if you do not wish there to be an indent, should you still use the <blockquote> tags in order to convey meaning to the browser and search engine, and then apply CSS to reduce/rid the indent, or should you just use a <p> tag for example?
It’s not much effort to restyle the blockquote element, and I assume that it is important to use the tags that most accurately convey the meaning of their contents, but at the same time I do not want to get into a habit of writing extra code if it is considered best practice not to do so.
I assume that it is important to use the tags that most accurately
convey the meaning of their contents
You assume correctly.
I would say yes, absolutely always try to use the appropriate element for the type of content/purpose you intend. Elements have names/designations for a reason, so your code can be structured in a way that makes semantic sense. Why is this important? Well ignoring SEO for which it plays an important part, or ease of access regarding your code, this is the intended design of HTML.
Not using a specific element because it has default styling applied is not a sensible or really logical course of action in this context. This is especially in light of the fact that when you compare browser-specific styling, most elements may have default styles applied.
I do not want to get into a habit of writing extra code if it is
considered best practice not to do so
Bad practice to some degree is subjective, otherwise it is simply right or wrong- in this case it wont be game breaking to not use the correct tags, however you will be going against their intended use according to specification, so it would most certainly be bad practice.
See:
Semantic HTML (Wikipedia)
Semantic Web (Wikipedia)
Yes, use the tags which are most aligned with the semantics of your content. Don't concern yourself with styling when constructing your HTML doc, as you could have different styles for different resolutions (smartphone, tablet, desktop) or even different mediums (web browser, screen reader, braille display, whatever device come out in the future...)
The following talks about class names specifically, but it does drive home the importance of semantic correctness:
ref: http://www.w3.org/QA/Tips/goodclassnames
HTML5 gives us many new elements to describe parts of a Web page, such as header, footer, nav, section, article, aside and so on. These exist because we Web developers actually wanted such semantics. How did the authors of the HTML5 specification know this? Because in 2005 Google analyzed 1 billion pages to see what authors were using as class names on divs and other elements. More recently, in 2008, Opera MAMA analyzed 3 million URLs to see the top class names and top IDs used in the wild. These analyses revealed that authors wanted to mark up these areas of the page but had no elements to do so, other than the humble and generic div, to which they then added descriptive classes and IDs.
(HTML5 Doctor has many articles about HTML5 semantics.)
Read
You use the blockquote tag to denote that the content is a quote.
The default style provided by the mark-up communicates information to the one interpreting or decoding the sign.
http://html5doctor.com/blockquote-q-cite/
It is not only a matter of the default style of the mark-up element.
By using CSS you can create a variation of that basic style. And this is certainly valid for the blockquote. The default style does not provide quotes just padding and margin. It is provided by the CSS quotes property. And this is just one way of styling a quote. You can have a left border on the quote, italic, ...
blockquote {
quotes: "\201C""\201D""\2018""\2019";
}
http://css-tricks.com/snippets/css/simple-and-nice-blockquote-styling/
This is largely opinion-based, and opinions on matters like this are often expressed almost as religious convictions, with little or no factual evidence or arguments presented. However, I will try to deal with the issue on a technical basis, focusing on the example given. (It’s a good example and does not take us too easily too deep into semantic jungles.)
The blockquote element is defined as structural rather than semantic. It does not say anything about the meaning of its content (it might be about apples, God, or screwdrivers), only about its structural relation with the enclosing document: the content is a copy of some content taken from an external source, i.e. from outside the document – that is, a quotation – and it is a “block quotation” as opposite to “inline quotation”, which means little (if anything) else than its default rendering being a block.
In practice, blockquote has widely been just simply to indent text, especially in the old days, before CSS was generally available. This is one reason why there is no sign of search engines (or browsers) making any use of the structural relationship (or “semantics”, if you want to put it that way) nominally expressed by the element. There are many things that search engines could do with such information. They just don’t. It is questionable if they ever will: too much content would be incorrectly treated as quoted, and there is too much content that is actually quoted but not marked with blockquote.
Thus, the effect of blockquote is in practice just the default rendering, with certain margins on all sides. When CSS is disabled or overridden for some reason, this is the rendering, and you should try to use HTML markup that gives you tolerable rendering even without CSS. This can be seen as the good reason for using blockquote for block quotations. On the other hand, if your block quotations have been clearly indicated as quotations in other methods, such as introductory phrases or headings, this argument does not really apply.
On the other hand, there is no good reason not to use blockquote just because you don’t want the indent. In that case, you must have some other method of visually distinguishing the block quotation from other content, such as using a background color, a different font, or maybe large decorative quotation marks. You would naturally be using CSS for that, and compared to what you do with it, setting margin-left: 0 is a trivial thing to do.
Moreover, even though browsers and general search engines ignore the structural meaning of blockquote, you (or your organization) may decide to do otherwise. You can choose to mark block quotations uniformly in order to be able to find them easily (for statistical, checking, or other purposes). You could achieve the same by using, say, class=quote consistently, but why not use an element when you can?
I can't find a convincing answer for this. Is it wrong in terms of semantic HTML? SEO unfriendly? Accessibility?
A lot of WYSIWYG editors use it. I think it is a good way to add some extra space between paragraphs, like you do when you're writing a document and want to express 'extra differentiation' between 2 specific paragraphs. Of course you can do that with CSS, but you need to add extra classes like so:
<p class="extra-space">
Some text
</p>
<p>
Other topic
</p>
I'm sure this is not a problem for screen readers. And semantics … why an 'empty paragraph' has not a valid meaning by itself?
It's because an empty paragraph is not a paragraph at all. A paragraph is defined as "A paragraph is a self-contained unit of a discourse in writing dealing with a particular point or idea." (by Wikipedia)
From a typographic point-of-view there are other elements that help seperating content in a more semantic way. If the next paragraph is so important you maybe want to add a heading in front of it.
You also violate the rules of seperating content and design. It's just not a good idea. Think of a blog you're writing. If you do something like that, you're typographic appearance may become totally inconsistent because sometimes you use 2 empty paragraphs, sometimes none. It's just not a good idea to mix content and appearance.
It is wrong in terms of semantics because these semantics define a way to properly "Talk" to the machine.
Although it displays fine, it is can become an issue when you need some automated process.
To put it in another perspective, lets say you have a recipe, that works well when you tell it to someone. At some point you are writing down the recipe for an automated robot.
Instead of writing "Add ice cream in the blender"
you are writing "Add I scream in the blender"
When you hear it, it is the same.
When someone reads it, and can correct the mistake, is fine.
What about when the robot reads it ?
Correct me if I'm mistaken, but AFAIK, unknown HTML tags in markup (i.e. tags not defined in the HTML spec, like say, <foobar>) will eventually be treated as a regular <div> in an HTML 5 browser environment.
I'm thinking: how supportable is this practice? I mean, if I use unknown HTML tags in my markup, what pitfalls can I expect? Will a velociraptor pounce on me within the next few seconds?
The reason I ask is that if these tags defer to <div>, I can potentially use these tags in a more semantic manner than, say, assigning class names that identify modules. Have a look at this article, for example, of a .media class. Now what if instead of writing up that CSS to target .media, I make it target <media> instead? In my opinion, that makes the markup much more readable and maintainable, but I do acknowledge that it's not "correct" HTML.
EDIT
Just to be transparent, I did find this SO question from a few years back. It's been closed as off-topic, but I feel that I have a valid point in my own wording. It's a close duplicate, I admit, but it's from a few years back, so there might have been changes in the general environ of opinions across web developers about the topic.
user1309389 had a very good answer, and I agree with the appeal to the spec. But I disagree with their conclusion, and I think they're wrong about made-up elements leading to "undefined behaviour". I want to propose an alternative way of thinking about it, rooted in how the spec and browsers actually handle made-up elements.
It's 2015, we're on the verge of the CustomElement spec being widely adopted, and polyfills are readily available. Now is a great time to be wondering about "making up your own elements". In the near future, you'll be able to create new elements with your own choice of tag and behaviour in a fully standard and supported way that everyone can love. But until this lands in all browsers, and until the majority of people are using supporting browsers, you can take advantage of the hard work of the Polymer or X-Tags projects to check out the future of custom elements in a nearly-standard and mostly-supported way that quite a few people can love. This is probably the "right thing" to do. But it doesn't answer your question, and frankly I find "just use X" or "don't do X" to be less helpful than "here's how the spec covers this, and here's what browsers do". So, here's what I love.
Against the heartfelt recommendation (and sometimes screaming) of much of the web dev community, I've been working with "made-up" elements for the past year, in all of my production projects, without a polyfill, and I've had no unsolvable issues (yet), and no complaints. How? By relying on the standard behaviour of HTMLUnknownElement, the part of the W3C spec that covers the case of "made-up" elements. If a browser encounters an unrecognized HTML element, there is a well-defined and unambiguous way that it should be handled, and HTMLUnknownElement defines that behaviour, and you can build on top of that. HTMLUnknownElement also has to be powerful and correct enough to "not break the web" when encountering all the tags that are now obsolete, like the <blink> tag. It's not recommended that you use HTMLUnknownElement, but in theory and in practice, there's absolutely no harm in doing so, if you know what you're doing.
So how does HTMLUnknownElement work? It is just an extension of the HTMLElement interface, which is the standard interface underlying all HTML elements. Unlike most other elements however, HTMLUnknownElement doesn't add any special behaviour — you get a raw element, unadorned with any special behaviour nor constraining rules about use. The HTMLDivElement interface works almost exactly the same way, extending HTMLElement and adding almost no additional behaviour. Put simply, making up your own element is almost identical to using a div or span.
What I like about "making-up" elements is the change of mindset. You should use or invent HTML elements based on several factors, ranging from how clear it makes the markup to read, to how the browser and screen readers and search engines parse your code, to how likely your code is to be "correct" by some objective measure. I sparingly use made-up elements, but I use in exactly the way Richard described, to make things more meaningful for the author of the HTML, not just meaningful to a computer service that extracts metadata. When used in a consistent way across a team, there can be a big benefit since made-up elements can concisely express what they're for.
I particularly like using made-up elements to indicate when I will be using JS to define extra behaviour for an element. For instance, if I have an element that will have children added/removed by JS, I will use a made-up element as a clue that this element is subject to special behaviour. By the same token, I don't use a made-up element when a standard element will suffice. You will see <dynamic-list> live happily next to <div> in my code.
Now, about those pesky validators. Yes, using made-up elements isn't "valid" in the sense that it won't pass a "validator". But many commonly used features, patterns, and systems of modern HTML and JS development fail all the W3C validators. The validators aren't the law — the spec is. And the law isn't binding — the implementations in all the browsers are. The utility of validators has been dimishing for years as the flexability of HTML has been increasing, and as browsers have shifted in their relationship to the spec. Validators are great for people who aren't comfortable with HTML and need guidance. But if you're comfortable taking your guidance from the spec and from browser implementations, there's no reason to worry about being flunked by the validator. Certainly, if you follow many of the guidelines offered by Google, Apple, Microsoft, etc, for implementing any experimental features, you'll be working outside the bounds of the validator. This is absolutely an okay thing to do, so long as you're doing it deliberately and you know enough about what you're doing.
Therefore, if you're going to make up your own elements and rely on HTMLUnknownElement, don't just treat it like a wild west. You need to follow a few simple rules.
You have to use a hyphen in the name of your tag. If you do, you are guaranteed to never collide with a future edition of the HTML spec. So never say <wrong>, always say <quite-right>.
Made-up elements can't be self-closing — you have to close them with a closing tag. You can't just say <wrong> or <still-wrong />, you have to say <totally-good></totally-good>.
You have to define a display property for your element in CSS, otherwise the rendering behaviour is undefined.
That's about it. If you do these things, you should be good to use made-up elements in IE9 and up, relying on the safety net of the HTMLUnknownElement. For me, the benefits far, far outweigh the costs, so I've been using this pattern heavily. I run a SaaS site catering to major industrial corporations, and I've had no trouble or complaints thus far. If you have to support older versions of IE, it's wise to stay far away from any "2015" technology or their crude approximations, and stay safely within the well-trodden parts of the spec.
So, in summary, the answer to your question is "yes, if you know what you're doing".
You should always approach HTML as it is defined in its respective specification. "Defining" new tags is a bit of an extreme approach. It might pass a browser check because it implements various failsafes, but there is no guarantee of this. You're entering the land of Undefined Behaviour, at best. Not to mention you will fail validation tests, but you seem to be aware of that.
If you wish to be more semantically expressive in your markup, you can use HTML5 which defines quite a bit of more descriptive tags for describing the structure of your page instead of generic divs which need to be appended ids or classes.
In the end, a short answer: No, it's bad practice, you shouldn't do it and there could be unforeseen problems later on in your development.
No. You will fail validation, you will get random issues cross browser and you WILL be eaten by said dinosaurs. CSS is the answer if you want your page to behave predictably.
Yes We Can.
There is a new spec going on about custom elements/tag - http://w3c.github.io/webcomponents/spec/custom/.
Only issue with this is you have to use js to register your new element
You can read more about this at
https://developers.google.com/web/fundamentals/getting-started/primers/customelements
Rule #1 of browser interoperability is: don't have errors. No matter how many browsers you test in, there are always browsers you can't test, for instance because they don't exist yet.
Also, unknown elements will be treated as <span>, not <div> by most browsers currently.
If it's really source readability(*) you're after, you should look into XML+XSLT.
That way, you can use all the tag names you want, and make them behave in any way you like and you don't have to worry that <media> will be a real element in some future version of HTML.
One good real world example is the element <picture>. If a website ever used <picture> and relied on the notion that this element would have no styles or special content by itself, they are in trouble now!
(*) With XML+XSLT, the readability will be in the XML part, not the XSLT part, obviously.
Generally not recommendable, e.g. IE wont apply css-styles to unknown tags.
All other browsers render unknown tags as inline-Elements (which causes problems with nesting).
I recommend you the following article: http://diveintohtml5.info/ There is a section about unknown tags.
In my case I use a lot of them into my Webkit-powered game GUI system, and everything works.
W3C says:
HTML5 supports unknown tags as inline elements, but it recommends CSS
styling for it.
Here is the source: https://www.w3schools.com/html/html5_browsers.asp
In your example you are talking about <media>, it's could be great but if html6 adds this tag for another element, your code won't be retrocompatible.
The one downside that worries me is what if a custom tag I use now, becomes an official HTML-tag next year or even later?
Therefore how about this: Instead of custom tags use 'div' + a custom CSS-class.
CSS-classes are meant to be custom, it is definitely ok to have your own custom CSS-classes. Your div can then further have any number of CSS-classes associated with it making the semantic machinery even more flexible, you could call it multiple inheritance.
Instead of div you could use span for the same purpose. I would like to use something shorter actually, say p but unfortunately p has its own special behavior of what happens if you don't close it.
But definitely if you go the route of expressing semantics with CSS-classes then it does help to use a tag-name that is as short as possible. I wish there was something shorter than div, say for instance t for 'tag'.
By default, custom elements main parts of many JavaScript-Framwork. It is state of the art in modern javascript.:
var XFoo = document.registerElement('x-foo', {
prototype: Object.create(HTMLElement.prototype)
});
https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements
https://www.html5rocks.com/en/tutorials/webcomponents/customelements/
Is it OK to use unknown HTML tags? If you ask wrong questions, you get allways wrong answers. If you define your unknown tag with javascript as a CustomeElement , your unknown tag is no longer part of the HTML5/HTML-definition.
Yes, you can use unknown tags, if you define the tag in your javascript.
What's wrong with the judicious use of < !-- your stuff here -- >. It worked for scripts back around the time of the Cretaceous–Paleogene boundary. Dinosaurs ceased to be a problem around that time, that is apart from the flying, feathered variety.
It's bad practice and you should not do it. The browser renders it as div as fallback solution in most cases but it's not valid html and therefore never will pass a validity test.
EDIT: Rephrased question.
Other than being bad practice, what other reasons are there against empty paragraphs in HTML?
ORIGINAL:
Background
Currently to add a nicely space paragraph in our CMS you press Enter key twice. I don't like empty paragraphs because they seem unnecessary to me. If you want a new paragraph, just press Enter and space it with CSS. If you want to write just below some text (e.g. to display code), then do a line break with Shift+Enter.
Question
Is there any very good reason in not allowing empty paragraphs? Is there a standard here? Seems like I just have a philosophical issue right now -- i.e. using empty paragraphs probably won't make page viewing faster or save that much space.
One thing I've learnt the heard way is that any time you have a WYSIWYG editor for a web page, you stand a risk of ending up with poor quality HTML.
It doesn't matter how good the editor is, or how well trained your people are to use it, you will end up with bad code.
They'll click the 'bold' button instead of selecting your sub-title class. They'll create spurious paragraph tags rather than line breaks. And I've had to explain to one person several times why it's a bad idea to use multiple spaces to indent stuff.
Even when people are very good at using the editor and understand the implications, you'll still get things like stray markup setting styles and then unsetting them without any content, because if you (for example) make a word bold and then delete it, it generally doesn't delete the bold tags, and no-one thinks to switch to the HTML view to check.
The basic problem is that when you make it easy to use like a word processor, people will treat it like a word processor, and the underlying code becomes completely irrelevant to them. Their job is to produce content that looks good, and as long as they can achieve that, they don't generally care for how the code looks.
The good thing is that there is a solution. In general, the people generating the content are the same people who care the most about SEO. If you emphasise that there might be SEO consequences to poor quality HTML, I find that they suddenly care a lot more about the code they're generating. They still don't generally have the skills to fix it when they've broken it, but it does seem to make people take more care to follow the rules.
To directly answer your question, I don't think it's a disaster to have empty paragraph tags like that. It's preferable not to though, and you need to consider how the content would look semantically to a search engine - it may cause the search engine to see the two paragraphs of content as being less connected to each other than they should be. This may affect how it weights the content of each paragraph when it comes to deciding its page rank. In truth, it's unlikely to be a huge difference; in fact, I'd say it's probably very tiny, but in a competitive world, it could be enough to push you down a few places. There are probably other more important SEO issues for you to deal with, but as they say, every little helps.
There are times when you have a CSS styling a particular element in your case a paragraph. IF you will use empty paragraph they will unneccesarily pick up that styling which might not be needed.
By styling paragraphs with CSS, you can change the way paragraphs are styled easily in future.
For example, you might want to style differently if the user is browsing on a mobile device, or you might just decide that you want to add more or less space between paragraphs (using attributes like margin-top and margin-bottom on the p tag I guess) because it just looks better that way. If the spacing is done with extra p tags it'd be a lot harder to change.
I expect that things like screen readers for the visually impaired would deal with CSS-styled paragraphs better than if the structure of the page is changed by adding empty paragraphs.
I have seen it a lot in css talk. What does semantically correct mean?
Labeling correctly
It means that you're calling something what it actually is. The classic example is that if something is a table, it should contain rows and columns of data. To use that for layout is semantically incorrect - you're saying "this is a table" when it's not.
Another example: a list (<ul> or <ol>) should generally be used to group similar items (<li>). You could use a div for the group and a <span> for each item, and style each span to be on a separate line with a bullet point, and it might look the way you want. But "this is a list" conveys more information.
Fits the ideal behind HTML
HTML stands for "HyperText Markup Language"; its purpose is to mark up, or label, your content. The more accurately you mark it up, the better. New elements are being introduced in HTML5 to more accurately label common web page parts, such as headers and footers.
Makes it more useful
All of this semantic labeling helps machines parse your content, which helps users. For instance:
Knowing what your elements are lets browsers use sensible defaults for how they should look and behave. This means you have less customization work to do and are more likely to get consistent results in different browsers.
Browsers can correctly apply your CSS (Cascading Style Sheets), describing how each type of content should look. You can offer alternative styles, or users can use their own; as long as you've labeled your elements semantically, rules like "I want headlines to be huge" will be usable.
Screen readers for the blind can help them fill out a form more easily if the logical sections are broken into fieldsets with one legend for each one. A blind user can hear the legend text and decide, "oh, I can skip this section," just as a sighted user might do by reading it.
Mobile phones can switch to a numeric keyboard when they see a form input of type="tel" (for telephone numbers).
Semantics basically means "The study of meaning".
Usually when people are talking about code being semantically correct, they're referring to the code that accurately describes something.
In (x)HTML, there are certain tags that give meaning to the content they contain. For example:
An H1 tag describes the data it contains as a level-1 heading. An H2 tag describes the data it contains as a level-2 heading. The implied meaning behind this is that each H2 under an H1 is in some way related (i.e. heading and subheading).
When you code in a semantic way, you basically give meaning to the data you're describing.
Consider the following 2 samples of semantic VS non-semantic:
<h1>Heading</h1>
<h2>Subheading</h2>
VS a non-semantic equivalent:
<p><strong>Heading</strong></p>
<p><em>Subheading</em></p>
Sometimes you might hear people in a debate saying "You're just talking semantics now" and this usually refers to the act of saying the same meaning as the other person but using different words.
"Semantically correct usage of elements means that you use them for what they are meant to be used for. It means that you use tables for tabular data but not for layout, it means that you use lists for listing things, strong and em for giving text an emphasis, and the like."
From: http://www.codingforums.com/archive/index.php/t-53165.html
HTML elements have meaning. "Semantically correct" means that your elements mean what they are supposed to.
For instance, you definition lists are represented by <dl> lists in code, your abbreviations are <abbr>s etc.
It means that HTML elements are used in the right context (not like tables are used for design purposes), CSS classes are named in a human-understandable way and the document itself has a structure that can be processed by non-browser clients like screen-readers, automatic parsers trying to extract the information and its structure from the document etc.
For example, you use lists to build up menus. This way a screen reader for disabled people will know these list items are parts of the same menu level, so it will read them in sequence for a person to make choice.
I've never heard it in a purely CSS context, but when talking about CSS and HTML, it means using the proper tags (for example, avoiding the use of the table tag for non-tabular data), providing proper values for the class and id that identify what the contained data is (and using microformats as appropriate), and so on.
It's all about making sure that your data can be understood by humans (everything is displayed properly) and computers (everything is properly identified and marked up).