I'm designing a new internal web app that has to support IE11 (as well as Chrome and Firefox). I love doing layouts in Grid, but having to figure out how to make any but the simplest work in IE11 can be a pain. Should I use CSS Grid and ms- prefixes, or avoid the headache and just pass on Grid for this one?
In short, it highly depends on how your application looks like. This article describes the problems you might face quite well - and I fully agree with the summary:
If you are using Grid in a very simple way, and positioning items
rather than using auto-placement then the fact that grid exists in
Internet Explorer from version 10 could turn out very useful. You
could certainly use this in order to create a simpler layout for IE10
and up, once Grid is shipped in other browsers.
However be aware that this is going to require some additional testing
and work, you are unlikely to be able to simply rely on Autoprefixer
to run and do the work for you. For example, if you have used auto
placement for any item and then don’t set a position using the -ms
properties, that item is going to stack up with any other unpositioned
items in the first grid cell.
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.
I read on two different websites (CSS Tricks and MDN) that Flexbox should not be used for large scale layouts. Why would this be seeing that it is being implemented in Bootstrap V4 as a grid system, as well as other Flexbox libraries?
I suspect it is mostly because that is the intended purpose of Flexbox and Grid Layout. As mentioned in the link:
Grid layout doesn’t have content structure, therefore enabling a wide variety of layouts not possible in tables. For example, a grid container's child elements could position themselves so they actually overlap and layer, similar to CSS positioned elements.
Also Flexbox and Grid Layout are both at the Candidate Recommendation stage. The other thing you should remember is that Bootstrap V4 is still in alpha.
A long time ago (4 years to be exact) in a galaxy far(on W3C Standards), far away.... Flexbox was an Candidate Recommendation stage for the first time:P
Browser was supporting it, even IE tried. Front-ends use it to build website and apps with it and nobody cared that it was only Candidate. Candidate always was changing in to proposals and in the end recommendations. Rarely some minor changes was made on that stage.
Then we discover that idea of flexbox was awesome but what we had on the table was pretty much no what we wanted. It was clumsy, not usfull and just wrong.
Huge decision made was. Flexbox get back to Working Draft.
That why, 4 years later everyone is afraid that it will happen again.
https://css-tricks.com/old-flexbox-and-new-flexbox/
https://css-tricks.com/using-flexbox/
The major issue with flexbox is how it loads.
When the server stream content to the browser, it can progressively render it, and when the first item loads, it adjust it to the available space, and then, when the second item loads, it re-adjust, hence both being less performant and cause misalignment and element shifting.
So I recommend to use it where it is needed, not as a replacement of a well structured markup, since that is what a good and well behaved web site should have.
Here is one of many resources, shedding some light on this (and a recording that shows how it loads in comparison with a grid):
https://jakearchibald.com/2014/dont-use-flexbox-for-page-layout/
I made this answer a wiki, so feel free to contribute with both pro's and con's on whether to use flexbox as an overall layout solution
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'm working on a site that uses images diagonally aligned. The images are fairly simple and have some text inside so I can achieve the effect using either images or the CSS3 transform: rotate and border-radius properties, granted, with all the proprietary extensions.
However I'm wondering if there are significant advantages for using one over the other. I'm thinking maybe the CSS-only alternative would load faster, but a downside would be the use of more code for each image. Although using images I'd still have to do a lot of positioning for each element. Also, the CSS in the first case would not validate using browser-specific extensions, how important is this if I still make sure the site is correctly displayed in most browsers?
Is there a general approach for using either one of these options? What would you recommend?
The use of CSS3, versus images, is best answered by your need to support Internet Explorer (or other older, or CSS3-unaware, browsers): if a large portion of your user-base browses with IE then you should use images.
If you're only interested in the later, more standards-compliant, browsers (possibly including IE9, but I've no experience with it as yet) then CSS 3 is likely the better option, since it might involve a larger CSS file, but it does allow you to switch your layout more easily in future, without having to create/recreate a new set of images for the new design.
You could, of course, combine both approaches: use CSS 3 for the compliant browsers, but include an IE-specific stylesheet, with conditional comments, to supply the images as, perhaps, background-images to build up the design. This is, of course, likely to be a lot of work, though.
I would honestly recommend an image for this. CSS3 is cool, but browsers that don't support it might break your layout. Also (possibly more importantly), text really needs proper anti-aliasing to be readable when rotated or scaled, and you can get finer control over that with an image.
Two things I think you should consider here:
Images are a killer for those on mobile devices. So if you are targeting those with mobile or expect a large mobile audience, you may want to reconsider using a lot of images (and having your users pay a ton in bandwidth).
The text in your images (if you use images) will not be searchable by search engines and will not be accessible for those with accessibility issues, unless you are good at filling in your alt tags. ;-)
I've been reading a lot of ways recently of how to avoid having to use Photoshop for things like gradients and shadows on buttons, when you can use CSS3 Box Shadow for such features. Now this is great, but obviously legacy browsers and most IE browsers don't yet implement CSS3 features, so my question is, why save yourself extra work in Photoshop when you can use CSS3 but then HAVE to use Photoshop for other browsers to see the desired effects? Isn't that just extra work?
you can use CSS3 but then HAVE to use Photoshop for other browsers to see the desired effects?
Often you don't really care whether the other browsers see the desired effects. If it's just a subtle background gradient effect, the site's going to work fine and still look reasonable with a flat background in downlevel browsers.
Compatibility was more of a problem when CSS 2 Positioning was at this stage: an unsupported positioning feature could lead to an unusable layout. But for essentially frivolous effects like backgrounds, borders and shadows, it's not critical if the effect goes missing.
There are a few reasons. From a developer/designers perspective, using CSS3 can be more flexible. An image is more or less just a static image. With CSS you can use script or CSS to animate or adjust the styling, and have advanced integration between the various technologies. This allows you to be able to do some things that are not possible or difficult just using images.
The page weight is also lower usually when using CSS, which allows the page to load faster, especially on slow connections or mobile devices. It also reduces HTTP requests (although you can use data uris too) which reduces latency and thus speeds up page loading.
Using CSS is often more maintainable and quicker, as you can adjust say a background colour or a shadow quickly just by changing the CSS, while with images you have to open up photoshop, edit the file, resave, etc. This is fantastic for quick tweaks.
There are also some people (myself included) that are much more comfortable in code than they are using graphics packages. For me it is easier to use CSS, but your milage may vary.
Also from the browser perspective we want to move the web platform forward and increase the capabilities. SVG is an example of another technology that doesn't work across all browser versions yet, but adds a lot of power. Although it may not be possible to deploy sites using certain CSS3 properties or SVG without fallbacks right now (depending on your audience or client) there will be a time in the future when old browsers are dead and what we are adding today works for all users. There was a time when most of CSS2.1 wasn't supported for example, while now you can rely on most of it if you don't need to design for IE6.
There are some parts of CSS3 that you can happily use without fallbacks, if you have a client that doesn't require all browsers to look the same. border-radius is an example, or giving a solid colour fallback to old browsers and applying transparency for newer browsers.
The world is moving forward, you can't ignore it. as long as old browser will show a button and new browser will show a more nice one, you are ok.
Otherwise, we were still be working on VT100... as why using "Windows" if most monitors doesn't support more than 4 color graphics and has 80X22 resolution....
If your bosses accepts the idea of having two versions of looks and feel and a warning. CSS3 is a good idea.
So, you use CSS3 features in your code and forget about the browsers that are not compatible -- they will see the "low-graphics version", you might want to issue a non-intrusive warning (like the one we get as alerts in StackOverflow), saying, "Your browser is not compatible with CSS3. To see this website in high graphics please upgrade your browser. Click the link here to update now."
But, depends on where you work. Big companies with lot of resources may like to stick with Photoshop and smaller once may like a light-weight CSS3 code that degrades silently in non-compatible browser.
Well you can always use ChromeFrame, to impose nice behavior on IE. Assuming that a lot of products will insist for it the near future (yeah we can argue against this), chances are that most IE users will have chromeFrame even before your application would insist for it. Once you take a decision on this, decision on using CSS3 properties or HTML5 elements is - well - hell yeah!!
Marvin