I have a web page like the following one:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Title</title>
</head>
<body>
<header>
<span>Logo</span>
<nav>Navigation</nav>
</header>
<main>
<h1>Page heading</h1>
<div>
Page content
</div>
</main>
<footer>
Content information
</footer>
</body>
</html>
The page structure is similar to one example in the current HTML5 draft: http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-main-element and I think it is semantically correct.
Now I would like to style this document using CSS. I would like to be the header at the top and footer at the bottom, which is, of course, easily doable. Inside the header I would like to put the logo to the right and the navigation in the center, which is also okay (e.g by using the flexible box layout model, which is in one or the other way supported by modern browsers, or by using floats).
My problems begin when I want to put the main's content heading (the h1 element) visually in the left of the header. I could do with position: absolute but such a layout is not very flexible and would break as soon as the header's or the heading's sizes change. The proposed CSS grid layout http://www.w3.org/TR/css3-grid-layout/ may be able to do exactly what I want but it is, as far as I know, only supported (somehow) in IE 10.
One simple and working solution would be to simply restructure my page:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Title</title>
</head>
<body>
<div>
<h1 id="heading">Page heading</h1>
<header>
<span>Logo</span>
<nav>Navigation</nav>
</header>
</div>
<main aria-labelledby="heading">
<div>
Page content
</div>
</main>
<footer>
Content information
</footer>
</body>
</html>
This solution, while easily layoutable, however, has its full semantics only expressed via aria-* attributes and seems to go against the spirit of the HTML5 semantics (especially the main element).
While my example page may be simple, you can easily imagine a more complicated one where the visual position of many more elements are not in the same order as the flow order of the HTML5 markup (and nested so that the flexible box layout order property won't suffice). How would you solve the problem? Rewrite the HTML5 markup with non-semantic elements (e.g. divs) so that it corresponds more to the visual layout and then exchange the non-semantic elements by semantic ones (e.g. footer or main) wherever possible with the new structure?
I am running into the same conundrum as you, and I appreciate the frustration. I will attempt a negative answer, because I feel both of these positive ones (which say you can achieve both your ends) are missing the point.
Firstly, the way I see it, your principle difficulty is that CSS cannot move an element to a new container. The two answers fall into two categories:
Some are ultra-specific hacks (subjectively speaking) involving floats, negative margins, and/or absolute positioning which can move an item presentationally out of its container. These can be effective, but only in very specific cases. As your needs grow, it becomes difficult to maintain and it requires putting a rather large thinking cap on to address each new need or edge case that you had missed earlier. The answer by #jennifit attempts to move you in this direction. It is, I believe, the normal route taken by those trying hard to follow the spirit of semantic HTML5, which is admirable. But it can be a quagmire that makes you begin to ask exactly who you're maintaining your semantic purity for? Is it for the search engines, the screen readers, or ease of maintenance? I'll get back to this after the next classification.
Some are pragmatic rationalizations that claim to be equivalent semantically but are, in truth, a different semantic meaning. These are really semantic hacking in my opinion. #volker-e 's answer is an instance of this. He's right, this is an alternative markup that could work -- but, it doesn't equal the same semantic meaning. The h2 belongs in main as an h1 -- it makes no sense to move it within the page's header. In fact, you're saying that your heading is unrelated to your main content. This, in some ways, is worse than using that div you wanted to use, because you're making a false semantic relationship by grouping the page-header and site-header into the same semantically-significant header. A semantically meaningless container, such as div, for both header and main, is actually less perverse in my opinion.
So, getting back to what I said about who you're maintaining semantic purity for, this is the real philosophical question at play. There is often an obvious, effective, and maintainable solution without rationalized mis-uses of existing semantic elements or css 'tricks'. In your case, of having an item which is semantically a child but presentionally not a child, the answer is the one you've already put forth as a question:
Rewrite the HTML5 markup with non-semantic elements (e.g. divs) so
that it corresponds more to the visual layout and then exchange the
non-semantic elements by[sic] semantic ones (e.g. footer or main) wherever
possible with the new structure.
This is the right thing to do whether you're semantic-purity was intended for
accessibility: in this case you can achieve that in a non-hierarchical way with ARIA roles.
search engines: search engines still understand the old way to do things, so you're not going to get into SEO trouble if you follow older approaches to semantics.
maintenance: this is the reason most people are lured in by -- but the problem is, what's the point of maintainable HTML but unmaintainable CSS, or the other way around? you have no choice but to see your maintenance as a combination of both CSS and HTML, and you have to find the middle ground where they are both deranged equally when you run into a difficult presentational problem.
The only other possible answer, if you feel that HTML semantics are all that matter, is to accept the limitations that hierarchical HTML semantics places on your layout. The problem is, there is no way in CSS to re-create the layout hierarchy. Until that happens, you'll have to accept that HTML is both a presentational and a semantic language, and, therefore, semantics will always be a matter of "better" and "worse". Truly beautiful or rich or perfect semantics will be unachievable in many, if not most, layouts.
My approach would be the following:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Title</title>
</head>
<body>
<a class="aural" href="#content">Jump to content</a>
<header role="banner">
<h1 class="site-logo">Logo</h1>
<nav role="navigation" aria-labelledby="nav-heading">
<h6 id="nav-heading">Navigation</h6>
<ul>…</ul>
</nav>
<h2 id="heading">Page heading</h2>
</header>
<main id="content" role="main" aria-labelledby="heading">
Page content
</main>
<footer role="contentinfo">
Content information
</footer>
</body>
</html>
and then go for a CSS ruleset like:
header h1,
header h2,
header nav {
float: right;
}
Diff:
You have appropriate accessible headings for page's content
You save otherwise seemingly useless div in header & main
You've got a nice HTML5 structure outline, which helps SEO.
I've included (was not part of the question) the navigational landmark roles as of WAI-ARIA 1.0 draft specification
I've included a skip link, which is still recommended best practice
Minor change: I know, charset value case is insensitive, but as you also write DOCTYPE uppercase, UTF-8 is the more correct value, see http://en.wikipedia.org/wiki/UTF-8#Official_name_and_variants
The first structure may still work if there is position:relative in < main > and using position:absolute on h1 with a z-index and a -ve margin. That way, the heading will always float on top in the same position in relation to the main content. While it may not be the best solution, I think it will not break the layout (?)
Related
I understand from reading similar posts that the <section> tag in html is meant for semantic and organizational purposes. I was wondering, however, why using the <div> tag with a class attribute wouldn't have a similar effect.
(e.g. <div class = "SectionOne">)
Given these two methods, I could refer to each of them in CSS by using their respective names:
Section
{
color = white;
}
or
.SectionOne
{
color = white;
}
Personally, I think the second method allows for greater versatility in webpage design and I don't see many advantages to the new HTML5 feature. Would anyone care to clear this up for me?
section is usually used for having article like contents whereas div are meant to combine various block elements in order to style them differently. The main difference is just semantics.
Refer https://www.thoughtco.com/difference-between-div-and-section-3468001 for derails
Let me know if you require any further help
The <section> tag defines sections in a document, such as chapters, headers, footers, or any other sections of the document.
Whereas: The <div> tag defines a division or a section in an HTML document. The tag is used to group block-elements to format them with CSS.
Maybe you mean section and not Section. Anyway, the semantics is a thing and the selectors another. In CSS it is better to select using classes than tag selectors, because you gain a lot in terms of versatility. So you are right from this point of view. Semantics is another matter: is not given by a class. Even if you give a "section" class to a div, you are not giving semantic meaning to a div.
<div> is simply a generic block-level element which predates the later, semantically-named, document-related elements which arrived with HTML5, such as:
<header>
<nav>
<main>
<section>
<aside>
<footer>
When dividing up a document into its anatomical parts, you could still use:
<div class="header">
<div class="section">
etc.
But... you don't need to anymore.
Of course, even if you still use all of the above in your document you might still want to add other block-level elements and when you do... <div> is general purpose.
This is a question regarding Angular 2 selectors, Custom tags vs. Custom attributes, SEO and browser rendering.
When I first started to look over Angular 2, the very first thing I did when following their quickstart, right of the bat, was to change my selector to '[my-component]' (attribute selector) instead of 'my-component' (tag selector), so I could have <div my-component></div> in my html instead of <my-component></my-component>, which isn't valid html. So I would write html according to standards. Well, at least pretty close to standards (because my-component isn't a valid html attribute, but I could live with only that html validation error)
Then, at some point in a video on youtube, someone from the angular team mentioned that we should use the tag selector, performance wise at least.
Alright I said, screw html validation... or shouldn't I?
So:
Say I ignore the W3C screaming about my html being completely invalid because of the <custom-tags>. I actually have another bigger and more real concern: how does this impact SEO?
I mean don't just think client-side app, because in the real world (and for my angular 2 project as well) I also have server-side rendering, for 2 very important reasons: SEO and Fast initial rendering of the site to the user for that initial view, before the app bootstraps. You can not have a very high traffic SPA otherwise.
Sure, google will crawl my site, regardless of the tags I use, but will it rank it the same in both scenarios: one with <custom-make-believe-tags> and the other with only standard html tags?
Let's talk browsers and css:
As I started to build my first SPA site in Angular 2, I was immediately faced with another concern:
Say (in a non SPA site) I have the following html markup:
<header>
<a class="logo">
...
</a>
<div class="widgets">
<form class="frm-quicksearch"> ... </form>
<div class="dropdown">
<!-- a user dropdown menu here -->
</div>
</div>
</header>
<div class="video-listing">
<div class="video-item"> ... </div>
<div class="video-item"> ... </div>
...
</div>
Angular 2 wise I would have the following component tree:
<header-component>
<logo-component></logo-component>
<widgets-component>
<quicksearch-component></quicksearch-component>
<dropdown-component></dropdown-component>
</widgets-component>
</header-component>
<video-listing-component>
<video-item-component></video-item-component>
...
</video-listing-component>
Now, I have 2 options. Let's just take the <video-listing-component> for example, to keep this simple... I either
A) place the entire standard html tags which I already have (<div class="video-item"></div>) within the <video-item-component> tag, and once rendered will result in this:
<video-listing-component>
<div class="video-listing>
<video-item-component>
<div class="video-item>...</div>
</video-item-component>
...
...
</div>
</video-listing-component>
OR:
B) Only put the content of <div class="video-item"> directly into my <video-item-component> component and adding the required class (class="video-item") for styling on the component tag, resulting in something like this:
<video-listing-component class="video-listing">
<video-item-component class="video-item"></video-item-component>
<video-item-component class="video-item"></video-item-component>
...
</video-listing-component>
Either way (A or B), the browser renders everything just fine.
BUT if you take a closer look (after everything is rendered in the dom, of course), by default the custom tags don't occupy any space in the dom. They're 0px by 0px. Only their content occupies space. I don't get it how come the browser still renders everything as you would want to see it, I mean in the first case (A):
While having float: left; width: 25%; on the div class="video-item", but each of these divs being within a <video-item-component> tag, which doesn't have any styling... Isn't it just a fortunate side-effect that the browser renders everything as you'd expect? With all the <div class="video-item"> floating next to eachother, even though each of them are within another tag, the <video-item-component> which does NOT have float: left? I've tested on IE10+, Firefox, Chrome, all fine. Is it just fortunate or is there a solid explanation for this and we can safely rely for this kind of markup to be rendered as we'd expect by all (or at least most) browsers?
Second case (B):
If we use classes and styling directly on the custom tags (<video-item-component>)... again, everything shows up fine. But as far as I know, we shouldn't style custom components, right? Isn't this also just a fortunate expected outcome? Or is this fine also? I don't know, maybe I'm still living in 2009... am I?
Which of these 2 approaches (A or B) would be the recommended one? Or are both just fine?
I have no ideea!!
EDIT:
D'oh, thanks Günter Zöchbauer. Yeah, since my divs have float: left, that's why the (custom or not) tag they're wrapped in doesn't expand it's height. Seems I've forgotten how css works since I started to look over Angular 2:)
But one thing still remains:
If I set a percentage width on a block element (call it E), I would assume it takes x% of it's immediate parent. If I set float: left, I would expect floating within the immediate parent. In my A case, since the immediate parent is a custom tag with no display type and no width, I would expect for things to break somehow, but still... my E elements behave like their parent isn't the custom tag they're each wrapped in, but the next one in the dom (which is <div class="video-listing> in my case). And they occupy x% of that and they float within that. I don't expect this to be normal, I would think this is just a fortunate effect, and I'm afraid that one day, after some browser update... I'll wake up to find all my Angular 2 sites looking completely broken.
So... are both A and B an equally proper approach? Or am I doing it wrong in case A?
EDIT2:
Let's simplify things a bit. As I got part of my question answered, let's take another example of generated html (simplified a bit, with inlined css):
<footer>
<angular-component-left>
<div style="float: left; width: 50%;">
DIV CONTENT
</div>
</angular-component-left>
<angular-component-right>
<div style="float: left; width: 50%;">
DIV CONTENT
</div>
</angular-component-right>
</footer>
In the original, not yet implemented html (whithout <angular-component-...>, those divs should float left and each occupy 50% of the <footer>. Surprisingly, once they're wrapped in the <angular-component-...> custom tags, they do the same: occupy 50% of the footer. But this just seems like good fortune to me, dumb luck... Unintended effect.
So, is it or isn't it "dumb luck"?
Should I leave it like that, or rewrite so instead of the above code, I would have something like this:
<footer>
<angular-component-left style="display: block; float: left; width: 50%;">
DIV CONTENT
</angular-component-left>
<angular-component-right style="display: block; float: left; width: 50%;">
DIV CONTENT
</angular-component-right>
</footer>
Note that the inline styling is introduced here for simplicity, I would actually have a class instead which would be in an external css file included in the <head> of my document, not through style or styleUrls from my angular components.
The issue is your HTML validator. The - in the element name is required for elements to be treated as custom elements and it is valid HTML5. Angular doesn't require - in element names but it's good practice.
Check for example https://www.w3.org/TR/custom-elements/#registering-custom-elements (search for x-foo) or https://w3c.github.io/webcomponents/spec/custom/#custom-elements-custom-tag-example. I'm sure this dash rule is specified somewhere but wasn't able to find the spec. It is for example required in Polymer that depends on elements being proper custom elements while this doesn't matter much in Angular. The only difference as far as I know is that when you query the element, you get a HTMLUnknownElement when the - is missing in the name and a HTMLElement when it contains a -.
See also this question I asked a few years ago Why does Angular not need a dash in component name
BUT if you take a closer look, by default the custom tags don't occupy any space in the dom. They're 0px by 0px. Only their content occupies space. I just don't get it how come the browser still renders everything as you would want to see it
I'm not sure I understand this question. When Angular processes the template it adds the content dynamically. When you see the content in the browser than it's also available in the DOM and has actual dimensions.
Search engine crawlers are able to process pages that are generated by JavaScript. If this isn't enough, server-side rendered pages can provide static HTML to crawlers that contain the whole view.
I'm referring to a main menu and a smaller supermenu (don't know the proper term), as seen here:
For something like this, I was going to put two <nav> elements in the <header>. Is there any reason (SEO or otherwise) that this is a bad idea? If so, what would an alternative be?
(this is different from multiple <nav> tags, which referred to multiple on an entire page, not in a single block element)
Short answer: no there is not (probably)
Longer answer: the HTML5 spec itself is a bit fluffy on the subject:
http://dev.w3.org/html5/spec/Overview.html#the-nav-element
The thing is that they designate the <nav> element to 'major' navigation blocks, but leave it to the imagination (of both developers and parsers) what that means. As you can see they even provided an example where they exclude the "site-wide" from the navigation block.
<body itemscope itemtype="http://schema.org/Blog">
<header>
<h1>Wake up sheeple!</h1>
<p>News -
Blog -
Forums</p>
<p>Last Modified: <span itemprop="dateModified">2009-04-01</span></p>
<nav>
<h1>Navigation</h1>
<ul>
<li>Index of all articles</li>
<li>Things sheeple need to wake up for today</li>
<li>Sheeple we have managed to wake</li>
</ul>
</nav>
</header>
They seem to do that because they consider limiting the number of links in nav elements a plus for readability (think screen readers etc).
It is probably a bit too early to know what the search engines are going to do, but it seems safe to think that they will attach more importance to nav element links to detect the structure of you site and maybe more so if you have less of them...
My impression: Twitter and Facebook links seem certainly out, support and blog are debatable
I think it does not matter. NAV element just marks functional role of some content. So if you have two separate navigation blocks (regardless of where it's placed: in header or in other parts of page), you are free to use separate NAV elements for them. Some "penalties" from search engines in that case would be pointless.
Nav can be used multiple times on a page in HTML5.
CAN…yes
SHOULD…probably not.
I’ve always worked on the basis that the NAV tag is only for the primary page/site navigations.
If my main (header) navigation area is used for the [nav] then any other menus can be in divs with some role for ARIA.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Margin on child element moves parent element
I'm having trouble with the margin applied to a children elment inside a <div/>. The child's margin affects the parent's:
<style type="text/css">
html{width:100%}
html body div{margin-left:auto;margin-right:auto;width:800px;}
div#desc{margin-top:100px;background-color:white;width:500px;font-size:24px;}
#photo{width:10px;height:10px}
</style>
<html>
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div>
<div style="background-color: silver">
<div id="desc">
CSS<br/>
IS<br/>
THE<br/>
HARDEST<br/>
LANGUAGE<br/>
EVER<br/>
</div>
</div>
</div>
</body>
</html>
Why div#desc instead of moving itself down by 100px moves whole construction by this value!?
Here is the working demo.
Because of collapsing margins.
See another answer I wrote for various ways to "fix" it.
For example, in your case, you could add float: left to the parent of #desc.
http://jsfiddle.net/jsK4y/10/
Or padding:
http://jsfiddle.net/jsK4y/16/
Or overflow not set to visible:
http://jsfiddle.net/jsK4y/17/
Collapsing Margins..
add 1px padding to <div style="background-color: silver"> padding stops margins "adjoining" if they can't adjoin, they can't collapse.
I would also suggest a change of Doctype to:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
the one you have is triggering quirks mode in IE7 and below and will lead to more heartache ;)
Welcome to Margin Collapsing:
population: #oneat
This is a common question for people new to CSS. Read the w3c docs, or search for margin-collapsing tutorials.
You're seeing collapsing margins in effect. The standard linked above lists a variety of conditions for that. By the way, <style> elements should go into the <head>.
This has to do with margin collapsing (ref to W3C spec)
Answers to this question of mine will help you.
overflow:auto seems best
That's because the outer div has no content, hence it looks like it does not work.
Using position:absolute; in css or putting something outside the #desc div will show you.
Since you didn't provide much of what you really want to do, I'll do my best to understand. I'm going to assume you want the description div 100px below ay content in the parent (wrap) div.
Your main problem is that your html body div{margin-left:auto;margin-right:auto;width:800px;} css declaration is being inherited by all of your divs on the page. I went ahead and chopped up some of your code to give you a better idea of how things are being placed. Another recommendation for your CSS and HTML code, is to try to not be general about your declarations. Be explicit, as you can see, I added an id to the parent. This way you can avoid inheritance issues as you did. Anyhow, here's the link:
http://jsfiddle.net/jsK4y/15/
There are plenty of ways to do what you want with floats or positioning or even as you did, by margins. But keep in mind that any one of those ways will have their kinks that you'll run into.
If you are talking about, why the text is moved down too, this is because the text is into desc div.If not, explain little better what you mean and, thanks.
I have a container div#content, which contains three divs inside. Now, how could I make sure that three divs inside have the same height? Of course, I hope each div's height could be expanded according to its content. For example:
here is what I tried
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<title></title>
<style type="text/css">
#content{background-color:#DDDDD;width:100%;overflow:auto;clear:both;height:100%;}
#col1{background-color:yellow;width:10%;float:left;height:100%;}
#col2{background-color:red;width:30%;float:left;height:100%;}
#col3{background-color:#AAAAAA;width:10%;float:left;;height:100%;}
</style>
</head>
<body>
<div id="content">
<div id="col1">
<script language="javascript">
for(i=0;i<1000;i++){
document.write(i+"<br />");
}
</script>
</div>
<div id="col2">
<script language="javascript">
for(i=0;i<100;i++){
document.write(i+"<br />");
}
</script>
</div>
<div id="col3">
<script language="javascript">
for(i=0;i<10;i++){
document.write(i+"<br />");
}
</script>
</div>
I regularly get bashed by the CSS purists for this suggestion, but whenever I run into a problem like this for which – to the best of my knowledge – CSS simply doesn't offer a solution (no, "change your design" doesn't count!)...
I recommend using a table for that part of your layout.
Tables do equal vertical sizing easily and correctly across all major browsers. I'll continue to recommend them until CSS offers workable solutions for those problems.
A very useful technique for creating divs of equal height is to emulate it with a technique called "Faux Columns". This was an idea first suggested by Dan Cederholm (You can read his original article here), and has since evolved. You can see a good tutorial here. If you need it in a liquid layout environment, you might want to read this article.
Basically, the idea builds on NOT trying to force the divs to be of equal height, but have a wrapper of the three divs with a background-image that simulates the background of the columns. This approach works consistently among all modern browsers (ie6 even counts as modern in this context). The negative part is that you'll need a background image that is at least as wide as the page is allowed to expand. i.e. X pixels wide and 1px high.
First of all: if you have an equal attribute on different elements, please adhere to the DRY principle (Don't Repeat Yourself) and write it like so:
.content div{
border:1px solid #404040
}
That way you'll only have to change it in one place.
Now about your question. For a dynamic height, I'd specify that the div's should have a height of 100%, so they fill all the vertical space. This doesn't work nicely cross-browser so look for a hack that does this. If you don't want the div's to fill up the content div, put another div inside the content div and put that around the 3 divs.
So:
<div id="content">
<div class="innerContent">
<div class="1">Lorem Ipsum</div>
<div class="2">Lorem Ipsum</div>
<div class="3">Lorem Ipsum</div>
</div>
</div>
I may be wrong, but I think you either put the same values for the heights in the divs (either in percent or px) or you'll have to do some script (for example in JavaScript) that will check on the content height and set the other heights. I don't think it's doable with CSS. If I'm wrong I'd like to know the answer though:P
You could try it using css for modern browsers (display:table-cell, etc.), however, that will not work in IE6 and IE7.
If IE6 and IE7 are a requirement (I suppose it is...), you can include some javascript just for them using conditional statements and have that javascript set the height of all columns to the tallest. Not really pretty, but the percentages of IE6 and 7 should be going down fast anyway.
By the way, Machine's solution (faux columns) is another solution that works for a lot of designs.