background-size

  • Revision slug: Talk:CSS/background-size
  • Revision title: background-size
  • Revision id: 127387
  • Created:
  • Creator: Jürgen Jeka
  • Is current revision? No
  • Comment 34 words added

Revision Content

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.

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.

  1. 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.
  2. 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-size and investigate support of contain and cover keywords 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


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

Revision Source

<p>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 <em>below</em> the table, which seems inconsistent. <a href="/User:Znerd" rel="custom nofollow">Znerd</a> 04 August 2009</p>
<p>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.</p>
<p>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    <em>Safari, Chrome (WebKit) | 4.0, 2.0 (528</em>).    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! ]</p>
<p>Listing Konqueror below the table is a compromise for consistency. Feel free to put it inside, nothing is set in stone.</p>
<ol> <li>Konqueror's global market share is 0.05%, (&lt; 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.</li> <li>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 <a class="internal" href="/en/CSS_Reference/Property_Template" title="/en/CSS Reference/Property Template">en/CSS_Reference/Property_Template</a> and all CSS property pages ; )  Start with <code>-webkit-background-size </code>and investigate support of<code> contain </code>and<code> cover </code>keywords 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.]</li>
</ol>
<p>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 &gt; 2% (&gt; 40% in some European countries).</p>
<p>{{ user("Jürgen Jeka") }} 2009-08-04</p>
<hr>
<p>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</p>
<p>{{ user("robertc") }} 2009-08-08</p>
<p> <code>-moz-border-image </code>should not inherit. Some example code? {{ user("Jürgen Jeka") }} 2009-08-09</p>
<p>OK, <a class=" external" href="http://www.boogdesign.com/examples/css3/bg-image-1.html">here's a page with both rules</a> - the CSS is derived from the code on the page here, <a class=" external" href="http://www.boogdesign.com/examples/css3/ff/bg-image-1.png">this is what it looks like in 3.6a2pre on Linux</a>, the background image appears on the whole page, and then again behind the main content. <a class=" external" href="http://www.boogdesign.com/examples/css3/bg-image-6-moz.html">Here's a slightly more complex example</a> (<a class=" external" href="http://www.boogdesign.com/examples/css3/ff/bg-image-6-moz.png">screenshot</a>), and <a class=" external" href="http://www.boogdesign.com/examples/css3/bg-image-6.html">the same page without the -moz-border-image image rule</a> (<a class=" external" href="http://www.boogdesign.com/examples/css3/ff/bg-image-6.png">screenshot</a>). {{ user("robertc") }} 2009-08-09</p>
<p>This is only an issue with <code>&lt;body&gt;</code> and <code>&lt;html&gt;</code>. &lt;body&gt;'s background extends per CSS spec to &lt;html&gt;. Since you have a 8px default margin on &lt;body&gt; and your &lt;body&gt;'s content is smaller than the viewport's height, you see what you see. Styles like this should work:</p>
<pre>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 } 
</pre>
<p>Furthermore, you may simplify things a bit if you apply the background and border-image styles to &lt;html&gt; rather than &lt;body&gt;.</p>
<p>{{ user("Jürgen Jeka") }} 2009-08-12</p>
<p>OK, probably my understanding of CSS inheritance isn't all it should be.  I tried locating the part of the spec about &lt;body&gt;'s background extending to &lt;html&gt; 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 &lt;body&gt; or &lt;html&gt;, and setting the height to 100% is more a matter of covering it up rather than stopping it happening (see further examples <a class=" external" href="http://www.boogdesign.com/examples/css3/bg-image-1a.html">a</a>, <a class=" external" href="http://www.boogdesign.com/examples/css3/bg-image-1b.html">b</a> and <a class=" external" href="http://www.boogdesign.com/examples/css3/bg-image-1c.html">c</a> - b and c look OK, but adding margin or padding reveals that the image applies to both &lt;body&gt; and &lt;html&gt; even though explicitly set to none) {{ user("robertc") }} 2009-08-14</p>
<p>See also {{ bug("509681") }} and {{ bug("497995") }}.  {{ user("Jürgen Jeka") }} 2009-08-23</p>
Revert to this revision