[CSSWG] Minutes and Resolutions 2009-10-28

Summary:

   - RESOLVED: ex definition to be changed to use the parent's element font
               size if set on font-size (just like em)
   - RESOLVED: preserve CSS2.1 0.5em fallback in CSS3 Values
   - No objections to Selectors API 2 introducing a new pseudo-class for its
     scoping element.

   - display: run-in clarifications <http://lists.w3.org/Archives/Public/www-style/2009Sep/0126.html>
     and drop-shadow proposal added to TPAC agenda

   - As of 2003 the CSSValue interface is deprecated+obsolete
       <http://lists.w3.org/Archives/Public/www-style/2003Oct/0347.html>
     and other specs should not rely on it. In response to
       <http://lists.w3.org/Archives/Public/www-style/2009Oct/0011.html>
     CSSWG will update the DOM-L3-Style spec to include this note inline.

   - Discussed TPAC agenda, schedules, and presenting at Thursday's Developer Gathering
       http://wiki.csswg.org/planning/tpac-2009
       http://www.w3.org/2009/11/TPAC/DevMeeting

====== Full minutes below ======

Present:

   Tab Atkins
   David Baron
   Bert Bos
   John Daggett
   Elika Etemad
   Simon Fraser (Apple)
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Peter Linss
   Anne van Kesteren
   Steve Zilles

<smfr> i'm Simon Fraser for those who don't know
<RRSAgent> logging to http://www.w3.org/2009/10/28-CSS-irc
Scribe: sylvaing

ex and font-size
----------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Oct/0294.html
   dbaron: I think it's a spec bug we should fix since it results in a
           circular reference
   dbaron: doing the same for ex as we do for em is the right thing to do
           as this is the implemented behavior
   RESOLVED: ex definition to be changed to use the parent's element font
             size of set on font-size
   <glazou> Webkit , FF, Microsoft already implement that
   <TabAtkins> It looks like IE does the same thing as everyone else.
   <TabAtkins> For the ex issue.
   ACTION howcome update CSS3 Values to fix ex definition

   <bradk> "Should we say that ex is 0.5em if no better value exists?"
   glazou: what does no better value mean ?
   bradk: not sure, part of the issue as raised
   Bert: this is part of a note in CSS3 Values
   dbaron: the x-height is typically part of font metrics
   Bert: 2.1 currently allows to use 1/2 em if there is no other way to
         define the x-height
   <oyvind> http://www.w3.org/TR/CSS21/fonts.html#font-size-props says ex
            refers to parent, by the way, but the Values section in 2.1 doesn't
   szilles: I thought this was discussed in the past and this was added as
            result to ensure fonts without x-height are supported e.g. CJK
   RESOLVED: preserve CSS2.1 0.5em fallback in CSS3 Values
   ACTION howcome preserve CSS2.1 0.5em fallback in CSS3 Values

Scoped selectors in Selectors API 2
-----------------------------------

   http://lists.w3.org/Archives/Public/www-style/2009Sep/0251.html
   glazou: I'm extremely reluctant to add support for this feature
   glazou: almost nobody uses :root; it could be used here to scope the query
   fantasai: but a :root element cannot have a parent
   <TabAtkins> Something like "div :scope p".
   fantasai: I don't think creating a pseudo-class for this proposal is
             a bad idea
   glazou: I'd prefer a new pseudo than the first example in the proposal
   TabAtkins: authors are already comfortable with this pattern from jQuery,
              however
   * Bert thinks ':here' but really has no opinion.
   glazou: new pseudo ?
   TabAtkins: no objection to that
   dbaron: new pseudo is ok
   fantasai: I prefer :scope to :reference
   ACTION glazou Respond to Lachlan with WG new pseudo recommendation

+annevk

display:run-in clarifications
-----------------------------

   <sylvaing> http://lists.w3.org/Archives/Public/www-style/2009Sep/0126.html
   Bert: the first issue is when can an element run in and become a block;
         my proposal was to accept proposal #1 in my summary
   fantasai: does it address fixed/absolute positioning ?
   Bert: absolute positioning includes position:absolute and position:fixed
         so the definition covers both
   szilles brings up an inline table case to run through Bert's definition
   glazou: is this a list of issues we could discuss at TPAC
   Tab: Yes
   Many others nod
   ACTION Bert add display:run-in discussion to TPAC wiki agenda

