issues-1

CSS2.1 Last Call: Disposition of Comments
=======================================================================

This issues list covers issues in the Last Call Working Draft
http://www.w3.org/TR/2003/WD-CSS21-20030915/

==> There are open issues. Search for *WG*.

Search for lines starting with one of the following to find issues
that need work:

   *Bert*     -- Task for Bert to do (3 remaining)
   *Ian*      -- Task for Ian to do (1 remaining)

"Further communication is required" means we have yet to send an
e-mail reply. "Document to be updated" means we still need to make
changes to the spec based on decisions the group has made. "NOTE:" is
a note by Ian based on what was noticed during issue checking.

When discussing issues, please refer to them by issue number. The
numbers used here are the numbers we will use in the final disposition
of comments (assuming I'm the one who writes that, which would seem
sensible).

When replying to or following up on e-mails mentioned below, please cc
either www-style or w3c-css-wg, and include [CSS21] in the subject
line and the issue number somewhere clearly labelled either in the
subject line or the body. This will significantly aid my ability to
keep track of what issues have been dealt with and which still require
a formal reply from the working group.

========================================================================
Issue 1. "For 'top' and 'bottom', if the height of the containing
block is not specified explicitly (i.e., it depends on content
height), the percentage value is interpreted like 'auto'." in the
definition of <percentage> for top/right/bottom/left is probably
wrong.
Resolution: MacIE, WinIE, Safari, and Mozilla do this proposal. so,
strike the sentence: "For 'top' and 'bottom', if the height of the
containing block is not specified explicitly (i.e., it depends on
content height), the percentage value is interpreted like 'auto'." in
section 9.3.2 near the end under <percentage>.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 2. "If the height of the containing block is not specified
explicitly (i.e., it depends on content height), and this element is
not absolutely positioned, the value is interpreted like 'auto'." in
the definition of <percentage> for height is probably wrong.
Resolution: Issue retracted.
Issue closed.
------------------------------------------------------------------------
Issue 3. [retracted]
Issue closed.
------------------------------------------------------------------------
Issue 4. example at the end of 5.8.1 misspells Laurence Olivier's name
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 5. http://lists.w3.org/Archives/Public/www-style/2003Sep/0134.html
"In addition, we would like to extend special thanks to fantasai, Ada
Chan, and Boris Zbarsky, who have both contributed significant time to
CSS2.1." should not say "both" in the acknowledgements section.
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 6. http://lists.w3.org/Archives/Member/w3c-css-wg/2003JulSep/0371.html
(e-mail from Tantek, see note near bottom)
Resolution: Change the titles as follows:
 10.6.3 Block-level, non-replaced elements in normal flow when
        'overflow' computes to 'visible'
 10.6.6 Block-level, non-replaced elements in normal flow when
        'overflow' does not compute to 'visible'; 'inline-block',
        non-replaced elements; and floating, non-replaced elements.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 7. http://lists.w3.org/Archives/Member/w3c-css-wg/2003JulSep/0372.html
[margin collapsing / clear issue]
Resolution: Add this text after the "An element's own margins"
paragraph in 8.3.1:
"When an element's own margins collapse, and that element has had
clearance applied to it, its top margin collapses with the adjoining
margins of subsequent siblings but that resulting margin does not
collapse with the bottom margin of the parent block".
Testcase: http://weblogs.mozillazine.org/hyatt/images/016.html
Safari and MacIE do this as proposed.
WinIE behaviour is inexplicable.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 8. "'float', 'height' (if 'float' is not 'none'), 'width' (if
'float' is not 'none')" are missing from the list of properties that
apply to ':first-letter
Resolution: 'float' should apply, but not 'width' and 'height'.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 9. http://www.w3.org/mid/3F87E607.9030501@escape.com
background-position: The following should be dropped: "The computed
value of background-position for the purpose of inheritance is
undefined, since the allowed values on this property may have
different effects in a child element due to differences in size and
position of their respective boxes." (it's defined now)
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47516.180523.899733@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 10. background-position should apply to inline elements,
although it's exact behaviour should not be defined in 2.1. (as it
says under background-repeat)
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 11. Section 6.1.2. "by the 'Applies To' [add reference] line" -- we
should add the reference.
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 12. Acknowledgements: the names "Lars Knoll" and "Peter Sheerin"
are repeated twice.
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 13. 9.2.4 The 'display' property: "table, inline-table,
table-row-group, table-column, table-column-group, table-header-group,
table-footer-group, table-row, table-cell, and table-caption": only
table-column is a link.
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 14. What is the computed value of:
   font-size: x-large;   -- is it 'x-large' or a platform-native length value?
   font-size: larger;    -- is it 'xx-large' or a platform-native length value?
   border: thin solid;   -- is it 'thin solid' or is it '1px solid'?
Resolution: Issue retracted.
Issue closed.
------------------------------------------------------------------------
Issue 15a. Text of CR exit criteria.
   http://lists.w3.org/Archives/Member/w3c-css-wg/2003JulSep/0411.html
   http://lists.w3.org/Archives/Member/w3c-css-wg/2003JulSep/0412.html
   [...]
   http://lists.w3.org/Archives/Member/w3c-css-wg/2003OctDec/0101.html (proposal)
Resolution: Agreed.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 15b. http://lists.w3.org/Archives/Public/www-style/2003Sep/0106.html
Text of CR exit criteria.
[for the last one, propose we say "If we make such changes, we will go
back to last call for a quick review period, then skip CR (since we
will be able to show interoperability straight away)" - ian]
This is due to section 7.4.3 of the process document:
<dbaron> http://www.w3.org/2003/06/Process-20030618/tr.html#cfi
<dbaron> "In the Call for Implementations, the Working Group MAY
identify specific features of the technical report as being "features
at risk." General statements such as "We plan to remove any
unimplemented feature" are not acceptable; the Working Group MUST
precisely identify any features at risk. Thus, in response to a Call
for Implementations, reviewers can indicate whether they would
formally object to the removal of the identified features."
Resolution: Change part 4 of the CREC to read:
4. Features that were not in CSS1 will be dropped (thus reducing the
   list of "all" features mentioned above) if two or more
   interoperable implementations of those features are not found by
   the end of the CR period.
Reply: http://www.w3.org/mid/16423.47436.256257.359604@lanalana.inria.fr
Response: http://www.w3.org/mid/403fab30.584920010@smtp.bjoern.hoehrmann.de
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402101410250.25633@dhalsim.dreamhost.com
Document updated.
Response: http://www.w3.org/mid/40421333.611546407@smtp.bjoern.hoehrmann.de
Reply: http://www.w3.org/mid/BC5641E9.3673B%25tantek@cs.stanford.edu
Reply: http://www.w3.org/mid/BC5645EC.3673F%25tantek@cs.stanford.edu
Response: http://www.w3.org/mid/40540e79.349908081@smtp.bjoern.hoehrmann.de
Reply: http://www.w3.org/mid/BC565859.36759%25tantek@cs.stanford.edu
Response: http://www.w3.org/mid/405619dc.352823283@smtp.bjoern.hoehrmann.de
Reply: http://www.w3.org/mid/BC5677AD.367B5%25tantek@cs.stanford.edu
Response: http://www.w3.org/mid/405b38e7.360770710@smtp.bjoern.hoehrmann.de
Reply: http://www.w3.org/mid/BC5690FE.367D8%25tantek@cs.stanford.edu
Response: http://lists.w3.org/Archives/Public/www-style/2004Feb/0315.html
The working group can no longer work out what the issue is.
Issue remained open.
------------------------------------------------------------------------
Issue 16. http://lists.w3.org/Archives/Member/w3c-css-wg/2003JulSep/0416.html
[overflow:hidden and .scrollTop]
Resolution:
| <Bert> ACTION Tantek: make change proposed by David Baron
| <Bert> "users have no access to hidden content" <-- strike sentence
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 17. Two instances of "color properties" in the selector chapter should
be "color property" as there is only one.
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 18a. 'fixed' in section 10.1 (visudet/containing block) is defined as:
# If the element has 'position: fixed', the containing block is
# established by the viewport.
...but in section 9.3.1 (visuren/position) is defined as:
# In the case of the print media type, the box is fixed with respect
# to the page, even if that page is seen through a viewport (in the
# case of a print-preview, for example).
...(without saying that it occurs on every page) and in section 9.6.1
(visuren/fixed positioning) as:
# For paged media, boxes with fixed positions are repeated on every
# page.
These three definitions need to be made consistent.
Resolution: Change 10.1 item 3 to read: "If the element has 'position:
fixed', the containing block is established by the viewport <ins>in
the case of continuous media or the page box in the case of paged
media.</ins>".
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 18b. Also, it needs to be clear whether position:fixed elements
appear on "earlier" pages or not too. (I (ian) think they should. It's
the only logical way of looking at it IMHO. Especially given what we
said about position: absolute.)
Resolution: Retracted.
Issue closed.
------------------------------------------------------------------------
Issue 19. We have no way of positioning something relative to the page
and only render it on one page. Is that a problem? Should we
explicitly say we don't support that?
Resolution: Move to CSS3.
Issue closed.
------------------------------------------------------------------------
Issue 20. If you can relatively position table cells / columns /
column groups / rows / row groups (or give them 'opacity', it doesn't
matter -- anything that either moves them, or makes them generate a
stacking context), then, er, good lord. Can we disallow that? If we
don't, we need to define the stacking context algorithm for that.
Resolution: Add "The effect of a 'position: relative' declaration on
table-row-group, table-header-group, table-footer-group, table-row,
table-column-group, table-column, table-cell, and table-caption
elements is undefined." to 9.3.1 Choosing a positioning scheme:
'position' property.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 21. The diagram at the bottom of 9.5 (before 9.5.1) is wrong now.
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 22. I think we should explicitly say in the paragraph in 9.5.1
reading "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." that "The collapsing of earlier margins
is affected by this, and indeed the float could move as a result."
See, e.g., http://www.damowmow.com/playground/bugs/204831/001.html
       vs. http://www.damowmow.com/playground/bugs/204831/002.html
The float in the first should be lower than in the second.
Note: The proposed text needs a tweak actually. We need to say
that it is the final position of the float that decides where
everything should go. IMHO. - ian
Resolution: Don't change it at all.
Issue closed.
------------------------------------------------------------------------
Issue 23. http://lists.w3.org/Archives/Public/www-style/2003Sep/0134.html
| Section 1.4.2, "Applies To" paragraph
| This should probably say "elements with display:table" instead of "table
| elements" (since the latter typically means "elements with a tag name of
| 'table'").
Resolution: We don't think it's ambiguous because single quotes mean
CSS keywords by convention. No change.
Reply: http://www.w3.org/mid/16423.47511.546847.222294@lanalana.inria.fr
Alternate resolution suggested by howcome:
  http://www.w3.org/mid/200311060755.hA67tTG21906@mail.opera.no
Issue closed.
------------------------------------------------------------------------
Issue 24. http://lists.w3.org/Archives/Public/www-style/2003Sep/0134.html
| Section 1.4.5
| "after" may be better than "to the right".  For example, in aural rendering,
| this would be the case....
| I can't check how this actually renders in various UAs because a quick look at
| the section of the specification with the most images (Chapter 9) doesn't show
| any images provided with a long description link as described... (and none have
| a "longdesc" attribute).
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47509.532308.973825@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 25 -- 32. Duplicates of issues 38 -- 45.
------------------------------------------------------------------------
Issue 33. http://lists.w3.org/Archives/Public/www-style/2003Sep/0096.html
| http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q15
| The new first paragraph in block formatting context is good and makes
| me think i understand the questions i had on floats earlier. However,
| i think an example or two would be helpful to more clearly show for
| instance how an element that generates a new block formatting context
| affects its containing blocks size when the containing block also
| generates a new block formatting context (is this described somewhere
| else? I failed to find it if so). I also think some kind of more
| explicit pointer to this effect should be supplied in the calculating
| widths/heights sections (or is the effect seen more as an implicit
| min-width/min-height?).
Resolution: We don't think an example would necessarily be useful.
This would be more useful in a tutorial than a spec.
Reply: http://www.w3.org/mid/16423.47507.261788.447475@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 34. http://lists.w3.org/Archives/Public/www-style/2003Sep/0096.html
| Something i dont understand is why non-initial overflow needs to
| generate a new block formatting context?
Resolution: Floats don't make sense across scrolling boundaries.
Reply: http://www.w3.org/mid/16423.47504.714489.749441@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 35. http://www.w3.org/mid/3F684CB4.21220.7532AF@localhost
| http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats
| The new paragraph on how the margin box of a block that generates a
| new block formatting context interacts with floats in the same block
| context is helpful, but i think perhaps the effect of a float nested
| inside an element wich generates a new block formatting context along
| with more examples would help even further (eg a float in a table
| cell). The way things in the draft are currently written the example
| under the paragraph probably belongs to the previous paragraph, which
| could be a bit confusing.
Resolution: See the upcoming test suite for some examples.
Reply: http://www.w3.org/mid/16423.47497.565605.768575@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 36. http://www.w3.org/mid/3F684CB4.21220.7532AF@localhost
| http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats
| The paragraph is a little vague on how to handle the conflict between
| a float and another block that generates a new block formatting
| context when they are in the same block formatting context. Why not
| require that the box is cleared? When is it desirable to position it
| adjacent, creating a kind of a "pseudo-float"?
Resolution: Because thats what UAs interoperably do, and the adjacent
position is desirable if there is enough room.
Reply: http://www.w3.org/mid/16423.47500.745841.146514@lanalana.inria.fr
Response: http://www.w3.org/mid/40293751.19528.946EC7@localhost
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402161501270.2210@dhalsim.dreamhost.com
Issue closed.
------------------------------------------------------------------------
Issue 37. http://www.w3.org/mid/3F684CB4.21220.7532AF@localhost
| http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats
| As an editorial comment i noticed that the phrase "block formatting
| context" was only occationally linked to its defintion, in case this
| is not intentional.
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47519.552017.332738@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 38. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.1.1
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#tokenization>
| Is it intended that '_' be a valid "ident" production?  At the moment it is.  So is
| '-_', for that matter.  Perhaps the "ident" production should be defined as:
|   ident    [-_]?{nmstart}{nmchar}
| and the "nmstart" definition retained as it was in CSS2
| ([a-zA-Z]|{nonascii}|{escape}) ?  No strong feelings either way here, it's just
| that the current proposal seems a bit odd.
Resolution: It's odd but it works and we're happy with it, so, let's keep it.
Reply: http://www.w3.org/mid/16423.47495.436082.810858@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 39. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.1.1
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#tokenization>
| Definition of the "unicode" production does not match Appendix G.
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47497.565605.768575@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 40. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.1.1
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#tokenization>
| Is there a reason that CDO and CDC are allowed at all places in the stylesheet
| between rules?  This seems to complicate parsing unnecessarily.  Is it desired
| that CDO/CDC be allowed in linked stylesheets?  They would seem very out of
| place there....  Perhaps I am misunderstanding what this is actually saying; if
| so, perhaps an informative note is in order to clarify the situation?
Resolution: It's odd but it works and we're happy with it, so, let's keep it.
Reply: http://www.w3.org/mid/16423.47479.358400.437258@lanalana.inria.fr
Response: http://www.w3.org/mid/4027D6C6.5000504@mit.edu
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402092217060.9897@dhalsim.dreamhost.com
Response: http://www.w3.org/mid/402811FA.8010105@mit.edu
Issue closed.
------------------------------------------------------------------------
Issue 41. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.3.4
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#uri>
| The text:
|    Parentheses, commas, whitespace characters, single quotes (') and
|    double quotes (") appearing in a URI must be escaped with a
|    backslash: '\(', '\)', '\,'.
| is misleading, since they in fact do not have to be escaped if the URI string
| is in quotes.  Also, it is not immediately clear to me why commas are included
| in the list.  Is there a reason.
Resolution: Add "unquoted" before "URI" in that quoted text. Commas
are escaped for future expansion.
Document updated.
Reply: http://www.w3.org/mid/16423.47493.492358.743155@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 42. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.3.4
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#uri>
| What happens if the URI string is not a syntactically valid URI?  For example:
|   url(http:/www.example.com/)
| or something along those lines?  Does this affect the parsing or style
| computation phase, or is this handled only when the resource actually needs to
| be loaded, thus falling under the "User agents may vary" clause at the end of
| the section?

(Original resolution: Computed <uri>s are the given specified URI,
except if it is a relative URI in which case the computed URI is the
absolute URI. Add to the end of the second paragraph of 6.1.2, "The
computed value for a valid relative URI is its absolute equivalent;
for other URIs, the computed value is as specified.". Invalid URIs are
not CSS syntax errors. We will also add "invalid URIs or" between
"handle" and "URIs" in the "user agents may vary" clause in 4.3.4.)

Resolution: Add "invalid URIs or" between "handle" and "URIs" in the
"user agents may vary" clause in 4.3.4.

Resolution changed due to issue resolution conflict. See:
   http://www.w3.org/mid/Pine.LNX.4.58.0401221524260.3387@dhalsim.dreamhost.com

Document updated.
Reply: http://www.w3.org/mid/16423.47491.180111.711062@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 43. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.3.7
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#strings>
| The language
|   Double quotes cannot occur inside double quotes, unless escaped (as '\"' or
|   as '\22').
| is somewhat misleading, since there are other ways that a quote could be
| escaped (eg using \000022).  Perhaps an "e.g.," at the beginning of the
| parenthetical remark is in order?  Same for single quotes.
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47488.226429.681347@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 44. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.4
| < http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q23>
| What about stylesheets that have a BOM but no @charset rule?  Should the
| presence of a BOM imply that the sheet is encoded as, eg UTF-8 or UTF-16LE (if
| the appropriate BOM is present), as it does for XML?
Original resolution: We should allow UAs to either ignore BOMs, or
handle BOMs in the absence of other encoding information.
Resolution: Accept the proposed changes but make sure the six (title,
two in 4.4, three in 4.4.1) occurances of "document" that mean "style
sheet" are changed to say "style sheet". Also replace "("big-endian"
or "little-endian")" with "(e.g. "big-endian" or "little-endian")".
Document updated.
Reply: http://www.w3.org/mid/16423.47486.259702.273080@lanalana.inria.fr
Response: http://www.w3.org/mid/4027D14A.6090707@mit.edu
Resolution: Deal as part of issue 45.
Issue closed.
------------------------------------------------------------------------
Issue 45. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.4
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q23>
| Another point is that it's trivial to have a stylesheet for which steps 1, 2, 3
| will give no useful charset value.  In fact, the vast majority of stylesheets
| currently on the web fall into this category.  Is the behavior UA-dependent in
| that case?  If so, this should be explicitly stated, I think.  Personally, I
| think it would be worthwhile to specify behavior in that eventuality.
Resolution: It's UA dependent.
Document updated.
Reply: http://www.w3.org/mid/16423.47481.705244.729423@lanalana.inria.fr
Response: http://www.w3.org/mid/4027D1AD.6050502@mit.edu
("please just specify it don't make it UA defined")
Resolution: change those four points to be (using the current text for
the first two rules):
  1. HTTP Content-Type,
  2. @charset,
  3. BOM,
  4. <link charset=""> or other metadata from the linking mechanism (if any),
  5. charset of referring document (if any),
  6. UA-defined.
Reply: http://www.w3.org/mid/16427.61280.674857.670826@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 46. http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
| Section 5.5 (Descendant Selectors)
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#descendant-selectors>
| This says, in the example:
|   "the whitespace is the descendant selector indicating..."
| The whitespace is a combinator which makes the whole selector a descendant
| selector, no?  Which is not what that's saying...
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47484.197984.890496@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 47. http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
| Section 5.10 (Pseudo-elements and pseudo-classes)
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#pseudo-elements>
| Why are "Conforming HTML UAs" exempted from :first-line and :first-letter?
| There seems to be no good reason for this.
Resolution: Remove the exemption.
Document updated.
Reply: http://www.w3.org/mid/16423.47476.811572.917445@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 48. http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
| Section 5.11.1 (:first-child pseudo-class)
| <http://www.w3.org/Style/css2-updates/WD-CSS21-20030915-diff/selector.html#first-child>
| This needs to define what a "first child" is.  From what I can tell, the intent
| is to match elements that would match both the "* > *" and "* + *" selectors.
| In particular, the <span> in both examples below would match :first-child:
|    <p>This is a <span>test.</span></p>
|    <p><!-- Of the emergency --> broadcast system</p>
| Perhaps something like, "The :first-child pseudo-class matches an element node
| that is the first element node in the child node list of some other element
| node"?
Addendum: http://www.w3.org/mid/200309282215.h8SMFaHS029555@nerd-xing.mit.edu
| I meant:
|   Match the "* > *" selector but not the "* + *" selector
| of course.
Resolution: Add "element" after "first child" in 5.11.1
Document updated.
Reply: http://www.w3.org/mid/16423.47474.310916.815551@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 49. http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
| Section 5.11.3 (The dynamic pseudo-classes: :hover, :active, and :focus)
| <http://www.w3.org/Style/css2-updates/WD-CSS21-20030915-diff/selector.html#dynamic-pseudo-classes>
| If an element is hovered, are its ancestors considered hovered?  Is this
| UA-dependent, or should it be specified?
| The example used is somewhat unfortunate because it encourages using selectors
| like "a:hover" which don't do quite what page authors expect based on this
| example (in particular, "a:hover" applies to named anchors, while ":link" and
| ":visited") do not.  I'm not sure how one could replace this example while
| still illustrating the order-dependence, though....
Daniel says: Similarly, how about columns.
Resolution: Leaving this undefined for CSS21:
 + say that whether :hover and :active apply to ancestors is undefined
 + add to note at end of 5.11.3 about :active in CSS1 only applying to links.
Reply: http://www.w3.org/mid/16423.47472.101982.551480@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 50. http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
| Section 5.12.2 (The :first-letter pseudo-element)
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-letter>
| 'float' is not listed as a propety that applies to :first-letter
| pseudo-elements.  An editing error?
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47469.609757.962247@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 51. http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
| Section 5.12.2 (The :first-letter pseudo-element)
| The last paragraph of the example with the floated 'T' says:
|   Note that the :first-letter pseudo-element tags abut the content (i.e., the
|   initial character), while the :first-line pseudo-element start tag is
|   inserted right after the start tag of the element to which it is attached.
| I'm not sure what this means, in light of the example for :first-line, in which
| we get the fictional tag sequence: <div><p><div:first-line><p:first-line> ...
| This section should also make it clear that given markup like:
|    <div>
|    <p>
|    Some text
|    more text
|    </p>
|    </div>
| with the linebreak occurring where I show it, the fictional tag sequence is:
|    <div><p>
|      <div:first-line><p:first-line>
|        <div:first-letter><p:first-letter>S</p:first-letter></div:first-letter>omeText
|      </div:first-line></p:first-line>
|      more text
|    </p></div>
| because right now, it only makes clear the interaction of first-letter and
| first-line when both are set on the same element, and does not specify the
| ordering of p:first-line and div:first-letter in the above example.
Resolution: No issue?
Reply: http://www.w3.org/mid/16423.47467.145644.35114@lanalana.inria.fr
Response: http://www.w3.org/mid/4027D4A5.5020303@mit.edu
Resolution: Yes, we will define that with that example.
Reply: http://www.w3.org/mid/16434.31687.655120.182477@lanalana.inria.fr
Response: http://www.w3.org/mid/200402172058.i1HKwk6J018767@no-knife.mit.edu
Reply: http://www.w3.org/mid/16442.20892.588427.737747@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 52. http://www.w3.org/mid/200309282304.h8SN40r2004872@nerd-xing.mit.edu
| Section 6.4.3 (Calculating a selector's specificity)
| The spec says:
|    li:first-line {}  /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,2 */
| It should say d=2 here.
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47464.897110.526868@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 53. http://www.w3.org/mid/200309282304.h8SN40r2004872@nerd-xing.mit.edu
| Section 6.4.4 (Precedence of non-CSS presentational hints)
| Why is "dir" not considered a presentational hint?
Resolution: because it is not. ("why are you asking us?")
Reply: http://www.w3.org/mid/16423.47460.927696.499175@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 54. http://www.w3.org/mid/200309282304.h8SN40r2004872@nerd-xing.mit.edu
| Section 6.4.4 (Precedence of non-CSS presentational hints)
| "type" is not presentational in some cases, but presentational in others (on
| <ol>, <ul>, <li>, to be precise).
Resolution: type on lists is not presentational.
Reply: http://www.w3.org/mid/16423.47458.270282.447366@lanalana.inria.fr
Response: http://www.w3.org/mid/4027D22B.7040706@mit.edu
Resolution: add "(except on LI, OL and UL elements)" after "type" in
the list in section 6.4.4.
Document updated.
Reply: http://www.w3.org/mid/16434.32592.921798.559429@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 55. http://www.w3.org/mid/200309282315.h8SNFiEh006969@nerd-xing.mit.edu
| Section 7.3 (Recognized media types)
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/media.html#media-types>
| What does "The names of media types are normative" mean?  What should a UA do
| when encountering an @media or @import rule that lists an unknown media type?
| E.g.
| @media screen, boomerang {
|  ....
| }
hakon says: http://www.w3.org/mid/200311031937.hA3JbsG24559@mail.opera.no
| I reworded the text sightly to address Boris first concern. I do not
| suggest discussing @boomerang.
Resolution: Agreed; also add: "Unknown media type identifiers should
not result in the @media rule being ignored." somewhere. Also strike
"parenthetical" in the text "names of media types are normative, but
the parenthetical descriptions are informative".
Reply: http://www.w3.org/mid/16423.47455.464079.962636@lanalana.inria.fr
Document updated.
Response: http://www.w3.org/mid/4027D1EB.5070006@mit.edu
Resolution: Remove "parentherical".
Document updated.
Reply: http://www.w3.org/mid/16434.33059.22990.896833@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 56. http://www.w3.org/mid/1064856561.a6c4b580cmoschini@myrealbox.com
| In the CSS2.1 Default HTML Style sheet:
|    http://www.w3.org/TR/CSS21/sample.html
| It still says that CSS2.1 cannot fully express the presentation
| of elements like img and frame. Yet CSS3 can, like so:
|    img, object, applet, embed, iframe, frame, frameset {
|      display:inline-block;
|    }
|    -- http://www.w3.org/TR/2003/WD-css3-ui-20030703/#qA
| With the introduction of inline-block to CSS2.1, it can in fact
| fully define all these elements' presentation. This and several
| other sections of the sample stylesheet need to be updated to
| reflect this newly available value in CSS2.1.
Reply: http://www.w3.org/mid/20030929175350.GA4936@darby.dbaron.org
| That doesn't fully describe the presentation, since it doesn't say what
| the replaced content is.  Doing that requires CSS3.
| [...]
| The addition of 'inline-block' doesn't change *anything* for replaced
| elements, since the rules for inline and inline-block replaced elements
| are exactly the same.  ('inline-block' allows non-replaced elements to
| act like inline replaced elements.)
Resolution: no change.
Issue closed.
------------------------------------------------------------------------
Issue 57. http://www.w3.org/mid/5D96738D926D724CA6744CB249F6799D17E5CA@RED-MSG-53.redmond.corp.microsoft.com
| http://www.w3.org/TR/CSS21/visufx.html
| The example list of overflow cases includes:
|   - A descendent box has negative margins, causing it to be positioned
|   partly outside the box.
| Even though this list is not meant to be comprehensive, I suggest we
| similarly add:
|   - A descendent box is relatively positioned, causing it to be positioned
|   partly outside the box.
| And change:
|   "An element's height exceeds"
| to
|   "An element's height (or line-height) exceeds"
| I think it's also possible that vertical-align of an absolute length
| (e.g. 200px) can also cause overflow.
Internal Reply: http://www.w3.org/mid/20031001001902.GA3745@darby.dbaron.org
| I'd prefer not to mention line-height here, since I don't think the
| logical box considered by line-height should be considered to be
| overflow.  I think only the box generated by the font edge, padding,
| border (and margin?) should be considered overflow.  That doesn't mean
| that the line-height couldn't cause overflow by increasing the height of
| a block, but the existing text accounts for that.  If that's what you
| meant by the addition of the parenthetical comment, I'd rather not say
| that because I think it could be misinterpreted.
|
| Perhaps we should define what counts as overflow a little more clearly.
| For example, we could say whether it's the border-box, the margin-box,
| or the union of the two that defines the part of a box considered when
| computing overflow.  Mozilla does border-box, and it would be rather
| difficult to change.  Saying that it's only the margin-box would
| probably be a bad idea because of negative margins.  The existing text
| isn't clear at all, and could be interpreted as undefined, as
| content-box, or perhaps as margin-box.
Resolution: no change.
Issue closed.
------------------------------------------------------------------------
Issue 58. http://www.w3.org/mid/15E88F9C-F3A7-11D7-B3E3-00039382AC6C@apple.com
| This reminds me of a question I had about relative positioning and
| overflow.  It seems like the rule of relative positioning is that the
| object is not supposed to have any effect on the layout of following
| objects.  However, if you decide that the final position of the object
| (once offset) constitutes overflow, and if overflow is set to auto, are
| you supposed to show scrollbars in order to scroll to the object?
|
| If you do show scrollbars, then you have just affected the layout of
| the object that follows you, despite the fact that the spec says you
| should not.  Right now, when deciding whether or not to show
| scrollbars, Safari actually looks at the untranslated position and so
| Safari will not provide the ability to scroll to see the relative
| positioned content, but I suspect this might be different from other
| browsers.
Resolution: http://lists.w3.org/Archives/Member/w3c-css-wg/2003OctDec/0004.html
| Change 9.4.3 (visuren "Relative positioning"): Add "However, if
| relative positioning causes an overlflow:auto box to have overflow,
| the UA must allow the user to access this content, which, through the
| creation of scrollbars, may affect layout." to the first paragraph.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 59. text-decoration model discussion
Original thread:
  http://www.w3.org/mid/3F7B235B.20958.28A853@localhost (needs answer A)
  http://www.w3.org/mid/200310011710.h91HArhC013740@nerd-xing.mit.edu (reply)
  http://www.w3.org/mid/3F7B2B12.5571.46C81E@localhost (reply)
  http://www.w3.org/mid/Pine.GSO.4.58.0310012037070.20874@korppi.cs.tut.fi (needs answer B)
  http://www.w3.org/mid/3F7B457C.12276.ADF822@localhost (reply)
  http://www.w3.org/mid/Pine.GSO.4.58.0310012255100.25242@korppi.cs.tut.fi (reply)
  http://www.w3.org/mid/3F7B596C.2060902@escape.com (good answer to B)
  http://www.w3.org/mid/Pine.GSO.4.58.0310020923540.11649@korppi.cs.tut.fi (needs answer C)
  http://www.w3.org/mid/3F7C661B.12938.2A2F51@localhost (CSS3 comments)
Issue split into 59a, 59b, 59c.
Issue closed.
------------------------------------------------------------------------
Issue 59a. http://www.w3.org/mid/3F7B235B.20958.28A853@localhost
Resolution: That's the way it was in CSS1.
Reply: http://www.w3.org/mid/16423.47452.313141.937717@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 59b. http://www.w3.org/mid/Pine.GSO.4.58.0310012037070.20874@korppi.cs.tut.fi
Reply: http://www.w3.org/mid/3F7B596C.2060902@escape.com
Reply: http://www.w3.org/mid/16423.47446.538444.910079@lanalana.inria.fr
Resolution: It was in CSS1 and is heavily used.
Issue closed.
------------------------------------------------------------------------
Issue 59c. http://www.w3.org/mid/Pine.GSO.4.58.0310020923540.11649@korppi.cs.tut.fi
Reply: http://www.w3.org/mid/16423.47449.480503.679534@lanalana.inria.fr
Resolution: We do not see any reason to deprecate.
Issue closed.
------------------------------------------------------------------------
Issue 60. formatting context discussion
Thread:
  http://www.w3.org/mid/3F7B3147.4242.5F08EB@localhost (query)
  http://lists.w3.org/Archives/Public/www-style/2003Oct/0050.html (reply)
  http://www.w3.org/mid/3F89D7DF.13755.2A8DAB4@localhost (further query)
  http://www.w3.org/mid/Pine.LNX.4.58.0310131334280.29626@dhalsim.dreamhost.com (reply)
  http://www.w3.org/mid/3F8AF0D5.15739.531E32@localhost (issue)
Issue split into 60a, 60b, 60c.
Issue closed.
------------------------------------------------------------------------
Issue 60a. The term "based on the content" in 10.6.4 Absolutely
positioned, non-replaced elements is not defined. (If it is, it needs
a link to the definition.) (Occurs twice.)
Resolution: leave it up to Bert to resolve. [Added section 10.6.7
'Auto' heights for block formatting context roots based on Oslo
decision]
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 60b. In 9.4.1 Block formatting context, paragraph 3 is no longer
true for elements that generate new block formatting contexts but are
still in flow.
Resolution: Add ", unless the child establishes a new block formatting
context" to end of paragraph?
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 60c. http://www.w3.org/mid/3F8AF0D5.15739.531E32@localhost
Should inline-blocks that contain floats shrink wrap them?
Resolution: Yes. Covered by issue 6 resolution.
Reply: http://www.w3.org/mid/16423.47443.397987.150474@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 61. http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
| Section 8.1 (Box Dimensions)
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#box-dimensions>
| The description of "content edge or inner edge" makes it sound like this edge
| always surrounds the "rendered content"; the latter term is sort of vaguely
| defined.  The overall impression given is that given the markup:
|    <div style="height: 1px">
|    line<br>
|    line2
|    </div>
| the "content edge or inner edge" will surround both lines (which is of course
| not the case).
| I hesitate to suggest a better wording offhand, though...  Perhaps "content
| area" instead of "rendered content", with a link to a few paragraphs below
| where it says "The dimensions of the content area of a box ..."?
Resolution: Not a problem since 8.1 is rather vague anyway.
Reply: http://www.w3.org/mid/16423.47439.784732.980081@lanalana.inria.fr
Response: http://www.w3.org/mid/4027DDFA.7090700@mit.edu
Reply: http://www.w3.org/mid/20040209194019.GA6816@darby.dbaron.org

Proposal: A simple proposal to fix this issue is to change:

  The content edge surrounds the element's rendered content.

to:

  The content edge surrounds the rectangle given by the width and height
  of the box, which often depend on the element's rendered content.

(Note that "width" and "height" are not links to properties, since that
would be inappropriate for some types of boxes, but they could be links
to sections 10.3 and 10.6.)

Resolution: Take change.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 62. http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.1 (Box Dimensions)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#box-dimensions>

The definition of "box width" given in this section gives me some pause.  The
only mentions of the term "box width" in chapters 8-18 of the specification
(other than this definition) are:

A)  A statement immediately preceding that says that box widths are explained
    in a later chapter.
B)  Discussion of percent values for left/right (section 9.3.1 Choosing a
    positioning scheme: 'position' property).  The prose there says these
    are percentages of the "containing block's box width"; is it really intended
    that he containing block's margin's affect the offset from the padding edge in
    this case, per the definition of "box width"?
C)  Discussion of min-width/max-width (10.4 Minimum and maximum widths:
    'min-width' and 'max-width').  The prose here says that these properties
    constrain "box widths".... except that's not true according to the Section
    8.1 definition of "box width".  They constrain content widths.
D)  A reference to "page box width" in chapter 13.  This also seems to want the
    content width.

