Issue 1.
URI: http://lists.w3.org/Archives/Public/www-style/2006Nov/0020.html
Description:

  "A declaration block (also called a declaration block in the following
  text)..."

  Remove "(also called a declaration block in the following text)" completely.

Resolution:

  Assumed editorial.

Issue closed.
------------------------------------------------------------------------
Issue 2.
URI: http://lists.w3.org/Archives/Public/www-style/2006Nov/0006.html
Description:

  Behavior of blocks that establish a new block formatting context
  in the presence of floats.

Proposal:

  http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0303.html

    1. Link the words "may become narrower" in 9.4.1 to the 5th
       paragraph of 9.5 "Floats"

    2. In the first sentence of of that 5th paragraph of 9.5,
       change "margin box" to "border box" (issue 21)

    3. Add this sentence at the end of that 5th paragraph of 9.5:
       "They may even make the border box of said element narrower
       than defined by section 10.3.3. CSS2 does not define when a
       UA may put said element next to the float or by how much
       said element may become narrower."

Resolution:
  Proposal accepted.

Issue closed.
------------------------------------------------------------------------
Issue 3.
URI: http://lists.w3.org/Archives/Public/www-style/2006Sep/0065.html
Description:

  Why aren't overlapping table cells required?

Proposal:

  http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0303.html

  Leave spec as-is.

  New proposal:
  http://lists.w3.org/Archives/Member/w3c-css-wg/2007AprJun/0250.html

  Add explicitly undefined cases to bullet 5 in 17.5

Resolution:

  (After discussing with the Director:) the layout of illegal XHTML
  tables (and all similar combinations of rowspan/colspan in other
  formats) when rendered with CSS's table properties is explicitly
  undefined, as follows:

  Change this text in bullet 5 of 17.5

      The rectangle must be as far to the left as possible, but it
      may not overlap with any other cell box, and must be to the
      right of all cells in the same row that are earlier in the
      source document. (This constraint holds if the 'direction'
      property of the table is 'ltr'; if the 'direction' is 'rtl',
      interchange "left" and "right" in the previous sentence.)

  to

      The rectangle must be as far to the left as possible, but the
      part of the cell in the first column it occupies must not
      overlap with any other cell box (i.e., a row-spanning cell
      starting in a prior row), and the cell must be to the right of
      all cells in the same row that are earlier in the source
      document. If this position would cause a column-spanning cell
      to overlap a row-spanning cell from a prior row, CSS does not
      define the results: implementations may either overlap the
      cells (as is done in many HTML implementations) or may shift
      the later cell to the right to avoid such overlap. (This
      constraint holds if the 'direction' property of the table is
      'ltr'; if the 'direction' is 'rtl', interchange "left" and
      "right" in the previous two sentences.)

  Also change the following example and its image caption
  correspondingly.

Issue closed.
------------------------------------------------------------------------
Issue 4.
URI: http://fantasai.inkedblade.net/style/specs/css2.1/min-max-replaced-2
URI: http://lists.w3.org/Archives/Public/www-style/2006Nov/0034.html
Description:

  The Min-Max Issue

Proposal:

  Leave spec as-is and continue with image-scaling in CSS3. Add note:

  Note: In cases where an explicit width or height is set and the other
  dimension is auto, applying a minimum or maximum constraint on the
  auto side can cause an over-constrained situation. The spec is clear
  in the behavior but it might not be what the author expects. The CSS3
  image-fit property can be used to obtain different results in this
  situation.

Resolution:

  No normative change, add warning note to authors.

Issue closed.
------------------------------------------------------------------------
Issue 5.
URI: http://lists.w3.org/Archives/Public/www-style/2006Nov/0049.html
URI: http://www.w3.org/Style/CSS/Test/CSS2.1/current/t1202-counters-17-d.htm
Description:

  Test assumes
    :before, :after { white-space: pre-line }
  is not there, even though it's in the sample style sheet.

Resolution:

  Repeat "white-space: pre" on :before, :after in test t1202-counters-17-d.htm

Issue closed.
------------------------------------------------------------------------
Issue 6.
URI: http://lists.w3.org/Archives/Public/www-style/2006Dec/0021.html
Description:

  issues-3.103: Add reference to Unicode Standard, not just ISO10646.

Resolution:

  We already reference Unicode.

