CSS rule doesn't show up in developer tools - css

One of my CSS rules does not show up at all in developer tools in ie8 (it works fine in normal browsers). Not even with strikethrough.
I checked the CSS file through the browser and the rule is really there
What could be going on here and how to fix this?
Why don't I drop support for ie8 altogether?
Just for those who wonder:
I recently worked for the Dutch government and they're still on Windows XP. They recently paid Microsoft for prolonging support by another year or so. They have their computers locked against installing anything (Firefox, Google Chrome) so they basically force employees to use ie8.
As we speak, some 6% of all visits to my site are by ie8. My guess is that many of those are involuntarily on ie8. Dropping support will bother them but really won't help them to upgrade to a proper browser.

IE8 might be having trouble parsing url(...)no-repeat with no whitespace separating the two values. See if adding a space there fixes the problem.
It's not clear from any spec if not having whitespace there is valid CSS; although the Jigsaw W3C CSS validator says it's valid, I don't really trust it. It's probably valid since url(...) and no-repeat are necessarily two separate tokens according to the grammar, but again, the spec does not spell this out very clearly in prose, so I can't say for sure.
I would strongly recommend having whitespace separating the shorthand values in any case.

Related

Is it worth specifying certain properties for IE, or just any other older versions? [Backwards Compatible]

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.

Internet Explorer compatibly stylesheet for WebKit?

I am working on a WebKit based browser, but things don't render properly on a IE - only site. Does anyone know of a stylesheet I can inject into these pages to make WebKit render like IE6? Kind of like an anti ie7-js.
I know the proper solution is to make the site standards compliant, but it's not under my control.
Thanks
A good start would be to implement IE's Quirks Mode if no !DOCTYPE is specified. Aside from that you can also support the X-UA-Compatible header to see if the site is designed for a particular version of IE.
Aside from that, there isn't much you can do. It's up to the website owners to decide "hey, we actually want users to be able to use our site" and actually make it standards-compliant.
There are three main things that make IE6 render so differently:
Bugs
Missing features
Quirks mode
You will never be able to (nor should you want to) try to replicate IE6's bugs in newer browsers. IE6's bugs are legendary. You probably have hacks and work-arounds to deal with them anyway, but be glad that you're moving on and away from them.
IE's missing features shouldn't be a problem for you, because your code just won't be using them. Nothing to worry about. Obviously, it would be a problem the other way if you'd written a site for a newer browser, but not for you.
The main point of those three you want to worry about is the third one: Quirks mode is the one that really mangles page rendering in older versions of IE compared with other browsers.
The correct solution to this is to use a valid <!DOCTYPE> at the top of your page. IE will go into standards mode, and will render the same as all other browsers. If your page is designed for quirks mode, then you may have to fix it, but this is probably the right thing to do anyway, and at least the rendering mode will then be consistent between all browsers.
A good doctype to use is !<DOCTYPE html>.
If you don't specify a doctype, then you will have a lot of compatibility problems going forward.
There is one quick way out: There's a CSS feature called box-sizing: border-box. If you set this CSS property in your site, then Webkit and other browsers will switch to rendering the boxes the same as IE's quirks mode.
This sounds like an ideal solution and a direct answer to your question, so what's the catch? As always, the catch is IE. Trying to use box-sizing CSS without fixing the <!DOCTYPE> issue will still leave you with areas of incompatibility, and if you do fix the <!DOCTYPE>, then IE6 won't render in quirks mode at all. It ought to be the solution, but in fact, box-sizing will still leave you with problems to fix.
So I'll say again that the correct solution is to add a <!DOCTYPE>, fix your site and move forward, not try to pull other browsers backward.

Which browser we should use to see HTML CSS rendering while making a site and why?

