What compatibility do I lose when dropping the -khtml- vendor prefix? - css

I have bits and pieces of CSS that use the -webkit- vendor prefix. For compatibility with "older" versions of Safari, I have the same rule with the -khtml- vendor prefix. I am actively uninterested in compatibility with Konqueror and other true KHTML browsers.
For example, I may have the following rules:
.menuItem {
-khtml-user-select: none;
-webkit-user-select: none;
}
I understand that modern WebKit browsers internally rewrite all -khtml- and -apple- rules to be -webkit- rules instead. However, that leaves me with the following question:
In what version of Safari did -webkit- become available? That is, what is the version before which Safari would completely ignore my rules?
I plan to use this information to find out whether my individual rules (such as -khtml-user-select) are actually supported by this early version of Safari.

The -webkit- prefix has been around since Safari 3. The -khtml- references in Safari 2 were replaced from that point on.
References
Webkit 63854 Changelog
Chromium Changelog
Webkit Bug 42990
Unforking of KHTML and WebKit
Interview with Lars Knoll, creator of KHTML
Companies and Organizations that have contributed to WebKit
konqueror/kcmcss.cpp at master · KDE/konqueror

The only browser that uses the -khtml- prefix now is a Konqueror, since it have a very little market share (less than 1%), you can drop it safely.

Basically very less people uses Konqueror, So it is not necessary to use -khtml- prefix
But if required you, can only use this with the -khtml- prefix

Related

Do you need to download webkit?

I am following an tutorial that is typing -webkit-box-sizing: border-box; in the style.css nothing seems to happen when I write it... I am on windows and using atom. is it something you need to download? I understand an engine and something to do with animation in chrome/safari.
No need to download anythig. webkit is one of the prefixes used to make experimental css properties work for other browsers, they are temporary and you should remove them from your code once a property is fully supported by all browsers.
This is a list of prefixes used:
-webkit- (Chrome, Safari, iOS Safari / iOS WebView, Android)
-moz- (Firefox)
-ms- (Edge, Internet Explorer)
-o- (Opera, Opera Mini)
to determine if a property need vendor prefixes or not, use Can I Use they mention on the notes if the property searched is experimental.
once you found that you need to use prefixes, here is an easy tool to auto-prefix
AutoPrefixes
the following are some articles for more in depth reading:
https://flaviocopes.com/css-vendor-prefixes/
https://www.lifewire.com/css-vendor-prefixes-3466867
https://bitsofco.de/css-vendor-prefixes/

Is vendor prefixes a temporary addition Or it cover the gab between css levels Now and in future

