I am trying to understand the purpose of the section and found the following article:
The section element is not a generic container element. Now I know
what it says. It says above that it represents a generic section of a
document. When people write specifications, sometimes they get vague.
It is not a generic container.
When an element is needed only for styling purposes or as a
convenience for scripting, things like JavaScript, authors are
encouraged to use the div element, which we'll talk about in just a
little bit. So a general rule is that the section element is
appropriate only if the elements contents would be listed explicitly
in the documents outline and that's where it reaches the sweet spot.
When you have content that needs to be listed in the document outline
but it doesn't meet the standard of being syndicated or pushed apart
by itself, then that's when the section element is probably
appropriate.
The questions are:
What is a generic container?
What does he mean with styling purposes
or as a convenience for scripting?
What is a generic container?
An element that can be used as a containing element for any arbitrary content, in any arbitrary context. E.g. div is the most generic container there is, because it does not carry any meaning in itself whatsoever. section does have a specific meaning, so shouldn't be used arbitrarily.
What does he mean with styling purposes or as a convenience for scripting?
When you want to style specific elements or you want to programmatically access specific elements via Javascript, you need some hook for that element. E.g., styling the eighteenth word in this sentence is pretty difficult, but becomes much easier when you <span>wrap</span> it in something. Now you can use span { color: red } or document.getElementsByTagName('span') to do something with that element.
Related
The div element is known to be a generic container, what is exactly meant be the term generic container in HTML5?
It's a container with no special purpose.
It carries no semantics (unlike a section or a main or a fieldset etc).
of, applicable to, or referring to all the members of a genus, class, group, or kind; general.
A div has nothing that every other container does not have (but the reverse is not true).
Generic containers are just containers that serve no special purpose. Mostly a style attribute is bounded to a generic container for specifying the rendering or using a CSS rule.
The only generic containers are <div> and <span>.
Technically speaking, they could be used to organize webpages into multiple different "sections" defined with classes and attributes.
Semantic markup
"Good" HTML code is semantic.
In the current context it means, that you wrap the content of your webpage / webapp into containers which are designed to contain that specific piece of content.
For example, headers typically are semantically correctly coded into <header> tags, articles in <article>, so on and so forth.
DIV as a Jolly Joker
Whenever you don't have a generic block level container at your disposal, you encapsulate the content you want to render in a div. It's usually the "last resort" tag you use when you run out of options.
One more thing
As <div> is the jolly joker of block level elements (panels, GUI control containers, etc.) the <span> tag is the jully joker of inline elements
Id say they typically just are simple holders that kinda define whats inside of them. They just hold stuff. Like a div typically is containing elements that go together. Like if you wanted to have a navigation bar, you can put all the elements that make it into a div and give that div an id or class of 'nav'. Keeps things nice and organized.
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.
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.
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've read many explanations of what the actual purpose of the < span > tag is, and I've tried to incorperate those explanations into real applications but have failed every time.
One person told me that it was to apply classes to sub-tags below it, which does kind of work, except it doesn't apply dimensions to elements, unless you mess around with the display and/or inline settings, which can totally screw up a layout.
Then someone else told me that it's use as a substitute for the < div > tag, which doesn't work because floats or "margin: auto"-type attributes don't work unless contained inside certain types of elements.
Then someone else told me that it's used as a text container, which doesn't work because the "text-align" attribute doesn't work, again, unless contained inside certain types of elements. A default-attribute-cleared < p > tag is much more suited, in my experience.
So what exactly is the point of them? Why are so many people using them when < div > seems to do everything that they're apparently capable of and more?
From Official Docs:
The DIV and SPAN elements, in conjunction with the id and class
attributes, offer a generic mechanism for adding structure to
documents. These elements define content to be inline (SPAN) or
block-level (DIV) but impose no other presentational idioms on the
content. Thus, authors may use these elements in conjunction with
style sheets, the lang attribute, etc., to tailor HTML to their own
needs and tastes.
As it says, you can use <span> tag to structure (inline) the sections of page along with styling which you may optionally pass via id, class or stylesheets.
Characteristics of <span> tag:
It's display is inline by default which means:
you can not apply width to it
you can not apply height to it
you can make it block-level too by using display:block (div serves the same purpose)
The <div> tag is opposite to that and you can apply above rules to it.
It is an inline element with no attached semantics that can be used to wrap some inline content for
the application of JavaScript (e.g. event handlers or moving about the DOM)
the application of CSS
use with the lang attribute
processing by custom tools
… when no element with more appropriate semantics exists.
floats or "margin: auto"-type attributes don't work unless contained inside certain types of elements.
They work (or otherwise) based mostly on the display value, not the element type.
Why are so many people using them when <div> seems to do everything that they're apparently capable of and more?
A div is identical to a span except it:
Can contain block elements
Cannot (error recovery not withstanding) be contained by an inline element (or any other element that can contain only inline content, such as a <p>)
Is display: block by default (instead of inline)
When the text is in a <span> element you can add styles to the content, or manipulate the content.