drop-shadow proposal
--------------------

   bradk: the general idea is to take children and their transparency into
          account when casting drop shadows
   bradk: and also to define which layer cast shadows
   * fantasai thinks we should discuss at TPAC
   TabAtkins: in general the idea of being able to apply these effects to
              specific parts of an element but would like to be able to use
              it more generally
   TabAtkins: also, some aspects such as transparency and inset shadows are
              hard to understand
   dbaron: I think this requires thinking wrt its interaction with ordering
   dbaron: also if you have selectivity, you need to figure out whether you
           have one shadow, multiple shadows and what their z-order are
   dbaron: also, whether/when the feature results in a stacking context
   sylvaing: agrees with fantasai that this is TPAC material

CSSValue interface
------------------

   http://lists.w3.org/Archives/Public/www-style/2009Oct/0011.html
   Sylvain: Everyone implements these interfaces, but the CSSWG has said that
            they are obsolete
   Sylvain: The will be replaced in CSSOM, but that doesn't exist yet.
   Sylvain: a number of specs (SVG, CSS3 2D Transforms) depend on DOM L2 Style
            interfaces such as CSSValue but the WG stated those to be obsolete
            years ago
   Sylvain: What am I supposed to do?
   dbaron: I've considered removing our support for it
   dbaron: but part of our chrome uses it
   dbaron: Still I'd really like to remove our support for it
   Sylvain: CSSOM is not ready/available to replace
   annevk: based on how disliked the interface is, it doesn't seem the
           right way forward
   annevk: Opera did not implement parts of SVG that depend on these
           interfaces. will do the same for transforms
   annevk: if it depends on CSSValue, we did not implement support for it
   <dbaron> We also didn't implement the part of transforms that depends on this
   Sylvain: My problem is that anyone who looks at the specs has no idea that
            there's an issue there
   Sylvain: you have to go back 6 years in the mailing list
   Sylvain: At least we should make it clear somewhere that this stuff is
            at risk or shouldn't be touched
   dbaron: we should mark it as an issue in those specs
   annevk: I think someone raised an issue against Transforms. SVGWG is
           aware of the issue and plans to address it
   glazou: What can we do?
   annevk: we could re-publish L2 Style
   annevk: and mention which parts are obsolete, referencing the email
   <dbaron> I think we should put a red "NOTE: ..." inside css3-2d-transforms,
            etc., where they use the stuff that's obsolete
   fantasai: that sounds like a good solution to me. can we do it ?
   glazou: if we consider this as an errata, could we republish fast ?
   glazou: note that this is a REC
   Bert: then it's not going to be a quick process
   <annevk> it is about: http://www.w3.org/TR/DOM-Level-2-Style/
   Bert: what we could do is publish a note or even a working draft.
         but changing a REC requires review
   szilles: but then unless you see the note, you still don't know
   <annevk> I suppose we could publish http://dev.w3.org/csswg/cssom/
   sylvaing: I'd rather see it in the spec, however long it takes, than in
             some place authors and implementers alike may miss
   glazou: what about tests ?
   szilles: it's already a REC
   glazou shifts uncomfortably enough that everyone can hear it
   ACTION glazou Gather all interfaces that need to be obsoleted in DOM L2 Style
+arronei
   (REC update process discussion)
   * myakura sees no tests for DOM2 Style: http://www.w3.org/DOM/Test/
   glazou: I'll email the hypertext coordination group
   <szilles> The process for changes due to errata is described by
   <szilles> http://www.w3.org/2005/10/Process-20051014/process.html#errata
   * annevk has to go; glad I could make it for the DOM Level 2 Style discussion
   * annevk see you guys Sunday most likely :)

TPAC
----

   glazou: next item is TPAC
   <glazou> http://wiki.csswg.org/planning/tpac-2009?s[]=tpac
   glazou: please add agenda items if you have any
   Steve will miss tuesday morning
   Steve has no interest in selectors or dom discussions
   <sylvaing> I'd love to talk about transitions and 2d transforms issues
              brought up on the list but will we have Apple participation ?
   <dbaron> sylvaing, I'd be interested as well (not sure what the transforms
            issues are, though)
   steve: Not sure I have much to add to modularization and profiles,
          although I care about it
   glazou: Will people from Apple attend?
   sfraser: Yes. And we will be able to discuss transitions and transforms

   glazou: please send a message to wg saying when you arrive and where you will stay
   <Bert> (Some people's arrival/departure info is already on http://www.w3.org/Style/Group/2009/Santa-Clara.html )

   fantasai asks about presenting at the Developer Gathering on Thursday
   <smfr> fantasai: i could do a demo
   <dbaron> I'm happy to demo too :-)
   fantasai: Anyone from Microsoft?
   Sylvain volunteers to be present, but nothing to demo
   <glazou> sylvaing: don't be cynical with IE :-)

The End

Received on Friday, 30 October 2009 19:21:32 UTC