W3C home > Mailing lists > Public > www-style@w3.org > December 2011

[CSSWG] Minutes and Resolutions Telecon 2011-12-14

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 14 Dec 2011 14:59:03 -0800
Message-ID: <4EE92A37.4060603@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:
   - Discussed Bucharest F2F logistics
   - RESOLVED: indicate in CSS3 Text that "full-size-kana may be replaced by a
              generic @text-transform mechanism" as an issue
   - RESOLVED: move other features proposed in fantasai's mail to L4
               http://lists.w3.org/Archives/Public/www-style/2011Nov/0395.html
   - 'appearance' property dropped from CSS3 UI
   - Grammar error in CSS2.1 to be fixed:
        http://www.w3.org/mid/20111206221126.GA13407@pickering.dbaron.org
   - RESOLVED: move ideographic advance unit to Level 4 of css3-values
   - Tab and fantasai to review all functional notation in CSS to evaluate
     extensibility and syntactic consistency and recommend any necessary changes
   - Discussed whether to drop 'pointer-events' or how to keep it without
     destabilizing CSS3 UI
   - Discussed publication of CSS3 Exclusions and Shapes FPWD and the fact
     that certain high-level design concerns were not noted in the draft.
   - RESOLVED: update css3-exclusions spec prose to reflect positioning
               dependency issue reported by dbaron

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

Present:
   Glenn Adams
   Rossen Atanassov
   David Baron
   Kimberly Blessing
   Bert Bos
   Tantek Çelik
   John Daggett
   fantasai Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Vincent Hardy
   Koji Ishii
   John Jansen
   Brad Kemper
   Håkon Wium Lie
   Chris Lilley
   Divya Manian
   Eric Mueller
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Alan Stearns
   Daniel Weck



<RRSAgent> logging to http://www.w3.org/2011/12/14-css-irc
Scribe: sylvaing


F2F Scheduling
--------------

   vhardy: so we need to choose whether we want to book early or make other
           arrangements. an email poll will follow
   vhardy: i.e. do we go ahead with bucharest at those dates or do we change
           the dates and/or the locale
   vhardy: the wiki page has information. we recommend sticking to the plan
           and booking as soon as possible
   glazou: please send the WBS questionnaire asap

appearance property
-------------------

   https://lists.w3.org/Archives/Member/w3c-css-wg/2011OctDec/0312.html
   jdaggett: tantek removed it from the spec so I don't think there is any
             discussion needed
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Nov/0395.html
   'appearance' dropped from CSS3 UI

