I've been using those properties, especially display: table-cell, a lot lately. It's well supported in modern browsers and it has a lot of benefits for some grids and for aligning content very easily, without the need of tricky markups. But in the last few days I have seen people talking about this, as it were a bad practice/approach using those attributes, like in this answer.
Pros (that come to my mind right now):
adds no semantics to the HTML-markup
well supported in modern browsers
helpful for aligning content
helpful for grid systems (most likely in combination of aligning content)
Cons
if you just use display: table-cell; the missing parts (row and table) are added automatically
So I don't really get, why it should be bad using those for layout.
I guess this question gets closed (I could understand that), but maybe somebody has a decent answer – even a positive towards their usage.
Quote from the linked answer:
Don't forget that table-cell is not the correct usage. You don't want
images to be trated as table cells, since table cells should only
contain table data. Just raising a caution flag. Stick to the
semantics.
I won't make this long: CSS simply has nothing to do with semantics.
I like to set display and positions as need be, though any large elements I almost always set to position: relative; so I can handle their children much easier.
As for display:table-cell - it's only changing how it's laid out. Instead of coding a full on table, if you just need a neat little 4x4 grid, why NOT use it? It's very simple, very clean, and is a very very simple alternative to coding a big (messy) table.
My advice is that "if it ain't broke, don't fix it". display: only changes the way items are... displayed ~ go figure!
I use as many display:'s as need be, like a menu might be :inline-block; for media queries or :block for full articles, or :table-cell for a nice simple even 2 column bit on a section of a sidebar/article.
one positive: provides table-layout without using table elements. one negative: affects some user agents negatively: http://www.456bereastreet.com/archive/201110/using_displaytable_has_semantic_effects_in_some_screen_readers/ this is one of those "it all depends..." question.
Related
I am new in front end design and when I was looking information about this I found 2 techniques about positioning: float and flexbox.
My question is: What should I use more? I'm oriented in mobile design too.
As this great article sums up:
Floats
Advantages
Most popular way to lay things out; most grid frameworks follow this.
Everyone's aware of float bugs due to the popularity of floating, and there are well documented ways to overcome them.
Disadvantages
Need to be cleared. Can be quite painful if you're changing widths at 2-3 media query breakpoints, because the floats will need to be cleared that many times.
No vertical centering
No equal heights
No source order independence
Use for:
Large layout blocks that don't need equal heights and vertical centering
Flexbox
Advantages
Source order independence. Could be of tremendous value for responsive layouts and eliminates the need for JS for this.
Vertical centering
Equal heights
Flex boxes move along interchangebly the X and Y axis, with such ease, that you can really change things around with a couple of properties.
Boxes grow and shrink, can be columns or rows, fit to the available space however you wish to declare this.
There are multiple ways to do the same thing with flexbox.
Disadvantages
Syntax is initially unintuitive. You spend the first few hours looking at demos saying WOW, followed by WTF.
I've been noticing weird cross browser inconsistencies [...]
A deep understanding of Flexbox takes a while. Once the layout gets more complex, or you add a couple of divs, things can get confusing. I'm going to document this more in an article.
Lots of vendor prefixes, with a different syntax for older IE and Webkit. Use something like Autoprefixr to work around this. Or write some mixins. Or do something..
Doesn't work on IE9. If you don't have to support IE9, you're fine.
Reports of the older syntax impacting performance. I wouldn't care too much about this honestly, especially if you were using JS to do the things Flexbox now can...
Use for
You can already start using it for vertical centering, if you don't need things to look the same on IE9.
If you don't need IE9 support, it's perfect for source order independent layouts, equal heights.
I would highly recommend using it for personal projects.
App layouts where things need to stretch and squish. Flexbox really shines here.
So to recap', flexbox is the modern way, very powerfull but harder to learn. As it is kind of new, there is also a lot of bugs and it is not seemlessly compatible. floats are the old way: it is more basic, but easy to use.
Can anyone please enlighten me on how the new Flexbox layout model is any better than current tables way? (display:table and all those are includedin my case) ?
It's not supported at all under IE10 which isn't very good for the near future, and I just can't see any benefits over table layout. But still, the internet is starting to get full of "worshipers" of this new CSS method of layout, and all the examples I see can be easily done with normal css without problems.
Update 25.12.15:
I have been using flexboxes a lot since they were introduced to modern browsers and had stopped using display:table and so on, because flexboxes are more powerful and easy to use.
There are three distinctions I can think of between using flexbox and using table display values or floats to layout a page:
Being able to re-order elements irrespective of the HTML source order, while keeping elements in the normal flow - you can do this by specifying an integer value with the order property.
It requires less typing than traditional float layouts (you don't need all of the pseudo-elements for clearing purposes) and is more semantic, while using floats or tables for layouts obviously isn't.
The ability for flex-items to grow and shrink to fill horizontal and vertical space based on an ancestor elements' dimensions - by using the flex-grow and flex-shrink properties.
The problem (as you've pointed out) is that support is still pretty bad; In fact Firefox is still implementing an older version of the flexbox module, so you have to account for minor discrepancies in syntax and behavior, depending on which browser you're using. It has been said quite a bit, though, that it is the future for layouts, especially for complex web apps that are popping up more often. It's worth learning if you're okay with making an inevitably wise investment - at the cost of not really being useable right now.
I also suggest you take a look at this smashing magazine article for a friendly introduction to flexbox (it's fairly recently written)
The Flexbox model is more powerful than display table. Flexbox supports layouts for right to left languages for example. And yes indeed, flexbox is a bit complex and that's an entry barrier. Float and clearfix layouts are a (clever) hack, somehow in the same way table layouts are a hack, flexbox is meant for layout.
The browser support is getting better lately, some say we should use it now. Bootstrap 3 does however not make use of flexbox, but i can imagine that the next version will.
Simply put, it's something that'll be beneficial in a few years. Like many advanced css techniques, HTML5, etc., a few people will adopt them with painful fallbacks and shims/shivs for the next couple of years.
When browsers support it in the future, we'll have a party and all hate on the 'old' browsers that don't support them :).
Flexboxes are more flexible and semantically appropriate since tables were never meant to be used for layout. From MDN introduction to Flexbox:
Why Flexbox?
For a long time, the only reliable cross-browser compatible tools available for creating CSS layouts were features like floats and positioning. These work, but in some ways they're also limiting and frustrating.
The following simple layout designs are either difficult or impossible to achieve with such tools in any kind of convenient, flexible way:
Vertically centering a block of content inside its parent.
Making all the children of a container take up an equal amount of the available width/height, regardless of how much width/height is available.
Making all columns in a multiple-column layout adopt the same height even if they contain a different amount of content.
As you'll see in subsequent sections, flexbox makes a lot of layout tasks much easier. Let's dig in!
I have some content set to be in 3 columns, but as it wraps from column to column in Chrome, it adds the margin at the top of the next column, which makes sense in one way, but looks very bad.
Here is an example of what I'm talking about: http://www.sanguinediabetes.com/wp/concept/
How can I style this so there is not an ugly gap at the top of some of the columns, but still space between the paragraphs that end midcolumn?
What you're seeing is arguably the correct behavior for multicolumn elements. The bottom margin you've set on each paragraph will push down subsequent paragraphs, even when there's a column break just before those paragraphs. Yeah, it's arguably weird, but hey, there are even bigger issues with this layout model that need fixing right now.
One way to address your problem would be to remove all paragraph margins and force a column break after certain selected paragraphs. The revised draft of the spec from last year provides for a column-break declaration. But support so far is literally nil, the MDN article on the topic is nonexistent, and chrome doesn't even pretend to support it. Basically, you're in some pretty new territory, and the tools aren't quite there yet.
While I'm here, there are other pressing problems with your layout. To see the most basic one, try sizing the viewport narrow, around 500 pixels. Your columns become painfully thin and unreadable, really just a stack of individual words. Considering that your text says "Mobile phones have helped to popularize the primary concept of interface design: it shouldn’t be the duty of the user to muddle through complex procedures and hidden options to achieve simple tasks, or even complex ones. It is the duty of the software to be designed in such a way that every operation is simple, obvious and fast."? This is kind of funny. Have you tried looking at this on a mobile phone? I would recommend it, considering the content.
Column-count is awesome and all but if you're looking for any real browser compatibility you're much better off with good old floated columns for now. Perhaps try some variation of the one true layout.
I am working on a website frontend and found myself constantly nesting divs for layout purposes. Without using tables for layout it seems like the natural option to layout boxes within boxes. However looking at my completed source code its not unusual to see 3 or 4 layers deep of nested divs...
Is this a problem and should I bother spending time trying to optimize my layout to reduce the amount of divs I am using? Is it bad for search engine indexing (or does it not make any difference at all)?
Edit: I think my confusion arises from the fact that I am ignorant as to how search engines handle divs. What do they look for in divs (are the id's important..should the divs somehow be descriptive of the title...or do the search engines simply parse out the divs)?
I don't think theres any empirical evidence that it is bad for search engines, but its definitively bad practice. It even has its own nickname -> divitis
Generally it arises from ignorance of what one can accomplish through CSS. Of course sometimes with complicated layouts you may need to nest divs and thats ok, you can't have perfectly semantical websites all the time. But I find that no matter how complicated any layout I do is, I've never had to go more than 2 or 3 deep.
Actually the most common nesting you'll see is the whole body container in order to center the layout - this is common because if, for example, you have 3 divs in the root and all three are centered, because of rounding errors they might be a pixel off each other on different window sizes.
Hope this helps.
I don't think it's bad for search indexing, but too many nested DIVs often crops up if you aren't using the CSS box model correctly. For example, if you have two img tags side by side in a containing DIV, you probably don't need div's around the img tags -- you can set the img's to display:block, and they'll behave just like a DIV.
Then again, I don't know what your code really looks like, so I can't say that it smells like anything, really...
It shouldn't bother search engines, and divs are what you might call semantically transparent - they have no meaning in and of themselves. That's why they're suited to defining blocks of content.
It's accepted practice to use divs as hooks for CSS styling and layout, but it's very easy to let the nesting run away from you. If you want to try to reduce the nested divs, see if any of them can be replaced by semantically meaningful tags. Careful attention to inheritance in the document might also help you cut some out by letting you apply specific styling without extra tags.
All that said: it can't be judged without seeing your markup, but if it's even a semi-complex layout then 3 or 4 layers of div might not be remarkable or problematic.
It is certainly no worse for search engine indexing than using tables, however divs themselves are not descriptive. You may want to look at the new HTML5 elements such as <section> <header> <footer> and <article> to more accurately describe what the div is for. These are good for search engine rankings.
One of the arguments I've heard about blueprint css is that it lets you think of your layout in terms of a grid rather than in terms of floats. This seems like a big advantage to me because I always get confused about where my floats are going to end up - sometimes a float will unexpectedly drop down below some other floats and I have a hard time figuring out how to reposition everything. Does this make blueprint css a good choice for me - or should I just put the time in to learn how to use floats properly and do all of my layouts manually?
Yes, absolutely it lets you use a grid - see this example page, which makes the grid visible by striping the background according to the grid columns.
(But I have to say, a little time spent learning how CSS layout really works would pay big dividends - better to understand it than to give up and try to work around it. And you'll then have the option of creating flexible layouts that work well on all sorts of different devices.)
One of the biggest issued with anything that is absolutely positioned is that items that are not absolutely positioned do not know that the absolutely positioned items exist.
Of course this is a debate that will go on forever about which is better but you will probably be better off using elements that can be scaled depending on the browser size and resolution.
Under the hood, Blueprint still uses floats.
Here's a novel approach to creating "float-less" layouts that are semantic and accessble,
http://www.tjkdesign.com/articles/css-layout/no_div_no_float_no_clear_no_hack_no_joke.asp
As stated, BluePrint is a grid system, but is based on CSS floats. So understanding CSS Floats is somewhat important to really grasp what BluePrint does.
I rarely use floats over absolute positioning for a variety of reasons.