There are a lot of vendor prefixes that try to make cross browsers compatibility between the old and new versions ...
my question is it temporary until all old browsers disappear or updated and then no need for it ?
Or we can depend on it when a new level of css shipping to cover maybe the gab between supported and unsupported browsers again?
Thanks
There's a long answer here, i'll try the short one first.
The vendor tags are a tryhard to avoid glitches or the no-rendering of some properties/attributes. If you need to support an old browser that is obsolete and unsupported you may need those vendor tags. If you are working on browsers with support, when they are updated, this vendor tags will not be necessary anymore.
Are there any update timeline to know when and when not a vendor tag is needed? No
Can we check if some vendor tag is needed on some property? Yes, here, if you want to support a browser that is not capable to run some property, try adding vendor tag.
Remember that vendor tag is not a magician, and it can't render things, the capability of the render engine dealing with vendor tags is different on all versions of the same browser, so i recommend you to check if it really works.
Looking to a realistic future, vendor tags will keep working as they worked till nowadays, giving mostly cross-browser compatibility between older and newer versions.
Historically, vendors have also used prefixes for experimental APIs. If an entire interface is experimental, then the interface's name is prefixed (but not the properties or methods within). If an experimental property or method is added to a standardized interface, then the individual method or property is prefixed.
Interface prefixes
Prefixes for interface names are upper-cased:
WebKit (Chrome, Safari, newer versions of Opera, almost all iOS browsers (including Firefox for iOS); basically, any WebKit based browser)
Moz (Firefox)
O (Older, pre-WebKit, versions of Opera)
MS (Internet Explorer and Microsoft Edge)
Property and method prefixes
The prefixes for properties and methods are lower-case:
webkit (Chrome, Safari, newer versions of Opera, almost all iOS browsers (including Firefox for iOS); basically, any WebKit based browser)
moz (Firefox)
o (Old, pre-WebKit, versions of Opera)
ms (Internet Explorer and Microsoft Edge)
Remember that saying "experimental" is subjective, for example, background-size was experimental on I.E. 8, Chrome 3 and FF 3 but it had native support on versions 9, 4 and 4 respectivelly.
Now, to answer your questions with the info:
Vendor prefixes are made to be temporary (till browsers support the feature you're prefixing), but you'll need to add vendor prefixes to new "experimental" features if you want to use it, so yes, you'll need vendor prefixes in a future, but to add cross browser compatibility on different properties etc.

What does it mean when a css property starts with a dash? [duplicate]

This question already has answers here:
Why do browsers create vendor prefixes for CSS properties?
(2 answers)
Closed 3 years ago.
I just downloaded a css file from this website and it contains properties such as -webkit-transform and -moz-transform. What does the dash mean and under what circumstances is it required?
For the nity grity does the phrase "vendor prefix" refer to the - or the content between the - and - (exuding the - and -) or the content between the - and - (including the - themselves)?
In other words does vender prefix refer to the dash itself or only the content between the dashes or the dashes with the content between them?
-webkit- and -moz- here are called vendor prefixes; they generally indicate a browser-specific feature of CSS, or one that’s under development/still a draft and can’t be considered a standard yet. When these features are used “ahead of time”, the only way to make it work in every browser is sometimes to provide a different rule with a different prefix for each one — that’s what you see in the project. The idea is that eventually, though, the feature will be standardized, browsers will drop the prefixes, and life will go on.
-webkit-gradient, for example, was the first way to define a gradient in CSS, but was replaced by a completely different linear-gradient and radial-gradient syntax.
A convenient way to find out what browsers support a certain feature and what prefixes you need if you’re using it before a definitive standard or global unprefixed browser support is Can I Use….
Some common prefixes are:
-webkit- for WebKit-based browsers, including Chrome/Chromium and Safari
-moz- for Firefox
-ms- for Internet Explorer (9 and up)
-o- for Opera (pre-WebKit)
They are called vendor prefixes. Different browsers have different prefixes:
-webkit- - Webkit based browsers such as Safari and Chrome
-moz- - Gecko based browsers such as Firefox
-ms- Internet Explorer
-o- Presto based browsers such as Opera
Vendor prefixes are used to denote experimental CSS features. They are used when a specific property or spec is not considered stable, and may change in the future. By using a prefix, the browser can experiment with that feature without the risk that developers will make use of the property and sites will break if the behaviour or syntax changes. Once the spec becomes final, the prefix is removed, and some browser will remove support for the prefixed version.
The official guidance from the W3C is that prefixes should be used until the spec from which the property or feature is from reaches Candidate Recommendation.
The general best practice is to use all vendor prefixes one after another, and the unprifixed version last.
Mozilla and Chrome (now they're moving to the Blink engine) have changed policy to hiding the feature behind a flag, rather than using a prefix. This means the feature will not be available to use unless the user enables that flag.
For more information, see this wiki page from the CSS Working Group: http://wiki.csswg.org/spec/vendor-prefixes

CSS with IE - is the -ms-filter required or not?

I have been learning about IE's rather ridiculous-looking requirements for shadows, gradients, etc., and I'm running into some contradictions on this point:
Many sites suggest the following lines are necessary for a gradient/shadow combination:
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#FFFFFF', EndColorStr='#F8F8F8') progid:DXImageTransform.Microsoft.Shadow(Strength=2, Direction=170, Color='#C6C6C6');
-ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorStr='#FFFFFF', EndColorStr='#F8F8F8') progid:DXImageTransform.Microsoft.Shadow(Strength=2, Direction=170, Color='#C6C6C6')"; }
CSS3Please.com suggests only the first filter is necessary for full compliance with IE 5.5-9, i.e. that the -ms-filter is of no use at all. Is -ms-filter needed any more or was that a temporary case in IE's development?
To answer your question even though I don't agree with its use, no it is not required. The "-ms-" prefix and other prefixes (such as "-moz-" and "-webkit-") are browser-specific and are usually just used while browsers are developing new properties. They leave the prefixed properties in later versions of the browser so that webpages using the prefixed property will still work, but both ways do the exact same thing.
P.S. IE 9 does support CSS3. It was released with Windows 7 SP1.

What is WebKit and how is it related to CSS?

More recently, I have been seeing questions with the tag "webkit". Such questions usually tend to be web-based questions relating to CSS, jQuery, layouts, cross-browers compatibility issues, etc...
So what is this "webkit" and how does it relate to CSS? I have also noticed a lot of -webkit-... properties in the source code for various websites. Are these two related?
Update
So from the answers so far... 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?
The ultimate question... Is WebKit supported by IE?
Update 2
All of the major browsers use different rendering engines. I guess this is a big reason why there are so many cross-browser compatibility issues!
So, is there some kind of project or movement to a standard rendering engine that ALL browsers will use? Will HTML5 bring an end to the cross-browser compatibility issues?
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.
Addition to what #KennyTM said:
IE
Engine: Trident
CSS-prefix: -ms
Edge
Engine: EdgeHTML → Blink3
CSS-prefix: -ms
Firefox
Engine: Gecko
CSS-prefix: -moz
Opera
Engine: Presto → Blink1
CSS-prefix: -o (Presto) and -webkit (Blink)
Safari
Engine: WebKit
CSS-prefix: -webkit
Chrome
Engine: WebKit → Blink2
CSS-prefix: -webkit
1) On February 12 2013 Opera (version 15+) announces they moving away from their own engine Presto to WebKit named Blink.
2) On April 3 2013 Google (Chrome version 28+) announces they are going to use the WebKit-based Blink engine.
3) On December 6 2018 Microsoft (Microsoft Edge 79+ stable) announces they are going to use the WebKit-based Blink engine.
Webkit is a web browser rendering engine used by Safari and Chrome (among others, but these are the popular ones).
The -webkit prefix on CSS selectors are properties that only this engine is intended to process, very similar to -moz properties. Many of us are hoping this goes away, for example -webkit-border-radius will be replaced by the standard border-radius and you won't need multiple rules for the same thing for multiple browsers. This is really the result of "pre-specification" features that are intended to not interfere with the standard version when it comes about.
For your update:...no it's not related to IE really, IE at least before 9 uses a different rendering engine called Trident.
This has been answered and accepted, but if someone is still wondering why are things a bit messed up today, you'll have to read this:
http://webaim.org/blog/user-agent-string-history/
It gives a good idea of how gecko, webkit and other major rendering engines evolved and what led to the current state of messed up user-agent strings.
Quoting the last paragraph for TL;DR purposes:
And then Google built Chrome, and Chrome used Webkit, and it was like Safari, and wanted pages built for Safari, and so pretended to be Safari. And thus Chrome used WebKit, and pretended to be Safari, and WebKit pretended to be KHTML, and KHTML pretended to be Gecko, and all browsers pretended to be Mozilla, and Chrome called itself Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13, and the user agent string was a complete mess, and near useless, and everyone pretended to be everyone else, and confusion abounded.
-webkit- is simply a group that Chrome, Safari, Opera and iOS browsers fit into. They all have a common ancestor, so often their capabilities/limitations (when it comes to running CSS and Javascript) are confined to the group.
A developer will place -webkit- followed by some code, meaning that the code will only run on Chrome, Safari, Opera and iOS browsers. Here is a complete list:
-webkit- (Chrome, Safari, newer versions of Opera, almost all iOS browsers (including Firefox for iOS); basically, any WebKit based browser)
-moz- (Firefox)
-o- (Old, pre-WebKit, versions of Opera)
-ms- (Internet Explorer and Microsoft Edge)
The ultimate question... Is WebKit supported by IE?
Kind of. Check out Chrome Frame, it's a plugin for Internet Explorer that makes it use the Webkit engine. The only quirk is that you have to persuade your visitors to install the plugin.
Update
Chrome Frame is no longer maintained or supported…
WebKit is a layout engine designed to
allow web browsers to render web
pages. The WebKit engine provides a
set of classes to display web content
in windows, and implements browser
features such as following links when
clicked by the user, managing a
back-forward list, and managing a
history of pages recently visited.
WebKit was originally created as a
fork of KHTML as the layout engine for
Apple's Safari; it is portable to many
other computing platforms. It is also
used in Google's Chrome Browser.
WebKit's WebCore and JavaScriptCore
components are available under the GNU
Lesser General Public License, and the
rest of WebKit is available under a
BSD-style license.
Source Wikipedia
For further information about layout engines you can look here
Webkit is an HTML rendering engine used by Chrome and Safari.
It supports a number of custom CSS properties that are prefixed by -webkit-.
Webkit is the html/css rendering engine used in Apple's Safari browser, and in Google's Chrome.
css values prefixes with -webkit- are webkit-specific, they're usually CSS3 or other non-standardised features.
to answer update 2
w3c is the body that tries to standardize these things, they write the rules, then programmers write their rendering engine to interpret those rules. So basically w3c says DIVs should work "This way" the engine-writer then uses that rule to write their code, any bugs or mis-interpretations of the rules cause the compatibility issues.
Webkit is the rendering engine used in the popular browsers Safari and Chrome, as well as others.
A common problem I have ran into as a website designer is that alot of people use IE6+. No big deal usually, except in CSS I have to add multiple rendering syntax' to parse each request, per browser. It would be very nice if there was a universal rendering setup for CSS that IE can read as easily as Chrome/FF/Opera and webkit. The problem with IE is that if I do NOT use ALL the proper CSS styles and rendering, than my websites look and work great using every browser except IE. This can make for an unhappy, die-hard IE customer.
Example is this: Let us say I need a 1px, grey border with a border-radius of 10%. For Chrome and others, I use the webkit property. Now, for IE, I have to add seperate CSS styles using the simple old CSS values of "border: 1px solid #E5E5E5" and "border-radius: 10%". A positive outcome is not always guaranteed over all IE browser versions, but for the most part this method works fine for me and many others.
Even though this is an older post, there is also another method to rendering for older versions of Internet Explorer. -webkit while being a CSS Vendor Prefix, you can also download a few JS applications and place them in the bottom of the HTML's HEAD.
Try using Modernizr, HTML5 Shiv and Respond.js. These are amazing IE compatible polyfill scripts that use polyfills, and other resources which will help better render HTML5 elements in IE9 and Below.
To use these polyfills, simply add HTML boolean logic to place them, IF the browser is less than the desire IE version. Example code is:
<head>
<!-- HEAD Elements -->
<script src="path/to/modernizr.js" type="text/javascript"></script>
<!--[if lt IE 6]>
<script src="path/to/HTMLSiv.js" type="text/javascript">
</script>
<script src="path/to/respond.js" type="text/javascript">
</script>
<![endif]-->
</head>
Webkit is the rendering engine used in the popular browsers Safari and Chrome, as well as others
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)
Firefox → Gecko
Opera → Presto (no longer uses Presto since Feb 2013, consider Opera = Chrome nowadays)
Safari → WebKit
Chrome → Blink (a fork of WebKit).
A good documentation about WebEngines especially webKit and its developers you can read at:
WebKit

Resources