The current spec, which was updated in response to some previous issues, reads:

   # A run-in element (or pseudo-element) A behaves as follows:
   #
   #   1. If A has any children that inhibit run-in behavior (see below),
   #      then A is rendered as if it had 'display: block'.
   #   2. Let B be the first of A's following siblings that is neither
   #      floating nor absolutely positioned nor has 'display: none'.
   #      If B exists and has a specified value for 'display' of 'block'
   #      or 'list-item' and is not replaced, then A is rendered as an
   #      'inline' element at the start of B's principal box. Note: A
   #      is rendered before B's ':before' pseudo-element, if any.
   #      See 12.1.
   #   3. Otherwise, A is rendered as if it had 'display: block'.
   #
   # In the above, "siblings" and "children" include both normal elements
   # and :before/:after pseudo-elements.
   #
   # An element or pseudo-element C inhibits run-in behavior if one of
   #  the following is true. (Note 

I've noticed that in two implementations*, at least, background-size: cover doesn't appear to operate as one would expect.

My case:

http://www.mnot.net/

... where a background image is attached to the body and sized to 'cover'.

Here, the image appears to cover well and scale appropriately with "normal" browser window sizes, but when one sizes the window to be reasonably narrow yet tall, a white bar appears at the bottom; i.e., it does not truly cover the box.

Is this working as specified, or are there bugs in the implementations?

Kind regards,

* Firefox, as well as Safari and Chrome; all most recent releases

--
Mark Nottingham     http://www.mnot.net/

  About *CSS Backgrounds and Borders Module Level 3* - *Working Draft 12
June 2010*

Hi,

reading through the background and border module I came across the
following things that I believe are mistakes in the text/editing of the
document.
I intend to also mention things that could be considered lacks in the
content/explanations (in all the humility of my opinion). This may seem
off topic but I truly don't purpose to discuss the specification itself,
merely pointing at the content of a certain version.

- in 4.4. The ?border-radius? properties
Prose specifies the meaning of border-radius values for the case of
values being given before and after the slash, and for the case of no
slash being used.
I believe it makes quite unclear what behavior is induced when a slash
is used but followed by no value: wether this is illegal syntax, or as
for border-*-radius the second value is copied from the first.

- 4.4.4. Overlapping Curves
In Example XXII a line goes like this: "/The height (2.5em) is enough 

Guys, I have a (light) problem with gradients and transformations.
An angle is not an angle...

- linear gradients' angles are counted counter-clockwise [1]

- rotations are counted clockwise [2]

Since gradients are not everywhere on the web YET, I hope we still can
change things here. So naive questions:

a) why that difference? Unintentional?
b) can we make both angles here mean the same thing and both
    rotate clockwise? Or both counter-clockwise?

I really don't care about clockwise or counter-clockwise. But I
would like an angle to be always meaning the same thing to web
authors. Think intuitivity. Think adding a -30deg linear gradient
to a 30deg rotated box to find again a horizontal linear gradient.
Makes sense.

I then suggest the following change in [1]:

-    * If the <angle> is greater than or equal to 0deg and less then
-      90deg, the starting-point of the gradient-line is the
-      bottom-left corner of the gradient-box.
-    * If the <angle> is greater than or equal to 90deg and less the

There is a pending issue for new writing modes (especially vertical) on what can be done to make one stylesheet work in all writing modes.

We had a brief discussion at F2F on a syntax option that would allow specifying logical values without adding many new properties. I have an action to write it up, here it is.

BACKGROUND

All directional CSS properties are defined as physical (so e.g. "margin-left:1em" is always visually left). But if the design intent of 'margin-left' is to add space before start of each line, it need somehow to be changed to 'margin-right' in RTL, or 'margin-top' in vertical.

I will not try to revisit all related discussions (details can be found in this mailing list). Just to summarize the current state of affairs,

*         Switching 'xxx-left', 'xxx-top' etc. from physical to logical is not an option.