In short, there is no usage of this term in this specification that is
consistent with the definition.  I suggest striking the definition and changing
the two uses to refer to content widths, since that seems to be the desired
effect.

The "box height" seems similarly useless.

Resolution: Remove definition of box width and box height (A),
Document updated.

Resolution: change occurrences B (remove "box")
Document updated.

Resolution: and C (use "content width" instead of "box width").
Document updated.

Resolution: D is referring to the {{page box} width} not the {page
{box width}}.
Reply: http://www.w3.org/mid/16423.47433.476395.452258@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 63. http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.2 (Example of margins, padding, and borders)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#mpb-examples>

"The height of each LI box is given by its content height, plus top and bottom
padding, borders, and margins."  What does that mean, exactly?  That is, what
does "the height of each LI box" in real terms?  The exampls does not really
say what this quantity (which is not even well-defined in the presence of
margin collapsing) is used for.

Resolution: Only an example.
Reply: http://www.w3.org/mid/16425.21820.894632.976802@lanalana.inria.fr
Response: http://www.w3.org/mid/4029683C.5050304@mit.edu
Resolution: Use 'margin-box height' instead of 'height'.
Document updated.
Response: http://www.w3.org/mid/200402161730.i1GHUrOC012037@nerd-xing.mit.edu
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402161755520.2210@dhalsim.dreamhost.com
Issue closed.
------------------------------------------------------------------------
Issue 64. http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.3.1 (Collapsing margins)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html>
  "Collapsing is based on the computed value of 'padding', 'margin', and
  'border'."
The computed value of margin properties is "the percentage as specified or the
absolute length".  What exactly does it mean for collapsing be based on the
computed value if that can be "the percentage as specified"?  Especially if the
collapsing margins belong to boxes with different containing blocks (and hence
different meanings of percentage values)?
Resolution: Changed "computed" to "used".
Reply: http://www.w3.org/mid/16425.21827.40104.443466@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 65. http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.4 (Padding properties: 'padding-top', 'padding-right',
'padding-bottom', 'padding-left', and 'padding')
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#padding-properties>
Unlike margin and border, conforming HTML user agents _do_ have to apply
padding to <html>?
Resolution: \/\/hatever. Non-issue.
Reply: http://www.w3.org/mid/16425.21831.313768.129260@lanalana.inria.fr
Response: http://www.w3.org/mid/402968C8.8050807@mit.edu
Resolution: Remove the two other caveats.
Document updated.
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402171524260.14033@dhalsim.dreamhost.com
Issue closed.
------------------------------------------------------------------------
Issue 66. http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.5.4 (Border shorthand properties: 'border-top', 'border-bottom',
'border-right', 'border-left', and 'border')
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#border-shorthand-properties>
The heading should list top, right, bottom, left in that order, probably.
Resolution: No change.
Reply: http://www.w3.org/mid/16425.21835.556302.689718@lanalana.inria.fr
Response: http://www.w3.org/mid/4029694D.4030101@mit.edu
Resolution: We'll fix it for you.
Document updated.
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402171526230.14033@dhalsim.dreamhost.com
Issue closed.
------------------------------------------------------------------------
Issue 67. http://www.w3.org/mid/3F81EB3F.5020400@escape.com
These two sentences are in conflict:
S4.1.3 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q6>:
# In CSS 2.1, identifiers... cannot start with a hyphen or a digit.
S4.1.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q4>:
# In CSS2.1, identifiers may begin with '-' (dash) or '_' (underscore).
Resolution: Strike "a hyphen or" from 4.1.3.
Document updated.
Reply: http://www.w3.org/mid/16425.21839.732821.339942@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 68. http://www.w3.org/mid/3F81EB3F.5020400@escape.com
S4.1.7 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q10>:
# A rule set (also called "rule") consists of a selector followed by
# a declaration block.

What you're saying here is that a "rule" is also a "set of rules".
The construct should be either singular /or/ plural, not both at the
same time. Please pick *one*. (And make sure its use is consistent.)

# A declaration-block (also called a {}-block in the following text)
# starts with a left curly brace ({) and ends with the matching right
# curly brace (}).

Is there a particular reason why "declaration-blocks" are not defined in
terms of "blocks" (as defined in the previous section)?

And don't call it a {}-block. @media rules have braces-delimited blocks,
too. Just call it a declaration block. It's a nice, unambiguous term;
there's nothing wrong with it.

Resolution: No change.
Reply: http://www.w3.org/mid/16425.21844.920400.9373@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 69. http://www.w3.org/mid/3F81EB3F.5020400@escape.com
S4.1.9 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#comments>:
# CSS also allows the SGML comment delimiters ("<!--" and "-->") in
# certain places, but they do not delimit CSS comments. They are
# permitted so that style rules appearing in an HTML source document
# (in the STYLE element) may be hidden from pre-HTML 3.2 user agents.
# See the HTML 4.0 specification ([HTML40]) for more information.

It says SGML comment delimiters are allowed "in certain places". Very
mysterious-like, especially considering the amount of detail about
HTML. Why not say where exactly?
And why is the definitive CSS document referring to the HTML 4.0 spec
for details about CSS syntax? Or is the "more information" more
information about hiding from pre-HTML 3.2 user agents, not "more
information" about, like, where the comment delimiters may be placed?

Resolution: Change text to say "in certain places _defined by the
grammar_" in section 4.1.9.
Document updated.
Reply: http://www.w3.org/mid/16425.21847.694241.729068@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 70. http://www.w3.org/mid/3F81EB3F.5020400@escape.com
S4.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#parsing-errors>:
# Malformed declarations. User agents must handle unexpected tokens
# encountered while parsing a declaration by reading until the end
# of the declaration, while observing the rules for matching pairs
# of (), [], {}, "", and '', and correctly handling escapes.

