csswg-drafts/css2/issues/issues-1 at c30ee4832e8b782553ffcaf8bdd88470f4e41571 · w3c/csswg-drafts

4750 lines (4224 loc) · 213 KB
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
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
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
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 no
A3CA
t 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,
  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
Addendum: http://www.w3.org/mid/200309282215.h8SMFaHS029555@nerd-xing.mit.edu
|   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:
|    Some text
|    more text
|    </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?
| @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"
|   "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
  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
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>
|    </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.
  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
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>:
View remainder of file in raw view
Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FilesExpand file tree

issues-1

Latest commit

History

issues-1

File metadata and controls