Firefox's Latest version
IE7
IE6
IE 8
Which browser we should use to see HTML css rendering for always and why?
Edit:
My question is not on which browsers should i test site before go live. i will try to test on all possible.
My question is which browser should i choose during layout development process and why?
because while development it's not possible to see every step in all browser it will waste time. after making a layout we can test in all but during development one browser would be better.
Uhh... every one of them?
I personally develop with Firefox 3.6 for convenience and the availability of Firebug, header sniffers and other tools. I try to test in all the browsers you mention before anything goes out for anybody to see (a client for example). But I don't think there is a real "best" choice here because in the end, you will need to test for every browser you need to support anyway.
Use the most up-to-date css compliant browser with a good debugging tool e.g. Firefox 3.6 and the Firebug plug-in.
Then check in the other browsers you want to support for your users and backwards correct any errors.
Do not attempt to make the site look EXACTLY the same in all browsers, you will be wasting your time.
As long as the effect is similar in older/other browsers (for example you could use border-radius for Firefox/WebKit browsers and this will degrade nicely for browsers that don't support border-radius) and the site is usable and fulfills it's purpose, then your ok
DONT WASTE TONS OF TIME ON IE6. Use a conditional commented stylesheet and just get it usable...
In the head of the document
<!--[if IE 6]>
<link rel="stylesheet" type="text/css" href="IE6.css"/>
<![endif]-->
It all depends on your target user group.
If you're working for customer that uses IE6, you will have to test for it. Sad, I know.
If you're designing a site for general public, then test for current versions of major browsers. Firefox, IE, Opera, Safari and Chrome(?).
Also: develop according to standards then fix whatever does not work in one browser or another. Not that you develop for IE, then trying to fix everything that suddenly falls apart on all other browsers.
During developing NOT testing I use this combo :
firefox
firebug extension
webdeveloper extension
live http headers extension
Give it a try, you won't regret it, you can make changes to your css IN BROWSER and then change your code (No more refresh needed for that one annoying one pixel offset), check to see where is the fault interface or code logic and plenty more.(Page Speed & YSlow to analize your page speed etc.)
I whole-heartedly agree with Pekka.
I develop everything within Firefox and use the excellent addons available during development (Firebug / Web Developer Toolbar / etc).
A suggestion would be to test often in other browsers as well....I would recommend every time you go to take a little break check it out in the other browsers to see if there are any issues, and then make a note to fix them and allow your website to be rendered properly in all browsers.
You really don't want to exclude any user based on his/her browser preference, so make sure
it works across the board!
edit
Also a good point from one of the other users...IE6 is in the process of being phased out, however if you are looking to have any users in a corporate environment you don't want to exclude testing this either!
You need to test your css in all the major browsers, that includes IE (6, 7 and 8), Firefox, Chrome and even Safari and Opera.
You can probably get away with just using the latest versions of Firefox, Chrome etc. as they auto-update and so users are less likely to be using older version (though it's not unknown).
IE is a problem because so many users - particularly corporate users - are running older versions.
Choose one, it doesn't really matter which as long as it has good development tool support, to develop in and get the site looking good in that. Then test in the others. Which order you do this and how much effort you want to expend will depend totally on your target audience. From my experience Firefox with Firebug and even (dare I say it) IE8 with it's built in developer tools are good choices. The advantage here is that you'll cover the majority of users with these. However as the browser market is getting more fragmented you will need to test in others.
This is an interesting question, I'm going to assume that you have a process that means that first you develop your page and then you do cross browser testing to make sure it works everywhere - so the question then becomes which one is going to get you to the best starting point for getting to working "everywhere" (definition of which will depend somewhat on your target audience).
This used to be easy - according to my (then) staff Firefox had good standards support and the best tools - so get it right in firefox first then adapt to cope with everything else, now its a lot less clear as IE8 has a very decent set of dev tools (and is better behaved than its predecessors) and Chrome is now getting into the act - again with a good set of tools and extensions.
My gut feeling is probably Firefox, Chrome, IE8 in that order - but I'm not doing anywhere near enough CSS work to assert that that's right.
You develop in Firefox (you have firebug to adjust things), you test in safari/chrome & opera (all of them is ok with standards so you have low chances to have bugs in those) and you debug in IE. Because is impossible to have a fully functional in ALL browser from one try :D
I use my main browser (Chrome) for basic progress, and frequently check all other browsers for bugs and layout problems.
I think If we choose firefox and IE 6.0 both for website design, the site will be look almost same for all browsers, because rest of IE 6 & 7 all browsers' HTML rendering pattern is almost same. So If we make css from start considering firefox and IE 6.0, bugs would be in less numbers and In this way we can make all browser compatible website.
Please give me feedback
I do it in ie6, the most primitive browser which is still in use.
I think any thing that will work on ie6 will work on any browser.

What are the main differences between browsers which web developers should be noted?

While making CSS for the website it is painful when sometimes it works on some browsers and some don't.
I wonder if there any place I can find the existing problem which has been noted with experience developers. So I can have a list of noted problem while developing.
What are the tricks?
Where Can I find it ?
How to solve it if possible?
The most problematic browser is Internet Explorer (especially 6 and below, 7 is not so bad, and 8 is a huge step in the right direction).
Even if IE holds the majority of the market, develop for a standard compliant browser such as Firefox or Webkit (Chrome and Safari) using an XHTML doctype, then fix the discrepancies on IE at a later stage. That way you will achieve the maximum compatibility with little or no efforts (if it works in the Gecko or Webkit engine, you are pretty close to being guaranteed that it will work for most browsers [except IE, but in most cases you'll be very close to perfect]).
Most of the problems you'll run into with IE are well documented on the Internet and are rather easy to fix if your page is standard compliant.
If you develop for IE first (especially IE6) then try to make your page work with the rest of the browsers, that will be problematic as your changes will probably end up breaking IE rendering.
Also, an other thing that is important to note is that font availability and rendering is different from platform to platform. Verdana on Windows may not be smoothed the same than on a Mac, and the font might not even be present on *nix.
QuirksMode has a comprehensive list of features supported on a given browser:
Compatibility Master Table (quirksmode.org)
Personally, my biggest peeve with IE6 is its poor support for PNG-24's with transparency. It requires a filter to somewhat support it.

Are good CSS design and IE6 / IE7 support mutually exclusive?

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.

Resources