I am new to HTML5 and CSS3. I was just seeing some CSS3 code which is as below:
.box
{
border-top-left-radius:5px;
-webkit-border-bottom-left-radius:5px;
-moz-border-top-left-radius:5px;
border:1px solid #8e8e8e;
background-color:white;
height:16px;
padding:4px;
padding-left:28px;
padding-right:10px;
color:#4a4a4a;
float:left;
}
I couldn't get why after border-top-left-radius border radius is mentioned with -moz and -webkit prefixes? Is syntax for different browsers different? Is it now being standardized?
Yes, the syntax can be different with experimental properties. This is entirely up to a vendor to decide, because a vendor-prefixed property is considered proprietary and not part of the standard.
In particular, Mozilla called it -moz-border-radius-topleft, not -moz-border-top-left-radius. The code you're looking at is mistaken (possibly a result of blind copying and pasting of declarations).
It has since been standardized to border-top-left-radius. The prefixed properties are only there to support older versions of browsers. For that matter, the unprefixed property should come last in order to ensure a browser's best/most stable implementation of a property.
To clarify what BoltClock said: The browser creators Microsoft, Google, Mozilla and such decide which parts of HTML and css to implement in their browsers. Most of the companies want people to use their brand of browser, because this means they can give a better experiance or direct you to their own propriety sites, Thus extra features such as new CSS-tags or other useful developer tools has been developed trying to get an edge on other browser-vendors.
This has been going on for a long time ever since the first browser was launched in the 1990:s. Netscape provided their own features and Microsoft came late into the game and had a hard time getting up to speed. In those times it was not certain that browsers would be free and so much effort went into making the best browser, and different features arose. Later when W3C came into the picture and started the work of standardizing the web vendors slowly but surely started to adhere to standards. That work is still in process and will most likely need to continue for quite some time.
There is a brilliant course on coursera that touches this subject. Check it out!
Related
I've been using -webkit and -moz for quite a few times now until this struck me. Aside from defining specific properties based on browsers and certain properties such as break-inside which are not widely supported,
Wouldn't
border-radius: 5px;
makes it shorter for
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px;
There are lots of other features which have been standardized but several examples still utilize the vendor prefixes and what are their purposes for doing so?
The former is supported by latest browsers but can we not assume almost everybody is using almost-latest browsers (especially NOT older versions of IE which certain rules apply)? (Even if people do not update their browsers, they are only left behind by just a few versions considering no one takes out a Nokia-old phone from a chest and started browsing)
Why should we use them? Why should we specify older IE specific rules or just older browser rules?
How much diving into older version would be enough? IE8?
Here are my thoughts - before going into detail I have to say that I am a freak when it comes to browser support.
Up until a couple of years back I was trying to support from IE8 and upwards. The reason behind this logic was that people where "trapped" with Windows XP and IE8 was the latest version supported by Windows XP. By trapped I mean that they were cases like government pcs that were too costly to upgrade.
After Windows 7 has matured enough and Windows XP usage dropped, I tried to support IE9 and upwards. This essentially meant that even after useful properties came out (like flexbox) it took me a long time to migrate - so I was building layouts with tables for best browser support, etc.
However, Javascript Frameworks started dropping support for older browsers (including IE9), then CSS frameworks started dropping support. If you consider it for a while, MS itself has dropped support quite some time back. Major mobile companies drop support for their 2-year devices, so why should we support older browsers? As stated in in other answers, it depends on the audience - imagine the CEO of your best client-company having a laptop with Windows XP or other outdated device - wouldn't matter if anyone else used modern browsers..
So, it came down to a point a couple of years back that you have to select between following the stream and being modern or supporting older devices. I am all up for consistency and uniformity of content, so supporting modern features for a few select browsers and dropping them for others would be a no go for me. Flexbox was one of those properties that pushed me to skip older browser support - it vastly helped me reduced markup - thus making maintenance easier. At the same time, even Bootstrap decided to drop support for older browsers, so, must upgrade to keep pace with the competition.
Needless to say, the problem isn't just IE, but was also Android which took up to v4.4 in order for the stock browser to support specific properties - vh, flexbox wrapping, etc
These said, let me give you a straight answer:
Don't bother with support for IE9 - not even 10. IE10 could be upgraded to 11 on the same OS, so it should be upgraded anyway for security reasons. IE9 is not supported by JS frameworks (eg Ember), lacks CSS3 transitions and other useful properties, like flexbox. Without these your designs would have to take many steps back if you were aiming for design consistency.
As a sidenote IE10 started supporting their own interpretation of flexbox (sorry about all this persistence with flexbox, but it's one of the most useful properties). This means, that in order to support it properly, you would have to write a lot of CSS. Imagine adding 30kb of minified CSS to support just one browser that is fairly uncommon. Is it worth it?
Some webkit browsers (like Opera) might still require vendor-specific prefixes for browser versions released 4 years ago -eg for CSS3 transforms. Tbh more important things are broken on such browsers (Opera included) that I would worry about other stuff more. Personally I only use the -webkit- prefix in select cases (eg flexbox properties that have matured quite lately).
There might be some cases where browser-specific prefixes might come handy even in modern browsers, eg styling a range input or a scrollbar where you have to mess with browser-specific properties to achieve consistency. In such cases specific CSS hacks with vendor prefixes might be required.
As a final note, I would avoid any bleeding-edge properties, eg grid; learn what it does and how it works, but don't use it just yet. You should give a look at https://caniuse.com/ in order to have an idea about CSS properties and browser support.
However, it is up to you to decide and you should make your selection based on the requirements of your project. Two years back I would tell you to support as old as you can... back then you would be able to achieve the same things with different effort, but this is not the case any more. From a point onwards... older browsers can't keep pace.
Well... This is a really big topic so its hard to answer all of it but there are best practices that you should/could follow.
First - Everything is based on YOUR SPECIFIC Audience. Look at your analytics and see what browsers are being used. The data might surprise you especially if you have US Health care or government users. Tools like Stylelint will help you find unsupported rules in your CSS.
Next, It's best practice to utilize feature detection instead of targeting specific browsers. You can implement that by using #supports in conditional code that works like a media query. This way your code is only being applied if the browser can use it. You can do similar detection in javascript using Modernizr.
Finally, I personally recommend using a CSS post processor or build script so you can stop worrying about prefixing (plus it will speed up your development with optional plugins). I tend to like a combo of PostCSS and Prefixfree (several Webpack customizations come with those included) but there are many similar options.
The main benefit is that the library tracks what needs prefixes and what doesn't so you write the non-prefixed version and the rest is taken care of.
There are no hard and fast rules but you should try to support your users' devices instead of pushing for upgrades. The nice thing about the above practices is that your resulting code will be easier to maintain, future proof and targeted to your users.
You should not worry about browsers older than IE 8. These browsers are barely used anymore and they do not support a lot of things. Please, refer to these to websites:
https://imagebox.com/industry/why-your-website-doesnt-look-the-same-in-every-browser/
http://dowebsitesneedtolookexactlythesameineverybrowser.com/.
In terms of the various border-radius commands, make sure to use them all. I've found that if you don't include webkit and mozilla, you lose a lot of traffic. In my website, I usually include every variation of a command so I know for sure my website works. Better to have a large and ugly CSS code than a broken website.
Feel free to comment on this answer if you need more clarification.
Here's an example style supported by most browsers:
.class {
background: rgba(0,0,0,0.3);
}
Old IE (IE 6-8) don't support rgba. There are at least three methods I could potentially use to support this.
Same class
.class {
background: grey;
background: rgba(0,0,0,0.3);
}
Modernizr
.class {
background: rgba(0,0,0,0.3);
}
.no-rgba .class {
background: grey;
}
star hacks
.class {
background: rgba(0,0,0,0.3);
background: grey\9; /*IE8 and below*/
}
I prefer to use methods 1 and 2 because they cover more than just IE browsers, but I'm not sure which method I should use.
Method 1 is good because it works even if JS is disabled. However, there's an extra attribute to render for all modern browsers.
Method 2 is good because it segregates the bad browsers into their own classes. Modern browsers won't render this class which saves milliseconds of rendering time.
Maybe there's something else I'm not thinking of that could be better? I'd like to avoid using PIE.htc or filters. What is the best method for optimization and load time?
For this kind of style, the correct answer is the first one you listed:
.class {
background: grey;
background: rgba(0,0,0,0.3);
}
Specify the fall-back options first, followed by the preferred option.
IE will set the background to grey because it doesn't support rgba; other browsers will use the rgba version as intended.
The reasons this is the best answer are:
It is the canonical "correct" answer for this exact scenario: CSS was designed to work this way, with exactly this kind of situation in mind.
It is the least expensive option, because no browser has to do any extra rendering or scripting. IE will completely ignore the second background, so nothing extra happens there; other browsers will parse both, but parsing the second will overwrite what has been parsed for the first, so the only overhead is the parsing, which would have to be done anyway for whichever option you pick.
Of the other possible solutions, Modernizr is great, but is overkill for this scenario -- if you have a solution that doesn't involve any scripting, there's no need to use a scripted solution. And the CSS hacks should be avoided at all costs. There may be cases where they are worth using, but I personally haven't seen a legitimate use for one since I stopped trying to support IE6.
The other solution that is available but which you didn't mention is conditional comments: ie use IE's <!--[if IE]> syntax to load an alternative stylesheet for IE. However I would avoid this as well if possible, and again, the need for this kind of solution is fading away as IE6 and IE7 become more distant memories.
Finally, a slightly different option for you: Just ignore old IE. For some things, IE8 may not render things the way you want, and it's a pain to make it do so. In these cases, it is a perfectly legitimate strategy to just let it fail. For the example in the question, this isn't necessary, as we have a perfectly good CSS solution, but for other more complex styles, consider how bad the site will look if IE doesn't get things right; if it's still usable, then there may be a case for simply letting it slide. This option needs to be weighed against the number of users that will be affected and how much of a problem it causes for them, and also the requirements you're working to, but it should be considered as an option.
Your method #1 is the generally accepted way, because not only does it handle IE, but it also handles any browser that doesn't support the CSS in question (in this case, RGBA). The rule for CSS that browsers are supposed to follow is that if they don't recognize a line, they ignore it and move on. As for more capable browsers, CSS such as this is cheap, and the browser may not even render the fallback CSS at all (I know most don't download the image for image-based fallbacks).
Method 2 not only adds classes (which add weight), but adds an entire JavaScript library. If you're dealing with a bunch of other CSS3 type stuff (especially things that don't have such easy fallbacks), then it's not a big deal, but if you're using to handle fallbacks such as these, or just one or two, then you're adding a lot of overhead (including potentially another HTTP request) for not a lot of extra benefit. Even if the modern browsers don't render the classes, they do have to run the JavaScript to check for the capability.
Method 3 is a hack and should be avoided whenever possible (I recommend conditional stylesheets over resorting to hacks). Not only does it target only specific versions of a specific browser (thus leaving all the other browsers that don't support this CSS out in the cold), but relies on bugs in a browser to get the job done. And what happens if that code triggers a different bug in a different browser, or if a browser recognizes the line with the hack, but also behaves properly with the correct CSS? Have a look at some of the tutorials circa 2005, when IE6 and IE5 for Mac were still major contenders, and see the crazy lengths people went to with browser hacks to keep them from stepping on each others' toes. (Note: I do not consider prefixed CSS to be hacks. Prefixed CSS items are documented functionality that the browser vendors chose to add and serve the stated purpose of sandboxing those features. If they are for things that make it into the standard, then they are designed to be phased out over time.)
So, in order of preference - Fallback CSS, Modernizr, Conditional Stylesheets, Browser Hacks.
I have a website that I've developed and tested using Firefox 9 exclusively. I'm pretty happy with the layout/styles when viewed in this version of Firefox. I'm now facing the unenviable task of making it display equally well (or as close as possible) in IE7+ (I'm not supporting IE6). Naturally, I'd also like it to display well in Chrome & Safari, but I think they implement the standards reasonably well, so I'm not so worried about them.
I'm using JQuery for JavaScript, which hopefully means I don't have too many differences in JavaScript behaviour, so my chief concern is the CSS. I imagine many others have been down this path, so I'm hoping there's a stylesheet available which when (conditionally) included will fix most common CSS problems seen when viewing a website in IE that has only been tested with Firefox. Does such a thing exist?
A catch-all miracle.css file which cures all IE-related ills? If only! The solution will probably boil down to a selection of some or all of the following:
Normalize (http://necolas.github.com/normalize.css/)
Brings most browser default settings to a more consistent baseline (think of this as an alternative to the popular Eric Meyer reset.css)
Modernizr (http://www.modernizr.com)
Seeing as you're already using javascript, including modernizr will give you additional methods of detecting browser capabilities. Also auto-injects .ie7 / .ie8 etc classes into your markup where necessary, allowing you to target IE in your styling, e.g.
.standard { ... }
.ie7 .standard, .ie8 .standard { ... }
CSS3PIE (http://www.css3pie.com/)
Progressive Internet Explorer - allows for styling which typically fails on IE (e.g. linear gradients, radiused corners, etc.)
IE7.JS (http://code.google.com/p/ie7-js/)
Probably the closest to what you were after, as an alternative to CSS fixes (which no doubt will still be necessary). Should help get you closer to the desired end result though.
I don't think there is any sort of stylesheet that does this for you.
You may look into a js script that look at solving IE issues. Or You can always do it the old fashion way using IETab and targeting the areas where you know there is going to be issues.
Most of them are described here: http://net.tutsplus.com/tutorials/html-css-techniques/9-most-common-ie-bugs-and-how-to-fix-them/.
Hope it helps :)
I am new to web design and I have some problems in my website.
First, it is not a cross-browser compatible website. I want to make it so, but I don't know how to do this. I have read some articles about this, but they have not been any help. Please tell me how I can design a cross-browser website.
Second, I have validated my website's CSS file and gotten these errors:
218 .box Property border-radius doesn't exist in CSS level 2.1 but exists in : 6px 6px
219 .box Property -moz-border-radius doesn't exist : 6px 6px
220 .box Property -webkit-border-radius doesn't exist : 6px 6px.
But I don't know how to solve this either.
http://www.harvestcreativemedia.com
border-radius is a CSS3 property, so if you're validating as CSS2, it will report errors.
-moz-border-radius and -webkit-border-radius are "vendor prefixed" versions of the same property. Vendor prefixes are given by the browser makers to features which they have implemented, but which either are not yet standardised or else their implementation of it is not yet complete. Either way, it allows a site designer to use the feature before it is officially ready.
If you're designing a cross-browser site, you need to consider which browsers to include. For example, do you want to take time making it work in very old versions of browsers (which perhaps no-one is using any more)? You need to decide which older versions to support.
This is relevant to border-radius because current versions of Firefox, Chrome and Safari all support border-radius without the vendor prefix. In fact, the vendor prefix hasn't been required for several versions, particularly for the Webkit browsers. So you may be perfectly justified in dropping those prefixed declarations. You need to check which versions of which browsers require them, and decide whether you want to support those browsers.
Another factor to consider is that until very recently, IE did not support border-radius at all, not even with a vendor prefix. IE9 does support it, but most IE users are still running IE8.
If you want border-radius to work for IE, you will need to do some hacks. The best option at the moment for this is CSS3Pie. Your other option is just to ignore it and leave IE users with square corners. Since this won't affect the usability of your site, you may decide this is the easiest option.
All the browsers and browser versions have their own combination of features which they support. A site like CanIUse.com is invaluable for helping you determine whether or not to use any given feature: it shows which browsers and versions support it, allowing you make an informed decision about whether to use it or not.
Finally, the most important piece of advice I can give you for making a site cross-browser: Test it in all browsers, and all browser versions that you want to support. (don't just assume that if it works in one version of a browser it'll work in other versions - you need to test them all).
To fix a website website cross browser the best way is to start it with this in mind and step by step in development to check each browser for any difference and try to find a cross browser solution. You can achieve it with a finished website also but of course it is much more difficult. If you have specific question you can use stackoverflow.com for help in any programming issue you have.
About the errors you get is because you try to validate a css 3 file with css 2.1 standards. Go at http://jigsaw.w3.org/css-validator/#validate_by_uri+with_options and select at profile level 3 css to validate for css 3.
A good thing to look into is jquery rounded corners. it's rather simple and does almost everything that css3 border-radius does. The downside is creating a border,if you want a 1px border you would have to wrap your target div in another div and set the outer to a padding of 1 px.
here is the site: http://plugins.jquery.com/project/corners
download the zip package to view the demo.
This works on all browsers and IE6+, it also adapts correct css properties if they exist for that browser.
Like every web developer, I usually curse the creators of IE6 with foul and untimely deaths at least once a week. Yet my company requires me to keep supporting that most-hated of browsers.
My problem today has been wanting to first use a wildcard in my CSS and then trying to use the "inherit" property instead. Neither of which are supported by IE7-.
I really, REALLY want to have good, well-structured, properly-inheriting CSS (object-oriented CSS, if you like that buzzword) but I have that sinking feeling in the pit of my stomach that sooner or later, it's going to have to be custom-purpose and location-based classes.
This poses the question: given how utterly awful IE is at handling many CSS concepts, is it impossible to adequately support this browser at the same time as having a well-structured CSS document?
Just to clarify: I'm aware that there are plenty of ways (some legitimate, some less so) to get around the bugs and shortcomings found in IE6 and 7. What I'm really asking is "if you want to have a single, well-written stylesheet that inherits correctly, must you choose between that and having a consistent look across all browsers?". Hope that makes sense.
In other words, should I stick to my principles and code a good style sheet or should I accept that IE6 still enjoys a horribly high (20% on last count) market share and bring myself to support it? Or is there some happy medium that allows me to minimise the frankenstein surgery on my HTML and CSS while still achieving some respectable results in IE?
To be fair, you can't blame it all on IE (though Microsoft certainly is by far the worst transgressor). Part of the problem with such large & rapidly-evolving standards is that it's too much of a moving target to be perfectly implemented in a timely fashion. Unfortunately, the release cycles of web browsers do not coincide with the release of new web specifications. So all browser developers can do is try to implement as many features as they can from the latest W3C recommendations, selecting what they think will be the most commonly used features to implement first.
However, things are clearly improving, and it is possible to support IE6/7 and still use proper CSS design. It's just... difficult. Take a look at this comparison of layout engines & CSS support. If you look at the overall trend, you'll see that most browsers (even IE) do tend to comply with established standards in the long-run, it just takes some browsers longer than others to implement a standard after its introduction.
And sometimes it's not that one browser is "less" standards-compliant than another. With new standards the problem is often that different development teams chose to adopt different parts of the new specification. So even though CSS3 is already beginning to be implemented by most browsers, we'll probably have to wait until CSS4 is published before seeing consistent support across all major rendering engines. And if you try to use the latest CSS3 features right now, you'll have a hard time establishing compatibility across all major browsers. But if you're using features introduced in CSS1, it's no problem at all.
Therefore, the only option--aside from using ugly CSS hacks--is to stick with well-established older specifications. Then the problem is no longer trying to conform to web standards while supporting a particular browser. Instead the problem simply becomes trying to resist the urge to use the latest & greatest CSS features.
Aside from that, the only permanent solution I see to this recurring situation is for the W3C to prioritize different parts of newly introduced specifications so that the new features can be implemented in discrete phases synchronized across all the major browsers. So, for instance, grammar rules might be given the highest priority along with a set deadline for its implementation. After that would come the second phase, which could be element & attribute selectors, and so on and so forth.
This would require a tremendous level of cooperation between the W3C and development teams, but it would be worth it. After all, it does users and web developers no good for IE to implement one subset of features from CSS3 while Firefox implements a different subset and the Webkit browsers yet another subset. A "standard" is no good until it's actually standardized across all the major rendering platforms. It's better for each browser to support fewer new features but have them all be the same features, than for them to separately introduce a ton of their own features that aren't universally supported.
Not at all - you can compensate for IE's shortcomings with conditional comments and an IE specific stylesheet, while serving your 'nice' stylesheet to other browsers.
Something else which I find helps is to use a CSS reset. While this isn't going to resolve all of IE's issues, it does give you a good baseline to work from.
The most anoying IE6 feature is it's box model handling. You should stick to margin instead when positioning boxes, and try to use relative font sizes to allow font resizing on IE. The rest of the quirks are well documented.
Using conditional comments is the cleanest way of having both a clean style sheet for well behaving browsers, and still using being beautiful on IE. This is what I use, only needing 1 css file of a few lines to repair my sites look and feel.
The dark path of crossbrowser consistent look & feel are css hacks, but I strongly discourage it's use, specialy now that for some time we'll have to target three different IE (6, 7 & 8)
Normally, if you get the style to work in both FF and Chrome/Safari, IE is only a few corrections away of being correct.
There is a great site Position Is Everything that details how FF, IE and Safari conform to standard CSS. At the site you will find most of the workarounds / cures for IE that will alleviate the need for you to write so much conditional code for your CSS.
You'll also want to check out A List Apart for more on CSS and IE. There are also great articles on tableless layout with CSS, handling the height bug in IE, etc. Good luck - IE 6 really sucks when it comes CSS.
Certainly not. If you ensure that they render the page in "standards" mode as opposed to "quirks" mode many of the common IE CSS issues are resolved. To do this you must provide a valid doctype statement at the top of the page, such as
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
As others have pointed out, another good idea is to start off your stylesheet with a snippet that removes all paddings and margins like so:
*,html {
margin: 0;
padding: 0;
}
Finally, one common problem with CSS based layouts in IE is that clearing of floats doesn't happen when you'd expect. This is to do with a hidden object property in IE called "hasLayout"; only objects that "have layout" will correctly wrap around and enclose floated child objects. It is easy to ensure that your containers "have layout" simply by specifying at least one dimension for them:
height: 1%;
width: 100%;
zoom: 1;
I do not personally use conditional IE stylesheets except for one single thing: to replace PNG backgrounds with GIFs in IE < 7 - there is nothing wrong with using them, I just find it unnescessarily complicates things when you have to define the appearance of the same object in two different places. With the three tips above and a bit of patience you should be able to create CSS based layouts using a single stylesheet that render just as well in IE 6/7 as they do in Mozilla/Webkit.
Happy coding!
IE 6 really does limit what we can do.
It’s the lack of support for advanced selectors (and inherit — IE 7 doesn’t support that either) that gets me. Just having the child selector and attribute selectors would be nice, that’d really cut down the amount of code we have to write and maintain. You can only work around the lack of support for them by duplicating your styles, so you just end up having to code as if they didn’t exist.
Sigh.
Only follow online CSS tutorials that is rendered correctly with IE6 and Chrome (or Webkit). If it looks right in both, it likely looks right in (almost) all browsers.