Moving Text features to L4
--------------------------

   http://lists.w3.org/Archives/Public/www-style/2011Nov/0395.html
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Dec/0022.html
   jdaggett: the text-transform property is L3 but the @text-transform rule
             is moved to L4
   <jdaggett> http://wiki.csswg.org/ideas:at-text-transform
   jdaggett: I think Florian's approach is a better way to go as it generalizes
             the feature
   florian: regarding that proposal, this is not something that meant to be
            ready soon
   florian: but it is intended to demonstrate we can generalize the feature
   jdaggett: I think there are two issues; one mail was about splitting features
             between L3 and L4. But I'd like to agree on a way to resolve the
             underlying issues vs. which subset is resolved in which level
   fantasai: I don't think @text-transform is as mature as many other features
             we want to keep in the spec
   fantasai: @text-transform has all the issues raised against text-replace,
             for instance
   fantasai: so I want to have this in L3. If we want to defer resolving
             full-sized-kana I'm fine with that. but I don't want to hold up
             Level 3 Text on the @text-transform feature
   howcome: I think we'd like to make sure we don't have a fork with EPUB who
            has a dependency on this feature
   florian: how soon do we expect the spec to move forward?
   fantasai: hopefully a couple of months
   sylvaing suggests EPUB dependencies should check for actual use and
            implementation
   howcome: my concern is that if we do not solve this EPUB will define their
            own version of it
   fantasai: I do not think that's a concern. EPUB will not include
             @text-transform in their September spec
   fantasai: I'm not arguing against defining a generic mechanism; only that
             if the feature is not ready at this point it's holding up the
             rest of the spec. i'd rather move it to the next level
   jdaggett: I think we should just explicitly mark this issue in the spec
             for now
   florian: we could also remove it and re-introduce it later if ready
   * sylvaing scribe having trouble with sound quality....
   jdaggett: why don't we use our wiki page wording for the spec to identify
             the issue clearly and move forward
   <jdaggett> i think we should simply add in the @text-transform rule
   <jdaggett> and mark it with an explicit issue
   florian: the concern seems to be about how fast we can achieve consensus
   <jdaggett> the full-size-kana value should be explicitly marked as an
              alternate
   [ ... ]
   <fantasai> Florian proposed marking the issue as "full-size-kana may be
              replaced by a generic @text-transform mechanism"
   <fantasai> I agree with this proposal
   <fantasai> I would like to go with that.
   RESOLVED indicate in CSS3 Text that "full-size-kana may be replaced by a
            generic @text-transform mechanism" as an issue
   RESOLVED move other features proposed in fantasai's mail to L4
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Nov/0448.html
   florian: I am not a fan of line-break. i think it's improved but i still
            don't like it
   jdaggett: should we let fantasai do all the edits and resume the discussion
             from a fresh draft
   general agreement
   <glenn> prefers line-break be defined (not removed)

error in @page grammar
----------------------

   http://www.w3.org/mid/20111206221126.GA13407@pickering.dbaron.org
   dbaron: I think this is just a mistake in the draft
   glazou: I did not understand why the presence of RULESET in the media
           production was an error. For page, maybe, but for media?
   dbaron: you're right.
   glazou: otherwise I agree that RULESET is incorrect here. The grammar
           should be fixed
   ACTION Bert to fix the grammar per dbaron's post
          http://www.w3.org/mid/20111206221126.GA13407@pickering.dbaron.org
   <trackbot> Created ACTION-412

CSS3 Values
-----------

   http://www.w3.org/Style/CSS/Tracker/products/8
   http://lists.w3.org/Archives/Public/www-style/2011Dec/0342.html
   fantasai: the first issue was defining ranges for CSS. This is on arronei
             for next week

   fantasai: the next was about whether we add an ideographic advance unit
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Oct/0888.html
   jdaggett: I think this is very undefined
   jdaggett: it's not clear from the proposal what this means from an
             implementation standpoint
   jdaggett: I think this feature is a candidate to move to L4; and in L4
             I'm concerned about the definition
   jdaggett: specifically the algorithm to use to calculate this metric
   <kojiishi> text-transform: full-size-kana
   <kojiishi> http://www.microsoft.com/typography/otspec/baselinetags.htm#ideoembox
   * sylvaing scribe not hearing koji so this may appear one-sided...
   jdaggett: i don't think this is specified yet
   jdaggett: i think this needs to move to L4 unless we get a better definition
             soon
   RESOLVED: move ideographic advance unit to Level 4 of css3-values

   <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/204
   fantasai: the next issue is about the attr() syntax
   fantasai: we're trying to align the attr() syntax with the model of
             radial-gradient()
   fantasai: the proposal is to drop the comma between the attribute name
             and the type keyword
   dbaron: we do have other functions that use commas as well such as counter()
   howcome: we do use the comma in multiple places and I don't see a full
            proposal on how this will be replaced consistently
   glazou: I would also expect attr() to be extended in the future
   fantasai: right, so Tab and I thought about ways to extend attr() and
             concluded this is the right way to go
   fantasai: We could, for example, allow checking multiple attributes. But
             because the fallback value could contain commas, we can't do
             that by adding more comma-separated arguments. You'd have to
             nest attr() instead.
   <howcome> a::after { content: "(see page " target-counter(attr(href, url), page, decimal) ")" }
   <tpod> Commas or spaces? This is not about clip right? ;)
   ACTION fantasai and Tab to look at functional notation extensibility in general
   <trackbot> Created ACTION-413

   howcome: regarding css3-values, it no longer specified fr but Grid still
            uses it
   fantasai: we suggest Grid should define fr
   fantasai: once it's clear the unit needs sharing across specs then we can
             pull it into Values & Units L4

