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.
Related
https://interactjs.io/docs/action-options/#ignorefrom shows how to use ignoreFrom to disable dragging from certain elements. My movable element look something like:
<article>
<div>
<h1>My Article</h1>
<p>Hello World</p>
</div>
</article>
It could contain any HTML tags within the <div>, not just <h1> and <p>
I want to ignore dragging from any child element except the <div>. I've tried using ignoreFrom: ':not(div)', but that does not work (I'm guessing that the :not pseudo-selector is not supported). The only option I can get to work is to provide a list of all possible HTML tags as the value for the ignoreFrom. So, for this specific example, setting ignoreFrom: 'h1,p' works, but this approach will become unmanageable in the general case. Is there an easier way?
I have to create a primary heading component, below is my markup along with CSS classes. I'm following BEM naming convention for class name.
I have h1 element consists of two spans. One span for main heading text, and second span for sub heading text. The main and sub are variations of my heading.
I have not specified the Element class (Which could be heading-primary__text ) and i have directly attached modifier classes to span elements.
<h1 class="heading-primary">
<span class="heading-primary--main">Video Background Option</span>
<span class="heading-primary--sub">One Page Parallax</span>
</h1>
Is that a right way to follow BEM methodology without specifying Elements classes & attaching Block's modifiers classes to Elements(span)? Because i don't need elements classes.
Is there any alternate?
While this is subjective, and as per the convinience of the project . i'd recommend doing something like this- as you already have a header-primary_text element class
<h1 class="heading-primary">
<span class="heading-primary_text">Video Background Option</span>
<!--create a modifier -->
<span class="heading-primary_text--sub">One Page Parallax</span>
</h1>
In this way you can make the sub a modifier class for the subtext.
More info can be seen here https://en.bem.info/methodology/quick-start/#modifier
Hope this helps :)
I think there is a much simpler way to do this just using basic HTML. You only want to have one h1 per page and since you said that your second span of your h1 is a "subheading" I feel like you would be way better off marking that one as an h2 instead of two spans of different context within one h1 heading! Always good to use the built in benefits of HTML first if you can.
No, it is not the right way. You cannot use block (or element) modifier alone on the HTML tag without specifying the block (or element) class itself.
Please refer to BEM documentation here: https://en.bem.info/methodology/quick-start/#modifier
A modifier can't be used alone From the BEM perspective, a modifier
can't be used in isolation from the modified block or element. A
modifier should change the appearance, behavior, or state of the
entity, not replace it.
Here is a code example from the docs:
<!-- Correct. The `search-form` block has the `theme` modifier with the value `islands` -->
<form class="search-form search-form_theme_islands">
<input class="search-form__input">
<button class="search-form__button">Search</button>
</form>
<!-- Incorrect. The modified class `search-form` is missing -->
<form class="search-form_theme_islands">
<input class="search-form__input">
<button class="search-form__button">Search</button>
</form>
You mentioned that you don't need an element class, this topic is also covered in BEM docs
https://en.bem.info/methodology/faq/#why-include-the-block-name-in-modifier-and-element-names
semuzaboi's suggestion sounds as a good alternative to me.
First of all, elements are specified after two __ like block__element_modifier.
Secondly, yes. Blocks may not have any elemenets inside, but rather have modifiers (most common case a block with lang modifiers for Internationalization (block_lang_ru))
PS as well as element may not have any modifiers inside. But block can not be nested inside another one. They should be placed inside one directory on the same level.
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 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 (?)
I'm learning in CSS, I am really confused when to use .(dot) and when to use # in CSS file. Sometimes I really wondered which one I should use.
#You are .Human
While there are many humans, there is only one you. As such, . is for classes, which can appear over and over in a document. # is for IDs, which are unique to a document.
<div class="firstname" id="personA">
<p class="lastname">Sampson</p>
</div>
<div class="firstname" id="personB">
<p class="lastname">Sampson</p>
</div>
Note the unique identifier for both div, personA and personB. However both elements have classes in common, such as .firstname, and .lastname.
Professional Examples
You can see how these are used out in the wild by looking at tools like Modernizr. This feature-detection tool assists you by adding classes to the <html> element that inform you as to what the device or browser is capable of:
<html lang="en" dir="ltr"
id="modernizrcom"
class="js no-touch postmessage history multiplebgs boxshadow...">
Here we see the one unique value for the <html> element, #modernizrcom. Following, a series of classes that give more general info about the element. This is a clear example of how an element can have only one id, but many classes.
Careful with those IDs!
Because these values are completely unique, they can cause you to paint yourself into a corner at times. It's worth reading Disallow IDs in Selectors to know more about the potential issues with using IDs in your selectors.
The # is used for the id of an element and . is used for classes of an element. In a HTML document, an id is unique (there should only be one element with that id) while classes can occur multiple times.
<div id="content" class="shade light">
</div>
You can now do:
#content { border: solid 1px black; }
to add styling to that particular div element. But you can also do:
.light { background-color: #eeeeee; }
The difference is that the latter will apply that background color to all elements with that class (i.e., all elements with the class light while the first CSS statement will only add styling to the element with the id content).
a dot (.) represents a class, a hash (#) represents an id.
There is more to it, but this is the gist:
An id (#myID) should be used when you only intend to use that selector once
A class (.myClass) should be used to create a reusable piece of styling code (e.g. to make text blue)
. is represent class
# is represent ID(but used only once in a page)
always the id is having the first priority in the race.
ex:
in the style
.alignmeleft{float:left;}
#alignmeright{float:right;}
in the html:
<div class="alignmeleft" id="alignmeright">
<!--div content-->
</div>
OUTPUT
THE DIV WILL ALIGNED RIGHSIDE