Let's say there is a list which every li element has an article element inside.
Since the article element is a sectioning content element, would it split the list explicitly? If so, does the list conserve its purpose?
The specification says li element accepts any flow content so any sectioning content would be allowed, and it would be validated, but won't it be better to put links to the articles instead of the articles?
The example uses the article element but I think It could be applied to every sectioning content element.
The question here is what would be the purpose of putting multiple <article> elements inside a <li>. I think that whatever you're trying to accomplish can be done in other ways. An article can contain lists; lists can contain links to articles; why put a sectioning element inside a list?
Your lists and articles certainly have CSS styles assigned to them. If you like the way your lists display content, you can arrange for your articles to look that way with CSS, without putting the latter inside the former. Inside of lists, <p> elements would be more appropriate, if you wanted to include more copy than just article links.
Here's a good reason why articles inside lists are semantically bogus. An article tag "specifies independent, self-contained content." If you put that inside a list, it is no longer independent or self-contained; it is either related to, or dependent on, the other list items.
Related
When I use angular.component() or angular.directive() to create a custom element, is that treated as sectioning content or not?
That is to say, is it semantically and syntactically appropriate to generate a single header and footer internally, or does that count as being part of the containing element tree?
For example if I have
angular.component('foo', {
template: `<header>Yay</header>`
})
And I use it so that the generated html is
<section>
<foo>
<header>Yay</header>
</foo>
<foo>
<header>Yay</header>
</foo>
</section>
Then what is the semantic? Is that a section which contains two header elements that are about the section? Or is it a section which contains zero header elements but two foo elements each with a header about the foo?
I don't think it would be correct to add the header footer unless it was wrapped by a sectioning element in the template or the custom element itself declared the correct ARIA role. My first thought was to see the rules in web components in which I think it would be valid if you were to extend a sectioning element
Angular components/directives can generate any HTML tag, including those that are defined as sectioning, for example angular.directive('article'...), or as phrasing, for example angular.directive('a'...), or custom elements, like foo in your example.
So it seems that your question is not so much about angular, but rather about custom elements and specifically what category they fall under. From reading the spec you linked, it depends on what your custom element is doing. If it's used for sectioning, and it has a header as in your example, I think it can be viewed as sectioning content. If your custom element is used for getting input from user, for example a div with contenteditable=true, then it can be treated as interactive content.
Then what is the semantic? Is that a section which contains two header
elements that are about the section?
It depends on what you intended it to be. But since it has header child element, I would view foo as sectioning content and would say that it's a section element without a header that contains two other sections with headers.
While studying the HTML 5 semantic tags, I've ran upon some doubts on how to proper utilize the main and section tags, and since the W3Schools reference seems a little vague and other references on the Web seems to diverge I would like to know if there is a proper guideline to the following questions or if its pretty much up to the programmer:
Does the main tag also has the meaning of grouping related elements or in that case should it be within a section tag?
Does it make sense to wrap single elements, such as an image, into a section tag?
It's pretty common to have a header and footer of the page (not inside any section), in that case, should the remaining in between those tags be wrapped inside a section tag, as if delimiting the "content" of the page?
Does the main tag also has the meaning of grouping related elements
Only to the same extent that <div> groups related elements. The primary purpose of <main> is to indicate where the dominant content of the page starts. (and additionally, according to the WHATWG spec but not the W3C one, where the dominant content of the page resumes).
or in that case should it be within a section tag?
A section tag is one way of grouping your content, to indicate that its contents are on a particular theme, in a way that differs from the content which is not in the section. Typically, you can and should give the section a heading using a <h[1-6]> element, which states what that theme is.
Does it make sense to wrap single elements, such as an image, into a
section tag?
Rarely. For one thing that would mean that the section didn't contain a heading. See above. It's unlikely that any new information would be conveyed by wrapping an image on its own in a section tag.
It's pretty common to have a header and footer of the page (not inside
any section), in that case, should the remaining in between those tags
be wrapped inside a section tag, as if delimiting the "content" of the
page?
No. The "content" of the section is the section less its header and footer. There's no need to add another sectioning element container.
I'm stuck deciding which to use as both seem to work.
Should I be placing links <a> inside of <h2> elements?
Or the other way around?
What is the correct standard?
You can only place <h2> elements within <a> elements if you're working with HTML5, which allows any other elements within <a> elements. Previous specifications (or current ones however you want to look at them) never allowed this.
The usual way of doing this is to place <a> within <h2>. This works, has always worked, and has been the only valid way to do it before HTML5, for heading links, as the link refers to the text in that heading. You rarely need to place <h2> within <a> unless that <h2> is part of some more complex structure which functions as a hyperlink as a whole.
Also its not functioning same, there is one big difference.
If you put <h2> into <a> the whole block (for example line) of heading will work like link.
However if you put <a> into <h2>, only visible text will work as link. (you can test it with cursor change)
The answer is that it depends...
From the W3C website, more specifically in the HTML5 semantics page, it is clear that h2 elements (as all other heading tags) have as content model "Phrasing content".
Now, following the Phrasing content link, you get the following description:
Phrasing content is the text of the document, as well as elements that
mark up that text at the intra-paragraph level. Runs of phrasing
content form paragraphs.
and in the following list you have that phrasing content include:
a (if it contains only phrasing content)
So, if the a tag includes only phrasing content, HTML5 allows it to be contained within a h2 tag.
Viceversa, the text level semantics page describes the a element content model as follows:
Transparent, but there must be no interactive content descendant.
Following the Transparent link, at the end of the description is found the following:
When a transparent element has no parent, then the part of its content
model that is "transparent" must instead be treated as accepting any
flow content.
Since in the h2 tag description it is said:
Contexts in which this element may be used:
Where flow content is expected.
an h2 tag may the considered as flow content.
So, if the a tag has no parent, in HTML5 it must be treated as accepting any flow content, including h2 tags.
HTML allows things inside <a> tags
I have this...
<header>
<a href="/home">
<h1>Main heading</h1>
<h2>Sub heading</h2>
</a>
</header>
And it works for me.
The whole heading text including the subheading is clickable as I want. I don't know of a better way to do this with html 5.
The W3C specs for h2 say that its permitted parent elements are anything that can contain flow elements, or hgroups. The specs for a permit parent elements that can contain phrasing or flow elements. h2 can contain phrasing content, and a can contain phrasing or flow content, so based on the spec it appears that either is permitted.
Since you included the semantics tag, I assume you're interested in which 'seems' better too. For my part, since I can't think of when I'd want an anchor to span a heading plus other content, but I can think of plenty of times when a header should contain an anchor plus other content, a inside h2 seems the best route to go.
Can I use <section> tag inside unordered list?
I know, that <section> represent a generic section of document. Usually we find heading inside.
So... I have list of products. Usually about 20 per page. Each element have:
heading,
short description (max 255 chars),
thumbnail, some details, button.
So each list item is something like section, "is a thematic grouping of content, typically with a heading".
Of course I don't use, <section> to styling purpose.
I think, <section> also could be here a wrapper for a list, and each element of list <article>.
What is your opinion?
Using a <section> tag inside an <li> tag validates (you can try this using the “Text Field” option on http://html5.validator.nu/), and the spec doesn’t seem to suggest you shouldn’t use it in this way (see http://dev.w3.org/html5/spec-author-view/the-section-element.html#the-section-element), so that seems fine to me.
The <article> tag is meant for “self-contained compositions”. I’ve never been entirely clear what that means outside of several blog posts being listed on a single page, but I think product summaries sound like a decent fit for that too. So your second idea of a <section> containing the entire list, and an <article> for each product, probably sounds best.
A List of DOs…
DO use section for each individual section of a tab switcher or content slider (if an unordered list isn’t needed)
DO use section to divide a lengthy “terms and conditions” (or similar) page into numbered sections
DO nest section elements if necessary (as you might do with the “terms and conditions” page)
A List of DON’Ts…
DON’T use section to divide content from the header and footer; use div instead (see the doctor)
DON’T use section to wrap a tab switcher for DOM manipulation or styling
DON’T use section for sidebar or other tangentially-related content boxes; use aside instead
DON’T use section just to add a border or drop shadow around something; use div instead
DON’T use section for the wrapper when implementing faux columns; again, use div instead
DON’T use section to nest elements when trying to avoid IE6′s float double-margin bug (or a similar layout-related issue); again, use div
DON’T use section to hold an individual author bio on a blog post or news article; use aside instead
Stolen from When to Use the HTML5 “section” Element
For some time I've been making websites, but have never really seen discussion of the proper usage of the container tags. I've seen any number of different types of content in the collection tags, but it usually seems that the page creator just picks a style they like and sticks with it.
The main discrepancy in my mind is that between
<p>
<div>
but I'd also like opinions regarding
<span>
and any others I may be forgetting.
HTML was originally created to put the content of documents into some sort of structure understandable to computers. With that in mind, the p tag is supposed to hold anything that would be structured as a paragraph if the content of the page were to be turned into a printed document. The div and span elements are reserved as general-use containers to facilitate formating and grouping of related elements to provide additional levels of structure, perhaps correlating to pages in a text document.
In some cases, p tags should contain other elements, such as anchor (a), image (img) and other in-line elements, because they relate directly to the content of the rest of the paragraph and it makes sense to group them that way, or the text of the rest of the paragraph provides a more in-depth description.
If there is not additional description of those elements, however, it does not make sense to place them in a paragraph simply as a convenient container; a div would be more appropriate. In general, a paragraph is supposed to contain one paragraph of text and any directly related or described elements. Nothing else makes much sense in a paragraph.
UPDATE: HTML5 also adds a number of other semantic "container" elements, including article, nav, header, section, and aside.
I think, the meaning of the tags is something like this:
<p>Paragraph, usually just text</p>
<div>A block, containing anything</div>
<span>Just a simple non-blocking wrapper</span>
The difference between these three (and many other) tags is their semantic meaning. The HTML standard includes both tags with specific semantic meanings (<p> for paragraphs, <em> for emphasized text, etc.) and tags without semantic meaning.
The latter are <div> and <span>, which are used to identify block- or inline-level content which needs to be identified (using, say a class= or id= attribute), but for which a semantically-specific tag does not exist. For example, one may write <p>Hi, my name is <span class="name">John Doe</span>.</p> — indicating that it's a paragraph (which the browser already has an idea how to handle) and that part of it's content is a name (which means absolutely nothing to the browser unless CSS or JavaScript uses it).
These tags are therefore incredibly useful both in adding additional information to an HTML document which doesn't fit within the semantic tags supplied by the standard (see the hCard specification for an excellent example) and for applying visual (CSS) or functional (JavaScript) structure to a document without altering its semantics.
I think page creators should use semantic markup, meaning that the markup they create should communicate meaning (and not presentation). <div> and <p> have different meanings. The former is used to define a division (or section) of an HTML page, the latter to define a paragraph of text.
<p> is a block-level element that should contain a paragraph, comprised of text, inline elements that modify that text (<p>, <a>, <abbr>, etc.), and images.
<div> is a block-level element used to divide the page, almost always in conjunction with CSS styles.
<span>... well, I honestly don't use this tag that often. It's an inline element, and I use it usually when I'd like to apply styles to a portion of text that wouldn't benefit from using something with more meaning, like the <strong> and <em> tags.
I was tought to view <span> and <div> as the "tofu of webdeveloppement", since it has no real flavor but you can do virtually anything with it.
(X)HTML tags define what the text they're surrounding is. Is it and address, is it a link, is it a paragraph, and so on...
<div> and <span> are simply ways of getting to pieces of your site you normally can't get to. Like when you're trying to resize a | symbol. Fastest way I've ever found was to put a span around it, give it a class and then implement the CSS.
That's what they're good for, in my opinion. I'd be interested to hear more or even corrections on what I've written here.
It sounds like you need to read the HTML specification
The p element:
The p element represents a paragraph.
The div element:
The div element has no special meaning at all. It represents its children. It can be used with the class, lang, and title attributes to mark up semantics common to a group of consecutive elements.
The span element:
The span element doesn't mean anything on its own, but can be useful when used together with the global attributes, e.g. class, lang, or dir. It represents its children.
The major difference between div and span is that span is flow content, phrasing content, and palpable content, while a div is only flow content and palpable content.
Essentially this boils down to:
div elements are block-level elements, and typically may only be placed within other block-level elements, whereas span elements are inline elements, and may be placed within most other elements.
The HTML spec defines which elements are acceptable as descendents of each element.