pointer-events and css3-ui
--------------------------

   <tantek> note: I've made what I think are the last necessary edits to
            publish a second LCWD of CSS3-UI, including postponing
            'pointer-events' to CSS4-UI because it has had the most issues
            of any feature for this draft, and because it requires documenting
            the previously undocumented hit-testing model. Per the desire to
            move more mature features more quickly, it didn't make sense to
            hold up the rest of CSS3-UI for 'pointer-events', so it got bumped
           to CSS4-UI.
   <tantek> (cont'd) I'd intended to check in these edits before the telcon,
            but didn't quite make it.
   <tantek> (cont'd) And I wanted to give a heads up here in the channel
            before I sent email to www-style stating that in my opinion CSS3-UI
            is ready for another LCWD and I'm asking the WG to resolve on this
            matter and publish it as such before year-end.
   <tantek> editor's draft is up to date: http://dev.w3.org/csswg/css3-ui/
   <dbaron> tantek, I think 'pointer-events' is one of the more important things in the draft

   [Tantek can't be heard clearly, so fantasai translates]
   fantasai: tantek noticed that pointer-events raises a lot of issues and
             proposed moving it to css4-ui
   dbaron: I think this is one of the most important issues in css3-ui so
           I'd like to look at the issues list first
   dbaron: I think we can define some things without defining everything
   ACTION dbaron to review css3-ui pointer-events issues list
   <trackbot> Created ACTION-414
   <tpod> Problem is hit testing not prev defined

Publication of Exclusions and Shapes WD
---------------------------------------

   discussion of dbaron's objection to the FPWD publication sans certain notes
   howcome: issues reported at the f2f are missing from the draft
   rossen: we agreed to add all the issues to the spec. we did that. we also
           agreed to use bugzilla to track all of the issues
   rossen: as to the format of the actual issues, if you want an inline verbatim
   dbaron: I think we explicitly discussed describing the issue in the spec.
           this ended up as a link to a bug number. I also cannot find the
           issue I'm looking for. specifically building exclusions on top of
           the positioning model instead of floats
   vhardy: clearly dbaron and howcome have a problem and we should update
           bugzilla to account for their issues. I'd like an agreement on how
           we track issues though as it helps me as an editor
   vhardy: I'd rather not maintain issues in two places (in the spec and in bugzilla)
   vhardy: maybe we can tool this
   vhardy: but I'd like to have an agreement
   vhardy: and that agreement should not be specific to just these two specs
   <dbaron> I don't think we need to turn everything into a general problem:
            the issue here was that a bunch of people wanted one particular
            issue to be noted in the prose of the spec so that readers were
            all aware of it.
   <sylvaing> dbaron, was that resolved in minutes?
   <dbaron> sylvaing, I thought it was
   <dbaron> sylvaing, though the minutes weren't as clear as they should have been
   <sylvaing> right. i recall the discussion.
   sylvaing: In general you can follow the guidelines and track issues
             elsewhere, but occasionally there's a major issue that people
             want to be noted directly in the spec. This is one of those
             occasions.
   RESOLVED: update spec prose to reflect positioning dependency issue
             reported by dbaron
   fantasai: I suggest dbaron take an action item to propose the exact wording
             of this issue. I note that the minutes from the F2F do not reflect
             this.
   ACTION dbaron to propose the prose he wants to see in Exclusions
   <trackbot> Created ACTION-415
Received on Wednesday, 14 December 2011 23:02:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:47 GMT