What happens if there's a mismatched bracket?
   elem {pro[perty: value; }

Resolution: Say that "How to handle unparseable and untokenisable
stylesheets is undefined in CSS2.1." in section 4.1.1.
Reply: http://www.w3.org/mid/16425.21850.243743.700512@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 71. http://www.w3.org/mid/3F81EB3F.5020400@escape.com
S4.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#parsing-errors>:
# Malformed declarations. User agents must handle unexpected tokens
# encountered while parsing a declaration by reading until the end
# of the declaration, while observing the rules for matching pairs
# of (), [], {}, "", and '', and correctly handling escapes.

[What happens if there's] a string with an unescaped newline?
   elem {prop: "string }

Resolution: Same as issue 70.
Issue closed.
------------------------------------------------------------------------
Issue 72. http://www.w3.org/mid/3F81EB3F.5020400@escape.com
S4.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#parsing-errors>:
# Malformed declarations. User agents must handle unexpected tokens
# encountered while parsing a declaration by reading until the end
# of the declaration, while observing the rules for matching pairs
# of (), [], {}, "", and '', and correctly handling escapes.

I can't seem to find "the rules for matching pairs of (), [],
{}, "", and ''".

Resolution: Don't add more text.
Reply: http://www.w3.org/mid/16425.21852.427012.28881@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 73. http://www.w3.org/mid/3F81EB3F.5020400@escape.com
S4.3.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#length-units>:
# In cases where the computed length cannot be supported, user agents
# must approximate it in the actual value.
                             ^^^^^^^^^^^^
Actual values haven't been defined at this point. Maybe link to the
appropriate section?

Resolution: Leave it up to the editor.
Document updated.
Reply: http://www.w3.org/mid/16425.21854.733108.683783@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 74. http://www.w3.org/mid/3F81EB3F.5020400@escape.com
S4.3.6 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#color-units>:
# The format of an RGB value in the functional notation is 'rgb('
# followed by a comma-separated list of three numerical values (either
# three integer values or three percentage values) followed by ')'.

Is rgb(255, 0, 50%) invalid, then?

Resolution: Yes.
Reply: http://www.w3.org/mid/16425.21857.420099.432694@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 75. vertical-align ambiguities A
Thread:
  http://www.w3.org/mid/3F833074.32375.922D24@localhost
  http://www.w3.org/mid/20031007195251.GA5491@darby.dbaron.org
  http://www.w3.org/mid/3F85B43E.12760.2B3E50@localhost
  http://lists.w3.org/Archives/Public/www-style/1999Mar/0121.html ("unsolvable cases")
http://dbaron.org/css/2000/01/dibm
| Unsolvable situations arise if a loose element that has
| vertical-align: bottom has descendants anchored to it that extend
| below its bottom or if an element with vertical-align: top has
| descendants anchored to it that extend above its top. When this is
| true, the bottom of the element cannot touch the bottom of the line
| box as required by the definition of bottom (top is analogous).
| ...
| Thus I think the definition of bottom should be changed to read:
|  Align the full bottom of the box with the bottom of the line box.
| and top should be changed analogously.
...where 'full bottom' is defined as in
http://lists.w3.org/Archives/Public/www-style/1999Mar/0121.html

Resolution: Use text from:
   http://www.w3.org/mid/20031112013921.GA6399@darby.dbaron.org
Reply: http://www.w3.org/mid/16426.37683.552491.628269@lanalana.inria.fr
Response: http://www.w3.org/mid/402BF500.18663.81B2B2@localhost
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402161648460.2210@dhalsim.dreamhost.com
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 76. vertical-align ambiguities B
Comment: http://www.w3.org/mid/3F833074.32375.922D24@localhost
Comment: http://www.w3.org/mid/20031007195251.GA5491@darby.dbaron.org
Comment: http://www.w3.org/mid/3F85B43E.12760.2B3E50@localhost
Comment: http://lists.w3.org/Archives/Public/www-style/1999Mar/0121.html
  "indeterminate cases"
http://dbaron.org/css/2000/01/dibm
| CSS does not fully describe the result if the tallest (in full
| height) loose element in the line is not the root of the line. This
| is what I mean by an indeterminate case.
| ...
| I think the best would be to treat the largest element (in full
| height) as the root of the line (that is, to place it first), and
| place the root element of the line as if it had the alignment of the
| largest loose element (which is either top or bottom).
...where 'full height', 'loose', 'root of the line' are defined as in
http://lists.w3.org/Archives/Public/www-style/1999Mar/0121.html
(I think this is equivalent to saying that you position the root of
the line, then place the biggest loose subtree according to its
alignment, then place the other loose subtrees in the resulting space,
then (vertically) shrink wrap the line box around that and stack it in
with the other line boxes. -- Hixie)

Resolution: Leave undefined in 2.1.
Reply: http://www.w3.org/mid/16426.37679.742180.198872@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 77. (semantic) stop ignoring default attributes (e.g. from DTD)
Thread:
  http://www.w3.org/mid/4.3.2.7.2.20031008173446.01709bf8@172.27.10.30 (issue)
  http://lists.w3.org/Archives/Public/www-style/2003Oct/0029.html (reply)
  http://www.w3.org/mid/200310131858.36221.roger.larsson@incrementa.se (issue)
  http://www.w3.org/mid/200310132109.h9DL96B01219@djwhome.demon.co.uk (reply to second issue)
  http://www.w3.org/mid/69421B63-FE02-11D7-8E9F-003065B8CF0E@iki.fi (response to first reply, needs reply)
  http://www.w3.org/mid/78A033BB-FE02-11D7-8E9F-003065B8CF0E@iki.fi (response to second reply, needs reply)
  http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi (needs reply)
  http://www.w3.org/mid/200310200620.h9K6KTl00612@djwhome.demon.co.uk
  http://www.w3.org/mid/338C56E6-0323-11D8-B18E-003065B8CF0E@iki.fi
  http://www.w3.org/mid/3FE9F445.50701@w3.org (XMLCG request on this issue, probably needs reply)

Resolution: Add text to the effect of:

   For external subsets: Not require that UAs read the DTD, handle the
   same as standalone document. (This is the <a>XML spec's conformance
   requirements</a>.)

   For internal namespace knowledge (e.g. HTML and XHTML UAs that do
   not read the HTML or XHTML DTDs but know what they contain): Not
   require that UAs treat attributes as present unless present in
   markup.

   For internal subsets: Require that UAs treat attributes as present
   even if not present in markup (as <a>required by XML</a>).

   Note: Typically implementations choose to ignore external subsets.

Document updated.
Reply: http://www.w3.org/mid/16426.37669.140608.891338@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 78. (editorial) clarify how we ignore default attributes
Comment: http://www.w3.org/mid/Pine.GSO.4.58.0310092216090.16941@korppi.cs.tut.fi
Comment: http://www.w3.org/mid/Pine.GSO.4.58.0310101624150.4119@korppi.cs.tut.fi
| This could be avoided by adding a simple statement: All references to
| attributes in CSS shall be taken as referring to attributes that have
| been explicitly set using attribute specifications in the document's
| markup.
Resolution: Made irrelevant by issue 77.
Reply: http://www.w3.org/mid/16426.37654.967152.718209@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 79. http://www.w3.org/mid/3F875337.6080406@escape.com
Preceding Siblings
S5.1 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#q1>:
# E + F   Matches any F element immediately preceded by an element E.
preceded by a _sibling_ element, you mean; E + F shouldn't match if
E is the parent of F.
Resolution: Leave up to editor to correct this.
Document updated.
Reply: http://www.w3.org/mid/16426.37648.184183.752748@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 80. http://www.w3.org/mid/3F875337.6080406@escape.com
Adjacent Elements
S5.7 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#adjacent-selectors>:
# In some contexts, adjacent elements generate formatting objects
# whose presentation is handled automatically (e.g., collapsing
# vertical margins between adjacent boxes). The "+" selector
# allows authors to specify additional style to adjacent elements.
This paragraph is confusing and, imo, useless. Take it out.
Resolution: Leave up to editor to correct this.
Document updated.
Reply: http://www.w3.org/mid/16426.37645.787588.959654@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 81. http://www.w3.org/mid/3F875337.6080406@escape.com
Attribute Selectors
S5.8 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#attribute-selectors>:
# CSS 2.1 allows authors to specify rules that match attributes
# defined in the source document.
Given the way "matches" is defined in section 5.1, this
sentence should be reworded. The selector doesn't match
the attribute, it matches the element *with* the attribute.
Resolution: Leave up to editor to correct this.
Document updated.
Reply: http://www.w3.org/mid/16426.37635.74088.759403@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 82. http://www.w3.org/mid/3F875337.6080406@escape.com
Default Attributes
S5.8.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#q11>
#    EXAMPLE { /*... default property settings ...*/ }
# Because this selector is less specific than an attribute selector,
# it will only be used for the default case.
This is false. The selector will be used for all cases, not just the
default case. If a declaration from this rule conflicts with one from
a more specific rule, then it will be overridden--but the declaration
still applies.
Resolution: It's only an example and is accurate enough, we think. (We
couldn't come up with better text that didn't sound stilted.)
Reply: http://www.w3.org/mid/16426.37630.476743.541538@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 83. http://www.w3.org/mid/3F875337.6080406@escape.com
Class Selectors
S5.8.3 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#class-html>:
# Working with HTML, authors may use the period (.) notation as an
# alternative to the ~= notation when representing the class
# attribute. Thus, for HTML, div.value and div[class~=value] have the
# same meaning. The attribute value must immediately follow the
# "period" (.). UAs may apply selectors using the period (.) notation
# in XML documents if the UA has namespace specific knowledge that
# allows it to determine which attribute is the "class" attribute for
# the respective namespace. One such example of namespace specific
# knowledge is the prose in the specification for a particular
# namespace (e.g. SVG 1.0 [SVG10] describes the SVG "class" attribute
# and how a UA should interpret it, and similarly MathML 2.0 [MATH20]
# describes the MathML "class" attribute.)
The poor quality of the prose here aside (which I'll have to address
later), I think this paragraph would benefit from a brief discussion
of what a class /is/ conceptually, not just syntactically.

Resolution: See 84.
Issue closed.
------------------------------------------------------------------------
Issue 84. http://www.w3.org/mid/3F875337.6080406@escape.com
Class Selectors
S5.8.3 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#class-html>:
Also, you need to make clear that an XML namespace may choose as its
class attribute an attribute with a name other than "class".
# Note. CSS gives so much power to the "class" attribute, that authors
# could conceivably design their own "document language" based on
# elements with almost no associated presentation (such as DIV and
# SPAN in HTML) and assigning style information through the "class"
# attribute. Authors should avoid this practice since the structural
# elements of a document language often have recognized and accepted
# meanings and author-defined classes may not.
You tell authors here what not to do with classes. One reads this
warning, but then what? There's no advice on what *to* do! Tantek's
post "A Touch of Class" [1] explains classes particularly well; adding
a few key points from that would turn this block into a more useful
redirect.
[1] http://tantek.com/log/2002/12.html#L20021216t2238

Resolution: Not necessary in a spec. Tutorial material.
Reply: http://www.w3.org/mid/16426.37624.649974.828010@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 85. http://www.w3.org/mid/3F875337.6080406@escape.com
ID Selectors
S5.9 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#class-html>:
# Document languages may contain attributes that are declared to be of
# type ID. What makes attributes of type ID special is that no two
# such attributes can have the same value; whatever the document
# language, an ID attribute can be used to uniquely identify its
# element...
Since CSS could conceivably be used for a non-SGML-based document
language, I suggest defining IDs as "unique identifiers" first and
relating them to type ID later. Another advantage is that you start
the definition with generic English rather than specific code.

Resolution: Not a problem currently. Will fix it in Selectors when it
is a problem.
Reply: http://www.w3.org/mid/16426.37618.894485.318065@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 86. http://www.w3.org/mid/3F875337.6080406@escape.com
| :first-child
| S5.11.1 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-child>:
| # Note that since anonymous boxes are not part of the document tree,
| # they are not counted when calculating the first child.
| -Boxes- are never part of the document tree. You mean to say that
| "non-element nodes" are not counted.
We probably mean both. -- Hixie
Resolution: Leave it.
Reply: http://www.w3.org/mid/16426.37616.275344.863349@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 87. http://www.w3.org/mid/3F875337.6080406@escape.com
Link Pseudo-Classes
S5.11.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#link-pseudo-classes>
# For example, in HTML 4.0, the link pseudo-classes apply to A
# elements with an "href" attribute.Thus, the following two CSS 2.1
# declarations have similar effect:
#
#   a:link { color: red }
#   :link  { color: red }
This example seems a bit pointless. If it's got a point, you need to
point it out. Otherwise, take it out.

Resolution: Leave it.
Reply: http://www.w3.org/mid/16426.37573.602435.944412@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 88. http://www.w3.org/mid/3F875337.6080406@escape.com
Link Pseudo-Classes
S5.11.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#link-pseudo-classes>
# Note. It is possible for stylesheet authors to abuse the :link and
# :visited pseudo-classes to determine which sites a user has visited
# without the user's consent. UAs may therefore treat all links as
# unvisited links, or implement other measures to preserve the user's
# privacy while rendering visited and unvisited links differently. See
# [P3P] for more information about handling privacy.
If you want to let UAs treat all links as unvisited, then put that in
the normative prose, not an informative note. As for privacy concerns
over :visited and :link, putting that kind of a note in here seems
like overkill to me.

Resolution: split note at "UAs may", second paragraph being normative.
Further communication is required.
Document updated.
Reply: http://www.w3.org/mid/16426.37569.461545.515893@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 89. http://www.w3.org/mid/3F875337.6080406@escape.com
Dynamic Pseudos
S5.11.3 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#dynamic-pseudo-classes>:
# Similarly, because A:active is placed after A:hover,
# the active color (lime) will apply when the user both
# activates and hovers over the A element.
will apply -> will take effect

Resolution: example, not important enough to worry about
Reply: http://www.w3.org/mid/16426.37561.542861.860475@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 90. http://www.w3.org/mid/3F875337.6080406@escape.com
Dynamic Pseudos
S5.11.3 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#dynamic-pseudo-classes>:
# An element can be both ':visited' and ':active' (or ':link' and
# ':active') and the normal cascading rules determine which properties
# apply.
which _style declarations_ apply

Resolution: agreed
Reply: http://www.w3.org/mid/16426.37552.623636.748989@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 91. http://www.w3.org/mid/3F875337.6080406@escape.com
:first-line
This entire section takes the "fictional tag sequence" idea
a bit too literally. For example,
# the user agent could generate the appropriate start and
# end tags for SPAN when inserting the fictional tag
# sequence for :first-line.
No. You can't make the tags real, because then you wind up
with an obscure box model. Suppose, for example, I specify
span { border: 1px solid}. The border shouldn't indicate a
split in the span element at the end of the first line.

Resolution: Change "generate the appropriate" ("user agent could
generate the appropriate start and end tags") to "simulate" or other
wording at editor's discretion.
Reply: http://www.w3.org/mid/16426.37547.537036.500848@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 92. http://www.w3.org/mid/3F875337.6080406@escape.com
:first-line
# The :first-line pseudo-element can only be attached to
# a block-level element.
   elem            { display: block; }
   elem:first-line { color: blue; }
   elem.special    { display: inline; }
say what?

Resolution: What you say?
Reply: http://www.w3.org/mid/16426.37542.615858.972672@lanalana.inria.fr
Response: http://www.w3.org/mid/40329701.710824902@smtp.bjoern.hoehrmann.de
Reply: http://www.w3.org/mid/20040211214355.GA4740@darby.dbaron.org
Response: http://www.w3.org/mid/4033a557.714495009@smtp.bjoern.hoehrmann.de
Issue closed.
------------------------------------------------------------------------
Issue 93. http://www.w3.org/mid/3F875337.6080406@escape.com
:first-line
# A UA should act as if the fictional start tag of the
# first-line pseudo-element is just inside the smallest
# enclosing block-level element.
What do you mean, the "smallest enclosing block-level
element"?
If you're trying to say something about nesting (I'm
guessing based on the example), then *say* something
about nesting. E.g.
    :first-line pseudo-elements are nested in the
    same order as the elements themselves.

Resolution: "smallest" becomes "inner-most".
Reply: http://www.w3.org/mid/16426.37538.30428.363450@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 94. Name of initial value of 'content'.
Comment: http://www.w3.org/mid/3F879150.9020504@escape.com
| I propose changing the 'normal' value to 'auto':
Comment: http://lists.w3.org/Archives/Public/www-style/2003Mar/0013.html
| It should also be renamed to 'auto', as 'auto' means "self"--
| which is a connotation you'll want in CSS3. It also means
| "automatic"; the content and behavior associated with the
| element is "automatic" instead of manually specified in the
| style rule. In contrast, 'normal' here means little more
| than 'default', and it implies that any other value is
| "abnormal". ;)
|
| If the WG still feels 'normal' is more appropriate than 'auto',
| I would *really* like to know why. *formally requests a reply*

Resolution: Tantek prefers "normal" and none of the rest of us really
care either way.
Reply: http://www.w3.org/mid/BC47273E.3599B%25tantek@cs.stanford.edu
Issue closed.
------------------------------------------------------------------------
Issue 95. http://www.w3.org/mid/3F879634.2070002@escape.com
:first-letter
S5.12.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-letter>
| What about punctuation immediately following the first letter?
(three examples included)

Resolution: Yes, we want to update this.
Reply: http://www.w3.org/mid/16426.37527.731396.902293@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 96. http://www.w3.org/mid/3F879634.2070002@escape.com
:first-letter
S5.12.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-letter>
| There's also this degenerate case to consider:
| | "_", foo

Resolution: \/\/hatever, leave it up to the UA...
Reply: http://www.w3.org/mid/16427.61137.179716.680629@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 97. http://www.w3.org/mid/3F879634.2070002@escape.com
:first-letter
S5.12.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-letter>
| And what of numbers? They're not letters, but...
(example included)

Resolution: We should allow this.
Reply: http://www.w3.org/mid/16427.61156.117066.137985@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 98. http://www.w3.org/mid/3F879634.2070002@escape.com
:first-letter
S5.12.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-letter>
# Some languages may have specific rules about how to treat certain
# letter combinations. In Dutch, for example, if the letter
# combination "ij" appears at the beginning of a word, both letters
# should be considered within the :first-letter pseudo-element.
The UA requirents wrt such combinations should be, IMO, more clearly
expressed.

Resolution: Rejected.
Reply: http://www.w3.org/mid/16427.61171.77156.911866@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 99. http://www.w3.org/mid/3F879634.2070002@escape.com
:first-letter and :before/:after (see end of e-mail)
Continued in:  http://www.w3.org/mid/3F8DF3CC.4090308@escape.com

Resolution: We should say it doesn't apply to markers but does apply
to :before/:after. (Using counters in :before/:after is bad.)

Bert added:
| Ad issue 99: ':first-letter' does not match a list markers, but it
| does match whatever is the element's first letter after :before and
| :after have been added. But how about a list marker with
| 'list-style-position: inside'?
 -- http://www.w3.org/mid/16346.1332.851144.151266@lanalana.inria.fr

Resolution: In 5.12.2, "The :first-letter pseudo-element", change
   ..."with a marker outside ('list-style-position: outside'), the
   ':first-letter' applies to the principal box of the element, not to
   the marker."
...to:
   ...", the ':first-letter' applies to the first letter in the
   principal box after the marker. UAs may ignore ':first-letter' on
   list items with 'list-style-position: inside'."

Document updated.
Reply: http://www.w3.org/mid/16427.61186.982900.183300@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 100. http://www.w3.org/mid/3F87E24C.10509@escape.com
Overflow and backgrounds. (Detailed argument.)

Resolution: We have interoperability now.
Reply: http://www.w3.org/mid/16427.61199.267854.605641@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 101. http://www.w3.org/mid/3F87E607.9030501@escape.com
Colors and Backgrounds
S14.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/colors.html#q2>:
# The background of the root element becomes the background of the
# canvas and covers the entire canvas, anchored 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.
It is unclear what is meant by this.

Resolution: Clear to us... What's unclear?
Reply: http://www.w3.org/mid/16427.61215.861025.252175@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 102. http://www.w3.org/mid/3F87E607.9030501@escape.com
Colors and Backgrounds
S14.2.1<http://www.w3.org/TR/2003/WD-CSS21-20030915/colors.html#background-properties>:
# The tiling and positioning of the background-image on inline elements
# is undefined in this specification. A future level of CSS may define
# the tiling and positioning of the background-image on inline elements.
Must CSS2.1 really make the tiling and positioning of all inline
elements undefined or can it get away with leaving backgrounds on
*multi-line* inline elements undefined?

Resolution: Leaving undefined for now, see CSS3.
Reply: http://www.w3.org/mid/16427.61229.958900.252878@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 103. Interaction of run-in with anonymous block boxes.
Comment: http://www.w3.org/mid/20031011130232.GA3710@tapir
Comment: http://lists.w3.org/Archives/Public/www-style/2000May/0010.html
Comment: http://www.w3.org/mid/20031011235501.GA2332@tapir

Resolution: three changes:
1. a run-in box cannot run in to a block into which a later box
   also runs in
2. run-in cannot run into a run-in
3. change "In other words: if a block box (such as that generated for
   the DIV above) has another block box inside it (such as the P
   above), then we force it to have only block boxes inside it, by
   wrapping any inline boxes in an anonymous block box." in 9.2.1 to:
   "In other words: if a block box (such as that generated for the DIV
   above) has another block box or a run-in box inside it (such as the
   P above), then we force it to have only block boxes or run-in boxes."
Reply: http://www.w3.org/mid/16427.61245.156261.190240@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 104. http://www.w3.org/mid/20031013160607.GA3966@darby.dbaron.org
From: http://lists.w3.org/Archives/Member/w3c-css-wg/2003JulSep/0342.html
# DB: proposes changes to:
#   last paragraph of 10.6.6:
#     http://www.w3.org/Style/Group/css2-src/visudet.html#q22
#   remove:
#     whose top margin edge is above the top established above or
Resolution: Apply already agreed changes.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 105. http://www.w3.org/mid/20031013160607.GA3966@darby.dbaron.org
From: http://lists.w3.org/Archives/Member/w3c-css-wg/2003JulSep/0342.html
#   10.6.4 rule 1 and rule 3 is too vague: "then the height is based on the
#     content"
#   10.6.4 should have text just like 10.6.6 (with proposed revision), but
#     I don't like coping text
# TC: put in separate section?
# IH: Add a 10.6.7 called "'auto' heights for block formatting context
#   roots"?
# DB: I like that.
Resolution: Apply already agreed changes.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 106. Make HTML4 sample default stylesheet comprehensive
Thread:
  http://lists.w3.org/Archives/Member/w3c-css-wg/2003OctDec/0029.html (issue)
  http://lists.w3.org/Archives/Member/w3c-css-wg/2003OctDec/0028.html (reply)
  http://lists.w3.org/Archives/Member/w3c-css-wg/2003OctDec/0030.html (issue)
Resolution:
| Add "html { display: block; }" but add nothing else (in particular, never
| add anything that may be UA-dependent).
Reply: http://www.w3.org/mid/16427.61260.577978.622980@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 107. Allow display:list-item on root element because four
browsers (Opera, Mozilla, Safari, MacIE) already do.
Resolution: Change "9.2.4 The 'display' property":
# For the root element, the computed value is as follows:
# 'inline-table' and 'table' become 'table', 'none' stays 'none',
# everything else becomes 'block'.
...to:
| For the root element, the computed value is changed as described in
| the section on the <a>relationships between 'display', 'position',
| and 'float'</a>.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 108. Section "9.7 Relationships between 'display', 'position',
and 'float'" repeats the table and doesn't mention the root element.
Resolution: Change section 9.7 as follows:
|
| The three properties that affect box generation layout and 'display',
| 'position', 'float' and interact as follows:
|
| 1. If 'display' has the value 'none', then 'position' and 'float' do
|    not apply. In this case, the element generates no box.
|
| 2. Otherwise, if 'position' has the value 'absolute' or 'fixed', the
|    box is absolutely positioned, the computed value of 'float' is
|    'none', and display is set according to the table below. The
|    position of the box will be determined by the 'top', 'right',
|    'bottom' and 'left' properties and the box's containing block.
|
| 3. Otherwise, if 'float' has a value other than 'none', the box is
|    floated and 'display' is set according to the table below.
|
| 4. Otherwise, if the element is the root element, 'display' is set
|    according to the table below.
|
| 5. Otherwise, the remaining 'display' property values apply as
|    specified.
|
| <table as now>
|
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 109.
> By the way, http://www.w3.org/TR/CSS21/generate.html#propdef-content
> does not list <uri> in the condensed Value list (not sure if this was
> noted previously on the list).
Resolution: Fix it.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 110. http://www.w3.org/mid/020A3CF87FB5AC47AA67966B338457550657FF3F@xboi22.boise.itc.hp.com
> "Note. If a quotation is in a different language than the
> surrounding text, it is customary to quote the text with the quote
> marks of the language of the surrounding text, not the language of
> the quotation itself. "
>
> This is in contradiction to the rules in my personal copy of Duden,
> which is the German authority on spelling etc. They ask for
> precisely the opposite, at least in cases where there's a whole
> phrase.
Replies:
  http://www.w3.org/mid/020A3CF87FB5AC47AA67966B338457550657FF3F@xboi22.boise.itc.hp.com
