Why <Big> Is Not in HTML 5 Tag List While <Small> Is

#main {    width: 800px;    height: 800px;    margin: 0 auto;}
.sidebar {    width: 31%;    margin-right: 1%;    margin-left: 2%;}
.content {    width: 61%;    margin-right: 2%;    margin-left: 1%;}
.sidebar, .content {    background: #888;    height: 100%;    float: left;    border-radius: 4px;    color: #FFF;    font-family: Helvetica;    text-align: center;}
.sidebar_inner, .content_inner {    height: 100%;    width: 100%;    padding: 0%;    font-size: 1em;    background-color: black;}
h1{   margin:0;   padding:0;}

<div id="main">    <div class="sidebar">        <div class="sidebar_inner">            <h1>Hello!</h1>        </div>    </div>    <div class="content">        <div class="content_inner">            <h1>Hello again!</h1>        </div>    </div></div>

Why anchor tag does not take height and width of its containing element

The CSS 2.1 spec says

The dimensions of the content area of a box — the content width and
content height — depend on several factors: whether the element
generating the box has the 'width' or 'height' property set, whether
the box contains text or other boxes, whether the box is a table, etc.
Box widths and heights are discussed in the chapter on visual
formatting model details.

The <a> element defaults to a display value of inline. Its contents participate in the layout so it is a non-replaced element.

For height, the spec says:

10.6.1 Inline, non-replaced elements

The 'height' property does not apply. The height of the content area
should be based on the font, but this specification does not specify
how.

So 18px is arrived at from a single line of text, taken from the font metrics. Neither the larger image content, nor the containing block size plays any part.

For width, the spec says

10.3.1 Inline, non-replaced elements

The 'width' property does not apply. A computed value of 'auto' for 'margin-left' or 'margin-right' becomes a used value of '0'.

in other words, the width is determined by the <a> element's contents, paddings, borders and margins.

For the first <a> element that's 114px (contents - image plus one space) + 20px (left margin) + 2x5px (left and right border) = 144px

For the second <a> element that's 280px (contents - image) + 20px (left margin) + 2x5px (left and right border) = 310px

Just need to account for the spaces. The elements are being laid out in a line box in a inline context, so the spaces at the start of the first <a> element and at the end of the second <a> element are being dropped. The spaces at the end of the first <a> element and the start of the second <a> element are being collapsed into one space. When spaces are collapsed, it's always the first space which remains, which in this case is the one at the end of first <a> element, so that's why a space participates in the width of the first <a> element but not in the width of the second one.

Correct usage of strong and small tags when used together

Anyone who has ever done search engine optimisation would know h1 tag makes whole hell of a lot of difference between ranked on page 1 to page 30. So yes these tags do have their importance but how?
I am copy pasting official explanation and my subsequent question is underneath.

<b> vs. <strong>

It is often confusing to new developers why there are so many ways to
express the same thing on a rendered website. and are
perhaps one of the most common sources of confusion, causing
developers to ask "Should I use or ? Don't they both do
the same thing?"

Not exactly. The element is for content that is of greater
importance, while the element is used to draw attention to text
without indicating that it's more important.

It may help to realize that both are valid and semantic elements in
HTML5 and that it's a coincidence that they both have the same default
styling (boldface) in most browsers (although some older browsers
actually underline ). Each element is meant to be used in
certain types of scenarios, and if you want to bold text for
decoration, you should instead actually use the CSS font-weight
property.

The intended meaning or purpose of the enclosed text should be what
determines which element you use. Communicating meaning is what
semantics are all about.

<em> vs. <strong>

Adding to the confusion is the fact that while HTML
4 defined as indicating a stronger emphasis, HTML 5 defines
as representing "strong importance for its contents." This is
an important distinction to make.

While is used to change the meaning of a sentence as spoken
emphasis does ("I love carrots" vs. "I love carrots"), is
used to give portions of a sentence added importance (e.g., "Warning!
This is very dangerous.") Both and can be nested to
increase the relative degree of importance or stress emphasis,
respectively.

The HTML <small> element represents side-comments and small print,
like copyright and legal text, independent of its styled presentation.
By default, it renders text within it one font-size smaller, such as
from small to x-small.

The question is if all of them have predefined behaviour and don't do anything other than visual appeal. Since Bold means important and strong means important visually speaking. then who is this behaviour targeted to. We don't usually go looking in source code do we?

Answer is BOTS and most importantly indexing, scraping BOTS. If you are doing SEO and some kind of content analytics or parsing this from that then these tags come handy. Other than that its no different than

<i><b>hello</b></i>

or

<b><i>hello</i></b>

or

<small><strong>hello</strong></small>

or

<strong><small>hello</small></strong>

Yes they do matter depending on your case to case basis. Other than visual human reads if I am expecting lot of computer readability such text to speech, or bots, or assisted display etc then these matter.

bold: tag my dad telling me to do something

strong: tag my dad telling me to do something in firm instructive voice

italic: its part of content but not flow of content doesn't matter if you missed it

small: its part of content but not flow of content but if you missed it we might come back to say you should have read it.

Within content marketing perspective above distinctions play a major role with in source code which computers are going to parse.

HTML Tags: Presentational vs Structural

W3C decides the semantics of tags. The specification documents of HTML5 gives conditions on the use of the various tags.

HTML5

To continue with your example, there is nothing wrong with using <b> to bold some text unless:

• The text being bolded is a single entity already represented by a tag:

  Incorrect:
  
  <label for="name"><b>Name:</b></label>

  Correct: (Use CSS to style the element)
  
  label { font-weight: bold; }

<label for="name">Name:</label>

• The text is being bolded to put added emphasis and weight on a section or words of a block of text.

  Incorrect:
  
  <p>HTML has been created to <b>semantically</b> represent documents.</p>

  Correct: (Use <strong>)
  
  <p>HTML has been created to <strong>semantically</strong> represent documents.</p>

The following is an example of proper use of the <b> tag:

Correct:

<p>You may <b>logout</b> at any time.</p>

I realize that there doesn't seem to be a lot of difference between the above example and the one using <strong> as the proper example. To simply explain it, the word semantically plays an important role in the sentence and its emphasis is being strengthened by bold font, while logout is simply bolded for presentation purposes.

The following would be an improper usage.

Incorrect:

<p><b>Warning:</b> Following the procedure described below may irreparably damage your equipment.</p>

Correct: (This is used to add strong emphasis, therefore use <strong>)

<p><strong>Warning:</strong> Following the procedure described below may irreparably damage your equipment.</p>

---

Using <span class="bold"> is markup-smell and simply shouldn't be allowed. The <span> element is used to apply style on inline elements when a generic presentation tag (ie.: <b> doesn't apply) For example to make some text green:

Incorrect:

<p>You will also be happy to know <span class="bold">ACME Corp</span> is a <span class="eco-green">certified green</span> company.</p>

Correct: (Explanation below)

<p>You will also be happy to know <b>ACME Corp</b> is a <em class="eco-green">certified green</em> company.</p>

The reason here why you would want to use <em> as opposed to <span> for the word green is because the color green here is used to add emphasis on the fact that ACME Corp is a certified green company.

The following would be a good example of the use of a <span> tag:

Correct:

<p>You may press <kbd>CTRL+G</hbd> at any time to change your pen color to <span class="pen-green">green</span>.</p>

In this example, the word green is styled in green simply to reflect the color, not to add any emphasis (<em>) or strong emphasis (<strong>).

Acceptable to include a definition list within a figcaption tag?

Yes, dl is allowed inside of figure/figcaption: dl is flow content, and figure/figcaption expect flow content according to their content model.

However, I don’t think it’s the best choice in your specific example.

The dl doesn’t really add anything to understanding the content of this figure. It would be appropriate if there were several name-value pairs (e.g., "Price", "Ingredients" etc.), but what you currently have is just a title and a description.

The strong element doesn’t seem to be used according to its definition ("strong importance, seriousness, or urgency") here.

And I also think that the category/title/description isn’t really a caption for the photograph in this case; to me, it seems these 4 elements should be on the same level, so to say. But this is open for interpretation and also depends on the context where this slideshow will be shown.

Instead of using figure, I think that each menu item should be an article. This choice enables the use of headings and header elements:

<article>
  <img src="" alt="Sample Image" />
  <header>
    <div>Sandwiches</div>
    <h1>Hammin' It Up</h1>
  </header>
  <p>Fontina Cheese & Blackforest Ham grilled on Texas Toast</p>
</article>

How to reduce the gap between HTML5 video tag

I have found the link which gives various method to solve this issue, may be helpful to some one Reference : http://css-tricks.com

Published April 21, 2012 by Chris Coyier

Here's the deal: a series of inline-block elements formatted like you normally format HTML will have spaces in between them.

In other words:

<nav>
  <a href="#">One</a>
  <a href="#">Two</a>
  <a href="#">Three</a>
</nav>

nav a {
  display: inline-block;
  padding: 5px;
  background: red;
}

Will result in:

Often highly undesirable (check the link for the output)

We often want the elements to butt up against each other. In the case of navigation, that means it avoids the awkward little unclickable gaps.

This isn't a "bug" (I don't think). It's just the way setting elements on a line works. You want spaces between words that you type to be spaces right? The spaces between these blocks are just like spaces between words. That's not to say the spec couldn't be updated to say that spaces between inline-block elements should be nothing, but I'm fairly certain that is a huge can of worms that is unlikely to ever happen.

