W3C home > Mailing lists > Public > www-style@w3.org > November 2008

[CSSWG] Summary and Resolutions F2F: Selectors and calc()

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 10 Nov 2008 11:04:38 -0800
Message-ID: <491885C6.6030205@inkedblade.net>
To: www-style@w3.org

Selectors
---------

   * Investigated behavior of attribute selectors with empty string. No
     resolutions to change the spec any further.

   * Briefly discussed dbaron's [:value] notation.

   * RESOLVED: Add note saying that if it's possible for ':hover' to
               apply to an element because its child is designated by
               a pointing device, then it's possible for ':hover' to
               apply to an element that is not underneath the pointing
               device.
     RATIONALE: The spec leaves undefined whether the ':hover' state
                is passed up the DOM tree. Browsers all treat it that
                way and websites would break if that were changed. We're
                adding this note to clarify to readers that it ':hover'
                can match an element even if it not hovered over if its
                child is positioned outside its geometric bounds.

   * Also discussed behavior of ':active', but made no resolutions about it.

   * RESOLVED: Accepted to add an+b grammar in ISSUE-66 to the spec
                 http://www.w3.org/Style/CSS/Tracker/issues/66

   * Discussed ::selection and its cascading, inheritance, and box model.
     Lots of complications were presented: this is not a simple problem.

   * RESOLVED: Add to the spec wrt ::first-line:
       The portion of a child element that occurs on the first
       line inherits properties applicable to the ::first-line pseudo
       element; for properties not applicable to the ::first-line pseudo
       element, the inheritence is from the non-pseudo-element parent of
       the ::first-line pseudo element. The portion of a child element
       that does not occur on the first line always inherits from the
       parent of that child.

Parsing calc()
--------------

   * RESOLVED: Spaces are required around arithmetic operators in calc().
               Spaces are not required around parentheses (due to the
               parentheses: they may be required outside parentheses due
               to adjacent arithmetic operators).
     RATIONALE: The contents of calc() cannot be tokenized without spaces
                around the minus sign, so to be consistent and avoid
                confusion we resolved to require spaces around all arithmetic
                operators.
Received on Monday, 10 November 2008 19:05:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:16 GMT