<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>A Tale of Two Headings</title>
<style>
html,
body {
width: 100%;
height: 100%;
font-size: 100%;
font-family: "Lucida Console", monospace;
}
*,
*:before,
*:after {
margin: 0;
padding: 0;
box-sizing: border-box;
line-height: 1;
vertical-align: baseline;
}
h1 {
font-size: 32px;
}
h2 {
font-size: 28px;
line-height: 32px;
}
#panel {
position: fixed;
bottom: 3em;
padding: 4px 8px;
width: 40em;
}
#panel button {
padding: 8px;
width: 64px;
line-height: 1.2;
text-align: center;
text-decoration: none;
cursor: pointer;
}
legend {
font-size: 30px;
}
.area {
max-width: 100%;
width: 60em;
height: auto;
padding: 2em 1em;
}
a {
text-decoration: none;
width: 100%;
height: 100%;
}
a:hover,
a:active {
text-decoration: underline;
}
#demo1 {
background: #8080FF;
width: 40em;
transition: width 1.5s;
}
#demo1 > .titles {
display: flex;
}
/* :target */
#demo1:target {
width: 20em;
}
#demo1:target > .titles {
display: flex;
flex-direction: column;
}
/* demo 2
transition */
#demo2 {
background: #FF8080;
width: 40em;
transition: width 1.5s;
}
#demo2 > .titles {
display: table-row;
}
#demo2 > .titles > * {
display: table-cell;
}
/* :target */
#demo2:target {
width: 20em;
}
#demo2:target > .titles {
display: block;
}
#demo2:target > .titles > * {
display: block;
}
/* demo 3
transition */
#demo3 {
background: #FFCC33;
width: 40em;
transition: width 1.5s;
}
#demo3 > .titles > h2,
#demo3 > .titles > h1 {
display: inline-block;
}
#demo3.block {
width: 20em;
}
#demo3.block > .titles > h2,
#demo3.block > .titles > h1 {
display: block;
}
</style>
</head>
<body>
<section id="demo1" class="area">
<!--==Pure CSS Demo #1==-->
<!--======Flexbox=======-->
<header class="titles">
<h1>Demo 1 - </h1>
<h2>display: flex</h2>
</header>
</section>
<section id="demo2" class="area">
<!--==Pure CSS Demo #2==-->
<!--=====Table-Row======-->
<header class="titles">
<h1>Demo 2 - </h1>
<h2>display: table-row</h2>
</header>
</section>
<section id="demo3" class="area">
<!--===CSS/JS Demo #3===-->
<!--=====classList======-->
<header class="titles">
<h1>Demo 3 - </h1>
<h2>classList</h2>
</header>
</section>
<fieldset id="panel">
<legend>Control Panel</legend>
<a href="#demo1"><button id="btn1">Demo 1</button></a>
<a href="#demo2"><button id="btn2">Demo 2</button></a>
<button id='btn3'>Demo 3</button>
</fieldset>
<script>
var btn3 = document.getElementById('btn3');
var demo3 = document.getElementById('demo3');
btn3.addEventListener('click', function(e) {
demo3.classList.toggle('block');
});
</script>
</body>
</html>
[#SO37853141](http://stackoverflow.com/questions/37853141/is-changing-default-display-value-a-good-practice/37909616#37909616)
[**POST**](http://stackoverflow.com/a/37909616/2813224)
#Q & A
> It all leads to a simple question: Is it a bad practice to change the default display property of HTML elements?
No, not at all. Matter of fact it's a very common practice of web developers (myself included), to alter not only properties of an element, but also attributes, and it's contents to name a few.
> Is it breaking the standard and should be avoided if possible?
No, but perhaps the way one goes about doing it may break the code itself which IMO is a greater concern than standards. Standards of course plays an important role but not an essential one. If that were the case, then web browsers should comply under one common set of standards (I'm talking to you IE :P). Off the top of my head, here's things that should be avoided:
- Using the [table](http://stackoverflow.com/a/84986/2813224) element for a layout
<table>
<tbody>
<tr>
<td><img></td>
<td><input type="button"/></td>
</tr>
...
- Using [inline styles](http://stackoverflow.com/q/6389808/2813224)
<div style="display: inline-block"></div>
- Using [inline event handlers](http://stackoverflow.com/a/15792621/2813224)
<div onclick='makeASandwich();'></div>
> Or is it our bread and butter and it does not really matter, as long as code is semantically correct (so headers are placed in h1, articles are placed in article etc...)
Changing an element's display property is a very small yet fundamentally essential aspect of web developing. So yes I suppose it can be considered *bread and butter*, which would make semantics *the parsley that's used as garnish and never eaten.* [Semantics is subjective](http://www.hongkiat.com/blog/html-5-semantics/), a way of thinking, it is not a standard. I believe a novice should be aware of it's importance (or at least how it's important to others), but should not be pontificating between an `<article>` and a `<section>` being semantically better than using a `<main>` and an `<aside>`. In due time, semantics will just *feel right*.
##Approach #1: Use display: inline
I have never found a good reason to use `display: inline` because [`display: inline-block` is a far better choice](http://stackoverflow.com/a/9189873/2813224).
##Approach #2: Use float
Floats are fragile antiques. Just like handling Grandma's bone china dinner plates, you must take certain precautions if you plan on using them. Be mindful of how to [clear floats](http://www.quirksmode.org/css/clearing.html) and don't throw them in the dishwasher.
Basically, if given only these 2 options, Approach #1 is a better choice, especially if using `inline-block`. I'd stay away from `floats`, they are counter-intuitive and break easily. I recall only using them once because a client wanted text wrapping around an image.
##CSS & CSS/JS
Provided is a Plunker comprising of 3 demos:
1. Pure CSS solution utilizing [`display: flex`](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Using_CSS_flexible_boxes).
2. Pure CSS solution utilizing [`display: table-row`/`table-cell`](http://colintoh.com/blog/display-table-anti-hero).
3. CSS and minimal JavaScript solution utilizing `display: inline-block` and the [`classList` API](http://blog.teamtreehouse.com/manipulating-classes-using-classlist-api).
Each of these demos are identical on the surface:
###HTML
<section id="demo1" class="area">
<!--==Pure CSS Demo #1==-->
<!--======Flexbox=======-->
<header class="titles">
<h1>Demo 1 - </h1>
<h2>display: flex</h2>
</header>
</section>
This is the original markup with the following changes:
- `div.container` is now `header.titles`
- `h1` text is: "Demo **`#n`**"
- `h2` text is: "**`prop`**:**`value`**"
- `section#demo#n.area` is wrapped around everything.
This is a good example of semantics: **Everything has meaning**
You'll notice at the bottom of the viewport, are buttons. Each button corresponds to a demo.
Details on how each demo works as well as pros and cons are in the following files located in the leftside menu of the Plunker (see screenshot):
- demo1.md `flexbox`
- demo2.md `disply: table`
- demo3.md `classList`
[**PLUNKER** - iNFO](http://plnkr.co/edit/0EsdLXtRGNM9aUvZN0gl?p=info)
These notes are not for the purpose of informing the OP of anything relevant to the question. Rather they are observations that I would like to address later on.
###Further Notes
- Demo 1 and demo 2 are powered by the pseudo-class [`:target`](https://css-tricks.com/on-target/). Clicking either one of them will trigger the `click` *event* It resembles an event because it's invoked by a `click`, but there's no way of controlling, or knowing the capture or bubbling phase if it actually exists. Upon further clicking of the first and second button, it will exhibit odd behavior such as: toggling of the other button then eventually becoming non-functionalđź—ˇ. I suspect the shortcomings of `:target` is that CSS handles events in a completely different way with little or no interaction with the user.
đź—ˇ fixed that issue by wrapping the anchor around the button.
#DEMO3
\ /
CSS
|
[STATE 0
|
#demo3 {
background: #FFCC33;
|
]PREPARE TRANSITION {40em
| |
width: 40em;|
transition: width 1.5s;
}
]STATE 0 | INLINE-BLOCK_
| |
#demo3 > .titles > h2,
#demo3 > .titles > h1 {
display: inline-block;
}
[STATE 1
|
]STATE 1 | BLOCK_
| |
#demo3.block {
]EXECUTE TRANSITION {20em
| |
| width: 20em;
}
]STATE 1 | FINAL STAGE
| |
#demo3.block > .titles > h2,
#demo3.block > .titles > h1 {
display: block;
}
____JavaScript
|
<0> REFERENCE btn3
|
var btn3 = document.getElementById('btn3');
|
<0> REFERENCE demo3
|
var demo3 = document.getElementById('demo3');
|
>1< CLICK
|
btn3.addEventListener('click', function(e) {
|
>1< TOGGLE STATES | CLASS SWITCH
|
toggle {
demo3.classList.toggle('block');
});
PROS
- Using JavaScript opens a whole universe of posibilities not available to CSS.
- Using a class to define a special state of an element is very simple:
- ex. `.show { display: block }` `.hide { display: none }`
CONS
- IE [partial support](http://caniuse.com/#feat=classlist) of `classList`
#DEMO2
\ /
CSS
|
[STATE 0
|
#demo2 {
background: #FF8080;
| |
]PREPARE TRANSITION |
| width: 40em; |
| transition: width 1.5s;
}
]DISPLAY | TABLE-ROW
|
#demo2 > .titles {
display: table-row;
}
|
]DISPLAY | TABLE-CELL
|
#demo2 > .titles > * {
display: table-cell;
}
|
[STATE 1 +][+TARGET
|
#demo2:target {
]EXECUTE TRANSITION
| width: 20em;
}
|
]DISPLAY | BLOCK
|
#demo2:target > .titles {
display: block;
} |
[STATE 1 | FINAL STAGE
|
#demo2:target > .titles > * {
display: block;
}
PROS
- Remember when I said never use `<table>` for layout? If you notice whenever someone on SO posts a `<table>` layout they get crucified? Still, everyone that does so will say it's the easiest way to create a solid reliable layout. Both are parties are right:
- you should only use tables to display and organize data.
- it is stable, reliable, and old as dirt so everyone knows it's basic components and how they are arranged.
- Using the following `display` properties, you can have your cake and eat it to:
- `table` element will behave like, well... like `<table>` the only thing it cannot do is take advantage of certain table attributes like `rowspan` or `colspan`.
- `table-row` = `<tr>`
- `table-cell` = `<td>`
- `table-row-group` = `<tbody>`
- `table-header-group` = `<thead>`
- `table-footer-group` = `<tfoot>`
- `table-caption` = `<caption>`
- `table-column` = `<col>`
- `table-column-group` = `<colgroup>`
- `inline-table` element will behave as `table`, but will position itself inline (next to--left or right of--side by side) with it's sibling elements. Normal `table` behavior is like `block` where it will occupy it's own line, having it's siblings either above or below it.
- This property is [universally supported](http://caniuse.com/#search=display)
CONS
- Hmmm...Um Firefox doesn't support `inline-table`, but that's easily solved by wrapping the element into a `<span>` or a `<div>` with `display: inline-block`.
- Basically there's no real disadvantage.
#DEMO1
\ /
CSS
|
[STATE 0
|
#demo1 {
background: #FF8080;
| |
]PREPARE TRANSITION |
| |
| width: 40em; |
| transition: width 1.5s;
}
]DISPLAY | FLEX
|
|
#demo1 > .titles {
display: flex;
}
|
[STATE 1 +][+TARGET
|
#demo1:target {
]EXECUTE TRANSITION
| width: 20em;
}
|
]DISPLAY | FLEX
|
#demo1:target > .titles {
display: flex;
} |
]FLEX-DIRECTION | COLUMN
|
[STAGE 1 | FINAL STAGE
|
#demo1:target > .titles > * {
flex-direction: column;
}
PROS
- Flexbox layouts can be easily altered by changing just one value.
- ex. `flex-direction: row` to `column` changes the whole layout's axis 90 degrees.
- Flexbox achieves `float` behavior on a group of elements cohesively without the crazy float problems like [collapsing parents](https://css-tricks.com/almanac/properties/f/float/).
- Flexbox is [awesome](https://philipwalton.github.io/solved-by-flexbox/)
CONS
- [IE support](http://caniuse.com/#feat=flexbox) is partial.