Bug 18344 - Appendix E imprecise about background propagation to canvas
Summary: Appendix E imprecise about background propagation to canvas
Status: NEW
Alias: None
Product: CSS
Classification: Unclassified
Component: CSS Level 2 (show other bugs)
Version: unspecified
Hardware: All Windows 3.1
: P2 normal
Target Milestone: ---
Assignee: Bert Bos
QA Contact: public-css-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-20 15:14 UTC by Anton P
Modified: 2012-12-04 00:53 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anton P 2012-07-20 15:14:06 UTC
E.2 says:

  # The canvas is transparent if contained within another, and given a
  # UA-defined color if it is not. It is infinite in extent and
  # contains the root element. Initially, the viewport is anchored with
  # its top left corner at the canvas origin.
  #
  # The painting order for the descendants of an element generating a
  # stacking context (see the 'z-index' property) is:
  #
  # 1. If the element is a root element:
  #    1. background color of element over the entire canvas.
  #    2. background image of element, over the entire canvas, anchored
  #       at the origin that would be used if it was painted for the
  #       root element.

and E.3 (Notes) says:

  # The background of the root element is only painted once, over the
  # whole canvas.


This fails to account for the special situation for the HTML BODY element described in 14.2:

  # The background of the root element becomes the background of the
  # canvas and covers the entire canvas, anchored (for
  # 'background-position') at the same point as it would be if it was
  # painted only for the root element itself. The root element does not
  # paint this background again.
  #
  # For HTML documents, however, we recommend that authors specify the
  # background for the BODY element rather than the HTML element.
  # For documents whose root element is an HTML "HTML" element or
  # an XHTML "html" element that has computed values of 'transparent'
  # for 'background-color' and 'none' for 'background-image', user
  # agents must instead use the computed value of the background
  # properties from that element's first HTML "BODY" element or XHTML
  # "body" element child when painting backgrounds for the canvas, and
  # must not paint a background for that child element. Such
  # backgrounds must also be anchored at the same point as they would
  # be if they were painted only for the root element.


E.2 should acknowledge 14.2 somehow.
Comment 1 Anton P 2012-07-20 15:17:26 UTC
Reported by Anton Prowse

Conversation begins:
Bug description:
http://lists.w3.org/Archives/Public/www-style/2012Jul/0478.html
Comment 2 Anton P 2012-07-20 15:18:36 UTC
Proposal A:

In E.2, prepend the following existing prose:

   # The painting order for the descendants of an element generating a
   # stacking context (see the 'z-index' property) is:
   #
   # 1. If the element is a root element:
   #    1. background color of element over the entire canvas.
   #    2. background image of element, over the entire canvas, anchored
   #       at the origin that would be used if it was painted for the
   #       root element.

with:

   | The background color and image of a child element of a root
   | element is sometimes painted over the entire canvas instead of that
   | of the root element itself.  This happens _in some situations with
   | HTML and XHTML documents_<link to 14.2>.  When this happens, no
   | background is painted for that child element.  User agents must
   | apply these rules instead of the ones below whenever the
   | latter concern the elements and backgrounds in question.

In E.3 (Notes), delete:

   # The background of the root element is only painted once, over the
   # whole canvas.


Note: the editorial device used in this proposal (that of explicitly 
discussing background propagation prior to the painting order algorithm 
whilst leaving the algorithm written in a manner which focuses the more 
typical general case) is deliberate, since it aids the proposal for Bug 17782.

Proposal: http://lists.w3.org/Archives/Public/www-style/2012Jul/0478.html