Here's some ways to fight the gap and get inline-block elements sitting directly next to each other.
Remove the spaces

The reason you get the spaces is because, well, you have spaces between the elements (a line break and a few tabs counts as a space, just to be clear). Minimized HTML will solve this problem, or one of these tricks:

<ul>
  <li>
   one</li><li>
   two</li><li>
   three</li>
</ul>

or

<ul>
  <li>one</li
  ><li>two</li
  ><li>three</li>
</ul>

or with comments...

<ul>
  <li>one</li><!--
  --><li>two</li><!--
  --><li>three</li>
</ul>

They're all pretty funky, but it does the trick.
Negative margin

You can scoot the elements back into place with negative 4px of margin (may need to be adjusted based on font size of parent). Apparently this is problematic in older IE (6 & 7), but if you don't care about those browsers at least you can keep the code formatting clean.

nav a {
  display: inline-block;
  margin-right: -4px;
}

Skip the closing tag

HTML5 doesn't care anyway. Although you gotta admit, it feels weird.

<ul>
  <li>one
  <li>two
  <li>three
</ul>

Set the font size to zero

A space that has zero font-size is... zero width.

nav {
  font-size: 0;
}
nav a {
  font-size: 16px;
}

Matt Stow reports that the font-size: 0; technique has some problems on Android. Quote: "Pre-Jellybean does not remove the space at all, and Jellybean has a bug whereby the last element randomly has a tiny bit of space." See research.
Also note, if you're sizing fonts in ems, this zero font size thing can be an issue, since ems cascade the children would also have zero font size. Rems would be of help here, otherwise any other non-cascading font-size to bump it back up.
Another weirdness! Doug Stewart showed me that if you use @font-face with this technique, the fonts will lose anti-aliasing in Safari 5.0.x. (test case) (screenshot).
Just float them instead