*         A global mode that changes all or some properties to logical is possible, but appears dangerous. There is no precedent for mode-changing properties so far (although 'box

Summary:

   - RESOLVED: Accept Bert's changes for CSS2.1 Issue 121 with slight edit
     suggested by dbaron in the minutes.
   - RESOLVED: Accept fantasai's proposal for CSS2.1 Issue 158
   - Reviewed proposal for CSS2.1 Issue 158; more edit work needed.
   - RESOLVED: Accept fantasai's proposal for CSS2.1 Issue 172
   - RESOLVED: Accept fantasai's proposal for CSS2.1 Issue 187
   - RESOLVED: Accept updated wording for CSS2.1 Issue 187
   - Reviewed CSS2.1 Issue 197: need test case results and proposed text.
   - Reviewed CSS2.1 Issue 199

====== Full minutes below ======
Present:
   Tab Atkins
   David Baron
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   H?kon Wium Lie
   Peter Linss
   David Singer
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2010/09/08-CSS-irc
<glazou> dbaron: do you have plans to extend -moz-*-gradient() to the CSS 3 values of <position> ?
<glazou> (as in CSS 3 Images spec...)
<dbaron> you mean the new b

Summary:

   - Peter set up an agenda template for TPAC on the wiki
   - Reviewed status of CSS2.1 issues
   - RESOLVED: Accept fantasai's proposed text for CSS2.1 Issue 173 with option B
   - RESOLVED: Accept proposal for CSS2.1 Issue 203
   - RESOLVED: Mark min/max as at-risk, and mark % in min/max as at-risk. (css3-values)
   - Reviewed Tab's proposal for counter style definitions

http://lists.w3.org/Archives/Public/www-style/2010Sep/0235.html

   - Discussed how to get implementation reports for CSS2.1 test suite

====== Full minutes below ======

Present:
   Tab Atkins
   David Baron
   John Daggett
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   H?kon Wium Lie
   Peter Linss
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2010/09/15-CSS-irc
Scribe: TabAtkins

Administrative
--------------

   glazou: We need a wiki page for agenda items during TPAC.
   glazou: Elika, can you set up a wiki page?
   plinss: Already done.
   <plinss>

I recently wondered whether it's possible to style a block of text *contained
within a single element* such that wrapped lines are indented. This is
particularly useful when dealing with code snippets, which are typically
inserted between `<pre><code>` and `</code></pre>`. For example?

<pre><code>Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Sed sit amet diam sit amet sem accumsan faucibus ac in arcu.

Quisque varius, erat vel euismod ornare, libero orci laoreet velit, at
lobortis sem nisl et eros.</code></pre>

? would perhaps be rendered as?

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Sed sit amet diam sit amet sem accumsan faucibus ac in arcu.

Quisque varius, erat vel euismod ornare, libero orci laoreet velit,

        at lobortis sem nisl et eros.

Here, the last line of "code" has been wrapped due to its length; this is
made apparent to the reader via indentation.

I posed this question on Stack
Overflow<http://stackoverflow.com/questions/3477625/is-it-possible-to

The CSS21 issues list (http://wiki.csswg.org/spec/css2.1#issue-158)
seems to have incorrect proposal URLs for Issues 158 and 159:

*) the proposal URL for Issue 158 points to version 5 of the margin
collapsing rewrite;
*) the proposal URL for Issue 159 points to version 4 of the margin
collapsing rewrite.

No doubt the version 5 link should have replaced the pre-existing
proposal URL for Issue 159 instead of that for Issue 158.

The proposal URL for Issue 158 should, I think, be
http://lists.w3.org/Archives/Public/www-style/2010Aug/0458.html as cited
in the Minutes and Resolutions for 2010-09-08.

Cheers,
Anton Prowse

http://dev.moonhenge.net

Noticed two minor things:

* ?? the ones already in CSS. [CSS21]? suggests to include ?[CSS21]?
in the sentence: ?? the ones already in CSS [CSS21].?

* ?Relationship to Inlines and blocks?: the uppercase ?I? seems off ?
maybe use ?inlines? or ?inline elements??