Issue closed.
------------------------------------------------------------------------
Issue 7.
URI: http://lists.w3.org/Archives/Public/www-style/2006Dec/0021.html
Description:

  issues-3.104: Clarify that CSS reserving all property values and
  @keywords does not retroactively make invalid SVG 1.0/1.1 documents
  with external stylesheets.

Resolution:

  We already agreed to publish an CSS3 SVG module.

Issue closed.
------------------------------------------------------------------------
Issue 8.
URI: http://lists.w3.org/Archives/Public/www-style/2006Dec/0021.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0117.html
Description:

  issues-3.105: RGB colors may be clipped prematurely.

  http://www.w3.org/Style/Group/css2-src/syndata.html#color-units

Proposal:

  (From Bert and Melinda)

  1. Replace note after last example in 4.3.6 with
        "Note. Mapping or clipping of color values should be done to
        the actual device gamut if known (which may be larger or
        smaller than 0..255)."

  2. In the paragraph before that example, change
       "Values outside the device gamut should be clipped"
     to
       "Values outside the device gamut should be clipped or
        mapped into the gamut when the gamut is known."

Resolution:
  Proposal accepted.

Issue closed.
------------------------------------------------------------------------
Issue 9.
URI: http://lists.w3.org/Archives/Public/www-style/2006Dec/0021.html
Description:

  issues-3.106: Make reference to CSS3 obviously non-normative.

Resolution:

  Assumed editorial. Changed "Implementors should look at CSS3 Lists"
  to "Implementors are advised to look at CSS3 Lists" in the section
  "Features at risk" on the cover page.

Issue closed.
------------------------------------------------------------------------
Issue 10.
URI: http://lists.w3.org/Archives/Public/www-style/2006Dec/0038.html
Description:

  Poster has a question about floats in absolutely-positioned elements,
  apparently can't find answer in spec. If we can't find it either, this
  is an issue. Otherwise, we just need to post a reply with the answer
  and add his test cases to the test suite.

Proposal:

  Reply: http://lists.w3.org/Archives/Public/www-style/2007Feb/0104.html
  No change.

Resolution:
  No change.
Issue closed.
------------------------------------------------------------------------
Issue 11.
URI: http://lists.w3.org/Archives/Public/www-style/2006Dec/0057.html
Description:

  Empty inline elements should act like display: none; (?)

  [Needs testcase]

Proposal 1:

  Line boxes that contain no text, no spaces, and no in-flow content
  (such as images, inline blocks or inline tables), and don't end with
  a line feed must be taken out of flow and not rendered. Inline
  elements on such line boxes must not be rendered. For the purposes
  of finding the static position for positioning or position for
  floats, an anonymous block that acts as a parent of these elements
  must be assumed to replace the line box.

Proposal 2:

  Line boxes that contain no text, no preserved white space, and no
  in-flow content (such as images, inline blocks or inline tables),
  and don't end with a line feed must be taken out of flow and not
  rendered. Inline elements on such line boxes must not be rendered.
  The static position and the position for floats is calculated as
  if such inline elements were anonymous blocks.

Proposal 3:

  Line boxes that contain no text, no preserved white space, no inline
  elements with non-zero margins, padding, or borders, and no other
  in-flow content (such as images, inline blocks or inline tables),
  and don't end with a line feed must be taken out of flow and not
  rendered. Inline elements on such line boxes must not be rendered.
  The static position of such inline elements is calculated with
  respect to an anonymous block that replaces the line box. This
  anonymous block is the containing block for any descendant floats.

Proposal 4:

  Line boxes that contain no text, no preserved white space, no inline
  elements with non-zero margins, padding, or borders, and no other
  in-flow content (such as images, inline blocks or inline tables),
  and don't end with a line feed must be taken out of flow and not
  rendered. Inline elements on such line boxes must not be rendered.
  The static and relatively-positioned position of such inline elements
  is the static position of an anonymous block that replaces the
  line box. This anonymous block is the containing block for any
  descendant floats.

Proposal 5:

  Empty inline elements without padding, margins or borders (and ignored
  height) on an otherwise empty line box do not participate in rendering.
  For positioning purposes treat the empty inline as an empty block box.

Proposal 6:

  Line boxes that contain no text, no preserved white space, no inline
  elements with non-zero margins, padding, or borders, and no other
  in-flow content (such as images, inline blocks or inline tables),
  and don't end with a line feed must be treated as zero-height line
  boxes. For the purposes of margin collapsing, this line box must be
  ignored.

