CSS Rules for Webkit Based Browsers

CSS rules for webkit based browsers

The problem is that you're overriding your webkit styling with the non-webkit styling.
Reversing the order should fix this:

#mgheader .letters {
  display: inline-block;
  margin-left: 10px;
  position: absolute;
}

@media screen and (-webkit-min-device-pixel-ratio:0) {
  #mgheader .letters {
    display: inline-block;
    margin-left: 55px;
    margin-top: -45px;
    position: absolute;
  }
}  

You may also want to check that your -webkit-min-device-pixel-ratio fires on all webkit-using devices, but it probably does.

For reference, Cascading Style Sheets are read from top to bottom. The key word is Cascading. If one CSS rule is given before an identical CSS rule, the latter one will take precedence. In your example you were styling specifically to webkit browsers but then overriding it with the general styling rules. Reversing the order means that the webkit styling here will override the general styling (without affecting non-webkit browsers).

Which browsers support WebKit CSS?

Wikipedia has a summary of what browsers use WebKit as their HTML rendering engine. The WebKit Project itself has even an more complete list.

What is WebKit and how is it related to CSS?

Update: So apparently, WebKit is a HTML/CSS web browser rendering engine for Safari/Chrome. Are there such engines for IE/Opera/Firefox and what are the differences, pros and cons of using one over the other? Can I use WebKit features in Firefox for example?

Every browser is backed by a rendering engine to draw the HTML/CSS web page.

• IE → Trident (discontinued)
• Edge → EdgeHTML (clean-up fork of Trident) (Edge switched to Blink in 2019)
• Firefox → Gecko
• Opera → Presto (no longer uses Presto since Feb 2013, consider Opera = Chrome, therefore Blink nowadays)
• Safari → WebKit
• Chrome → Blink (a fork of Webkit).

See Comparison of web browser engines for a list of comparisons in different areas.

The ultimate question... is WebKit supported by IE?

Not natively.

Is there a way to set any style for a specific browser in CSS?

For example, if I want to set the corner radius in Webkit, Firefox and other than I can use the following CSS

No, that isn't how it works.

Vendor prefixed properties are used for experimental features. Either because the specification for the property hasn't been locked down or because the browser implementor knows their are problems with the implementation.

In general, you shouldn't use them in production code because they are experimental.

Support for the vendor prefixed versions is removed as support stabilises.

Is there a way to set any style for a specific browser in CSS?

There are several methods that have been used for that effect.

Parser bugs

By exploiting bugs or unsupported features in specific CSS engines (e.g. some versions of IE will ignore a * character on the front of a property name while other browsers will (correctly) discard the entire rule).

Conditional comments

Older versions of Internet Explorer supported an extended HTML comment syntax that could be used to add <link> or <style> elements specifically for certain versions of IE.

Support for this has been dropped.

JavaScript

Classes can be added to elements (typically the body element) using JavaScript after doing browser detection in JS.

How do I load css rules dynamically in Webkit (Safari/Chrome)?

I think it's a better practice to append a "link" tag to the head of your document. If that isn't possible, try to append a "style" tag to the head. Style tags shouldn't be in the body (Doesn't even validate).

Append link tag:

var link = document.createElement('link');

link.setAttribute('rel', 'stylesheet');

link.type = 'text/css';

link.href = 'http://example.com/stylesheet.css';

document.head.appendChild(link);

Append style tag:

var style = document.createElement('style');

style.innerHTML = 'body { background-color: #F00; }';

document.head.appendChild(style);

Cross browser css rules: Mozila,chrome,safari and css2 vs css3

Welcome :)

If you start without the prefixes, you should write the code, generally, with all the semantically appropriate tags, first.

Then, you can decide what your goals are.

If you want W3C compliant CSS files, then you'd need to strip out the vendor specific prefixes by default. This would then allow the latest browsers to pick up the standardised CSS properties if they support them.

This will target less of your market than you might wish, so then you should ask if progressive enhancement is a possibility. If you can reasonably enhance the visuals by using css applied after the page has loaded, such as applying styles with jQuery, MooTools or Prototype libraries AND these libraries are already serving a purpose in your website, then you could apply additional styles with those libraries (and possibly use them in conjunction with Modernizr to determine which elements you may want to additionally support.

However, it's likely that a browser will skip a property it doesn't understand and will render the ones that it does, so I'd suggest that if you code it to W3C Standards first and then add in your additional vendor prefixes 'before' the final (correct) one, then you'll likely have satisfied reasonable measures to be compliant and meet design needs.

Edit:
There is a little bit of confusion between validation results from:

http://validator.w3.org/

and writing valid code related to vendor prefixes to get CSS effects cross-browser:

List of CSS vendor prefixes?

for working on some cross-browser CSS, you might find http://csspie.com, for IE compatibility with some CSS3 properties, useful along with http://www.colorzilla.com/gradient-editor/ for cross-browser gradients and http://cssplease.com for code that gives you alternative vendor prefixes, including different versions of IE support for many different properties.

In terms of validation, here's what W3C says about it: (see comments here: W3 VALID cross browser css gradient,) and official docs here: http://www.w3.org/TR/css3-syntax/#vendor-specific

If you code according to the specifications first and test your code out against that and then add in your vendor prefixes to get the same effects on the browsers you want to support (see progressive enhancement: What is Progressive Enhancement?) then you can be more confident that your code is supporting the appropriate standards, adding value to those with more advanced browsers and still useful for those without additional features (see also WAI III compliance, 508 compliance and others if you want to write a more inclusive site).

Caveat: Web Apps may not always be inclusive or follow these guidelines depending on who the audience is.

---

Related Topics