Resolution: already fixed.
Issue closed.
------------------------------------------------------------------------
Issue 111. Border Collapsing.
  http://www.w3.org/mid/0A54FF50-FDB9-11D7-9559-000A958E6110@apple.com
  http://www.w3.org/mid/CEE4BF06-FDC8-11D7-9559-000A958E6110@apple.com
  http://www.w3.org/mid/20031015230139.GA6078@darby.dbaron.org (proposal)
  http://www.w3.org/mid/5D3A6013-0013-11D8-8B5E-000A958E6110@apple.com

Resolution: Diagram and prose of 17.6.2 to be updated. (Bert to do
diagram. Hyatt to do text.)
New text: http://www.w3.org/mid/61D1296A-1243-11D8-BEB5-000A958E6110@apple.com
Document updated.
Issue closed.
------------------------------------------------------------------------
Issues 112. Position of inside list bullet should match the
typographically better CSS3 proposal (or at least allow it).
  http://www.w3.org/mid/EEF69332-FDB9-11D7-9559-000A958E6110@apple.com
howcome says: I have added the text "CSS 2.1 does not specify the
precise location of the marker box." as per David's suggestion. It's a
truism.
Resolution: Assumed agreement.
  http://www.w3.org/mid/200311060719.hA67JWG11358@mail.opera.no
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 113. Default stylesheet for <table rules>
  http://www.w3.org/mid/D82ECDEC-FF4D-11D7-8118-000A958E6110@apple.com
  http://www.w3.org/mid/20031015221209.GA5773@darby.dbaron.org (proposal)

Resolution: cut example from spec
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 114. http://www.w3.org/mid/3F8DBE91.7A3671E@i18nguy.com
| section 4,
| http://www.w3.org/TR/CSS21/syndata.html :
|
| In section 4.1.3, in the third type of escape it says that if a
| character in the range [0-9a-zA-Z] follows a hexadecimal number, the
| end of the number needs to be made clear. The range should be
| [0-9a-fA-F], since characters g-zG-Z are clearly beyond the
| hexadecimal number.
Reply: http://www.w3.org/mid/20031015223936.GB5773@darby.dbaron.org

Resolution: fix it
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 115. http://www.w3.org/mid/3F8DBE91.7A3671E@i18nguy.com
| 2) Section 4.4 on CSS document representation
| Mention should be made of the Unicode BOM and its relationship to the encoding
| of the file.
|
| Is BOM allowed?
|
| The @charset rule is required to be the first character of the file.
| For some people, it is confusing whether the BOM is considered a
| character. (To me it is clear that it is not.)
Reply: http://www.w3.org/mid/20031015223936.GB5773@darby.dbaron.org
Response: http://www.w3.org/mid/3F8DDC83.8FE77A0B@i18nguy.com

Resolution: see issue 44.
Reply: http://www.w3.org/mid/16427.61280.674857.670826@lanalana.inria.fr
Response: http://www.w3.org/mid/402BF173.1040003@mit.edu
Reply: http://www.w3.org/mid/16435.26816.6696.770444@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 116. http://www.w3.org/mid/3F8DBE91.7A3671E@i18nguy.com
| Where does BOM fit in the precedence hierarchy?

(Original resolution: UA dependent.)
Resolution changed due to issue resolution conflict with issue 44.
Resolution: see issue 44.
Reply: http://www.w3.org/mid/16427.61317.429022.962180@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 117. http://www.w3.org/mid/3F8DBE91.7A3671E@i18nguy.com
| What if the UTF-8 BOM exists, but the encoding is declared by @charset
| rule as something else? Is this an error, or is it considered that the
| encoding simply changes after the @charset rule?
Comment: http://www.w3.org/mid/4.2.0.58.J.20031016205528.05b6c5d0@localhost
Resolution: see issue 44.
Issue closed.
------------------------------------------------------------------------
Issue 118. http://www.w3.org/mid/3F8DBE91.7A3671E@i18nguy.com
| More generally, I find the character numbering a little confusing. It
| is in fact self-consistent, but it is not obvious to the reader
| without some checking and if you don't recognize the values.
|
| If you take into account:
|
| -In 4.1.1 Tokenization it is mentioned that Octal codes refer to ISO 10646.
| (This is specific to Lex expressions but that is not immediately obvious. I
| realize saying octal refers to 10646 doesn't mean that the reverse is true,
| 10646 codes will be in octal. But it doesn't mean it isn't true either.)
|
| -The character codes at the end of 4.1.1 are decimal. Although one code (space)
| is identified as a Unicode value.
|
| -All of the escapes are of course hex.
|
| Then, when you read in section 4.1.3 that ISO 10646 characters 161 and higher
| are allowed in identifiers, it is not immediately obvious if 161 is octal,
| decimal or hex.
|
| It would perhaps be more clear to use the Unicode notation for character codes:
| U+hhhh, as the hex notation is more common now and the U+ is distinctive and
| indicative of the notation. The hex values are more recognizable as well, for
| characters like ideographic space, etc.
| and fit in better with the escape notation.
Comment: http://www.w3.org/mid/4.2.0.58.J.20031016205044.05b71008@localhost

Comment: http://www.w3.org/mid/4.2.0.58.J.20031016210049.05b36ad0@localhost
Resolution: Editors to fix this.
Reply: http://www.w3.org/mid/16427.61352.349177.974034@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 119. http://www.w3.org/mid/3F8DBE91.7A3671E@i18nguy.com
| I am surprised that the on section URIs doesn't mention IRIs.
See also: http://www.w3.org/mid/3F9625D7.CC1F5B19@i18nguy.com
Reply: http://www.w3.org/mid/0aba01c398c7$64f30d70$3ef4ae8b@heim4.tuclausthal.de
Can we reference IRIs? I thought that hadn't reached last call yet. We
can't reference something that is still a draft.

Resolution: A CR can't reference anything before a last call, and IRIs
i8
aren't last call.
Reply: http://www.w3.org/mid/16427.61379.908812.394931@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 120. http://www.w3.org/mid/3F8DBE91.7A3671E@i18nguy.com
| The section 4.3.7 on strings introduces \A for newline and points to
| an example, so I assume there isn't a section describing other
| backslash codes (e.g. \t etc.). However, the section doesn't define
| what the user should do if they actually want a linefeed.
|
| Is \0A (not \A) supposed to generate a linefeed or a newline? In other
| words, is that string "\A" a special string, or is the character code
| U+000A mapped to linefeed in css? The parenthetical remark seems to
| indicate that CSS redefines the Unicode character.
|
| (Which seems like a very odd and dangerous thing to do.)
Reply: http://www.w3.org/mid/20031015223936.GB5773@darby.dbaron.org
Response: http://www.w3.org/mid/3F8DDC83.8FE77A0B@i18nguy.com
Reply: http://www.w3.org/mid/20031016005340.GA6839@darby.dbaron.org
Response: http://www.w3.org/mid/3F8DF771.AFB20E72@i18nguy.com
Response: http://www.w3.org/mid/200310160609.h9G699J02898@djwhome.demon.co.uk
Reply: http://www.w3.org/mid/4.2.0.58.J.20031016205044.05b71008@localhost
Response: http://www.w3.org/mid/3F8F64B9.2776AC68@i18nguy.com
Reply: http://www.w3.org/mid/16427.61404.249580.528039@lanalana.inria.fr

Resolution: Yes, this is how it is.
Issue closed.
------------------------------------------------------------------------
Issue 121. http://www.w3.org/mid/3F8DBE91.7A3671E@i18nguy.com
| Also I assume that \a and \A are equivalent. True?
Reply: http://www.w3.org/mid/20031016005340.GA6839@darby.dbaron.org
Response: http://www.w3.org/mid/3F8DF771.AFB20E72@i18nguy.com

Resolution: Yes.
Document updated.
Reply: http://www.w3.org/mid/16427.61469.930908.25767@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 122. http://www.w3.org/mid/3F8E49FF.A8ABAA98@i18nguy.com
| Section 5.11.4 on :lang still references RFC 1766.
|
| Although HTML technically refers to 1766, XML has been upgraded to
| RFC 3066 for its support of 3 letter tags and also prescribes the
| empty tag to allow the removal of language info. And most browsers I
| believe do support rfc 3066 for html anyway.
|
| CSS should therefore address rfc 3066
Resolution: Yes, it should be updated.
Document updated.
Reply: http://www.w3.org/mid/16427.61511.332061.654384@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 123. http://www.w3.org/mid/3F8E49FF.A8ABAA98@i18nguy.com
| Does ':lang()' match elements that have language set to the empty
| tag?
|
| It might be thought to match all languages, since in the absence of
| simple selectors, * is presumed, so it is conceivable that absence
| of a tag might be equivalent to all. It might also be deemed to be
| an error to have no tag inside the parens.
|
| So the spec should address the issue.
Reply: http://www.w3.org/mid/16270.39061.194849.106208@lanalana.inria.fr

Resolution: Make :lang() undefined in 2.1 (we'll define in CSS3+) In
addition, specify that :lang()'s argument must be an identifier as it
says in the grammar. This also needs changing the grammar to allow
function-like pseudo-classes with null arguments.
Document updated.
Reply: http://www.w3.org/mid/16427.61526.604998.374365@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 124. http://www.w3.org/mid/3F8E49FF.A8ABAA98@i18nguy.com
| For the purposes of matching, I wonder if it makes sense to
| reference the RFCs at all. Isn't it really string matching based on
| strings formatted with hyphen separators? Does any software verify
| that the language tag contains appropriately registered codes or
| uses ISO codes? Should it be an error, or perhaps the rule ignored,
| if a CSS document specifies :lang(k9) since k9 is not an offical
| language code or a properly formatted private code.
Some other messages on that thread (it's a long thread):
  http://www.w3.org/mid/16270.39061.194849.106208@lanalana.inria.fr (bert)
  http://www.w3.org/mid/15411558279.20031016161109@w3.org (chris)
  http://www.w3.org/mid/Pine.GSO.4.58.0310162227430.238@korppi.cs.tut.fi
  http://www.w3.org/mid/18316510540.20031016232304@w3.org (chris)
  http://www.w3.org/mid/3F8F30C3.1F802EB6@i18nguy.com
  http://www.w3.org/mid/4.2.0.58.J.20031016212319.06011f40@localhost
  http://www.w3.org/mid/3F8F5666.DFB8DE6E@i18nguy.com (useful points)
  http://www.w3.org/mid/3F8F59A9.5F0B455C@i18nguy.com
  http://www.w3.org/mid/3F8F6723.B4BA94C5@i18nguy.com
  http://www.w3.org/mid/Pine.GSO.4.58.0310171106140.15855@korppi.cs.tut.fi
  http://www.w3.org/mid/16271.47379.949013.187179@lanalana.inria.fr (proposal)
  http://www.w3.org/mid/3F8FC99A.12AEC995@i18nguy.com
  http://www.w3.org/mid/115226064.20031017155409@w3.org
  http://www.w3.org/mid/4.2.0.58.J.20031017140847.07153d28@localhost (proposal edits)
  [...]

Resolution: Let Bert do the edits that he proposed.
Document updated.
Reply: http://www.w3.org/mid/16427.61557.33889.765202@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 125. http://www.w3.org/mid/3F8E6343.710045EE@i18nguy.com
What should copying to the clipboard copy?
Thread:
  http://www.w3.org/mid/200310162122.h9GLMG703275@djwhome.demon.co.uk
  http://www.w3.org/mid/00a701c39432$f36ba6a0$c401c941@w3c40upc3ma3j2
  http://www.w3.org/mid/3F8F32D8.1EA24826@i18nguy.com
  http://www.w3.org/mid/4.2.0.58.J.20031016203541.07448160@localhost ("me too")
  http://www.w3.org/mid/62726204.20031017143909@w3.org (chris)
  http://www.w3.org/mid/3F8FEAC3.B864436C@i18nguy.com
  http://www.w3.org/mid/Pine.LNX.4.55.0310170930350.10760@homer.w3.org
  http://www.w3.org/mid/3F9625D7.CC1F5B19@i18nguy.com (i18n)
  http://www.w3.org/mid/0aba01c398c7$64f30d70$3ef4ae8b@heim4.tuclausthal.de
Resolution: UA defined.
Reply: http://www.w3.org/mid/16427.61572.906764.676666@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 126. http://www.w3.org/mid/3F8E6343.710045EE@i18nguy.com
| # ...consider the value of 'text-transform' to be 'none' for
| # characters that are not from the Latin-1 repertoire and for elements
| # in languages for which the transformation is different from that
| # specified by the case-conversion tables of ISO 10646 ([ISO10646]).
|
| a) I suspect you mean EITHER/OR not AND. ie the value can be none if
| characters are EITHER not from Latin-1 OR for elements...
|
| For example the letter i uses different conversion values in Turkey,
| and I assume that even though it is a latin-1 letter, you intended for
| the conversion to not be required.
|
| I guess if the AND is intentional, you are saying that it is better to
| do no case conversion than do the wrong conversion. However, this
| seems silly, since then implementors need to have a list of characters
| that have different conversions for certain languages and insure that
| no conversion is performed. At the point you are detecting these
| characters and language contexts, you may as well implement the
| correct conversion.
Thread:
  http://www.w3.org/mid/4.2.0.58.J.20031016203541.07448160@localhost ("me too")

Resolution: Replace "for characters that are not from the Latin-1
repertoire and for elements in languages for which the transformation
is different from that specified by the case-conversion tables of ISO
10646 ([ISO10646])." with "for writing scripts for which there is no
transform".
Document updated.
Reply: http://www.w3.org/mid/16427.61588.178851.675753@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 127a. http://www.w3.org/mid/3F8E6343.710045EE@i18nguy.com
| # ...consider the value of 'text-transform' to be 'none' for
| # characters that are not from the Latin-1 repertoire and for elements
| # in languages for which the transformation is different from that
| # specified by the case-conversion tables of ISO 10646 ([ISO10646]).
|
| b) From an international perspective, I don't see why you mention latin-1 at
| all. Why should latin-2 users for example not have the benefit of
| text-transform? Why not simply require support for the 10646 case conversion
| table, since Unicode character support is more generally required elsewhere?
| Given everything else needed to implement CSS, the Unicode case conversion
| table seem to be a very small burden to implementers.
Thread:
  http://www.w3.org/mid/4.2.0.58.J.20031016203541.07448160@localhost ("me too")
Resolution: See 126.
Reply: http://www.w3.org/mid/16427.61617.358134.824929@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 127b. http://www.w3.org/mid/3F8E6343.710045EE@i18nguy.com
[text-transform]
| The reference to 2070 should be upgraded to rfc 3066.
Thread:
  http://www.w3.org/mid/4.2.0.58.J.20031016203541.07448160@localhost ("me too")
Resolution: Ok.
Reply: http://www.w3.org/mid/16427.61631.463079.938187@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 127c. http://www.w3.org/mid/3F8E6343.710045EE@i18nguy.com
[text-transform]
| Also, what should occur if the empty language tag is specified for
| the language in XML? Use the default conversion or perform no
| conversion? What if the tag is "UND"?
Thread:
  http://www.w3.org/mid/4.2.0.58.J.20031016203541.07448160@localhost (proposal)
  http://www.w3.org/mid/3F8F5DC4.E27D085C@i18nguy.com
  http://www.w3.org/mid/4.2.0.58.J.20031017120014.0714b198@localhost

Original resolution: Transformation isn't usually language-dependent,
when it is then don't transform.

Tantek says:
   http://www.w3.org/mid/BC478AE2.359A2%25tantek@cs.stanford.edu

Resolution: No change.
Issue closed.
------------------------------------------------------------------------
Issue 128. The four examples under 'background-position' is one
paragraph too low. It should be raised before the paragraph about
undefined rendering on inline elements.

Resolution: up to the editor.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 129. http://www.w3.org/mid/3F90EEA2.D954C4FB@i18nguy.com
| In both descriptions of the border properties "value:, the color is listed as
| border-top-color instead of border-color.
Reply: http://www.w3.org/mid/3F90F357.90204@mit.edu
Response: http://www.w3.org/mid/3F91919C.B11E5F0A@i18nguy.com
Reply: http://www.w3.org/mid/oprw9kt7boou6nf2@smtp.ozforces.com.au

Resolution: Do nothing.
Reply: http://www.w3.org/mid/16427.61646.738425.165664@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 130. http://www.w3.org/mid/p06002002bbb70a2ea318@%5B192.168.254.4%5D
How to style namespaced content in non-namespace-aware UAs.
Reply: http://www.w3.org/mid/200310181600.h9IG0Qb16613@server1.livestoryboard.com
Reply: http://lists.w3.org/Archives/Public/www-style/2003Oct/0138.html
Note: This thread rapidly spiralled into off-topic concerns about a
particular UA's rather inventive interpretations of the
specifications, before really clarifiying the original request or
review comment.

Resolution: replied already.
Issue closed.
------------------------------------------------------------------------
Issue 131. http://www.w3.org/mid/3F9221BA.B938248A@i18nguy.com
The Long description illustrating relationship between page box and sheet
 http://www.w3.org/TR/CSS21/images/longdesc/page-info-desc.html
has a link "return to image" which is incorrect. Should return to the section
on page margins 13.2.1, but instead goes back to section 12.

Resolution: editorial.
Reply: http://www.w3.org/mid/16427.61660.135545.111584@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 132. http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
Links to non-normative versions
I suggest providing the diff between CSS 2 and CSS 2.1 with the final
REC and linking to it.

Resolution: yeah, we agree.
Reply: http://www.w3.org/mid/16427.61678.548315.836995@lanalana.inria.fr
*Ian* Check that this is in fact done.
Issue closed.
------------------------------------------------------------------------
Issue 133a. http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
3.1 Definitions
"Element" is defined using a normative reference to SGML. The SGML
standard is not freely available on the Web. Considering that the
SGML specification is not available for linking and reading on the Web,
I suggest removing the normative reference to SGML and defining
"element" by reference to XML instead.

Resolution: So?
Reply: http://www.w3.org/mid/16427.61695.481340.533007@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 133b. http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
The definition for "ignore" says there are three meanings. However, it
only list meetings introduced by "First" and "Second".

Resolution: editorial.
Reply: http://www.w3.org/mid/16427.61709.395845.960931@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 134. http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
| 4.3.2 Lengths
| I suggest calling "absolute" units "physical" instead, because people
| tend to consider pixels absolute in the context of computer graphics.
Reply: http://www.w3.org/mid/200310200620.h9K6KTl00612@djwhome.demon.co.uk

Resolution: we appreciate your input but no thanks.
Reply: http://www.w3.org/mid/16427.61723.920063.87334@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 135. http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
5.9 ID selectors
Unlike class selectors, the id selectors are defined to depend on the
IDness defined in the DTD. For performance reasons, Web browser can
reasonably be expected not to process the external DTD subset.
Therefore, id selectors when used with XHTML would fail in most if not
all Web browsers. I suggest allowing the UA to have hard-coded
knowledge about IDness based on the namespace--just like the UA is
expected to have hard-coded knowledge about what constitutes class.

Resolution: yes
Reply: http://www.w3.org/mid/16427.61742.161095.294103@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
[Issue 136a. Duplicate of issue 135.]
------------------------------------------------------------------------
Issue 137a. http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
| 8.6 The box model for inline elements in bidi context
| No definition is given for the term "bidi context".

Resolution: change "bidi context" to "bidirection context" ("context"
is a perfectly good English word...)
Reply: http://www.w3.org/mid/16427.61757.498724.869424@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 138a. http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
9.10 Text direction: the 'direction' and 'unicode-bidi' properties

"This seemingly one-sided requirement reflects the fact that, although
not every Hebrew or Arabic document contains mixed-directionality text,
such documents are much more likely to contain left-to-right text
(e.g., numbers, text from other languages) than are documents written
in left-to-right languages."

Probably what is meant is that dominantly RTL documents are more likely
to contain LTR parts than dominantly LTR documents are to contain RTL
parts.

(Original resolution: Remove paragraph.)
Resolution: Remove the section of this paragraph quoted above.
Resolution changed due to issue resolution conflict. See:
    http://www.w3.org/mid/Pine.LNX.4.58.0402022039110.27375@dhalsim.dreamhost.com
Reply: http://www.w3.org/mid/16427.61783.798263.570191@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 139a. http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
10.1 Definition of "containing block"
The example uses a HTML 4.0 Transitional doctype without a SYSTEM id.
The implementation practice (and CSS 2.1 is about implementation
practice) is not to treat such documents as specified in this section.
It would probably be clearer to use an HTML 4.01 Strict doctype with a
SYSTEM id.

Resolution: up to editor
Reply: http://www.w3.org/mid/16427.61796.72333.974733@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 140a. http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
| 12.3.1 Specifying quotes with the 'quotes' property
| "Note. While the quotation marks specified by 'quotes' in the previous
| examples are conveniently located on computer keyboards, high quality
| typesetting would require different ISO 10646 characters."
| I think it would be better to use the high quality alternatives in the
| examples.
Resolution: howcome says:
  http://www.w3.org/mid/200311060719.hA67JWG11358@mail.opera.no
| No change performed. Reasoning: Experts will disagree on what "high-quality"
| typesetting is, and the glyphs are likely to be unavailable in many fonts.
Reply: http://www.w3.org/mid/16427.61810.726486.6718@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 141a. http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
| 13 Paged media
| "The computed value of box margins at the top or bottom of the page
| area is zero."
| Is there a reason why same rule doesn't apply to left and right margins
| that touch the edges of the page area?
hakon says: http://www.w3.org/mid/200311032111.hA3LBgG27686@mail.opera.no
| I propose no change. The answer to the question is roughly the same
| as for why margins collapse vertically and not horizonallry.
Resolution: Assumed agreement.
Reply: http://www.w3.org/mid/16427.61833.837271.481366@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 142a. http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi
14.3 Gamma correction