Resolution:

  Proposal 6 accepted for 9.4.2.

Issue closed.
------------------------------------------------------------------------
Issue 12.
URI: http://lists.w3.org/Archives/Public/www-style/2006Dec/0086.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0117.html
Description:

  Dissent on change to ignoring broken URIs in 'content'.

Proposal:

  Reply: http://lists.w3.org/Archives/Public/www-style/2007Feb/0106.html
  No change.

Resolution:
  No change.

Issue closed.
------------------------------------------------------------------------
Issue 13.
URI: http://lists.w3.org/Archives/Public/www-style/2007Jan/0001.html
Description:

  Definition of replaced element unclear about embedded <svg> elements,
  uses undefined term "CSS formatter".

Proposal:

  Change "CSS formatter" to "CSS formatting model" and either
    a) Remove "The rendered content of a replaced element comes
       from outside the source document" or
    b) Replace it with "The rendered content of a replaced element
       is outside the scope of this specification"

Resolution:

  Proposal accepted with wordsmithed option b:
    "How a replaced element's content is rendered is not defined by
    this specification."

Issue closed.
------------------------------------------------------------------------
Issue 14.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2006OctDec/0183.html
Description:

  The third bullet in Section 3.2 says that UA's that render must respect
   points 1-5.  Should this be point 1-6?

Resolution:

  Assumed editorial.

Issue closed.
------------------------------------------------------------------------
Issue 16.
URI: http://lists.w3.org/Archives/Public/www-style/2007Jan/0040.html
Description:

  Unclear whether escapes are allowed in !important tokens.

Resolution:

  Assumed editorial. Fixed Appendix G to allow escapes.
  Reply to www-style/Bjoern:
  http://lists.w3.org/Archives/Public/www-style/2007Feb/0048.html

Issue closed.
------------------------------------------------------------------------
Issue 17.
URI: http://lists.w3.org/Archives/Public/www-style/2007Jan/0041.html
Description:

  Define whether -0 is a non-negative number. (Browsers seem to treat
  it as non-negative.)

Proposal:

  Add "-0 is equivalent to 0 and is not a negative number."
  to the end of the first paragraph in 4.3.1.

Resolution:

  Proposal accepted.

Issue closed.
------------------------------------------------------------------------
Issue 18.
URI: http://lists.w3.org/Archives/Public/www-style/2007Jan/0042.html
Description:

  Replace <list-style-type> with <'list-style-type'> in syndata and generate

Resolution:

  Assumed editorial.

Issue closed.
------------------------------------------------------------------------
Issue 19.
URI: http://lists.w3.org/Archives/Public/www-style/2007Jan/0062.html
URI: http://lists.w3.org/Archives/Public/www-style/2007Jan/0064.html
Description:

  What to do with Unicode escapes above U+10FFFF

Resolution:

  A UA should display something, such as a replacement character or a
  missing glyph character. Bert to add something to either chapter 4
  or chapter 15.

  Actual text added to 4.1.3:

    If the number is outside the range allowed by Unicode (e.g.,
    "\110000" is above the maximum 10FFFF allowed in current Unicode),
    the UA may replace the escape with the "replacement character"
    (U+FFFD). If the character is to be displayed, the UA should show a
    visible symbol, such as a "missing character" glyph (cf. 15.2, point
    5).

Issue closed.
------------------------------------------------------------------------
Issue 20.
URI: http://lists.w3.org/Archives/Public/www-style/2007Jan/0070.html
Description:

  Changes section out-of-sync.

Resolution:

  Assumed editorial.

Issue closed.
------------------------------------------------------------------------
Issue 21.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0088.html
Description:

  Should floats be excluded from the margin box or the border box of
  elements flowing alongside?

Proposal:

  Change "The margin box of a table..." to "The border box of a table..."
  in the 5th paragraph of 9.5.

  Group is leaning towards accepting this proposal, waiting for feedback
  from HP (and others who want to think about it) before making it final.

Resolution:

  Proposal accepted.

Issue closed.
------------------------------------------------------------------------
Issue 22.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0170.html
Description:

  "Note. After a certain amount of time, user agents may choose to
  return a visited link to the (unvisited) ':link' state." should be
  normative.

Resolution:

  Replace the note in 5.11.2 by this (normative) paragraph:

    UAs may return a visited link to the (unvisited) ':link' state at
    some point.

