Doing a code review, I noticed that a heading was using <span> tags instead of headings, so I suggested using an <h4> tag, to gain the semantic benefits. The context is a website footer, where there are various lists of links under different headings.
<span>Category 1 Links</span>
<ul>
<li>Link 1 in the footer</li>
<li>Link 2 in the footer</li>
<li>Link 3 in the footer</li>
<li>Link 4 in the footer</li>
<li>Link 5 in the footer</li>
</ul>
The counterargument was that <h4> is a "block-level" element, whereas an inline element was needed. Therefore he didn't think the element should be changed. (And yes, he knows CSS and is familiar with the display: inline; property.)
That sounds absolutely insane to me--goes against everything I always thought was best practice: separation of content and presentation, semantic web, the very purposes of HTML and CSS... yet in trying to formulate a response, I came across this section in the HTML 4.01 spec:
Certain HTML elements that may appear in BODY are said to be
"block-level" while others are "inline" (also known as "text level").
...
Style sheets provide the means to specify the rendering of arbitrary
elements, including whether an element is rendered as block or inline.
In some cases, such as an inline style for list elements, this may be
appropriate, but generally speaking, authors are discouraged from
overriding the conventional interpretation of HTML elements in this
way.
The alteration of the traditional presentation idioms for block level
and inline elements also has an impact on the bidirectional text
algorithm. See the section on the effect of style sheets on
bidirectionality for more information.
So here is the question: does this section make the issue sufficiently vague for there to be valid difference of opinion here, or is it (as I had thought) pretty clear in one way or the other? If this section is open to interpretation, are there any other W3C guidelines that are more concrete?
I don't want to get into opinions on this, I just want to make sure I'm understanding the spec and the W3C guidelines correctly: is there true ambiguity here, or not?
W3C specifications allow display: inline on heading elements. In general, HTML specifications do not restrict what you can do in CSS, and vice versa.
The section Block-level and inline elements that you quoted contains a recommendation (“discouraged”). It is a “should not”, not a “shall not” statement, i.e. not a conformance criterion. The motivation for the recommendation is not given, but generally such ideas are based on the fact that HTML documents may be processed by software that ignores style sheets, or may have author style sheets overridden, or otherwise gives preference to the defined meanings of elements rather than their CSS styling.
Even though the possibility of making a heading an inline element (in the sense of setting display: inline) is not mentioned here, doing so is part of one way of creating “run-in headings” (headings that appear inline at the start of a paragraph, rather than on a line of its own). Nowdays a better way to achieve that is display: run-in, as exemplified in the CSS basic box model WD. The basic point is still the same: it’s OK to turn a heading element from its default display: block to inline-like presentation.
Regarding the specific case presented, I don’t quite see why an inline element would be needed. The next element is ul, causing a line break (and vertical spacing) by default. And if the rendering of the ul is changed to inline with CSS, it is difficult to see why you could not do the same to an element that is logically a heading for the list.
First of all, the quoted section is indeed from the 14-year old HTML 4.01 specification. I do not remember ever reading anything of the type in the HTML5 specs. I personally think it was deemed a good remark at the time but has since been obsoleted by experience. Don't forget that HTML4 was the one to actually properly separate HTML and CSS, and as such contains 'mistakes' like the quoted remark that were later 'corrected'.
In essence, there should not be any implicitly locked relationship between your semantic markup and your styling. Like the hX elements, a div is also a block level element, but only because of the way it interacts with other elements, most specifically which elements it can contain - an inline element must not contain a block element while a block element can contain both inline and block elements, bar explicitly defined relationships such as ul > li and table > tr > td. Essentially the separation of semantics and presentation should be kept so strict that the specifications of the markup language HTML should never even mention the existence of the concept of stylesheets - stylesheets can be applied to anything, not just HTML, and HTML feeds so many more technologies than just browsers.
From a web developer's perspective, you are absolutely right. The block nature of a h4 element merely implies its relationship with potential child elements, and its default representation in the browser's default stylesheet. What the CSS developer then wants to do with his stylesheet is his own choice - for all you care he applies a display:table-cell rule to it if that properly fits his design.
TL;DR: There is no ambiguity, and you should always write your CSS to conform to how you want to display your HTML, not adapt your HTML to the requirements of the CSS. Using a span where an h4 is required is just plain wrong from a semantic (and SEO) perspective.
In my opinion, any typographic convention that you have ever seen in a book or other printed media is fair game for modeling a web page.
For example, I have seen text books with several columns, each with a header, and one could achieve this effect by using display: inline to a h4 tag.
In this example, whether h4 is on a stand-along block or part of a horizontal sequence will depend on the content and how you are trying to communicate ideas to your readers.
Consider how your page would render in a text-only browser that does not support CSS, would the raw ordering of the text make any sense? If so, then, your choice of HTML are probably valid.
On the other hand, if you took table tags and turned them into headers or list items, then you are probably going to get HTML that would not sound right if the page were read by some type of audio browser (think visually impaired people using a page reader).
Let semantics dictate the tags that you use and use CSS to get the visual layout that you need.
Related
I am working on a website where users can post comments. I intend to use the <ins>-element herefore. When comments are inaccurate, they will be marked as deleted using the <del>-element.
My first question is whether I use the semantics of these elements correctly?
It surprised me when I saw at W3C that these two elements can contain block-level-elements inside it since that is usually not the case for text-elements who are set to display: inline; (cannot have a width, height etc.). I checked the computed browser value which is definately display: inline; for both <del> and <ins>.
So my second question is how the browser makes this special behavior to work? (Or is it even special? - am I missing something?)
Try not to confuse styling (CSS) with the HTML content model. These are deliberately separate and orthogonal concepts. The only link is that some HTML elements have a consistent default styling.
Although ins and del could be used the way you describe in HTML4, HTML5 makes this separation much more distinct, because it does not use the terms "block" and "inline". These terms are left to CSS. HTML5's content model uses separate categorization, including "flow", "phrasing", and important in this case, "transparent"
The content model is used to assist a document content's meaning. But browsers do not care about the meaning, only how to render it.
CSS provides clear rules about how to render block elements inside inline elements, completely regardless of HTML's content model restrictions. See this answer: Is it wrong to change a block element to inline with CSS if it contains another block element? .
So, no the behaviour isn't "special", and browsers do not have to do anything except use the normal CSS rules to handle it.
As for your first question, it's hard to tell whether "inaccuracy" should imply use of <del>. If the commenter intends to withdraw that inaccuracy, then <del> would be appropriate, otherwise probably not.
I passed a style sheet with the following to the W3C validator and it passed:
a {
display: block;
}
So want to make sure, is it valid markup to use an inline element as a block one?
I know it will work but is it valid?
Thanks
Yes, it's completely valid. And useful too.
One small note (since the above answer is very short), this method of styling normally inline elements as block elements is quite common. For example, when creating a horizontal navigation menu from a list, you'll often see <a> elements styled with display:block in order for the links to be able to take up the full width and height of the parent list item.
Yes it's valid but also you can use inline-block to use an inline element while keeping the block properties.
Yes, it is valid.
There are elements, as you know, that are inline or block by default. But it is completely valid to then go and override this in CSS.
Yes, it is valid. However, if you really don't want to do that, you could wrap the a in a div. That would be useless though, because it is completely valid; that's why the display attribute is there.
The style sheet is valid, in the sense that it conforms to the CSS specifications. This is a purely formal thing. In CSS, the selector a has no special meaning, it is just an identifier; CSS has no information about the meaning of a in HTML, such as being an inline element, and the style sheet could in fact be used to style an XML document, where a means something completely different.
HTML validity, on the other hand, does not depend on CSS at all. It is a formal thing about markup, and style sheets aren’t markup.
Whether it is “valid” in some other, informal sense (like “good practice” or “useful” or “conforming to a style guide”) is a different issue, and a debate issue rather than a technical question. Anyway, it is common usage to set display: block on an a element to make it possible to set its dimensions the way we can do for blocks (e.g., to make a link fill a table cell).
I understand all these tags have different semantic meanings, like article is for a story that stand apart; section is for self-contained part of the page...
They are good and useful tags, in many ways. But, are they just syntax sugar? Because I didn't see any style differences among them. When not applied by any CSS rules, they are just like divs.
Hope some webkit/gecko experts can clarify it on the code level.
Mostly yes. They're not actually divs, but block level elements (subtle but different).
http://diveintohtml5.info/semantics.html#new-elements
There are several new elements defined in HTML5 which are block-level elements. That is, they can contain other block-level elements, and HTML5-compliant browsers will style them as display:block by default.
So yes, for now they are just there for shortening your code length and creating cleaner markup, but that's what block level elements do. If you remove the default styling from a <p> tag isn't it just like a <div>?
I didn't see any style differences among them. When not applied by any CSS rules, they are just like divs.
Each browser has it's own native stylesheet that is applied to the page content. This is why we commonly use CSS reset stylesheets - to normalize everything between different browser stylesheets. Style and content are two completely separate things, what something looks like has no bearing on what it is, therefore you should not be marking up your page based on how you want it to appear.
Some day, it may be common for browsers to add default style to certain HTML5 elements, like some padding on <section>s, but it doesn't matter (and is actually unlikely).
Are they just syntax sugar?
Not at all. While there may not seem to be much of a difference, it allows your content to be understood by, for example, screen readers or search engines, in a more meaningful way.
As Grillz's answer mentions, the elements in question are all block level elements, so in that respect - they are basically rendered like divs, but have semantic value and aren't meant to be used as generic container elements.
In XHTML/HTML which elements has semantic value , which are presentational and which are not in both category?
And who decide which tag is semantic, presentational? W3C or web developer with their own terms?
What is the difference between structural and semantic mark-up?
Is DIV and span not semantic , if yes then why we use ?
Ordered lists (OL) and unordered lists (UL), for instance, are examples of markup elements with some semantic loading. The idea is to show to a client that several elements are somehow connected, for example, represent options in some menu. It helps screen readers which will read the menu options in sequence.
And who decide which tag is semantic, presentational? W3C or web developer with their own terms?
Both. The standards dictate what and how is supposed to be used. Developers can either agree or ignore it (as with the ubiquitous case with tables used for design).
I believe the general idea is to treat (X)HTML construct as structural (with semantic meaning or without one), and use CSS to adjust presentational properties.
It depends, in general presentational elements are the ones that act on the look and feel of the object, while semantic gives only "significate".
Example: what is the difference between:
<h1>Hey, I'm a title</h1>
and
<font size="36px">Hey, I'm a title</h1>
?
Pretty nothing, but tags are the one with also semantic value, because they mean something, instead of the font tag that contains only presentational things.
Semantic is about the meaning of an element.
Presentation is about the look of an element.
E.g. <i> is a presentational statement, while <blockquote> or <q> is a semantic statement.
I don't know whether there is a definitive list of elements that are seen as more semantic or more presentational, but generally you should be able to decide which one it is by simply asking you whether the markup says something about what the element is or what it should look like.
<span> and <div> tags can be used to convey information about both, but they should be used to say something about the purpose of the element. The styling can then be set via CSS. So, while <span> and <div> have no meaning per se, the class or ID set for them should hold information about their purpose rather than their look.
I see the <p> tag used a lot in the code of others but have never used it in my own work.
I'm wondering what advantage this gives over using a <div> tag?
Are there any benefits I could get
from incorporating the <p> tag
into my pages?
Is there any disadvantage in only
using <div> tags without <p>?
DIV indicates a separate section on a page, which is not semantically connected to the others. With P tags you indicate that this piece of text is broken into paragraphs but it still stays a single entity.
ADDED: With "semantics" people usually refer to the possibility to extract information from HTML as to what various elements of a page represent and how they are related to each other, as opposed to treating the whole HTML as just a markup to be rendered. For example, when you do menus it is recommended that you use ULs (unordered list) for that purpose, because it will be possible to learn from the markup that all LIs (list items) contained within a particular list probably mean choice options of the same level. I know it is helpful for screen readers for impaired people that you try to make your markup as semantic-rich as possible.
If you're not concerned with this, then it is virtually no difference for the rendered result whether you use DIVs or Ps. You can style both with CSS to achieve the same look and feel.
Semantic HTML is still not "the absolute good" to be strived for. For many people semantics does not add any value as they wish just that their pages are rendered correctly. That's why the ever-lasting discussion on whether to use tables for markup (and add semantics where it does not belong) or stick to CSS is not going to end any soon.
p means 'paragraph', div means 'division'. That's as complicated as it gets. It's a way of telling search-engines, scrapers, tools, etc that this is a paragraph of text.
div is undesirable when you're actually marking up a 'paragraph' of text.
Both tags have a different purpose.
p indicates a paragraph, usually for
organising content (text and
images,mostly)
div on the other hand is a
rectangular space on the canvas,
usually for layout purposes.
Example: You would put your navigation panel in a div, making it easy to move it from the left to the right of the page, or switching to a 3 column layout. The different sections in your navigation (first the general site navigation, next specific hotlinks to the most recent blog post or whatever) could be seperated by putting them in defferent paragraphs.
(I know, bad example, because the navigation is better represented by unordered lists, but what the hey).
In direct answer to your question, they give you the advantage of differentiating between organising your layout and organising your content, in a way that becomes clear in the HTML source.
If you are tagging content so you can lay it out with CSS, you probably want <div>; <p> should be used to indicate a paragraph of text and that's it.
Beyond just the semantics of it (which are important), you will also want to consider validation problems. According to the HTML4 spec, you are not allowed to nest other block-level elements (<div>, <ul>, other <p>, etc) inside a <p> without invalidating your HTML.
I've seen a number of instances where parsers will choose to prematurely close the <p> to allow the other nested block element to begin.
Are there any benefits I could get
from incorporating the tag into my
pages?
Yes, provided that you use it correctly -- because the use of semantic HTML is always a benefit.
There are a range of reasons why this is so, but the primary one for people who need a quick explanation is SEO. Search engines will understand your page better if you use semantic HTML.
p tags are for paragraphs. p tags often contain additional CSS styling regarding the textual content that goes into them, and this styling can be defined in various places in the css documentation. for example, a p usually has a bit of extra space below it. if you try laying something out with p tags, you'll end up with uneven padding.
It is better to use divs if you want to have more control over the content in your page from a programmatic perspective. sticking to divs for all layout concerns will also allow you to use p tags exclusively for paragraphs.