I have search page that contains 4 groups of elements:
The field where user types the keyword (event name)
The filters such as dates (from/to), city, place
The category filters (check boxes): concert, theater, musical, show and so on
Top 20 events
Plus "Search" button.
So, I'm trying to figure out the right way to organize the page. Is it better to use "div" or "section" or something else and why?
I found this nice text in the w3-documentation:
The section element is not a generic container element. When an
element is needed only for styling purposes or as a convenience for
scripting, authors are encouraged to use the div element instead. A
general rule is that the section element is appropriate only if the
element's contents would be listed explicitly in the document's
outline.
I hope this helps.
It's up to you. if you want to stick with HTML5 Standards then Use scetion, etc. or your not wrong when use divs creating layouts
Related
I wanted to know if tables are allowed inside anchors like this:
<a>
<table>
<tr>
<td>Hello!</td>
</tr>
</table>
</a>
Because some people on the internet say it is allowed while others say it is not.
I looked under ยง4.5.1 The a element and it says the content model is "transparent". Then I looked into 3.2.5.3 Transparent content models to see what that means. And it says:
[...] the elements required in the part of the content model that is "transparent" are the same elements as required in the part of the content model of the parent [...]
They use the word required but I think it must be the word allowed.
Inside the 'a' element no elements are required at all. Instead the question is which elements are allowed. Or am I wrong?
Note that this question is not about whether tables are allowed inside anchors but instead if there is a mistake in section 3.2.5.3 of the HTML specification.
They use the word required but I think it must be the word allowed.
well, you just answered yourself with the next sentence:
Inside the 'a' element no elements are required at all.
and no
Instead the question is which elements are allowed.
that's not the question of the content model of the spec.
the spec says that an a-tag can't contain other interactive elements, which would then make those elements not-allowed.
also to the tables inside links question: as long as the table does not contain any interactive elements (buttons, inputs, other links etc.) you can put a table inside your a-tag (if that's a good idea is another question), the spec itself even gives that exact example:
The a element can be wrapped around entire paragraphs, lists, tables, and so forth, even entire sections, so long as there is no interactive content within (e.g., buttons or other links).
so no, in my opinion there is no "mistake" there.
I currently have an id attribute on each section heading in a HTML document, so that URLs can be generated with a hash fragment that links directly to that section in the document. For example:
<h2 id="section3.4">Section 3.4 - Foo</h2>
This would, of course, be linked as page.html#section3.4.
I would like to offer an alternative formatting for that fragment, e.g. page.html#s3.4. The exact formatting is arbitrary and not important here.
Obviously one cannot simply apply multiple ID tags to a single HTML element in order to achieve this. The solution, it seems, is to add a secondary tag to the page at the same position as the heading, e.g.:
<h2 id="section3.4">Section 3.4 - Foo</h2><xyz id="s3.4"></xyz>
Is there a standard or preferred tag type that is used for this purpose? Searching around, I was surprised to find no "best practice" answer for this.
Technically the tag type is arbitrary, since any element with an id attribute should work, but picking canvas or script, for example, is clearly silly. I've seen a suggested, but I'm not sure that is semantically correct, since a is supposed to create an anchor to a location, not be a location.
One thought I had was to have the enclosing section tag's ID be the target, but that doesn't enable an arbitrary number of alternate fragment names, and technically it isn't linking to the same location since the bounding box is subject to CSS.
I feel like the ideal element would be one that is guaranteed to have no visual presence on the DOM, hold the same vertical position as the adjacent element, have no side effects, and which makes semantic sense as a positional marker, all while also not having any impact on accessibility (e.g. screenreaders). However, I cannot think of such an element. Is there a standard that I missed? If not, which tag might be the best option?
In inline contexts, use a <span> element wrapping the text inside the appropriate heading.
<h2 id="section3.4"><span id="s3.4">Section 3.4 - Foo</span></h2>
In block contexts, use a <div>.
Both are semantically neutral. And this approach ensures the heading text receives appropriate focus regardless of which fragment identifier is used.
I'm learning about HTML5, and honestly I can't say I'm really impressed. Semantics are nice and all, but I think that they introduced new elements with a very thin line between them, and a even thinner line between them and the old divs.
Everything is very clear if you do a generic purpose site, like a blogging engine, news publishing portal, and similar, but web apps... I'm having a lot of dilemmas about new html elements.
Here is my situation. I'm developing an ordering system. On the sellers interface I have 3 columns (inline), which represent the status of the order. When the status is changed element is moved from one column into another (background ajax, and js manipulation).
In Html4 I would use 3 divs and put a heading with a title on top of each one. Elements inside the columns would also be divs.
But what about HTML5? I have been looking at the section element, but I'm not really sure how to use it. Here are the options:
Put everything inside one section - I don't think that is the way to go
Put a section around each of the column divs, and heading inside the section
Replace the divs with sections
Put sections inside column divs
So, which way to go?
EDIT: first of all thanks everyone for your quick replies. In the end I'll probably go with Ian Devlins suggestion, and put each column as section. Anyway, just to point out my dissatisfaction with html5, multiple permitted options aren't always a good thing. I'm afraid what will the html5 web look like in a few years, when we can't fully agree on a simple question like this.
EDIT2: one more thing. I'll ask it here so I don't have to open another question. In addition to these 3 columns I have another div which contains order details, when any of the orders are selected. Should it be an article since its self-contained content, or to use an aside tag?
div is a perfectly valid HTML5 tag. If the new tags don't make any sense in your project, don't feel forced to use them.
To quote the w3.org spec:
The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.
And another quote from the w3.org people:
The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element's contents would be listed explicitly in the document's outline.
Given the definition for section by w3 we can conclude that your example would be a good use of section because:
The elements have a header
It is a thematic grouping of content
It is a part of the document outline.
EDIT:
To expand upon your comment below, the new HTML5 elements are NOT supposed to replace the old HTML4 elements. For example, going through a page and replacing all the div elements with section elements would be flat out wrong. The section element was, in my opinion, intended to make it easier for machines to parse certain pages (think: feedburners) by giving a more semantic structure to a page. After all, what's easier to parse, a page with 30 div elements, or a page with 10 div 5 header 5 section 5 article and 5 footer elements?
In this particular case I would have an overall div around them, and then each column as a section as each one has a different meaning, each of which I assume has a heading indicating its status.
e.g.
<div>
<section id="col1">
<header><h1>Column 1</h1></header>
content....
</section>
<section id="col2">
<header><h1>Column 2</h1></header>
content....
</section>
<section id="col3">
<header><h1>Column 3</h1></header>
content....
</section>
</div>
I'm editing books/articles in HTML. These texts were printed once and I scan them, convert them into an intermediate XML-Format and then I transform them into HTML (by XSLT). Because some of those texts are extinct from the market today and are only available through the major libraries I want to publish them in a way so that people could possibly cite them by referring to the page numbers in the original document. For this purpose my intermediate XML-format has an element that marks a page-break. Right now I'm working on the XML->HTML transformations and I'm wondering myself how to transform these page breaks in HTML. They should not appear in the final HTML by default (so a simple | doesn't fit) but I plan to wrap these documents with some lightweight JavaScript that will show the markers when needed. I thought about <span>s with a | in it that are hidden by default.
Is there a better, possibly 'semantic' way to this problem?
Page breaks are very much a thing of layout, and HTML isn't designed to describe layout, so you aren't going to find anything that is semantic for this within the language.
The best you can hope for is some sort of kludge.
Since a page break can occur in the middle of a paragraph, and <p> elements can contain only inline elements you can eliminate most of the options from the outset.
The two possibilities that suggest themselves to me are <span> and <a>. The former has no semantics, that latter is designed to be linked to (with a name attribute) or from (with an href attribute), and you could consider a page from an original document something that you might wish to link to.
No matter what element you use, I wouldn't include a marker in it and then hide it with CSS. That sort of presentational flag is something I would consider adding via :before in a stylesheet (combined with a descendent selector for a body class that can be toggled with JS since you want the toggle)
Alternatively, if you want to take a (very) broad view of the meaning of "HTML" you could consider the l element (from the defunct XHTML 2 drafts) and markup each line of the original document. Adding a class would indicate where a new page began (and you could use CSS counters and borders to clearly indicate each page and number it should you so wish). Pity the browser vendors refused to get behind a real semantic markup language and favoured HTML 5 instead.
Use a <div class="Page"> for each page, and have a stylesheet containing:
.Page {
page-break-after: always;
}
Maybe you can use an xml tag not parsed/interpreted by html like <pagebreak/>.
In this way viewing the html the tag will be not rendered but using jQuery or any other Javascript library, transform, when asked, these particular tags in standard or whatsoever visual mark.
I think this can be a semantic approach...
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.