Issue closed.
------------------------------------------------------------------------
Issue 23.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0168.html
Description:

  Clearly specify handling of unicameral scripts.

Resolution:

  In 16.5, replace

    Conforming user agents may consider the value of 'text-transform'
    to be 'none' for writing scripts for which there is no transform.

  by

    Only characters belonging to bicameral scripts [xyz] are
    affected.

  and add a bibliographic reference [xyz] to
  http://www.unicode.org/reports/tr21/tr21-5.html#Introduction

Issue closed.
------------------------------------------------------------------------
Issue 24.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0209.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2006JulSep/0217
Description:

  We decided a change to the priority rules among possible page
  breaks, but no action was assigned at the time. So here is the
  action:

Resolution:

  In section 13.3.3, change

    If the above doesn't provide enough break points to keep content
    from overflowing the page boxes, then rules B and D are dropped in
    order to find additional breakpoints.

    If that still does not lead to sufficient break points, rules A
    and C are dropped as well, to find still more break points.

  to

    If the above doesn't provide enough break points to keep content
    from overflowing the page boxes, then rules A, B and D are dropped in
    order to find additional breakpoints.

    If that still does not lead to sufficient break points, rule
    C is dropped as well, to find still more break points.

  (I.e., 'A' should be added to the first paragraph and deleted from
  the last paragraph.)

Issue closed.
------------------------------------------------------------------------
Issue 25.
URI: http://lists.w3.org/Archives/Public/www-style/2007Jan/0098.html
Description:

  Define what happens to margin/border/padding/text-decoration where
  element is broken.

Proposal:

  (From Bert, modified by Melinda:)

  http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0303.html

  Add to the end of 13.3.1:
    "When a page break splits a box, the box's margins, borders, and
    padding have no visual effect where the split occurs."
  or:
    "When a box is interrupted at the bottom of one page and continued
    on the top of the next, the box's margins, borders, and padding
    are not rendered at the bottom and top of the respective pages. 
    Future specifications may define properties to modify this
    behavior. (At the time of writing, a property 'border-break'
    [CSS3BG] is under consideration.)"

Resolution:

  First proposal accepted.

Issue closed.
------------------------------------------------------------------------
Issue 26.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0069.html
Description:

  This is a request from SVG.

  Intrinsic ratio is ignored when there is neither intrinsic height or
  width. Should use available width like for non-replaced blocks where
  possible and calculate height from ratio.

  Example (use FF or Opera):
    SVG image with intrinsic ratio, but no intrinsic size:
      http://fantasai.inkedblade.net/style/tests/issues/intrinsic-ratio.svg
    Document with a wide body that includes this image:
      http://fantasai.inkedblade.net/style/tests/issues/intrinsic-ratio-1