" Mac using QuickDraw
     apply gamma 1.45 [ICC32] "

I think assuming a particular gamma based on platform is harmful. The
display gamma is configurable on the Mac. When the user agent and
doesn't really know the display gamma, I think it would be better not
to try to "correct" it.  Applying "corrections" based on guesses has
been harmful in connection to the PNG format.
See http://iki.fi/hsivonen/png-gamma.html

"(ColorSync-savvy applications may simply pass the sRGB ICC profile to
ColorSync to perform correct color correction)"

The ICC rendering intent is not specified. If a PNG image where is
marked to be in the sRGB color space, which rendering intent should be
specified in order to match CSS colors in a User Agent that does color
matching based on ICC profiles?

Resolution: make the what-to-do-on-what-os stuff informative
Document updated.
Reply: http://www.w3.org/mid/16427.61869.450902.612360@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 143a. http://www.w3.org/mid/170A2352-0259-11D8-9167-003065B8CF0E@iki.fi

15.2 Font matching algorithm

I think the specification is too detailed here. When the page isn't
displayed with the font the author primarily wanted, do this specifics
of the font matching really matter? For example, on Mac OS X ATSUI
already implements a font matching algorithm which could be considered
good enough. Having to implement another matching algorithm on the
application level is a performance problem. Consideration
implementation difficulty, performance and the user experience, I think
passing the list of font alternatives to the system Unicode imaging
service and letting the system apply its fallback algorithm would be
quite sufficient when the system offers font list-based fallback
functionality. Also, considering user experience, allowing (but not
requiring) the user agent to make decisions based on the content of the
entire page is likely to be better than doing per character font
selection.

Resolution: nothing to say.
Reply: http://www.w3.org/mid/16427.61882.228425.733542@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 144a. http://www.w3.org/TR/CSS21/visuren.html#direction
proposal to change bidi requirement
Followup: http://www.w3.org/mid/3F930BAC.3EBE051D@i18nguy.com
Followup: http://www.w3.org/mid/3F930E44.8813BEC1@i18nguy.com

Resolution: take the change in the last message mentioned above.
Reply: http://www.w3.org/mid/16427.61896.710632.410220@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 145a. http://www.w3.org/mid/3F93547A.1F7C7C1C@i18nguy.com
References that need updating.

Resolution: yep
Document updated.
Reply: http://www.w3.org/mid/16427.61931.909311.355830@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 136b. @font-face
Thread:
  http://www.w3.org/mid/3F936BA4.123A233C@i18nguy.com (issue)
  http://www.w3.org/mid/oprxbua7msou6nf2@smtp.ozforces.com.au (response)
  http://www.w3.org/mid/3F937A78.81E3CDAC@i18nguy.com (response)
  http://www.w3.org/mid/1514084062.20031020162222@w3.org (chris) (issue)
  http://www.w3.org/mid/1535852265.20031020165150@w3.org (chris) (response)
  http://www.w3.org/mid/C088942F-031D-11D8-B18E-003065B8CF0E@iki.fi (response)
  http://www.w3.org/mid/3F94178C.4C4E50DE@i18nguy.com (response)
  [more e-mails that contributed nothing to the discussion ignored]
Replies to chris:
  http://www.w3.org/mid/Pine.LNX.4.58.0310201509440.20117@dhalsim.dreamhost.com
  http://www.w3.org/mid/Pine.LNX.4.58.0310311520400.25431@dhalsim.dreamhost.com
No reply from chris.
Original reviewer still requires reply.

Resolution: Change introduction.
Document updated:
   http://www.w3.org/mid/200311060755.hA67tTG21906@mail.opera.no
Reply: http://www.w3.org/mid/16427.61946.590634.80356@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 137b. http://www.w3.org/mid/3F9432F6.9080408@escape.com
| S7.2.1 Media groups
| http://www.w3.org/TR/2003/WD-CSS21-20030915/media.html#media-groups
| # This section is informative, not normative.
|                   ^^^^^^^^^^^^^^^^^^^^^^^^^^
| # Each CSS property definition specifies the media types for which the
| # property must be implemented by a conforming user agent.
|            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| ????
hakon says: http://www.w3.org/mid/200311031937.hA3JbsG24559@mail.opera.no
| I removed the conformance requirements.
Resolution: Assumed agreement.
Reply: http://www.w3.org/mid/16427.61960.635700.764090@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 138b. http://www.w3.org/mid/3F9408C5.2040507@escape.com
S6.1.1: Specified values
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#specified-value

# User agents must first assign a specified value to a property...
                                                      ^
to _each_ property

Resolution: yep
Reply: http://www.w3.org/mid/16427.61971.778093.329173@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 139b. http://www.w3.org/mid/3F9408C5.2040507@escape.com

# Since it has no parent, the root of the document tree... if necessary.

Take this paragraph out; this case is already handled by the
rules above it.

Resolution: yep
Reply: http://www.w3.org/mid/16427.61985.10618.475287@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 140b. http://www.w3.org/mid/3F9408C5.2040507@escape.com

S6.1.2: Computed values
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#computed-value

# For absolute values, no computation is needed to find the computed value.

Is the computed value of "1cm" and "10mm" the same or different?
Because you need to convert in order to make them the same, and
converting units involves computation...

Resolution: we appreciate your input but we don't really want to
change this at this time. NOTE: This will be changed quite a bit
anyway as part of later issues' resolutions.

Reply: http://www.w3.org/mid/16427.61998.590572.291438@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 141b. http://www.w3.org/mid/3F9408C5.2040507@escape.com
# However, some properties may define the computed value of a property
# for an element to depend on whether the property applies to that element.

This sentence serves no purpose here and therefore is just confusing.
Take it out.

Resolution: we appreciate your input but we don't really want to
change this at this time.
Reply: http://www.w3.org/mid/16427.62019.448022.354941@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 142b. http://www.w3.org/mid/3F9408C5.2040507@escape.com
S6.2: Inheritance

# When inheritance occurs, elements inherit computed values. The
# computed value from the parent element becomes both the specified
# value and the computed value on the child.
...
# Each property may also have a specified value of 'inherit', which
# means that, for a given element, the property takes the same
# computed value as the property for the element's parent.

There's a dichotomy in how the "specified value" for inherited values
works, depending on whether it's explicit or implied. It would be best
if the initial behavior of 'color' and "color: inherit" meant exactly
the same thing. And this way the meaning of "color: inherit" on the
root element would follow from the inheritance logic without having to
be handled as another exception.

Resolution: we appreciate your input but we don't really want to
change this at this time.
Reply: http://www.w3.org/mid/20040217223733.GA5825@darby.dbaron.org
Issue closed.
------------------------------------------------------------------------
Issue 143b. http://www.w3.org/mid/3F9408C5.2040507@escape.com

# If the user agent does not have the 12pt font available...

Change 120% to 130% and make it 13pt font. Because the vast majority
of fonts out there do have 12pt versions--13pt is not a common size
and is therefore more likely not to exist.

Resolution: yep
Reply: http://www.w3.org/mid/200402131739.i1DHdnZO030344@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 144b. http://www.w3.org/mid/3F9408C5.2040507@escape.com

6.3 The @import rule
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#at-import

Move this section to either before Specified, Computed and Actual Values
or after The Cascade, because it breaks up the conceptual flow between
these two sections.

Resolution: we appreciate your input but we don't really want to
change this at this time.
Reply: http://www.w3.org/mid/200402131739.i1DHdnw7030348@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 145b. http://www.w3.org/mid/3F9408C5.2040507@escape.com

6.4 The Cascade
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#cascade

# Note that the default style sheet may change if system settings are
# modified by the user (e.g., system colors). However, due to limitations
# in a user agent's internal implementation, it may be impossible to
# change the values in the default style sheet.

This note seems rather useless. If there's no good justification for
putting it in, then take it out.

Resolution: change to informative note, let editor improve wording if
possible, maybe to: "Note that the user may modify system settings
(e.g. system colors) that affect the default style sheet. However,
some user agent implementations make it impossible to change the
values in the default style sheet."
Reply: http://www.w3.org/mid/200402131739.i1DHdnQl030352@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 146. http://www.w3.org/mid/3F9408C5.2040507@escape.com

# Rules specified in a given style sheet override rules of the same
# weight imported from other style sheets.

Even if the imported rules have higher specificity?
I think you mean to say that rules in an imported style sheet are
considered to be before the rules in the importing stylesheet.

Resolution:
+ change "weight () and origin ()" in 6.4.1 to "importance () and origin ()"
+ strike the paragraph beginning with "Rules specified"
Reply: http://www.w3.org/mid/200402131739.i1DHdngt030356@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 147. http://www.w3.org/mid/3F9408C5.2040507@escape.com

6.4.2 !important rules
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#important-rules

# the keywords "!" and "important" follow the declaration

Since when is "!" a keyword?

Resolution: yep (it's a delim token) -- editor to deal with this
Document updated.
Reply: http://www.w3.org/mid/200402131739.i1DHdn4v030360@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 148. http://www.w3.org/mid/3F9408C5.2040507@escape.com

# The first rule in the user's style sheet in the following example...

I think the example would be more illustrative if the second rules
in the author and user style sheets were switched.

Resolution: editorial, editor to deal with this
Editor said no: http://www.w3.org/mid/402D0E3F.6010900@aol.com
Reply: http://www.w3.org/mid/200402131739.i1DHdnZC030364@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 149. http://www.w3.org/mid/3F9408C5.2040507@escape.com

S6.4.3: Calculating a selector's specificity
http://www.w3.org/TR/2003/WD-CSS21-20030915/cascade.html#specificity

# Concatenating the four numbers a-b-c-d (in a number system with
# a large base) gives the specificity.

Use of dashes here doesn't match use of commas in the examples.

Resolution: editorial, editor to deal with this
Reply: http://www.w3.org/mid/200402131739.i1DHdnCm030368@lanalana.inria.fr
Change not made, but reply said it was. See:
    http://www.w3.org/mid/402D0E3F.6010900@aol.com
Reply: http://www.w3.org/mid/16434.33648.835633.693769@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 150. http://www.w3.org/mid/3F9408C5.2040507@escape.com

# Note: The specificity is based only on the form of the selector.
# In particular, a selector of the form "[id=p33]" is counted as an
# attribute selector (a=0, b=0, c=1, d=0), even if the id attribute
# is defined as an "ID" in the source document's DTD.

This text should be normative, not informative, and therefore should
not be marked as a note.
Also, move it up to before "Some examples", right after "Contcatenating
the four numbers a-b-c-d (in a number system with a large base) gives
the specificity".

Resolution: editorial, editor to deal with this
Reply: http://www.w3.org/mid/200402131739.i1DHdsDk030612@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 151. http://www.w3.org/mid/3F9408C5.2040507@escape.com

S6.4.4: Precedence of non-CSS presentational hints

# For XHTML and other languages written in XML, no attribute should
# be considered presentational. The styling of elements and
# non-presentational attributes should be handled in the user agent
# stylesheet.

First off, the non-presentational attributes aren't being styled.
The elements to which they belong are being styled based on these
attributes.

Original resolution: technically yes but editorial, let editor solve
this
Resolution: Covered by issue 153.
Reply: http://www.w3.org/mid/200402131739.i1DHds8N030616@lanalana.inria.fr
Response: http://lists.w3.org/Archives/Public/www-style/2004Feb/0279.html
Reply: http://lists.w3.org/Archives/Public/www-style/2004Feb/0317.html
Issue closed.
------------------------------------------------------------------------
Issue 152. http://www.w3.org/mid/3F9408C5.2040507@escape.com

Secondly, the 'spacing' attribute of <orderedlist> in DocBook
  <http://www.docbook.org/tdg/en/html/orderedlist.html>
is clearly presentational. Trying to deny this is silly. What you
/want/ to do is to restrict the special handling of presentational
hints to HTML.

Like this:
# The UA may choose to honor presentational attributes in the source
# document.

 > The UA may choose to honor presentational attributes in an HTML
 > source document.

Resolution: sure, take the change
Reply: http://www.w3.org/mid/200402131739.i1DHdnkk030372@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 153. http://www.w3.org/mid/3F9408C5.2040507@escape.com

# For XHTML and other languages written in XML, no attribute should
# be considered presentational. The styling of elements and
# non-presentational attributes should be handled in the user agent
# stylesheet.

 > For other languages, all document language-based styling should be
 > handled in the user agent style sheet.

(SGML needs to be handled somewhere, so one can't say HTML and XML
without leaving room for the general case.)

Resolution: agree as well
Reply: http://www.w3.org/mid/200402131739.i1DHdnIc030376@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 154. http://www.w3.org/mid/3F9408C5.2040507@escape.com

# The following user stylesheet would override the font weight of
# 'b' elements in all documents, and the color of 'font' elements
# with color attributes...

I personally think an example with <center> and <div align="center">
would be more interesting... =]

Resolution: Response: "No comment."
Reply: http://www.w3.org/mid/200402131739.i1DHdnNS030380@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 155. http://www.w3.org/mid/3F94ED06.5060006@escape.com

S9.4.3 Relative positioning
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#relative-positioning

# Relative positioning may also be used as a general form of superscripting
# and subscripting except that line height is not automatically adjusted to
# take the positioning into consideration.

change to
   Although relative positioning may be used as a form of superscripting and
   subscripting, the line height is not automatically adjusted to take the
   positioning into consideration.

Resolution: remove the entire sentence or make it informative
Reply: http://www.w3.org/mid/200402131739.i1DHdodR030384@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
[Issue 156. duplicate of 155.]
------------------------------------------------------------------------
Issue 157. http://www.w3.org/mid/3F94ED06.5060006@escape.com

S9.5 Floats
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats

# The top of the floated box is aligned with the top of the current line
# box (or bottom of the preceding block box if no line box exists).

Are you saying that a float floats over it's parent's top margin+border+padding?

Resolution: replace with:
# If there's a line box, the top of the floated box is aligned with
# the top of the current line box.
Document updated.
Reply: http://www.w3.org/mid/200402131739.i1DHdoaq030388@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 158. http://www.w3.org/mid/3F94ED06.5060006@escape.com

# The margin box of an element in the normal flow that establishes a new
# block formatting context (such as a table, or element with 'overflow'
# other than 'visible') must not overlap any floats in the same block
# formatting context as the element itself. If necessary, implementations
# should clear the said element by placing it below any preceding floats,
# but may place it adjacent to such floats if there is sufficient space.

The margin box of an element in normal flow is always as wide as the
containing block. What is this rule *supposed* to say?

Resolution: We think it's good enough.
Reply: http://www.w3.org/mid/200402131739.i1DHdovt030392@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 159. http://www.w3.org/mid/3F94ED06.5060006@escape.com

# Example. In the following document fragment, the containing block is
# too short to contain the content

Too narrow, not too short. The /line boxes/ are too short next to the
float; the containing block is wide (and long) enough.

Resolution: agree
Document updated.
Reply: http://www.w3.org/mid/200402131739.i1DHdoSq030396@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 160. http://www.w3.org/mid/3F94ED06.5060006@escape.com

# Formatting would have been exactly the same if the document had been:
...
# because the content to the left of the float is displaced by the float
# and reflowed down its right side.

Poor explanation, imo. Try:
   because the float is taken out of the flow from the same line as in
   the previous example.

Resolution: disagree, original is better
Reply: http://www.w3.org/mid/200402131739.i1DHdo9Q030400@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 161. http://www.w3.org/mid/3F94ED06.5060006@escape.com

S9.5.1 Positioning the float: the 'float' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#float-position

# It may be set for elements that generate boxes that are not absolutely
# positioned.

It can be set for any element. It just doesn't _apply_ to some of them.

Resolution: nitpicking. up to editor.
Reply: http://www.w3.org/mid/200402131739.i1DHdoBc030404@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 162. http://www.w3.org/mid/3F94ED06.5060006@escape.com

# Same as 'left', but content flows on the left side of the box, starting
# at the top.

No, it's not the same as 'left' because it's floated to the _right_, not
the left.

Resolution: true. should be fixed.
Document updated.
Reply: http://www.w3.org/mid/200402131739.i1DHdoWF030408@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 163. http://www.w3.org/mid/3F94ED06.5060006@escape.com

# References to other elements in these rules refer only to other elements
# in the same block formatting context as the float..

But weren't you just talking about inline elements? (Like in rule 5.)
Inlines don't participate in the block formatting context.

Resolution: Yes, they do, so we reject the change. But remove two
periods at the end of the sentence. editorial.
Document updated.
Reply: http://www.w3.org/mid/200402131739.i1DHdoXe030412@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 164. http://www.w3.org/mid/3F94ED06.5060006@escape.com
S9.5.2 Controlling flow next to floats: the 'clear' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#flow-control

# The clearance dimension is introduced as a dimension above the
# margin-top of an element that is used to push the element
# vertically (typically downward).

Calling it a dimension doesn't seem quite right. How about:

   Clearance is introduced as spacing above the margin-top of an
   element. It is used to push the element vertically downward,
   past the float.

Resolution: true. should be fixed.
Document updated.
Reply: http://www.w3.org/mid/200402131739.i1DHdoxp030416@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 165. http://www.w3.org/mid/3F94ED06.5060006@escape.com
| I can't think of any cases where clearance would cause the element
| to go up, so "typically" should not be there to imply that there
| are some.
Resolution: There _are_ cases.
Reply: http://lists.w3.org/Archives/Public/www-style/2003Oct/0360.html
Issue closed.
------------------------------------------------------------------------
Issue 166. http://www.w3.org/mid/3F94ED06.5060006@escape.com

# Values have the following meanings when applied to non-floating
# block boxes:

What about floating boxes?

Resolution: it's mentioned a few paragraphs lower down.
Reply: http://www.w3.org/mid/200402131739.i1DHdoRG030420@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 167. http://www.w3.org/mid/3F94ED06.5060006@escape.com

# Example:
#
#  span { clear: left }

This example is useless. Take it out.

Resolution: true. should be removed.
Document updated.
Reply: http://www.w3.org/mid/200402131739.i1DHdo3C030424@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 168. http://www.w3.org/mid/3F94ED06.5060006@escape.com

9.8.3 Floating a box
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q27

The image for these examples imply that all the leading is added
on top of the line. They should depict a 50/50 split in the leading.

Resolution: Unless someone volunteers to go through and make the
images accurate, we refer to the note at the end of section 9.8:
"Note. The diagrams in this section are illustrative and not to scale.
They are meant to highlight the differences between the various
positioning schemes in CSS 2.1, and are not intended to be reference
renderings of the examples given."
Reply: http://www.w3.org/mid/200402131739.i1DHdoKx030428@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 169. http://www.w3.org/mid/3F94ED06.5060006@escape.com

# #sibling { clear: right; color: red }

I thought we just established that 'float' does not apply to inline
elements?

Resolution: The example is indeed inaccurate, but we're going to leave
it for now.
Reply: http://www.w3.org/mid/200402131739.i1DHdoDp030432@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 170. http://www.w3.org/mid/3F94ED06.5060006@escape.com

S9.8.4 Absolute positioning
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q28

# Relative and absolute positioning may be used to implement change
# bars, as shown in the following example.
# ... the change bars seem to "float" to the left of the current line.

Wouldn't it make more sense to use a float?