Maybe they don't need to be inline-block at all, maybe they can just be floated one way or another. That allows you to set their width and height and padding and stuff. You just can't center them like you can by text-align: center; the parent of inline-block elements. Well... you kinda can but it's weird.
Just use flexbox instead

If the browser support is acceptable to you and what you need out of inline-block is centering, you could use flexbox. They aren't exactly interchangeable layout models or anything, but you might get what you need out of it.

Why do some major websites use invalid HTML?

Most people have gotten the answer basically right — that the rules are different when you serve a page a billion times a day. Bytes begin to matter, and the current level of compression clearly shows that Google is concerned with saving bandwidth.

A few points:

One, people are implying that Google's reasons for saving bandwidth are financial. Unlikely. Even a few terabytes a day saved on the Google search results page is a drop in the bucket compared to the sum of all their properties: Youtube, Blogger, Maps, Gmail, etc. Much more likely is that Google wants its search results page, in particular, to load as quickly as possible on as many devices as possible. Yes, bytes matter when the page is loaded a billion times a day, but bytes also matter when your user is using a satellite phone in the Sahara and struggling to get 1kbps.

Two, there is a difference between the codified standards of XHTML and the like, and the de-facto standard of what actually works in every browser ever made since 1994. Here, Google’s scale matters because, where most web developers are happy to ignore any troublesome browser that accounts for less than 0.1% of their users, for Google, that 0.1% is perhaps a half million people. They matter. So their search-results page ought to work on IE 5.5. This is the reason they still use tables for layout on many high-value pages – it’s still the layout that “just works” on the greatest number of browsers.

As an exercise, while an intern at Google, I wrote a perfectly compliant XHTML/CSS version of Google’s search result page and showed it around. Eventually the question came up – why are we serving such hodge-podge HTML? Shouldn’t we be leading the web dev community towards standards? The answer I got was pretty much the second point above. Google DOES follow a standard – not the wouldn’t-it-be-nice standards of web utopia, but the this-has-to-work-absolutely-everywhere standard of reality.

---

Related Topics