Proposal:

   1. Use 300px by 150px. This will help us exit CR, because it's what
      implementations do today. It is not what CDF agreed to, and it's
      not what CDF or SVG wants.

      Text: current text

   2. Use available width and intrinsic ratio where possible (fall back
      to 300px otherwise). This is not what implementations do today.
      It is what SVG wants, what CDF expected the spec to say, and it
      is the most useful for authoring.

      Text: http://lists.w3.org/Archives/Member/w3c-svg-wg/2006OctDec/0373.html
            (+ changes for #3 to handle fallback)

   3. Use 300px times intrinsic ratio. This is not what implementations
      do today, and it's not what CDF or SVG wants.

      Text: Remove "'width' has some other computed value," from the 3rd
            paragraph in 10.6.2.

Resolution:

  Proposal 2 accepted.

Issue closed.
------------------------------------------------------------------------
Issue 27.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0121.html
Description:

  In  8.3.1
    "An element's own margins are adjoining if ... it has neither vertical
    borders nor vertical padding"

  Term "vertical borders" and "vertical padding" is confusing.

Proposal:

  Replace "vertical" with "top or bottom".

Resolution:

  Assumed editorial.

Issue closed.
------------------------------------------------------------------------
Issue 28.
URI: http://www.w3.org/TR/css3-speech/#aural-model
Description:

  The informative appendix on aural properties
    http://www.w3.org/Style/Group/css2-src/aural.html#pause-props
  says
  # These properties specify a pause to be observed before (or after)
  # speaking an element's content. Values have the following meanings:
  # ...
  # The pause is inserted between the element's content and any
  # 'cue-before' or 'cue-after' content.

  To be consistent with CSS3 Speech, we can replace
    "an element's content"
  with
    "an element's cues and content"
  and delete the other sentence.

  Otherwise, we should add a note after that last sentence.
    Note: In CSS3 pauses are inserted around the cues and
    content rather than between them. See [CSS3 Speech] for
    details.

Resolution:

  Add note.

Issue closed.
------------------------------------------------------------------------
Issue 29.
URI: http://lists.w3.org/Archives/Public/www-style/2007Mar/0004.html
Description:

  Spec is not clear on whether 'clip'-ed content that would have overflowed
  should be considered as causing overflow.

Resolution:

  Add "Content that has been clipped does not cause overflow" to after
  "... outside the clipping region" in section 11.1.2

Issue closed.
------------------------------------------------------------------------
Issue 30.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/att-0376/MarginCollapsingSamples070302.htm
Description:

  9.5.2 defines behavior of 'clear' as follows:

    Computing the clearance of an element on which 'clear' is set is done
    by first determining the hypothetical position of the element's top
    border edge within its parent block. This position is determined after
    the top margin of the element has been *collapsed* with previous
    adjacent margins (including the top margin of the parent block).

    If the element's top border edge has not passed the relevant floats,
    then its clearance is set to the amount necessary to place the border
    edge of the block even with the bottom outer edge of the lowest float
    that must be cleared.

  However 8.3.1 describes collapsing margins as

    In this specification, the expression collapsing margins means that
    adjoining margins (no non-empty content, padding or border areas or
    *clearance* separate them) of two or more boxes (which may be next to
    one another or nested) combine to form a single margin.

  This creates a circular reference which makes the two rules contradictory.

Original proposal from MS:

  In 8.3.1, remove all 5 instances of the word 'clearance' (and whole sentences
  that are not needed without 'clearance')

  Note:
    Clearance was added as a concept at Oslo f2f in 2003. It was added both
    to 9.5.2 and 8.3.1. However since margin collapsing happens before
    clearance, it doesn't need to have clearance-related rules.

Alternate proposal from Hyatt:

  http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0512.html

Alternate proposal from Ian:

  http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0535.html

Alternate proposal from Ian/Elika:
  http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0538.html

Resolution:
Ian's text accepted:
http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0535.html

Issue closed.
------------------------------------------------------------------------
Issue 31.
URI: http://lists.w3.org/Archives/Public/www-style/2007Mar/0035.html
Description:

  Make XHTML <body> magic like HTML <body>.

Proposal:

   6.4.4 paragraph 2: change "For HTML" to "For HTML and XHTML".

   11.1.1: Change the sentence "HTML UAs must instead apply the 'overflow' 
   property from the BODY element to the viewport, if the value on the 
   HTML element is 'visible'." to:

      When the root element is an HTML "HTML" element or an XHTML "html" 
      element, and that element has an HTML "BODY" element or an XHTML 
      "body" element as a child, user agents must instead apply the 
      'overflow' property from the first such child element to the 
      viewport, if the value on the root element is 'visible'.

   14.2 paragraph 4: change to:

      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 those 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.

   17.5 paragraph 2: change the last sentence to: "These rules do not 
   apply to HTML or XHTML; HTML imposes its own limitations on row and 
   column spans."

   17.5 final example: This would need various editorial changes to 
   indicate that the second example is not XHTML but some non-HTML XML 
   vocabulary.

Alternate proposal from Ian/Elika:
  http://lists.w3.org/Archives/Member/w3c-css-wg/2007JanMar/0538.html

Resolution:

  No change at this point.

Resolution #2:

  Mark ? at risk.

Issue closed.
------------------------------------------------------------------------
Issue 32.
URI: http://lists.w3.org/Archives/Public/www-style/2007Mar/0068
Description:

  page-break-inside on child can override parent, but the same isn't
  true of page-break-before/after

Proposal 1:

  Do nothing. Add a new value in CSS3.

Proposal 2:

  Insert before the last "," in rule B: "and all the blocks contributing
  to the margin have a 'page-break-inside' value of 'avoid'"

Resolution:

  No change.

Issue closed.
------------------------------------------------------------------------
Issue 33.
URI: http://lists.w3.org/Archives/Public/www-style/2007Mar/0105.html
Description:

  Clear may not have the desired effect on the last child of a formatting context.

Resolution:
  There is indeed a mistake.
  David to propose text.

David's Proposal:
  http://lists.w3.org/Archives/Public/www-style/2007Apr/0013
  maybe modified according to
  http://lists.w3.org/Archives/Public/www-style/2007Apr/0015
Ian Agrees:
  http://lists.w3.org/Archives/Public/www-style/2007Apr/0014

Resolution:
  Proposal accepted.

Issue closed.
------------------------------------------------------------------------
Issue 34.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2007AprJun/0039.html
URI: http://lists.w3.org/Archives/Public/www-style/2007Apr/0001.html
Description:

  "margin box" "border box" and "padding box" used but not defined

Proposal:

  In section 8.1 Box dimensions,

  Add to the definition of "margin edge"
    | The four margin edges define the box's <dfn>margin box</dfn>.
  Add to the definition of "border edge"
    | The four border edges define the box's <dfn>border box</dfn>.
  Add to the definition of "padding edge"
    | The four padding edges define the box's <dfn>padding box</dfn>.
  Add to the definition of "content edge"
    | The four content edges define the box's <dfn>content box</dfn>.

Resolution:

  Proposal accepted.

Issue closed.
------------------------------------------------------------------------
Issue 35.
URI: http://lists.w3.org/Archives/Public/www-style/2007Apr/0018.html
Description:

  background-position defined by example, not by normative text

Proposal:

  See URI.

Resolution:

  Proposal accepted.

Issue closed.
------------------------------------------------------------------------
Issue 36.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2007AprJun/0040.html
Description:

  "padding area" incorrectly used in place of "padding box"

Resolution:

  Assumed editorial.

Issue closed.
------------------------------------------------------------------------
Issue 37.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2007AprJun/0041.html
Description: 

  Confusion over newlines and line feed

Proposal:

  Add after the value definitions in 16.6:
    "Newlines in the source can be represented by a carriage return
    (U+000D), a linefeed (U+000A) or both (U+000D U+000A) or by some
    other mechanism that identifies the beginning and end of document
    segments, such as the SGML RECORD-START and RECORD-END tokens.
    The CSS 'white-space' processing model assumes all newlines have
    been normalized to line feeds."


Resolution:

Issue closed.
------------------------------------------------------------------------
Issue 38.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2007AprJun/0063.html
Description: 

  Elika writes:

    [...] the third paragraph of 10.6.2 states the
    same thing, essentially, three times:

       # If 'height' and 'width' both have computed values of 'auto' and
       #   the element has no intrinsic height, but does have an intrinsic
       #   width and intrinsic ratio;
       # or if 'height' has a computed value of 'auto', and the element
       #   does have an intrinsic ratio;
       # or if 'height' and 'width' both have computed values of 'auto' and
       #  the element has an intrinsic ratio but no intrinsic height or
       #  width and the containing block's width doesn't itself depend on
       #  the replaced element's width;
       # then the used value of 'height' is:

    I think we can replace all that with

       | Otherwise if 'height' has a computed value of 'auto' and the
       | element does have an intrinsic ratio then the used value of
       | 'height' is:

    since that second case covers the other two.

  Bert agrees and thinks this is editorial.

Resolution:

  Assumed editorial.

Issue closed.
------------------------------------------------------------------------
Issue 39.
URI: http://lists.w3.org/Archives/Public/www-style/2007May/0072.html
Description:

  "outline-width: thick solid" in example should be "outline: thick solid"

Resolution:

  Assumed editorial.

Issue closed.
------------------------------------------------------------------------
Issue 40.
URI: http://lists.w3.org/Archives/Public/www-style/2007May/0035.html
Description:

  Not clear what media style rules that are not qualified by an @media
  rule apply to.

Proposal:

  Add to the end of 7.2.1:
    Style rules outside of @media rules apply to all media types
    that the sheet applies to.

Resolution:

  Proposal accepted.

Issue closed.
------------------------------------------------------------------------
Issue 41.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2007AprJun/0277.html
Description:

  Initial containg block for fixed positioning and absolute positioning
  don't match.

Proposal:

  In 10.1 where it says
    If the element has 'position: fixed', the containing block is
    established by the viewport in the case of continuous media or
    the page box in the case of paged media
  change "page box" to "page area".

Resolution:

  Proposal accepted.

Issue closed.
