I'm about to update http://getcrow.eu and have one "issue" to solve that would make the framework everything I always wanted it to be.
Important to know:
Crow does not use tables, absolute positioning, floats or clearfix'es and it should stay that way.
We know that putting inline-blocks next to each other like so:
<div class="parent">
<div>Block 1</div>
<div>Block 2</div>
<div>Block 3</div>
</div>
with CSS:
.parent {
> div {
display: inline-block;
}
}
Creates white-spaces between the blocks. We also know there's a handful of solutions to prevent the white-spaces from creating space, which is highly required if creating a grid framework with this method.
Beneath I list the methods that I'm aware of and why I don't want to/can't use them:
(SKIP IF YOU WANT TO GET TO THE QUESTION)
Comments in the HTML inbetween children div's.
No-go because: it creates ugly HTML that the developer, using crow, must be aware of and work with.
Breaking lines at the end of children tags/ not using closing tags.
No-go because: same as above
Using minus (-) margins on .parent-wrapper.
No-go because: specified margins depends on document font size which mean the grid could break in responsive markup where html { font-size:{X}px; } changes.
Setting 0px font-size to .parent and "reset" the font size on children (this is the method I'm currently using).
No-go because: I don't want the developer using crow to force-set the children. I just want the inheritance to be natural without a grid that's setting the font size downwards for me.
Using Javascript to remove all white-spaces from .crow elements.
No-go because: I want the framework to be pure CSS and no js. This could also "flick" the DOM after pageload if user has bad connection.
Loading a font with font-family on .parent that has no white spaces.
No-go because: loading in an extra font just to get the grid framework is just wrong. Especially as you have to download extra files (font-files) and declare fallbacks for all browsers.
Using letter-spacing -{X}px on .parent.
No-go because: same as .3 (see above)
Using flex box.
No-go because: the framework focuses on vertical centering (if desired) and flex box lives it own life when it comes to that. I'm also making sure the grid is supporting IE8 which it does today.
So basically I'm searching for a - unknown/not yet discovered/way that I'm not aware of - for removing white spaces in between inline-blocks. I want it to be pure CSS. If you have a method that you know of/think would work - I can try it on different browsers.
Resolving this would surely make Crow the best grid framework. I'm already using it for various websites and I can tell that the possibilites are many when given the ability to easily position elements center vertically.
Sidenote:
Marking up the DOM like so: <div class="parent"><div>Block 1</div><div>Block 2</div></div> does the job just like I want it to. But that would require the developer using Crow to mark it up that way. And I don't want to rely on a framework creating that HTML.
InuitCSS (my choice of framework lately) uses a similar system. As wonderful as the use of display: inline-block; is in a grid system, it does appear that the whitespace issue, is an inherent one; with little chance of resolution beyond the current workarounds.
I agree that the use of comments or closing tags does introduce some issues with CMS entries, and a certain amount of mental overhead for the developers involved; but not an unmanageable amount.
If you want to have a look at Inuit's grids I would recommend it's GitHub found here:
https://github.com/inuitcss
I would also advise reading this issue, in-which Inuit's creator; Harry Roberts, weighs in on the various solutions this problem. Whilst it may not tell you anything you don't already know, it is an interesting (if outdated) discussion on the matter.
https://github.com/csswizardry/inuit.css/issues/170
I know that the above may not solve your issue, or even shed any light on the matter, but I hope it can be of use.
Using a float is your best option.
.parent div {
float: left;
}
Following your comments below you could use a negative margin.
.parent div {
margin-left: -4px;
}
But this may change browser to browser.
Related
I've made the jump from HTML table layout for designing webpages to CSS about a week ago and have since been reading more about it. Yesterday, I read a long post here on Stack overflow where users were knocking float and how deprecated they are for layout. There was a lot of talk about inline-block being used in its place.
I have an HTML5 design that I just finished and it looks fantastic in Firefox and Chrome, but when tested in Internet Explorer 7, 8, and 9, the design absolutely explodes. It seems to me that anything in this design that I've floated right is not honored in IE. It just seems to wrap under whatever is to the left of it.
I'd like to know if I'm OK with floats or if I should I be using inline-block instead. An example of how to have two divs next to one another where one is on the left side and the other on the right, using inline-block would be nice.
Floats were never meant for layout.
They’re simply meant to take an element, put it to one side, and let other content flow around it. That’s all.
Eric A. Meyer, in Floats Don’t Suck If You Use Them Right
The early web was influenced by print/academic publications where floats are used to control the flow of text around figures and tables.
So why did we use them for layout?
Because you can clear a footer below two floated columns, float layout
came into being. If there had ever been a way to “clear” elements
below positioned elements, we’d never have bothered to use floats for
layout.
Today, the CSS Flexible Box Layout Module flex and the CSS Grid Layout Module grid are optimized for user interface design and complex layouts and are expected to complement each other.
Grid enforces 2-dimensional alignment, uses a top-down approach to layout, allows explicit overlapping of items, and has more powerful spanning capabilities. Flexbox focuses on space distribution within an axis, uses a simpler bottom-up approach to layout, can use a content-size–based line-wrapping system to control its secondary axis, and relies on the underlying markup hierarchy to build more complex layouts.
Flexbox and Grid are—as of this writing—W3C candidate recommendation and candidate recommendation draft, respectively. Flexbox is supported by all major browsers and has known issues in IE11. Grid is supported by all major browsers but IE11 supports an older version of the spec.
This question is from 2012 and the other answers are outdated.
Floats should not be used for layout anymore (though you can still use them for the original purpose - floating text around images).
Flexbox is now widely supported and is better for layout.
Floats should work fine, although it depends on how you've used it - how about a link to your design?
inline-block doesn't work correctly in Internet Explorer versions less than 8: http://www.quirksmode.org/css/display.html
You can use this example in inline
<div id="firstdiv">
That is the first div
</div>
<div id="seconddiv">
That is the second div
</div>
style.css
#firstdiv{
display:inline;
background-color: #f00;
}
#seconddiv{
display:inline;
background-color: #00f;
}
it will be work at IE8 and higher but if you wanna use it in IE6 and 7 make the following code in style.css
#firstdiv{
display:block;
background-color: #f00;
float: left;
}
#seconddiv{
display:block;
background-color: #00f;
float: right;
}
if you use HTML5 and CSS3 and you want it work with IE6 read the following article 5 Tools to Make IE Play Nice With CSS3 and HTML5 in WordPress
you can read that article too it is very useful difference between block, inline and inline-block
Are there any disadvantages to using word-wrap:break-word in the following way?
body
{
word-wrap: break-word;
}
The descriptions of the values for this property are as follows:
normal: Break words only at allowed break points
break-word: Allows unbreakable words to be broken
Now, this only makes a difference in the breaking of unbreakable words (i.e. continuous strings that are longer than their containers). Otherwise, it'll make no difference for 99% of text anywhere.
So, are there any disadvantages to using this globally? It can certainly solve a lot of layout issues without (at least as far as I can see) having any adverse effects. It seems better to do this once than to have to apply it everywhere you could possibly have overflowing text that would mess up your layout.
I can't think of any disadvantages since, if you want to have some other kind of word-wrap elsewhere, you'll always be able to override this global style.
That said, if you can at all narrow down the situations in which this will be necessary, using a broad class would be preferable. There's no telling what rare but very frustrating bugs a global break-word style will cause (and in what browsers).
I can't see any advantages of making it global on a page if the page is anything other than a test page.
For me I would not want words that are unbreakable to break at all. It's easier to read when they are not broken up. However if you want to make your text fit a div without using text-align:justify; and leaving gaps in between letters or words it might be nice.
The reason why I said in other than a test page was because sometimes, when I wanted to use place holder text besides "lorum ipsum" I would type gibberish but the div would always stretch. But since I wouldn't be using that text on the live site, I probably wouldn't use it.
I think the only consideration would be support in IE8.
According to this, word-wrap: break-word; doesn't work in all scenarios.
This property applies to elements that have layout. An element has
layout when it is absolutely positioned, is a block element, or is an
inline element with a specified height or width.
Of course, this seems quite easily rectified, but it should be known in case you need to support IE8 and you intend to apply this to items that do not "have layout".
Interesting are the new CSS3 properties:
http://www.w3.org/TR/css3-text/#word-break
http://www.w3.org/TR/css3-text/#word-wrap
I'm making more of an effort to separate my html structure from presentation, but sometimes when I look at the complexity of the hacks or workarounds to make things work cross-browser, I'm amazed at huge collective waste of productive hours that are put into this.
As I understand it, floats were never created for creating layouts, but because many layouts need a footer, that's how they're often being used. To clear the floats, you can add an empty div that clears both sides (div class="clear"). That is simple and works cross browser, but it adds "non-semantic" html rather than solving the presentation problem within the CSS.
I realize this, but after looking at all of the solutions with their benefits and drawbacks, it seems to make more sense to go with the empty div (predictable behavior across browsers), rather than create separate stylesheets, including various css hacks and workarounds, etc. which would also need to change as CSS evolves.
Is it o.k. to do this as long as you do understand what you're doing and why you're doing it? Or is it better to find the CSS workarounds, hacks and separate structure from presentation at all costs, even when the CSS presentation tools provided are not evolved to the point where they can handle such basic layout issues?
Clearfix is unnecessary most of the time, and the popular version of hack is needlessly verbose and complicated.
You can get clearing effect by applying overflow:hidden to the container. If container doesn't have fixed height, it will stretch to size of content anyway. It's not a hack, but specified behavior that works in all browsers.
And when you really need overflow:visible you can still clear without extra element in the markup:
.container::after {
content:""; /* not "."! */
display:block;
clear:both;
}
and that's perfectly standard CSS 2.1. In IE versions that don't support CSS 2.1, hasLayout happens to have desired effect:
.container {
zoom:1;
}
Yours is the right approach. Rules are created for those who do not understand them. If you know all pros and contras, make your own call.
You are particularly justified in this case. CSS decided to ignore common wish to separate content A from content B horizontally, so you have to choose a hack you dislike least. I compare the three solutions already presented here.
Your solution is bad because it changed content of the document, inserting element C whose only purpose is visual separation between A and B. Content should not serve layout purpose.
Karpie’s solution is slightly worse (in my book) because it does the same in a sly way. Pseudo element ":after" was not designed for that. It has a great advantage, however, of never actually changing the HTML.
PorneL’s solution achieves desired separation between A and B by radical change of properties of A. The change will not only separate A from B, but also separate A from preceding content, change the way width of A is calculated and so on. Of course, sometimes it’s perfectly OK, but you have to be aware of those unexpected side effects.
The choice is ours.
I definitely don't agree with the idea of using extra markup just to clear divs.
I favour the 'group' approach - putting class="group" on the parent div, with the following CSS:
/* Clear groups of floats by putting class="group" on their parent */
.group:after
{
content: ".";
display: block;
height: 0;
clear: both;
visibility: hidden;
}
And in an IE-specific stylesheet for IE6/7:
/* IE7 */
.group
{
min-height: 1px;
}
/* IE6 */
* html .group
{
height: 1%;
}
This was detailed in CSS Mastery, by Andy Budd. It stretches semantics a little bit, but it makes sense - you're grouping together floated divs, which obviously have some relation to each other.
edit: I wouldn't consider this a huge hack or workaround either - the method has been around for years in various incarnations, (usually known as the 'clearfix' method), and I don't see it going away anytime soon.
I stumbled upon this article
http://www.thefloatingfrog.co.uk/css/my-hatred-of-br-clearall/
When would one need to use that ?
Why is it evil ?
I don't understand the substitute syntax can you explain ?
Setting clear to both with not allow other elements to float on either the left or right side of the element. The class below is an easy way to add this anywhere.
.clear {
clear:both;
}
So when you want to clear something (that is, if you were to float the next element to the left, it would be below the current element and to the left, instead of left of it) you'd simply add the .clear class.
The problem with the following code is that if later on you decide that you don't want to clear everything after the 'something' class, then you have to go through your HTML and remove the br clear="all" wherever you have that 'something' class.
<div class="something">Cool content.</div>
<br clear="all">
<div class="other">Cool content again.</div>
Instead you could do something like this:
.something {
float: left;
}
.other {
clear :both;
float: left;
}
<div class="something">Hi!</div>
<div class="other">Hi again from below!</div>
That way if later on you decide to float all blocks with the 'other' class then you can just remove the 'clear:both;' from the CSS once.
I was about to post something snarky about you not reading the article, but when I saw that it was just a page of vitriolic rage with no explanation, I figured I'd answer.
It's because there are better ways of doing what you want to do -- namely, by using CSS in the way he does in the article, he has separated the semantics of the elements he's displaying from how he's displaying them. Why is this a big deal? Well, for one, he can more easily transform how his page looks when it's shown on different platforms (mobile, desktop) and media (screen, print, a screen reader for the blind), simply by editing CSS and not having to touch the document itself. This feature of CSS is pure gold.
On the other hand, if you use a construct such as this, you put in a hard constraint about your document's presentation that sticks around no matter what media or platform you're dealing with. What makes him so mad? Because once a developer has come in before him and used <br clear="all">, he has to take it out in order to get the benefits I just mentioned. That's why it's so frustrating. One bad developer can disable a whole host of development scenarios for every other developer who comes after.
As far as CSS goes, I have to say that it's a very difficult subject to just pick up without reading all about how it works. It's hard to explain how the clear attribute works if you don't understand floats. I had quite a hard time myself until I bought a great book on the subject.
When you have floated elements, the parent element can't calculate it's dimensions effectively and sizes incorrectly. Other items that follow floated items may also sit out of position. By clearing an element at the end of your floats, you correct alter this behaviour.
EDIT
Actually correct is probably the wrong word to use as this is what is supposed to happen and using the word correct suggests it is broken.
The author is just going off on a crazy rant about how the same thing can be accomplished using CSS on the DIV elements themselves. He's saying that br class="clear" is unnecessary.
It's also not a good practice because it mixes content with presentation. If a web designer wanted to re-theme the web application, he or she would need to modify the HTML to pull out all of the br clear elements, whereas if this was done as the author suggested, then the CSS files could be swapped out independently of the HTML, making their jobs easier and giving them one less thing to rant and rave about.
The rant is of course justified, as these simple, silly lines of code can actually cause a lot of headaches.
The idea is that your markup describes the information, and the CSS formats that information.
A dummy tag to clear floats isnt semantic, as it's only purpose is for layout reasons. There are other semantic ways of clearing floats that keep this separation. As commented below but here for clarity this is a good resource for semantically clearing floats http://css-tricks.com/the-how-and-why-of-clearing-floats/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
In every design tool or art principle I've heard of, relationships are a central theme. By relationships I mean the thing you can do in Adobe Illustrator to specify that the height of one shape is equal to half the height of another. You cannot express this information in CSS. CSS hard-codes all values. Using a language like LESS that allows variables and arithmetic you can get closer to relationships but it's still a CSS variant.
This inability in my mind is the biggest problem with CSS. CSS is supposed to be a language that describes the visual component of a Web page but it ignores relationships and contraints, ideas that are at the core of art.
How possible is it to imagine a new Web design language that can express relationships and contraints that can be implemented in JavaScript using the current CSS properties?
Are you looking for something like CSS Scripting Layout Specification or Constraint Cascading Style Sheets for the Web? Both are still in the research/prototype stage though.
The CSS Scripting Layout Specification has been implemented as a Google Chrome plugin, it seems.
If you set the size attributes using a percentage, and place the element as a child of the one you're sizing, you will be able to size an element relatively to another. Then, use positioning to move the child outside the parent physically.
There was also a JavaScript Style Sheets spec from Netscape back in 1996, http://en.wikipedia.org/wiki/JavaScript_Style_Sheets.
The CSS Scripting Layout Specification is not a Chrome plugin. What is provided is a proof of concept. Many people are not convinced that JavaScript can perform well enough for CSS layout due to Microsoft's CSS Expressions implementation that had severe performance issues.
It is limited to layout as this seems to be the biggest complaint with CSS. It's aim is to give power users the ability to do nearly anything they want, but at the same time make it such that layouts can be encapsulated, referenced, and reused by novice users.
Directly, this isn't something you can do in pure CSS without causing more trouble than helping due to varying amounts of support from different browsers.
Indirectly,frameworks like Less or by running your CSS through a server-side script before sending it to the client are your best bet but, like you said, not ideal.
In Javascript, using jQuery to set one element's height property based on another's outerHeight is probably the start of a decent solution, but I can't find any code examples people have written to solve your specific problem. I'd imagine it might be something like this, though:
var totalHeight = 1000;
$("#div2").height(totalHeight - $("#div1").outerHeight());
That would set the height of one based on the height + border + padding of the other. In order to be more robust, there's more that needs to go into it than that, but it's the beginning of a solution.
You may want to take a look at Clever CSS, a pythonic approach to writing CSS. It includes variables, arithmetic, you can even do operations on colors.
I'm also looking after one such approach to writing styles, something that is a higher level over CSS. But one of the big problems, I believe, will be the fact that CSS style sheets are often written by designers and not programmers, using design tools that probably allow them to work at a higher level and generate the CSS afterwards. What for us programmers could be a good flexible approach may not work because it is too geekish for designers.
Use of percentages to determine the height is to express a relationship with a hard-coded value.
"if you set the size attributes using a percentage, and place the element as a child of the one you're sizing, you will be able to size an element relatively to another" BUT ONLY IF parent elements heights are expressed explicitly (and this apply iterating until the html element).
In CSS Level 2 "The percentage is calculated with respect to the height of the generated box's containing block. If the height of the containing block is not specified explicitly (i.e., it depends on content height), the value is interpreted like 'auto'".
But from Revision 1 "percentage heights on absolutely-positioned elements are no longer treated as 'auto' when the containing block's height is not explicitly specified."
With absolute positioning this solution breaks because "For absolutely positioned elements whose containing block is based on a block-level element, the percentage is calculated with respect to the height of the padding box of that element. This is a change from CSS1, where the percentage was always calculated with respect to the content box of the parent element."
In the following code the inner wrapper divs heights will collaps using absolute positioning, losing the ability to use them to place margins.
<body>
<style type="text/css">
html, body {
height: 100%;
}
div#wrapper {
height: 100%;
}
div#content-wrap {
height: auto;
}
div#wrapper-upper-half {
height: 50%;
background-color:aqua;
}
div#wrapper-lower-half {
height: 50%;
background-color:fuchsia;
}
</style>
<div id="wrapper">
<div id="wrapper-upper-half">
</div>
<div id="content">
</div>
<div id="wrapper-lower-half">
</div>
</div>
</body>