Should not the "Browser compatibility" table also list Google Chrome and Konqueror? Chome is not mentioned at all, but is becoming increasingly popular. Konqueror is listed below the table, which seems inconsistent. Znerd 04 August 2009
Chrome, Iron, Icab4, OmniWeb etc. are based on WebKit, like Netscape 6-8, SeaMonkey, Camino, Flock, Fennec, Blackbird etc. are based on Gecko. Both layout engines are mentioned in the table. People should refer to the WebKit and Gecko version to get the info they need.
Agreed; we should definitely encourage people to look stuff up by engine rather than browser. These tables should be revised over time to list Gecko, WebKit, Internet Explorer, and Opera, with perhaps a tooltip on each that provides details on which browsers are encompassed by each. I'm going to post on dev-mdc momentarily with a proposal on this. (Sheppy 07 December 2009)
We should encourage web developers to ask for layout engines, not for browsers. [That said, the popularity of Chrome let me think of a table row like Safari, Chrome (WebKit) | 4.0, 2.0 (528). But I'm not able and willing spending time for this. Remember you have to test yourself, don't trust online references, don't trust WebKit | Apple | Google homepage, they are wrong. DON'T TRUST THE INTERNET AT ALLl! ]
Listing Konqueror below the table is a compromise for consistency. Feel free to put it inside, nothing is set in stone.
- Konqueror's global market share is 0.05%, (< 5% of Linux users). Given the fact that this reference has serious shortcomings in many places and few contributors, I think spending much time here is not effective. People especially interested in this browser are welcome to contribute.
- It's hard to get reliable information about its CSS support without having this browser (read: multiple versions of this browser) installed. Are you able and willing to do that for all CSS properties? If so, feel free to change the en/CSS_Reference/Property_Template and all CSS property pages ; ) Start with
-webkit-background-sizeand investigate support ofcontainandcoverkeywords and "omitted second value" behavior. [I assume it's the same as Safari, since they just backported a WebKit patch into KHTML. But we need facts, rather than assumptions.]
Btw, some time ago I'v listed Opera in the property template table and removed Netscape because Netscape is Gecko based and Opera has a global market share of > 2% (> 40% in some European countries).
User:Jürgen Jeka 2009-08-04
<hr>Is there anyway to have the -moz-border-image only apply if -moz-background-size is not supported? I'm guessing not, just asking because having both rules in for 3.6 creates a strange effect: -moz-border-image gets inherited by every element on the page
User:robertc 2009-08-08
-moz-border-image should not inherit. Some example code? User:Jürgen Jeka 2009-08-09
OK, here's a page with both rules - the CSS is derived from the code on the page here, this is what it looks like in 3.6a2pre on Linux, the background image appears on the whole page, and then again behind the main content. Here's a slightly more complex example (screenshot), and the same page without the -moz-border-image image rule (screenshot). User:robertc 2009-08-09
This is only an issue with <body> and <html>. <body>'s background extends per CSS spec to <html>. Since you have a 8px default margin on <body> and your <body>'s content is smaller than the viewport's height, you see what you see. Styles like this should work:
body { border:0; margin:0; padding:0.6em }
/* or for less content, if body is small */
html, body { height:100%; } body { border:0; margin:0; padding:0.6em }
Furthermore, you may simplify things a bit if you apply the background and border-image styles to <html> rather than <body>.
User:Jürgen Jeka 2009-08-12
OK, probably my understanding of CSS inheritance isn't all it should be. I tried locating the part of the spec about <body>'s background extending to <html> but it didn't seem to be explicitly mentioned in the Cascading and Inheritance section and both the background-image and border-image say 'inherited: no'. And anyway, it's more the -moz-border-image that seems to be the problem - that gets inherited even if I add in -moz-border-image: none, to <body> or <html>, and setting the height to 100% is more a matter of covering it up rather than stopping it happening (see further examples a, b and c - b and c look OK, but adding margin or padding reveals that the image applies to both <body> and <html> even though explicitly set to none) User:robertc 2009-08-14
See also bug 509681 and bug 497995. User:Jürgen Jeka 2009-08-23