Resolution: Please send us more substantial comments...
Reply: http://www.w3.org/mid/200402131739.i1DHdojX030436@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 171. http://www.w3.org/mid/3F94ED06.5060006@escape.com
(And wouldn't it be better to use a proper em-dash?)
Resolution: No really, _substantial_ comments...
Reply: http://www.w3.org/mid/200402131739.i1DHdpf1030440@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 172. http://www.w3.org/mid/3F94ED06.5060006@escape.com

S9.9.1 Specifying the stack level: the 'z-index' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#z-index

# In this section, the expression "in front of" means closer to the
# user as the user faces the screen.

screen -> canvas

Resolution: No change.
Reply: http://www.w3.org/mid/200402131739.i1DHdpcK030444@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 173. http://www.w3.org/mid/3F94ED06.5060006@escape.com

# Stacking contexts are not necessarily related to containing blocks.
# In future levels of CSS, other properties may introduce stacking
# contexts, for example 'opacity'.

The first sentence needs an example.

Resolution: No change. We disagree.
Reply: http://www.w3.org/mid/200402131739.i1DHdpsZ030448@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 174. http://www.w3.org/mid/3F94ED06.5060006@escape.com

# Stacking contexts are not necessarily related to containing blocks.
# In future levels of CSS, other properties may introduce stacking
# contexts, for example 'opacity'.

The second sentence should not have [an example].

Resolution: No change. We disagree.
Reply: http://www.w3.org/mid/200402131739.i1DHdp17030452@lanalana.inria.fr
Response: http://www.w3.org/mid/402D28C3.3010406@escape.com
Reply: http://www.w3.org/mid/BC5270B3.3640F%25tantek@cs.stanford.edu
Issue closed.
------------------------------------------------------------------------
Issue 175. http://www.w3.org/mid/3F94ED06.5060006@escape.com

# The default behavior of a box is to allow boxes behind it to be
# visible through transparent areas in its content.

The default behavior of the background is...

Resolution: Editorial, up to editor.
Reply: http://www.w3.org/mid/200402131739.i1DHdpWd030456@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 176. http://www.w3.org/mid/3F94ECB2.3080503@escape.com

S9.2.1 Block-level elements and block boxes: Anonymous block boxes
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#anonymous-block-level

# The properties of anonymous boxes are inherited from the enclosing
# non-anonymous box (in the example: the one for DIV).

There's no DIV in the example. (It would make sense for the example
a few paragraphs up, but that's not in range of this sentence.)

Resolution: Editorial: refers to the example at the top of the
section, editor to clarify maybe. (move paragraph up above example)
Reply: http://www.w3.org/mid/200402131739.i1DHdpJJ030460@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 177. http://www.w3.org/mid/3F94ECB2.3080503@escape.com

# Properties set on elements that are turned into anonymous block boxes
# still apply to the content of the element. For example, if a border
# had been set on the BODY element in the above example, the border
# would be drawn around C1 and C2.

Would the border be drawn as a block border around C1 and another around
C2, or would the border be drawn as an inline border around C1 and another
around C2?

(Original resolution: Strike the paragraph, or edit it so that it
makes sense -- but no element is ever "turned into" an anonymous block
box.)
Resolution changed due to issue resolution conflict with issue 206.
Resolution: See issue 206.
Reply: http://www.w3.org/mid/200402131739.i1DHdp8U030464@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 178. http://www.w3.org/mid/3F94ECB2.3080503@escape.com

Would the border split where the block occurs? I.e. if it's a block border,
would the bottom border not exist for C1/if it's an inline border, would
the last border not exist for C1?

Resolution: it's inline, and the last border does indeed not exist for
C1, but the spec is clear about this in our opinion.
Reply: http://www.w3.org/mid/200402131739.i1DHdpKX030468@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 179. http://www.w3.org/mid/3F94ECB2.3080503@escape.com

If it's a block border, then what happens with:
   <p>There's an <em>interesting <span class="block">formatting</span>
      effect</em> in this paragraph.</p>

   em { border: solid }
   .block { display: block }

?

Resolution: It's not a block border.
Reply: http://www.w3.org/mid/200402131739.i1DHdp8v030472@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 180. http://www.w3.org/mid/3F94ECB2.3080503@escape.com

S9.2.2 Inline-level elements and inline boxes: Anonymous inline boxes
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#anonymous

# The <p> generates a block box, with several inline boxes inside it...
# ...they don't have an associated inline-level element.

No mention of the conditions for creating an anonymous inline.

Resolution: This will be better defined in CSS3. [or we could add
"Text directly inside block-level elements is wrapped by anonymous
inline boxes." - ian]
Reply: http://www.w3.org/mid/200402131739.i1DHdp3n030476@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 181. http://www.w3.org/mid/3F94ECB2.3080503@escape.com

S9.2.3: Run-in boxes
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#run-in

# If a block box (that does not float and is not absolutely positioned)
# follows the run-in box, the run-in box becomes the first inline box
# of the block box.

I don't think the intention is to have last-child run-ins combine with
their parents' next-siblings, so change that to "a sibling block box".

Resolution: Assumed editorial by David, Ian, Bert.
Reply: http://www.w3.org/mid/200402131739.i1DHdp1u030480@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 182. http://www.w3.org/mid/3F94ECB2.3080503@escape.com
Also, see http://lists.w3.org/Archives/Public/www-style/2000May/0010.html

Resolution: Covered by issue 103. Reporter to clarify if she does not
deem the issue resolved.
Reply: http://www.w3.org/mid/200402131739.i1DHdpVc030484@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 183. http://www.w3.org/mid/3F94ECB2.3080503@escape.com

S9.2.4 The 'display' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#display-prop

# and the element itself is formatted as a replaced element on the line.
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
change to
   as an inline replaced element.

Resolution: Assumed editorial by David, Bert, Ian.
Reply: http://www.w3.org/mid/200402131739.i1DHdp4U030488@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 184. http://www.w3.org/mid/3F94ECB2.3080503@escape.com

S9.3.1 Choosing a positioning scheme: 'position' property
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#choose-position
> In the case of the print media type, the box is fixed with respect to
> the page

If it repeats on every page, then that should be mentioned here.

Resolution: We accept the comment. (Editor to add mention here.)
Document updated.
Reply: http://www.w3.org/mid/200402131739.i1DHdpem030492@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 185. http://www.w3.org/mid/3F94ECB2.3080503@escape.com

S9.3.2 Box offsets: 'top', 'right', 'bottom', 'left'
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#choose-position

It seems like the property definitions for top, right, left, and bottom
could be combined into one table+description+note. Other than the name
of the side, the text is exactly the same.

# The offset is a percentage of the containing block's box width
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
change to
   containing block's width

Resolution: Dealt with by issue 62.
Reply: http://www.w3.org/mid/200402131739.i1DHdqZm030496@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 186. http://www.w3.org/mid/3F94ECB2.3080503@escape.com

# See the sections on the width and height of absolutely positioned,
# non-replaced elements for details

Strike out "non-replaced".

Resolution: We disagree.
Reply: http://www.w3.org/mid/200402131739.i1DHdqKq030500@lanalana.inria.fr
Response: http://www.w3.org/mid/402D2D44.8030707@escape.com

Resolution: Add "For non-replaced elements," at the start of the <dd>
for 'auto', then add at the end of it: "For replaced elements, the
effect of this value depends only on the intrinsic dimensions of the
replaced content. See the sections on the <a
href="visudet.html#abs-replaced-width">width</a> and <a
href="visudet.html#abs-replaced-height">height</a> of absolutely
positioned, replaced elements for details."

Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402172347440.2286@dhalsim.dreamhost.com
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 187. http://www.w3.org/mid/3F94ECB2.3080503@escape.com
|
| S9.4.1 Block formatting context
| http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q15
| # In a block formatting context, each box's left outer edge touches the
| # left edge of the containing block (for right-to-left formatting, right
| # edges touch). This is true even in the presence of floats (although a
| # box's line boxes may shrink due to the floats).
|
| What about clearance?

Resolution: Clearance doesn't affect it (wrong axis) -- See also issue 60b.
Reply: http://www.w3.org/mid/200402131739.i1DHdqKX030504@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 188. http://www.w3.org/mid/3F94ECB2.3080503@escape.com

S9.10 Text direction: the 'direction' and 'unicode-bidi' properties
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#direction

# For the 'direction' property to have any effect on inline-level
# elements...                  ^^^^^^^^^^^^^^^^^^

change to
   For the 'direction' property to affect reordering in inline-level
   elements...

Resolution: Assumed editorial by Ian, David, Bert.
Reply: http://www.w3.org/mid/200402131739.i1DHdqJk030508@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 189. http://www.w3.org/mid/3F94ED7C.8070206@escape.com

S8.2 Examples of margins, padding, and borders
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#mpb-examples

# The content width for each LI box is calculated top-down; the
# containing block for each LI box is established by the UL element.

The relationship between these two sentences is not clear. What
does top-down calculation have to do with the UL establishing a
containing block for each LI?

Resolution: Assumed disagreement; the spec seems clear to us here.
(It's basically saying the same thing in two different ways: the
widths are determined from the root element down to the inner most
elements, via the containing block hierarchy.)
http://www.w3.org/mid/20031120004949.GA10250@darby.dbaron.org
Reply: http://www.w3.org/mid/200402131739.i1DHdqea030512@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 190. http://www.w3.org/mid/3F94ED7C.8070206@escape.com

# The right padding of the LI boxes has been set to zero width
# (the 'padding' property). The effect is apparent in the second
# illustration.                 ^^^^^^^^^^^^^^^^^^

No it's not.

Resolution: Assumed editorial by David, Bert, Ian.
Reply: http://www.w3.org/mid/200402131739.i1DHdqHx030516@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 191. http://www.w3.org/mid/3F94ED7C.8070206@escape.com

S8.3 Margin properties
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#margin-properties

# If the containing block's width depends on this element, then
# the resulting layout is undefined in CSS 2.1.

Might want to give an example of when this happens.

Resolution: Assumed disagreement by David, Ian, Bert. This is a
specification, not a thesis. The reasons why things are undefined are
documented in the working group's discussions.
http://www.w3.org/mid/20031120004949.GA10250@darby.dbaron.org
Reply: http://www.w3.org/mid/200402131739.i1DHdq6E030520@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 192. http://www.w3.org/mid/3F94ED7C.8070206@escape.com

# margin-top, margin-bottom
# Applies to: all elements but inline, non-replaced elements and
#             internal table elements

Any reason why it doesn't need to apply to inline, non-replaced
elements? Borders and padding do; they just don't have an effect
on line-height calculation. Since that seems to be the rationale
for excluding it, I'd just combine the definitions for all margins
and leave the no-effect part to the inline model explanation.

Resolution: Assumed disagreement by Ian, David, Bert. Vertical margins
don't apply to non-replaced inlines because they have absolutely no
effect, and it is easier to explain this by saying "they don't apply"
than "well they apply, they just don't do anything".
http://www.w3.org/mid/20031120004949.GA10250@darby.dbaron.org
Reply: http://www.w3.org/mid/200402131739.i1DHdqfT030524@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 193. http://www.w3.org/mid/3F94ED7C.8070206@escape.com

S8.3.1 Collapsing margins
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#collapsing-margins

The number of times "clearance" is referred to without reasonable
context or previous definition is just maddening. Call it "float
clearance" or something, at least.

(I've been reading straight through, so continuity problems are
more evident.)

Resolution: The hyperlink is good enough. We don't know how to resolve
this otherwise.
Reply: http://www.w3.org/mid/200402131739.i1DHdqhv030528@lanalana.inria.fr
Response: http://www.w3.org/mid/402D2E5E.9010505@escape.com
Resolution: It's bad to use two terms for the same thing.
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402172352190.2286@dhalsim.dreamhost.com
Issue closed.
------------------------------------------------------------------------
Issue 194. http://www.w3.org/mid/3F94ED7C.8070206@escape.com

# Vertical margins between a floated box and any other box do not
# collapse (not even between a float and its in-flow children).

Not even between two boxes both floating left? Things would look
nicer imo if these margins would collapse.

Resolution: We disagree. This is something interoperably implemented
which originated in CSS1.
http://www.w3.org/mid/20031120004949.GA10250@darby.dbaron.org
Reply: http://www.w3.org/mid/200402131739.i1DHdqIu030532@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 195. http://www.w3.org/mid/3F94ED7C.8070206@escape.com

S8.5 Border properties
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#border-properties

# Note. Notably for HTML, user agents may render borders for certain
# elements (e.g., buttons, menus, etc.) differently than for "ordinary"
# elements.

Are you sure you want this to be informative?
Also, I suggest adding "user interface" between 'certain' and 'elements'.

Resolution: Keep it informative, but editor can edit text to be
clearer if he likes.
Reply: http://www.w3.org/mid/200402131739.i1DHdqvG030536@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 196. http://www.w3.org/mid/3F94ED7C.8070206@escape.com

S8.5.3
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#border-style-properties

# none
#    No border.

I'd put
>    No border; the border width is zero.

Resolution: Assumed editorial by David, Ian, Bert.
Document updated.
Reply: http://www.w3.org/mid/200402131739.i1DHdqp0030540@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 197. http://www.w3.org/mid/3F94ED7C.8070206@escape.com

S8.6 The box model for inline elements in bidi context
http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#q11

Beautiful! I would make one change, however:

# the left-most generated box of the first line box in which the
# element appears has a left margin, left border and left padding
                      ^
Change "a left margin" to "the left margin", and likewise for the
other three analogous instances.

Resolution: Assumed editorial by David, Tantek, Bert, and Ian.
Document updated.
Reply: http://www.w3.org/mid/200402131739.i1DHdqVe030544@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 198a. http://www.w3.org/mid/3F94F0D9.7060200@escape.com

> S9.10 Text direction: the 'direction' and 'unicode-bidi' properties
> http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#direction

Left out the rest:

# For block-level elements this creates an override for inline-level
# descendents not within another block.

Why does adding a "display: block" to an element in a paragraph all
of a sudden obviate the need for a directional override?


Resolution: See CSS3 Text or a tutorial for details about why
'direction' and 'unicode-bidi' work this way. We don't need to change
anything.
Reply: http://www.w3.org/mid/200402131739.i1DHdrGJ030548@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 198b. http://www.w3.org/mid/3F94F0D9.7060200@escape.com
| # In this process, non-textual entities such as images are treated
| # as neutral characters
|
| as object replacement characters (U+FFFC)

I don't see why this is useful. - ian
Agree. - tantek

Resolution: Editor may check with CSS3 Text and/or Michel Suignard
<michelsu@microsoft.com> to see if this matters or not. Suggested no
change.
Reply: http://www.w3.org/mid/200402131739.i1DHdrVJ030552@lanalana.inria.fr
Response: http://www.w3.org/mid/402D2EA0.3090309@escape.com
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402171356590.14033@dhalsim.dreamhost.com
Issue closed.
------------------------------------------------------------------------
Issue 199. http://www.w3.org/mid/CC289B4D-040A-11D8-AEB2-000A958E6110@apple.com
hyatt says: If I have:

<p><br>Foo

Is the "F" considered a first-letter?  I'd like the answer to be no.
More generally, I'd like to state that a first-letter must occur on a
first-line.

Does that seem reasonable?

tantek says: See http://tantek.com/w3c/css/pbrfirstletter.html for a
test and more info. See related http://tantek.com/w3c/css/pbrfirstline.html .

Resolution: Agreed.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 200. http://www.w3.org/mid/020A3CF87FB5AC47AA67966B33845755069BA20A@xboi22.boise.itc.hp.com
|
| Neither the CSS2 or the CSS2.1 specifications address vertical-align
| <length> in section 17.5.3 Table height Algorithms.
|
| Is there a reason for omitting <length> and <percentage>?  If so, CSS2.1
| should state why these values of vertical-align are not appropriate.
|
| If this is a oversight, I think the spec should say that they have their
| meanings as defined.

Bert says:
I think it is indeed an oversight that nothing is said about
'vertical-align: <length>|<percentage>' for tables. And I think it
should say that it does nothing and is interpreted as 'baseline' (the
initial value). It should say this in 17.5.3.

Resolution: We should say it does the same as baseline.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 201a. http://www.w3.org/mid/3F96E580.26593.6A6B1A@localhost

http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats
# The margin box of an element in the normal flow that establishes a
# new block formatting context (such as a table, or ...

That 'table' should possibly read table-cell, but i think it makes
more sense to update
http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q15
to include tables as well.

Resolution: Update to "The margin box of a table or an element in the
normal flow that establishes a new block formatting context (such as
an element with 'overflow' other than 'visible') must not overlap any
floats in the same block formatting context as the element itself."
(Note that a display:table does not establish a block formatting
context, a display:table establishes a table formatting context.)
Reply: http://www.w3.org/mid/200402131739.i1DHdr3I030556@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 201b. http://www.w3.org/mid/3F96E580.26593.6A6B1A@localhost

Also, i think it may be a good idea to change the heading
"9.4.1 Block formatting context"
to
"9.4.1 Block formatting contexts"
to make it more explicit that there are multiple.

Resolution: Editorial.
Reply: http://www.w3.org/mid/200402131739.i1DHdrIU030560@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 202. http://www.w3.org/mid/B2901A91-05A3-11D8-A7F5-000A958E6110@apple.com
Does first-line apply to list-items and table-cells as well as blocks?

(Original resolution: Yes, :first-line DOES apply to list-items and
table-cells as well as blocks. The effect of :first-line on list item
markers is undefined in CSS2.1. See
http://tantek.com/w3c/css/litdfirstline.html for tests and results.)
Resolution changed due to issue resolution conflict with issue 219.
Resolution: See issue 219.
Issue closed.
------------------------------------------------------------------------
Issue 203. http://www.w3.org/mid/B2901A91-05A3-11D8-A7F5-000A958E6110@apple.com

Hyatt says: Does first-letter apply only to block flows like
list-items, table cells, and blocks? I'd prefer it if it did, i.e., if
it was applicable only to the same set of elements that first-line is
applicable to. It doesn't make sense to me to apply it to inlines,
since an inline element could be right in the middle of a word. The
term "first-letter" sort of loses its meaning if it could be applied
to inlines.

Tantek says: I think first-letter can make sense in many inline
contexts, like the start of a sentence. I have seen the first-letter
of some inline spans (like words) boldened in a few instances in some
publications. In CSS3 Selectors we made the deliberate choice to allow
first-letter to apply to *all elements* for this reason. However, for
CSS2.1 I am fine with saying that :first-letter, like :first-line, can
only be attached to a block-level element. See
http://tantek.com/w3c/css/inlinefirstletter.html for tests and
results.

Ian says: I think we should make apply only to blocks in 2.1 too.

Bert says: No opinion.

Resolution: Doesn't apply to inlines in 2.1
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 204. http://www.w3.org/mid/B2901A91-05A3-11D8-A7F5-000A958E6110@apple.com

Hyatt says: Do first-line and first-letter cross from blocks into
inline blocks? For the former, I'd say "No", since that doesn't make
much sense, and so i'd like to say "No" for first-letter as well in
order to be consistent.

<div><span style="display:inline-block">Hello</span></div>

In the above, I'd like a first-letter/line style on the div not to
apply to "Hello" at all.

Tantek says: Proposed resolution: Accept. I agree that descendant
inline-blocks (and floats and positioned elements and tables and table
cells etc.) should *not* get first-line(letter) styling from a block
parent whose first-line(letter) was selected. See
http://tantek.com/w3c/css/firstlinefloatinlineblock.html for tests of
first-line in particular and results.

Resolution: Agreed. :first-line doesn't _apply_ to the inline-block
(you stop propagating the "pseudo-elementness" when you hit a line
box, basically, so :first-line only applies to one line). (Note,
however, that we don't define if styles set on the :first-line should
/inherit/ into inline-blocks on the first line. That's undefined in
2.1 because we don't know what is best yet.)
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 205a. http://www.w3.org/mid/200310270540.h9R5ehJv016652@nerd-xing.mit.edu

-- Section 9.1.2 (Containing blocks)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#containing-block>

Does the root element sentence really belong here rather than in the sections
describing those properties?

Resolution: Editorial. Those caveats for the root element should be
stated in the sections for those properties (float, position).
Reply: http://www.w3.org/mid/200402131739.i1DHdrQ8030564@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 205b. http://www.w3.org/mid/200310270540.h9R5ehJv016652@nerd-xing.mit.edu
-- Section 9.2.1 (Anonymous block boxes)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#anonymous-block-level>

The example talks about having a "anonymous block box for BODY".  I'm not sure
what this means.  Since the BODY is an inline inside a block (HTML), and the
boxes of BODY end up with a block sibling (the P), I would expect an anonymous
block _around_ the BODY boxes.  But the boxes of BODY should be inline.

This example should probably be clarified.

Resolution: "anonymous block box for BODY" should be "anonymous block
box around the BODY".
Reply: http://www.w3.org/mid/200402131739.i1DHdrg9030568@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 206. http://www.w3.org/mid/200310270540.h9R5ehJv016652@nerd-xing.mit.edu
The part about being turned into anonymous block boxes that follows
the example is also confusing.... What does it mean for the border of
the BODY to apply in this case? The spec sounds like it should draw
two block-like borders -- one around the anonymous block containing
C1, one around the anonymous block containing C2.

David, Bert: This is editorial.

Tantek: It seems to me that the inline border from BODY may also be
drawn around the P (in addition to C1 and C2), due to wrapping of the
P with an anonymous inline. See
http://tantek.com/w3c/css/CSS21_921_eg2_bodyinline.html for online
version of the example in question with border declared on body.

Tantek and Ian propose to replace the last paragraph of 9.2.1 with:
|
| Properties set on elements that cause anonymous block boxes to be
| generated still apply to the boxes and content of that element. For
| example, if a border had been set on the BODY element in the above
| example, the border would be drawn around C1 (open at the end of the
| line) and C2 (open at the start of the line).
|
| Some user agents have implemented borders on inlines containing
| blocks in other ways, e.g. by wrapping such nested blocks inside
| "anonymous line boxes" and thus drawing inline borders around such
| boxes. As CSS1 and CSS2 did not define this behavior, CSS1-only and
| CSS2-only user agents may implement this alternative model and still
| claim conformance to this part of CSS2.1. This does not apply to UAs
| developed after this specification was released.

Resolution: Text above accepted.
Reply: http://www.w3.org/mid/200402131739.i1DHdrC6030572@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
[Issue 207. Duplicate of issue 206.]
------------------------------------------------------------------------
Issue 208. http://www.w3.org/mid/200310270540.h9R5ehJv016652@nerd-xing.mit.edu
-- Section 9.2.2 (Inline-level elements and inline boxes)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q7>
'inline-block' should be listed as a display type that makes an element inline.

(I disagree; the spec is written in such a way that inline-block is
neither inline-level nor block-level, but listed explicitly where
appropriate. - ian)

Resolution: Disagree.
Reply: http://www.w3.org/mid/200402131739.i1DHdrqF030576@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 209. http://www.w3.org/mid/5.1.1.5.2.20031029164514.04806d40@mailsj-v1.corp.adobe.com
| Section 13.1 Introduction to paged media, paragraph numbered "1." says,
| "The page box [p. 196] extends the box model". I do not see how the page
| box is an extension. As shown in the figure in section 13.2.1, the page box
| seems to be a restriction of the normal box. The page box does not seem to
| have either borders or padding.
hakon says: http://www.w3.org/mid/200311032111.hA3LBgG27686@mail.opera.no
| Correct, I have reworded and shortened the introduction.
Resolution: Agreed.
Reply: http://www.w3.org/mid/200402131739.i1DHdrSc030580@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 210. http://www.w3.org/mid/5.1.1.5.2.20031029164514.04806d40@mailsj-v1.corp.adobe.com
| section 13.2 Page boxes: the @page rule, the first bullet item talks
| about the "page area" and the second bullet item says the margins
| surround the "page area", but the figure in section 13.2.1 show the
| margins surrounding the "page content". I assume that "page area"
| and "page content" are the same thing, but if that is true then only
| one name should be used. I also assume that the "page area/page
| content" is the "content rectangle/area" for the page box. (I base
| this assumption on the statement in the first bullet item that, "The
| edges of the page area act as the initial containing block.")
hakon says: http://www.w3.org/mid/200311032111.hA3LBgG27686@mail.opera.no
| I don't find the term "page content" anywhere in the text.
Tantek thinks the author may have meant "page context".
Resolution: Agreed.
Reply: http://www.w3.org/mid/200402131739.i1DHdrEM030584@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 211. http://www.w3.org/mid/5.1.1.5.2.20031029164514.04806d40@mailsj-v1.corp.adobe.com
| Section 13.2.1 Page margins: the first paragraph explicitly says
| that the margin properties, "margin-top", "margin-bottom",
| "margin-right" and "margin-left" apply to the "page-context", but
| there does not seem to be a list of what other properties apply. For
| example, do the "height" and "width" properties apply? If so, do [they]
| define, as is usually the case, the height and width of the "page
| area/page content" rectangle. I assume that if they do not apply or
| are not specified, then their "auto" initial values will align the
| margin rectangle with the edges of the sheet and the "page area/page
| content" will fill the remaining space on the sheet (where I
| assuming that the sheet is acting like a containing block for the
| page box (which is itself the containing block for the page
| conent)). If the "height" and "width" properties do not apply, then
| how does one ever get a page box that differs in size from the
| sheet?
hakon says: http://www.w3.org/mid/200311032111.hA3LBgG27686@mail.opera.no
| In CSS 2.1 only the margin properties apply. I've changed the text
| to clarify this.
|
| Your assumptions are correct. In CSS 2.1, it is not possible to
| specify the size of the page box -- only the width of the page
| margins. So, one cannot get a page box that differs from the sheet
| (excluding n-up etc.). Should this be clarified? If so, could you
| suggest some text?
Resolution: Agreed.
Reply: http://www.w3.org/mid/200402131739.i1DHdrJc030588@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 212. http://www.w3.org/mid/5.1.1.5.2.20031029164514.04806d40@mailsj-v1.corp.adobe.com
| The general comment is that the description of how the page box is
| defined and how it relates to the sheet could be a lot more crisp
| and the figure in 13.2.1 is, I believe, misleading because it shows
| the margins inside the sheet without indicating what one would
| specify to acheive this result. I believe that one would need to say
| more than is said in section 13.2.1.
hakon says: http://www.w3.org/mid/200311032111.hA3LBgG27686@mail.opera.no
| I agree that figure 13.2.1 does not match the text fully since the
| bottom page margin is wider than the other. Before changing the
| figure, could you suggest some crispy text?
Resolution: No change, unless something really better is proposed.
Reply: http://www.w3.org/mid/200402131739.i1DHdrlU030592@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 213. http://www.w3.org/mid/5.1.1.5.2.20031029164514.04806d40@mailsj-v1.corp.adobe.com
| There seems to be a confusing referenence to "page context" in the
| first paragraph of 13.2.1 which refers to a definition on page 196 .
| The only thing that looks at all like a definition on page 196 is
| the sentence, "The declarations are said to be in the page context."
| This is hardly a definition. I wondered whether the "page context"
| is the new formatting context, like a block context, but it it were,
| I am not sure what that would have to do with declarations being in
| the "page context" I was, therefore, unsure what a page context was
| supposed to be or do.
hakon says: http://www.w3.org/mid/200311032111.hA3LBgG27686@mail.opera.no
| I've changed the text to read:
|>  The declarations in an @page rule are said to be in the page context.
Resolution: Agreed.
Reply: http://www.w3.org/mid/200402131739.i1DHdsIJ030596@lanalana.inria.fr
Document updated.
Issue closed.
========================================================================

Extracurricular issues
========================================================================
Issue 214. missing section in 10.3 -- at the Oslo meeting we agreed to
factor some stuff out in 10.3 but that has not materialised. We need
to check the minutes to make sure all the editing action items from
Oslo are taken into account.
Resolution: Editor to find out what is missing from Oslo minutes.
Document updated. (See issue 60 part 1 -- it was section 10.6.7 that
we were talking about here. -- ian)
Issue closed.
------------------------------------------------------------------------
Issue 215. adjacent/adjoining -- we need to decide on terminology for
8.3.1 and elsewhere. Are margins adjacent or adjoining.
Resolution: Use adjoining in the few cases where we have adjacent.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 216. should make sure we say that UAs may apply other properties
to :first-letter and :first-line.
Resolution: Agreed.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 217. [retracted: "computed value of length properties should not
be absolute lengths. e.g. the 'width' property computes to 'an
absolute length' but that isn't true, since 'px' is not an absolute
length." -- it is, actually, at this stage, since dpi is a constant
during rendering; and other units are dependent on font-size and so
can get computed to absolutes by this point]
Issue closed.
------------------------------------------------------------------------
[Issue 218. Issue retracted. Was: overflow-not-visible should create a
new stacking context. I think overflow should generate a new stacking
context because the idea of interleaving content outside an overflow
block and content inside the block seems both unintuitive and complex
to implement (having heard people whine about how to implement
stacking contexts...). - Ian (Note: Block formatting context and
stacking context are totally independent.)
<Hixie> control: http://junkyard.damowmow.com/102
<Hixie> test: http://junkyard.damowmow.com/103
MacIE and Mozilla do the same thing, as proposed
WinIE seems to as well.
Opera and Safari do not, they do it per spec.]
------------------------------------------------------------------------
Issue 219. "block level elements" is sometimes used to mean
block+table and sometimes to mean block + table-cell

Tantek says:

Yes this could be a problem.

Essentially the distinction is outer-block-level-ness and
inner-block-level-ness, e.g.

 display      block-level-ness (if any)
 -------------------------------------
 block        inner and outer
 list-item    inner and outer
 table        outer
 table-cell   inner
 inline-block inner

I believe "block level elements" is used nearly always to mean "outer
block level" but there are probably some instances where it really
means "inner block level". Not sure how to resolve this.

Perhaps we should simply leave this as is and address specific
instances as we find them (e.g. if "block level element" is used in a
context where table vs. table-cell makes a difference, we can point
that out).

Notes from meeting: How to resolve this for table-cells and
   inline-blocks and table-captions: Imagine the same situation with
   an anonymous block box immediately inside the table cell containing
   all its children -- the rendering should be the same.

Resolution: Solve individual cases (see below) and rely on editors to
find further cases.

Resolution 1:
   For line-height, change "If the property is set on a block-level
   element whose content" to "If the property is set on a block-level,
   table-cell, table-caption or inline-block element whose content".

Resolution 2:
   For vertical-align, change "or to the strut of a parent block-level
   element." to "or to the strut of a parent block-level, table-cell,
   table-caption or inline-block element."

Resolution 3:
   :first-line pseudo-element should apply to block-level, table-cell,
   table-caption or inline-block.

Resolution 4:
   Definition of bidi-override, second sentence, reword to: For
   block-level, table-cell, table-caption, or inline-block elements
   this creates an override for inline-level descendents not within
   another block-level, table-cell, table-caption, or inline-block
   element.

Resolution 5:
   Editors to check their chapters for occurances of the term "block
   level" to ensure the above criteria are met.
    --  http://www.w3.org/mid/BC52B345.3647F%25tantek@cs.stanford.edu

Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 220. Table and table formatting contexts: tables don't generate
new BFCs but still need to dodge floats.

Tantek says: We could say that tables generate new "float formatting
contexts" and thus both must dodge floats, and nothing inside them can
float outside. The latter statement is also true for table-cells.

Ian says: What's a "float formatting context"? Wouldn't that be the
same as a block formatting context?

Duplicate of issue 201a.
Issue closed.
------------------------------------------------------------------------
Issue 221. Margins of children of inline-blocks
Resolution: inline-block children margins do not collapse with the
inline-block margins. Add this as bullet to section 8.3.1. (Same as
floats and abs pos.)
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 222. Character classes: Pi and Pf classes should be mentioned in
5.12.2.
Resolution: Uh, sure, you got it.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 223. 10.6.1. "the formed would" should read "the former would".
Resolution: Editorial.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 224. 10.6.6. "(Note that the margins of the float and its
children do not collapse together.)" -- this section now talks about
more than just floats, so this needs updating to be more generic.
Resolution: Editorial.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 225. Where does a float between two blocks go? The current text
contradicts itself (defines it as being at the bottom of the last line
box or the top of the (common) containing block, then says it is
undefined and should be positioned at a place between collapsed
margins). We could change rule 5 in section 9.5 to read:

5. The outer top of a floating box may not be higher than the outer
   top of any block or floated box generated by an element earlier in
   the source document<ins>, and may not be higher than the bottom padding
   edge of any earlier block-level sibling</ins>.

...or add a new rule after rule 5 to mention that, or we could move
the text after the rules to be before the rules, or be the first rule,
and change the text to read:

0. When the float occurs between two collapsing margins, the float is
   positioned as if it had an otherwise empty anonymous block parent
   taking part in the flow. The position of such a parent is defined
   by the rules in the section on margin collapsing. This block then
   becomes the containing block for the float in the rules below.

See also:
  http://www.w3.org/mid/20031121002240.GA25096@darby.dbaron.org
  http://www.w3.org/mid/A23328EA-1BBA-11D8-BE2C-000A958E6110@apple.com

Note: This is technically editorial (We already agreed to the change,
we just got the wording too wooly. Our sheep would be proud.)

Resolution: Take the paragraph after the rules in section 9.5 Floats
("When the rules above do not result in an exact vertical position, as
may be the case when the float occurs between two collapsing margins,
the float is positioned as if it had an otherwise empty anonymous
block parent taking part in the flow. The position of such a parent is
defined by the rules in the section on margin collapsing.") and move
it to the end of rule 4, then edit the first bit of this text (up to
the second comma) to read "When the float occurs between two
collapsing margins".

Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 226. Line boxes shrink to make room for floats... do we want to
say they make room for the outer edge of a float? If not, earlier
content can have to move out of the way of later floats, which is a
circular dependency. We appear to have lost the note saying that
behaviour for negative margins on floats is undefined. (It doesn't
need to be, the most sensible, IMHO, behavour is to define things per
the outer edge as we have for the rules.)

Tantek suggests: "negative margins for floats may not necessarily
display earlier content"

Ian says: I'd rather just say it shouldn't (i.e. "use the margin
box"). It seems much more predictable, a LOT easier to implement, and
actually more useful for authors who want to have that kind of effect.
For example, Eric's book has examples where he puts negative margins
on floats that would get broken if we let UAs wrap around the border
edge instead.

Tantek later agreed with Ian.

David and Bert also agree.

Resolution: Change "However, line boxes created next to the float are
shortened to make room for the floated box" to "However, line boxes
created next to the float are shortened to make room for the margin
box of the float". (adds "for the margin box of" remove trailing "ed
box".)
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 227.
<dbaron> http://www.w3.org/TR/CSS21/generate.html#propdef-content
<dbaron> the final example in section 12.2 should have 'white-space: pre'.
Resolution: Assumed agreement by David, Tantek, Ian.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 228.
# 'background-position'
# Value: [ [<percentage> | <length> | top | center | bottom] ||
#          [<percentage> | <length> | left | center | right] ] | inherit

...should be:

  Value: [ [ <percentage> | <length> | left | center | right ]
           [ <percentage> | <length> | top | center | bottom ]? ] |
         [ [ left | center | right ] || [ top | center | bottom ] ] |
         inherit

Resolution: Agreed.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 229. http://www.w3.org/mid/20031116221647.GA15866@darby.dbaron.org
| I think the CSS 2.1 exit criteria need to be revised to take this into
| account.  (I wasn't previously aware that you considered the error
| handling rules applicable to a feature not to be part of that feature.)

(i.e. do we need a way to say that unless a UA pass all the error
handling tests of the test suite, it doesn't count? Or do we need a
way to say that a feature that for a feature to pass, we have to have
interoperability on its forward-compatibility parsability as well as
its implementation?)

See also: http://www.w3.org/mid/Pine.LNX.4.58.0311162257160.3009@dhalsim.dreamhost.com
See also: http://lists.w3.org/Archives/Member/w3c-css-wg/2003OctDec/0200.html
See alse: http://www.w3.org/mid/Pine.LNX.4.58.0311170614520.3009@dhalsim.dreamhost.com

Tantek says: In general, I think this kind of criteria is too harsh
for 2.1, or even the CSS3 drafts which are in CR or passed LC. I think
perhaps the first CSS draft that should consider making use of such
criteria should be CSS3 Syntax (or whatever we rename it to).

Resolution:
  * Require that all UAs report results for all error handling tests.
  * UAs that fail error handling tests will not block that feature.
Issue closed.
------------------------------------------------------------------------
Issue 230. http://bugzilla.mozilla.org/show_bug.cgi?id=226067#c23
Add:
   table { border-spacing: 2px; }
...to our UA stylesheet. (WinIE6/Mozilla/Opera interoperate)

Resolution: Agreed.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 231. http://www.w3.org/mid/000701c3ae58$ffa563d0$b801a8c0@w3c40upc3ma3j2
Feedback regarding @charset, BOMs, etc, from i18n group.
See also: http://www.w3.org/mid/20031120011507.GA10275@darby.dbaron.org

Tantek suggests: postpone these changes to CSS3. I think this request
has come too late for CSS2.1, and should be postponed to CSS3 Syntax.
Basically, what David said at the end of his message:
  "(I think some of the conformance requirements mentioned here may be
  a bit strong for CSS 2.1 (although I don't feel strongly), but would
  certainly be reasonable for CSS3. "
Except that I *do* feel more strongly about not having these
conformance requirements in CSS2.1.

Resolution: No change, although note that we did agree to some
BOM-related text additions -- see issue 44.
Reply: http://www.w3.org/mid/200402131739.i1DHdsXo030600@lanalana.inria.fr
Response: http://www.w3.org/mid/40340502.3060801@yergeau.com
Reply: http://www.w3.org/mid/16442.34803.458599.316060@lanalana.inria.fr
Issue open. (We didn't address point 6 in the last response)
------------------------------------------------------------------------
Issue 232. "See the section on computing widths and margins" in 8.3
should refer to "calculating widths and margins".

Resolution: Editorial.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 233. http://bugzilla.mozilla.org/show_bug.cgi?id=227004
What is 'column width'; does it include cell padding, borders, border
spacing?

Tantek:
| Proposed resolution:
|   include cell padding: YES
|   include cell borders: NO
|   include border spacing: NO
|
| This is according to:
|
| http://www.w3.org/TR/CSS21/tables.html#auto-table-layout
|
| "column width" appears to include cell padding, but NOT cell border nor
| border spacing.

Resolution: Not sure what the problem is. (Ian may investigate further.)
Issue closed.
------------------------------------------------------------------------
Issue 234. http://bugzilla.mozilla.org/show_bug.cgi?id=45631

text-indent: % is relative to the containing block and not the width?!
That seems rather silly in cases like:

   <div class="very wide">
    <div class="very narrow and text-indent set to 50%">
    </div>
   </div>

Tantek:
| Yes and this should not change.
| See test case with compliant interoperable results from 3 browsers:
|  http://tantek.com/w3c/css/textindentpercentage.html

Ian:
| Opera and Safari also do this per spec.

Resolution: No change.
Issue closed.
------------------------------------------------------------------------
Issue 235.
Section 6.1.2, Computed values, needs to be slightly rewritten now
that we've changed the meaning of computed. I suggest replacing the
first two paragraphs with:

| Specified values are resolved to computed values during the cascade;
| for example valid relative URIs are made absolute and 'em' and 'ex'
| units are computed to pixel or absolute lengths. Computing a value
| never requires the user agent to render the document.
|
| The computed value of invalid and absolute URIs is the specified
| value.

Actual values (6.1.3, the next section) should be changed as well. In
fact we might want to add mention of Used values. I propose replacing
6.1.3 Actual values with:

| 6.1.3 Used values
|
| Computed values can be relative to each other; for example a width
| could be set as a percentage, which is dependent on the containing
| block's width. The <dfn id="usedValue">used value</dfn> is the
| result of taking the computed value and resolving these dependencies
| into a final absolute value used for the actual layout.
|
| 6.1.4 Actual values
|
| A used value is in principle the value used for rendering, but a
| user agent may not be able to make use of the value in a given
| environment. For example, a user agent may only be able to render
| borders with integer pixel widths and may therefore have to
| approximate the computed width, or the user agent may be forced to
| use only black and white shades instead of full colour. The actual
| value is the used value after any approximations have been applied.

Then in section 10.3 Calculating widths and margins replace the <dfn>
markup for the mention of "used value" with <a
href="cascade.html#usedValue">.

(Original resolution: Agreed with slightly different text. (assumed
editorial by Bert, David, Ian, Tantek))

Resolution: Make changes described above.

Resolution changed due to issue resolution conflict. See:
   http://www.w3.org/mid/Pine.LNX.4.58.0401221524260.3387@dhalsim.dreamhost.com

Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 236.
emeyer writes:
| In CSS2.1, section 17.2.1 talks about inserting anonymous objects in
| various scenarios, but it doesn't mention table-caption elements.  If
| I'm reading rule 5 correctly, then an anonymous table-row object should
| be inserted between a table-caption element and its parent table
| element.  Is that correct?
|
| The way I read the rules, the following markup:
|
|     <table>
|      <caption>ick</caption>
|      ...blah blah blah...
|     </table>
|
| ...should result in an anonymous table-row element being inserted
| between the table and the caption, thanks to rule #5, which doesn't
| list table-caption elements as one of the types that avoids the
| triggering of said rule.
|     Furthermore, if I'm correct, given the following:
|
|     <table>
|      <caption>ick</caption>
|      <td>yuck</td>
|     </table>
|
| ...then a single table-row should enclose the caption and cell
| together.  Am I overlooking something?

Resolution: add 'table-caption', 'table-column', and
'table-column-group' to rule 5 in section 17.2.1 Anonymous table
objects. Add 'table-header-group', 'table-footer-group' to rule 2 at
the end of the list of parts after "is not a".
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 237. http://lists.w3.org/Archives/Member/w3c-css-wg/2003OctDec/0244.html
list-style-type: georgian, armenian and greek
Resolution: add these back
Reply: http://www.w3.org/mid/200402131739.i1DHdsib030604@lanalana.inria.fr

Tantek:
| Ok with proposed resolution (since there are two implementations supposedly)
| with the understanding that this is a sufficiently new implementation
| development that even reasonably simple tests may reveal it to be
| insufficiently interoperably or compliably implemented.
|
| We really should draw the line here.  No more new features in CSS2.1.  (No
| new old ones either please). It is simply too late at this point, adding
| anything in will just slow down CSS2.1 more, perhaps enough so that other
| properties/values get implemented and need to be added, thus never-ending
| the revision/expansion of CSS2.1.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 238. http://lists.w3.org/Archives/Member/w3c-css-wg/2003OctDec/0263.html
We should define that text-transform:captialise doesn't affect
anything other than the first letter
Resolution: text-transform:capitalise should be clearer: capitalise
means change the first letter to uppercase but don't change the other
letters.
Reply: http://www.w3.org/mid/200402131739.i1DHdsND030608@lanalana.inria.fr
Reply: http://www.w3.org/mid/16429.18696.411447.196794@lanalana.inria.fr
Response: http://www.w3.org/mid/4.3.2.7.2.20040213130614.029f1a78@172.27.10.30
Reply: http://www.w3.org/mid/BC52766D.36429%25tantek@cs.stanford.edu
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 239.
In:
   <table><tbody><tr><td><span>text</></></></></>
...does a unicode-bidi: bidi-override on the table affect the text?

Duplicate of 219.
Issue closed.
------------------------------------------------------------------------
Issue 240.
In:
   <table><span>text</></> <!-- implied anonymous table elements -->
...does a unicode-bidi: bidi-override on the table affect the text?

Duplicate of 219.
Issue closed.
------------------------------------------------------------------------
Issue 241.
http://www.hixie.ch/tests/adhoc/css/background/22.html
http://bugzilla.mozilla.org/show_bug.cgi?id=226254
https://bugs.opera.com/show_bug.cgi?id=131589

Currently the spec says margins of the root element collapse with its
children. Should it?
Opera pre-release builds say yes.
Previous Opera builds say no.
Mozilla and Safari pre-release builds say no.
WinIE6.1 preview release build says no.

Doing this breaks livejournal.com quite visibly.

Could be easily fixed (if we think "no") by adding another bullet
point to 8.3.1:

* Margins of the root element's box do not collapse.

Resolution: Change the spec as described above.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 242.
The link in section 10.6.6 is broken ('height depends on the element's
descendants.', it's missing a fragment identifier). Same with the two
'based on the content' links in section 10.6.4.
Resolution: Agreed. Editorial.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 243.
| In issue 6 we decided to change the title of some sections:
| | 10.6.3 Block-level, non-replaced elements in normal flow when
| |        'overflow' computes to 'visible'
| | 10.6.6 Block-level, non-replaced elements in normal flow when
| |        'overflow' does not compute to 'visible'; 'inline-block',
| |        non-replaced elements; and floating, non-replaced elements.
| Should we add "root element" to 10.6.6? (Does the root element contain
| floats?)

Resolution: No. But. Change the two occurances of "if the element has
a non-zero ... padding and/or ... border," in section 10.6.3
("Block-level non-replaced elements in normal flow when 'overflow'
computes to 'visible'") to "if the element has a non-zero ... padding
and/or ... border, or is the root element,".
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 244. What does "generic notion of newline" mean wrt bidi?

Specifically, <br> is supposed to be equivalent to U+2028 LINE
SEPARATOR (HTML4 9.3.2.1), which is bidi class WS (whitespace
neutral), while U+000A is class B (paragraph separator).

But we say line breaks occur "where necessary" for automatic line
wrapping and "at occurances of \A" and "newlines in the source". We
also say that "\A is the generic concept of a newline" in CSS.

So how do you, in a pure CSS UA, implement the <br> element in CSS?

Are \A-style-newlines in generated content bidi class B? Presumably the
"needed" newlines are class WS?

Ref: http://www.unicode.org/reports/tr9/#Bidirectional_Character_Types

Tantek:
| I am not a bidi expert so I'm not sure how to evaluate this issue.
| How do bidi UAs implement <br> in terms of CSS?

Ian:
| Badly. IIRC, WinIE does it per CSS, Mozilla does it per HTML, and
| Opera does something stupid (treats it as a line break and LRO or
| something).

Resolution: No change. Ian to examine this for CSS3 Text.
Issue closed.
------------------------------------------------------------------------
Issue 245. Need to update the end of appendix E to match what we agreed
to in terms of backgrounds on root elements. (section 14.2)
Resolution: Assumed agreed. Editorial. (by Ian, Tantek)
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 246. Given that we agree that the cascade happens before layout,
how do you inherit from :first-line?

   <p> test <span> span </span> test </p>

   p { margin: 0; color: red; width: 20em; }
   p:first-line { margin-left: 25em; color: green; }
   span { margin: inherit; color: inherit; }

Tantek:
| Proposed resolution: inheriting from :first-line is undefined in CSS2.1.

Ian:
| So how do we (Opera, Mozilla, Safari) implement it?

test case: http://tantek.com/w3c/css/firstlineinheritance.html

Resolution: leave undefined and don't say anything in the spec.
(Come back later for CSS3)
Issue closed.
------------------------------------------------------------------------
Issue 247. Broken out of issue 219:
   Section 10.1 says "In the case that the ancestor is block-level" --
   what about if it is table-row? or a table-cell? or a
   table-row-group? or a table-column? or an inline-block? etc

Tantek:
| what about if it is table-row? No.
| or a table-cell? Yes.
| or a table-row-group? No.
| or a table-column? No.
| or an inline-block? Yes.

Ian:
| Why? I think it should work for table-cell and inline-block, and
| possibly row and row-group too.

DB: switch bullets one and two in middle list. Change "block
level" to "otherwise" in the (old) first bullet.

Resolution: Agreed.
Document updated.
Issue closed.
========================================================================

Emergency Issues.

There are issues that are either serious enough, or trivial enough,
that I (Ian) felt we should resolve them despite their coming in after
the official last call deadline.
========================================================================
Issue 248. http://www.w3.org/mid/3FA4B003.5080204@escape.com
|
| width, height:
|
| # Computed value:  the percentage as specified or the absolute length; 'auto'
| #                  if the property does not apply
|
| What happens if 'auto' is specified on an element to which the
| property /does/ apply?

DB: change to "the percentage _or auto_ as specified..."

Resolution: Agreed.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 249. http://www.w3.org/mid/3FA4B003.5080204@escape.com
Change "between" to "among" in first paragraph of "10.3.3 Block-level,
non-replaced elements in normal flow"
Resolution: Editorial. (Assumed by Ian, Tantek)
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 250. http://www.w3.org/mid/BBCA317A.2F7A5%tantek@cs.stanford.edu
where should scroll bar space come from
Proposed resolution (see e-mail) agreed by Tantek, David (dependent on
new testcase being written) and Ian (assuming David agrees).
Testcase included, see e-mail. More needed.
Thread:
  http://www.w3.org/mid/20031103012851.GA16667@darby.dbaron.org

Resolution: Tantek's proposed text (at the end of his e-mail
http://lists.w3.org/Archives/Member/w3c-css-wg/2003OctDec/0103.html)
to be added to the chapter.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 251. http://www.w3.org/mid/20031103011613.GA16565@darby.dbaron.org
whether centering of blocks using auto margins should center outside
viewport/containing block or be blocked by the left edge
Proposed resolution (see e-mail) agreed by David, Tantek and Ian.
Testcases included, see e-mail.

Resolution: use proposal from David in
http://lists.w3.org/Archives/Member/w3c-css-wg/2003OctDec/0104.html
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 252. http://www.w3.org/mid/3FA7E4EA.2030309@escape.com
Change "user-defined" to "author-defined" in the paragraph before the
last example in visufx.
Resolution: Agreed. Editorial.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 253. http://www.w3.org/mid/1067971420.c7f357a0cmoschini@myrealbox.com
|
| As long as we're discussing:
|  http://www.w3.org/TR/CSS21/media.html#media-groups
|
| Errata:
| The "emboss" media type is referred to as "embossed" in section 7.3,
| but "emboss" in 7.3.1.

Editorial, but WG needs to decide which is the real name. "emboss" is
more consistent with the other names, "embossed" sounds better. Straw
poll? It doesn't really matter, it's not like anyone is ever going to
support it anyway... *cough* -Ian. "emboss" -Tantek. That's fine by
me. -Ian.

Resolution: use "embossed" and change 7.3.1 (since (1) emboss is a
verb and (2) 7.3.1 is informative)
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 254. http://www.w3.org/mid/5B78805D3185784993C473999029D7366EA7D1@RED-MSG-53.redmond.corp.microsoft.com
| Although the tokenization section of CSS 2.1 spec
| <http://www.w3.org/TR/CSS21/syndata.html#tokenization> was changed to
| allow for hyphens as the first character of identifiers, the prose in
| the second bulleted list item of section 4.1.3 still reads "they cannot
| start with a hyphen or a digit."
Resolution: Editorial, remove "a hyphen or".
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 255. http://www.w3.org/mid/3FA8A89F.50002@escape.com
| What happens with
|    <div style="text-decoration: underline">
|      <p>paragraph</p>
|      <p>paragraph</p>
|      <p>paragraph</p>
|    </div>
| or
|    <table style="text-decoration: underline">
|      <tr>
|        <td>content</td>
|      </tr>
|    </table>
| ?

Tantek:
| See test case and results:
|
| http://tantek.com/w3c/css/textdecorationnestedblocks.html
|
| Proposal: IE5/Mac and Firebird0.7 have reasonable interop.  Go with that,
| and let IE6/Windows' implementation fall under the "CSS2-only user agents"
| exception clause already in the document.

Opera 7.50~ and Safari show both underlined. - Ian


TC: Probably need Ian here; the current text in 2.1 is his.
BB: Fantasai's issue seems to be that it is ambiguous when there is
_no_ anonymous inline text, but only blocks within blocks.
DB: Should that make a difference?
BB: It shouldn't...

Discussion about what Ian wants/meant...

We agree that we need clarification in 16.3.1 to say that underline is
propagated into blocks. But need to check with Ian first.


Resolution: In 16.3.1 "Underlining, overlining, striking, and
blinking: the 'text-decoration' property", first paragraph, change ",
otherwise, the decorations are propagated to the anonymous inline box
that wraps all the inline contents of the element" to "; for all other
elements, the decorations are propagated to an anonymous inline box
that wraps all the in-flow inline children of the element, and to any
block level in-flow descendants.". Remove "Nor is it propagated to
block-level descendants of inline elements."

Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 256. http://www.w3.org/mid/3FA8A89F.50002@escape.com
| From http://lists.w3.org/Archives/Public/www-style/2003Apr/0202.html :
| > It's not clear how this would be handled:
| >
| >   span {letter-spacing: 2px}
| >
| >   word<span>spaced out</span> word2
| >
| > Is spacing be applied before the 's' or after the 't'?
| > If the text broke across two lines, would letter-spacing be applied
| > at the start of the second line? The end of the first?
| >
| > Also, you should specify whether letter spacing applies to spaces or not.
| > (I think it should for the reasons outlined in
| >    http://bugzilla.mozilla.org/show_bug.cgi?id=1046#c21 )
| ...
|
| Where is word-spacing applied? At every space character? At zero-width-spaces?
|
| From http://lists.w3.org/Archives/Public/www-style/2002Aug/0332.html
| > If I wrote
| >   <pre>two  spaces</pre>
| > how would word-spacing and letter-spacing affect the gap between
| > 'two' and 'spaces'?

Resolution: use Tantek's proposals from
http://lists.w3.org/Archives/Member/w3c-css-wg/2004JanMar/0060.html
(namely, no change)
Issue closed.
------------------------------------------------------------------------
Issue 257. From agenda.
Apply 'border-spacing' to frame sets?

http://lists.w3.org/Archives/Member/w3c-css-wg/2003JanMar/0414.html
http://lists.w3.org/Archives/Member/w3c-css-wg/2003AprJun/0005.html
http://lists.w3.org/Archives/Member/w3c-css-wg/2003AprJun/0008.html

A suggestion from Tantek. And a counter-suggestion from Jim.


TC: Seems not dangerous to say that border-spacing may be used by
implementers, even if we don't have a full model for frame layout.
DB: But is it border-spacing or border-width? They can have a color
(BORDERCOLOR)
TC: But that can be the background of the frame.
BB: Not so happy specifying an aspect of the rendering, if we don't
know the full model for rendering frames yet. But no strong opinion.
DB: Even if informative, people will still complain if a part of an
official spec is not implemented.

Resolution: add informative text, as per Tantek's proposal:
http://lists.w3.org/Archives/Member/w3c-css-wg/2004JanMar/0061.html
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 258. From agenda.
Error recovery for invalid style sheets

If a file doesn't conform to the forward-compatible grammar, it is not
CSS, but should there be rules for how to recover at least parts of
the file in an interoperable way?

258:
TC: Could be good to specify for CSS3, maybe something like XML does:
stop at error
BB: Afraid that it assumes a particular type of parser, if the rules
are too precise.
Resolution: say nothing in 2.1 (no change to spec), but consider for
CSS3.
Issue closed.
------------------------------------------------------------------------
Issue 259. http://www.w3.org/mid/3FAA5B65.8050802@oracle.com
|
| The media group table states
|
|    handheld  ---> visual, audio, speech (media groups)
|
| I am not sure why "speech" was added to the handheld media.
| Is this for multimodal? Even then I think that is incorrect.
| speech interface on a multimodal devices is still media type "speech"
|
| So on a handheld device that support speech, the following would
| result in voice-volume: x-soft
|
| @media speech {
|     voice-volume: x-soft
| }
|
| @handheld {
|    voice-volume: silent
| }
|

TC: I think confusion is over 'speech' being both media type and media
group.
Resolution: no change
Issue closed.
------------------------------------------------------------------------
Issue 260.
Properties padding, margin, we say applies to all elements, should
exclude certain inner table parts.

DB: margin: Applies to: all elements except elements with table display
types other than table and inline-table
padding: Applies to: all elements except elements with table display
types other than table, inline-table, and table-cell

Resolution: put this in property database
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 261.
Section 10.6.7 "'Auto' heights for block formatting context roots"
Change "i.e., floats inside absolutely positioned descendants" to
"e.g., floats inside absolutely positioned descendants or other
floats" in the last paragraph.

Resolution: change as proposed
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 262. http://www.w3.org/mid/BB6E8DC0-11D6-11D8-8AC1-000A958E6110@apple.com
outlines. Detailed proposal included.
Ian agrees with the proposal.

TC/DB: Interesting proposal, but too late for 2.1. Add to CSS3 UI
instead.
TC: should call it 'auto' instead of 'outlinecolor'

Resolution: no change to CSS 2.1
Issue closed.
------------------------------------------------------------------------
Issue 263. http://www.w3.org/mid/7AF9450E-21FA-11D8-B12D-000502CB1B77@stickdog.com

How should CSS processors react to the presence of a noncharacter code
in a style sheet?
How do CSS processors react to the presence of a noncharacter code in a
style sheet?
How should CSS processors react to a reference to a noncharacter code
in a style sheet?
How do CSS processors react to a reference to a noncharacter code in a
style sheet?

By "noncharacter" I mean codes like unpaired surrogates or U+FFFF.

See also issue 265.

Resolution: Per resolution to issue 258, leave this undefined in
CSS2.1 (don't even bother saying anything), and specify it in CSS3
Syntax.
Issue closed.
------------------------------------------------------------------------
Issue 264.
The spec contradicts itself over whether IDs can start with digits or
not. In particular, prose in 4.1.3 and the grammar in section 4 and
appendix G.

tantek proposes: http://www.w3.org/mid/BC32D85B.346F3%25tantek@cs.stanford.edu
dbaron disagrees: http://www.w3.org/mid/20040120212517.GA6242@darby.dbaron.org
Bjoern Hoehrmann says: http://www.w3.org/mid/4047c522.347257379@smtp.bjoern.hoehrmann.de

Resolution:

First, in 4.1.3 "Characters and case", just after "they cannot start
with a digit.", add: "Only properties, values, units, pseudo-classes,
pseudo-elements, and at-rules may start with a hyphen (-); other
identifiers (e.g. element names, classes, or IDs) may not."

Second, change 5.9 "ID selectors" from "A CSS ID selector contains a
"#" immediately followed by the ID value." to "A CSS ID selector
contains a "#" immediately followed by the ID value, which must be an
identifier."

Third, change the following sentence in Appendix G:

   A conforming UA must also adhere to the forward-compatible parsing
   rules, the property and value notation, and the unit notation.

...to this:

   A conforming UA must also adhere to the forward-compatible parsing
   rules, the selectors notation, the property and value notation, and
   the unit notation.

Documented updated.
Issue closed.
------------------------------------------------------------------------
Issue 265. null bytes and \0 - \000000 should be parsing errors.
   http://www.w3.org/mid/200401161857.42942.bert@w3.org

What kind of parsing errors, exactly? Same as an unexpected character,
rendering the current token invalid and causing the declaration or
rule to be ignored?

tantek:

Proposed resolution:

Add a sentence to Appendix G prohibiting null bytes and \0 - \000000.  The
presence of any such character makes the style sheet invalid.

Per the resolution to issue 258, leave it undefined/unspecified what
implementations should do with such a style sheet, and specify it in CSS3
Syntax.

[Agreement with Bert via IRC]

Resolution: In third bullet point of 4.1.3 "Characters and case",
replace "character with that number" with "character with that number,
which must not be zero".
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 266. "13.3.3 Allowed page breaks" says "When a page break occurs
here, the computed values of the relevant 'margin-top' and
'margin-bottom' properties are set to '0'." but it should say "used
values" not "computed. (editorial)

Resolution: Agreed.
Document updated.
Issue closed.
========================================================================


Proposed Issues

These are not CSS2.1 issues, they are issues pending WG approval.
Unless the WG actively agrees to address these, they aren't issues.
========================================================================
Issue 267. http://bugzilla.mozilla.org/show_bug.cgi?id=225811#c14

CSS2.1 says "A descendent box is positioned absolutely, partly outside
the box. Such boxes are not clipped by the overflow property on their
ancestors." (section 11.1) but also says " It affects the clipping of
all of the element's content except any descendant elements (and their
respective content and descendants) whose containing block is the
viewport or an ancestor of the element." (section 11.1.1)

I believe the first quote above should have the second sentence
changed to "Such boxes are not always clipped by the overflow property
on their ancestors." (addition of "always"), leaving the later section
to define it properly.

Resolution: Agreed.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 268. http://www.w3.org/mid/410-2200312014154837156@mindspring.com
Section 17.5, Visual layout of table contents: Typos at the end of the
XHTML example's 2nd and 3rd lines (invalid markup).

Resolution: Editorial agreed.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue P3. http://www.w3.org/mid/3FF6FF3C.3050004@mit.edu
There is a number of places in the spec where terms are used without
linking to the term definition.  For example the "Applies To" part of
hte "max-width" property says "all elements except non-replaced inline
elements and table elements".  None of this is linkified; the user is
left to guess what "table elements" are in this context.  These are
actually defined at http://www.w3.org/TR/CSS21/tables.html#internal but
that's not made clear anywhere in the spec apart from the Index.  I've
seen at least one WG member be confused as to the meaning of "table
element" in the CSS2.1 spec as a result....

It would be good to make both "table elements" and "non-replaced inline
elements" links in that text and in all similar texts in the spec.

Rejected.
Editors can fix if they see it.
Issue closed.
------------------------------------------------------------------------
Issue P4. fantasai has been quite vocal against our saying
'background-attachment: scroll' should't scroll when used with
'overflow: scroll'.
e.g.:
   http://www.w3.org/mid/3FF8C0E6.5050107@escape.com
...and related posts.

Rejected.
Issue closed.
------------------------------------------------------------------------
Issue 271. http://www.w3.org/mid/40155B52.8040806@gmx.de

Can 'empty-cells' affect the width of an empty cell? e.g. if it has
borders when shown, are those borders taken into account when empty?

The spec is a little vague on this.

Testcase: http://people.freenet.de/bernd_mozilla/empty_w3c.html

Resolution: Spec is clear enough. No effect on layout.
Issue closed.
------------------------------------------------------------------------
Issue 272. 5.8.2 Default attribute values in DTDs
[[-XMLNAMESPACE]] is not a defined biblio entry.
Resolution: Editor to fix.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 273. 5.11.3 The dynamic pseudo-classes: :hover, :active,
and :focus
| CSS 2.1 doesn't define if the parent of an element that is ':active'
| or ':hover is also in that state.
Missing quote after "':hover".
Resolution: Editor to fix.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 274. Fallout from computed/used issue in 4.3.2 Lengths

| Child elements do not inherit the relative values specified for
| their parent; they (generally) inherit the computed values.

Strike "(generally)".

| In cases where the computed length cannot be supported, user agents
| must approximate it in the actual value.

Change "computed" to "used" and linkify.

Resolution: Accepted.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 275. Add to definition of "source document" so that it also
covers "XML instance" and "SGML instance".
Resolution: agreed.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 276. 10.3.5 Floating, non-replaced elements
# Thirdly, find the available width: in this case, this is the width
# of the containing block minus 'margin-left' and 'margin-right'.

That should be "minus the used values of 'margin-left',
'border-left-width', 'padding-left', 'padding-right',
'border-right-width', 'margin-right', and the widths of any relevant
scroll bars".

Resolution: agreed.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 277. 10.4 Minimum and maximum widths: 'min-width' and 'max-width'

If you have a 300x375 image, with 'height' and 'width' both set to
'auto', and:

   min-width: 75
   max-width: 150
   min-height: 0
   max-height: 75

...the current rules in section 10.4 end up saying that the dimensions
should be 150x75, which is much more skewed than it should be. The
better answer would be 75x75.

dbaron says:
|
| I propose the following two changes be made to both sections 10.3.2
| and 10.6.2, no matter what we decide for section 10.4, to clarify things
| that I noticed I had to implement that were defined poorly or not at
| all:
|
|   1. In sections 10.3.2 (PROP=width, OTHER=height) and 10.6.2
|      (PROP=height, OTHER=width), change the text:
|
|        If 'PROP' has a computed value of 'auto' and 'OTHER' also has a
|        computed value of 'auto', the element's intrinsic PROP is the
|        used value of 'PROP'.
|
|      to:
|
|        If 'PROP' has a computed value of 'auto' and 'OTHER' also has a
|        computed value of 'auto', the used value of 'PROP' is determined
|        by the <a href="the rules in section 10.4">as described in the
|        section on min-width</a>.
|
|   2. To the end of sections 10.3.2 and 10.6.2, add:
|
|      Note: The used OTHER is influenced by the computed values of
|      'min-OTHER' and 'max-OTHER'.
|
| Proposal (1) resolves a contradiction between 10.3.2/10.6.2 and 10.4
| (where we clearly want 10.4 to win), and proposal (2) clarifies the case
| where one is 'auto' and the other is not.

fantasai proposed the following table to replace the current list in
section 10.4:
   http://fantasai.inkedblade.net/style/specs/css2.1/min-max-replaced

dbaron implemented this and it passed the relevant tests.

Document updated.
Issue closed.
------------------------------------------------------------------------
Issue P12 [278]. What happens when the first line of text in that cell
is fully occupied/displaced by a very wide float?
   http://lists.w3.org/Archives/Member/w3c-css-wg/2004JanMar/thread.html#84
Issue rejected.
Issue closed.
------------------------------------------------------------------------
Issue P13 [279]. Re: UTF-8 signature / BOM in CSS
Comments from i18n on the latest changes in issues 44/45/115:
http://www.w3.org/mid/008301c3f0cb$1d305540$6501a8c0@w3cishida
Issue rejected.
Issue closed.
------------------------------------------------------------------------
Issue 280. Internal WG comments about BOMs and @charsets.
Comment: http://www.w3.org/mid/16427.57406.693616.482856@lanalana.inria.fr
Comment: http://www.w3.org/mid/402df57e.81368982@smtp.bjoern.hoehrmann.de
Comment: http://www.w3.org/mid/Pine.LNX.4.58.0402161625580.2210@dhalsim.dreamhost.com

Resolution: Swap "The @charset at-rule" and "BOM" lines and inform
www-style.
Document updated.
Reply: http://lists.w3.org/Archives/Public/www-style/2004Feb/0335.html
Response: http://www.w3.org/mid/4032A9C9.8050309@mit.edu
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402172357590.2286@dhalsim.dreamhost.com
Issue closed.
------------------------------------------------------------------------
Issue P15 [281]. the 'reader' media type
Issue rejected.
Issue closed.
------------------------------------------------------------------------
Issue 282. need to update text at top of section 6.1.
It reads:

| The final value of a property is the result of a three-step
| calculation: the value is determined through specification (the
| "specified value"), then resolved into an absolute value if
| necessary (the "computed value"), and finally transformed according
| to the limitations of the local environment (the "actual value").

It should read:

| The final value of a property is the result of a four-step
| calculation: the value is determined through specification (the
| "specified value"), then resolved into a value that is used for
| inheritance (the computed value), then converted into an absolute
| value if necessary (the "used value"), and finally transformed
| according to the limitations of the local environment (the "actual
| value").

Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 283. http://www.w3.org/mid/200402162226.i1GMQ0n01266@djwhome.demon.co.uk
C.2.18 says that aural style sheets have been moved to an
informative appendix.  I interpreted this to mean that they
had been deferred pending interoperable implementations,
so didn't look at Appendix A in detail.

However, A.1 says:
 1) that they are deprecated, which is much stronger than
    simply being deferred;
 2) says they are *defined* by the appendix, which seems very
    normative to me (this is an internal conflict in Appendix
    A as well as between Appendix A and Appendix C.

Resolution: Change appendix C to say appendix A is deprecated.
Issue closed.
------------------------------------------------------------------------
Issue P18 [284]. http://www.w3.org/mid/16428.57705.189337.320274@lanalana.inria.fr

We decided that Fantasai was right and the example in 9.8.3, showing
'clear' on an inline element, was wrong. But we didn't remove the
example:

    Resolution: The example is indeed inaccurate, but we're going to
    leave it for now.

I'm not too happy with that. Can't we remove 9.8, or add some text to
it, that says the example is wrong?

Issue rejected.
Issue closed.
========================================================================

This concludes the current list of outstanding comments.