[CSSWG] Minutes Telecon 2013-05-15

   - RESOLVED: publish LC of css3-fonts (next Thursday)
   - RESOLVED: split Exclusions and Shapes into separate modules
   - Republication of Multicol deferred until more issues can be resolved.
   - RESOLVED: publish new WD of CSS Filters
   - RESOLVED: @counter-style width descriptor renamed to pad (counter styles)
   - RESOLVED: decoration color is reflected in text-shadow
   - Discussed dbaron's issues wrt text-decoration positioning
   - RESOLVED: calc() can be used inside media queries
   - Discussed return value of getComputedStyle() for grid layout properties
   - Discussed an+b syntax redefinition in css3-syntax

====== Full minutes ======

   Glenn Adams
   Rossen Atanassov
   Shezan Baig (Bloomberg)
   David Baron
   Tantek Çelik
   John Daggett
   Justin Erenkrantz (Bloomberg)
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Koji Ishii
   Dael Jackson
   John Jansen
   Brad Kemper
   Peter Linss
   Anton Prowse
   Matt Rakow
   Dirk Schulze
   Alan Stearns
   Leif Arne Storset
   Nick Van den Bleeken

<RRSAgent> logging to http://www.w3.org/2013/05/15-css-irc
Scribe: sgalineau

CSS3 Fonts

   Topic: css3-fonts publication
   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013AprJun/0161.html
   jdaggett: I'd like to move to LC. I think we can resolve the italics
             issue at the f2f
   jdaggett: I'd rather discuss LC issues at the f2f a few weeks from now
   jdaggett: I responded to text-decoration issues; I am not sure whether
             Elika wants to resolve this first
   fantasai: I am ok to go to LC based on John Hudson's response
   fantasai: I think there is an interaction we need to resolve; LC is fine
             if the italics issue is noted
   jdaggett: it is noted
   fantasai: Would suggest waiting until next week to publish; still have
             to finish review comments, would be good to incorporate such
             minor fixes before publishing LC.
   RESOLVED: publish LC of css3-fonts (next Thursday)
   <stearns> +1 from me

Exclusions and Shapes

   Topic: Splitting Exclusions and Shapes
   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013AprJun/0171.html
   astearns: we discussed this a number of times in the past. they are
             separate features with separate use-cases; they should advance
             more quickly if they are not tied to each other
   Rossen: +1
   glazou: +1
   fantasai: no objection
   glenn: does this involve new editors?
   astearns: no change expected at the moment
   RESOLVED: split Exclusions and Shapes in separate modules
   astearns: I will come back next week and ask for WD publications for both

CSS Regions WD

   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013AprJun/0177.html
   astearns: this is just a WD update; the current one is 9 months old
   glazou: I support this; there have been quite a few changes
   bradk: I did not like the move from @region to a pseudo-element
   bradk: I think this is a big change
   rossen: I would like another week to review this
   astearns: ok, let's do this next week.
   dbaron: would prefer 2 weeks
   glazou: action on everyone to review Syntax two weeks from now
   * fantasai notes that Gecko Layout team has a work week next week

<glazou> http://lists.w3.org/Archives/Public/www-style/2013May/0232.html


   <glazou> http://www.w3.org/mid/20876.36468.730367.345119@gargle.gargle.HOWL
   glazou: should we go back to LC given the latest changes?
   fantasai: it would be good to review these changes in detail, specifically
             the painting order update; someone posted that it was wrong.
   rossen: I also have a couple of updates; one is the drawing order of
           rules resolved in Tucson
   rossen: also multicolumn columns creating their own BFC, which we
           discussed last week
   rossen: so going back to LC seems reasonable
   antonp: I think other issues need addressing; I support LC as well
   fantasai: we should try resolving these before publishing LC

CSS Filters WD

   krit: I added feedback to the security section indicating there is
         pending work; I would like to publish a new WD
   glazou: do not forget to add a change section to your documents
   RESOLVED: publish new WD of CSS Filters

Counter Styles

   fantasai: there was a discussion to rename the width descriptor to 'pad'
   fantasai: this is the only issue raised thus far; we would like to
             resolve this and move to LC
   <stearns> http://lists.w3.org/Archives/Public/www-style/2013May/0037.html
   <fantasai> http://dev.w3.org/csswg/css-counter-styles/#counter-style-width
   jdaggett: can we hold this one more week for additional review?
   fantasai: ok
   glazou: objections to the proposed renaming?
   RESOLVED: width descriptor renamed to pad (counter styles)

Text Decoration

   fantasai: some of these might be better dealt with face-to-face
   <fantasai> http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013#issue-15
   fantasai: we discussed this one last week and did not resolve it
   fantasai: I have no opinion
   glazou: what do browsers do?
   fantasai: they do not interop
   glazou: I do not have an opinion
   dbaron: I have a slight preference for repeating the color of the
           decoration in the shadow
   RESOLVED: decoration color is reflected in text-shadow

   jdaggett: I think we can defer the super/subscript discussion to next
             week or the f2f.
   jdaggett: I have no opinion on the other issues on the agenda

   <fantasai> http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013#issue-11
   fantasai: issue 11 is about whether line position should be per-line
             or across lines
   <fantasai> http://www.w3.org/TR/CSS21/text.html#lining-striking-props
   <fantasai> "In determining the position of and thickness of text decoration
               lines, user agents may consider the font sizes of and dominant
               baselines of descendants, but must use the same baseline and
               thickness on each line."
   fantasai: what does it mean 'on each line'? does it mean that the position
             is the same for all lines, or does one evaluate the position
             for each line individually?
   fantasai: I think the original intent was to deal with cases where the
             same line included subscript, superscript, large text etc and
             we wanted to avoid ransom-style underlining
   dbaron: I think the intent was also to avoid position and thickness to
           change between lines
   fantasai: if you want a constant position across lines, you ignore all
             descendants; or you consider them and account for them
   fantasai: if you do the latter then for each decorating box you need to
            layout all your lines to figure out the consistent position/
            thickness which could be a perf concern
   fantasai: if there is a perf concern we could scope the averaging to
             each linebox
   fantasai: or we ignore descendants
   fantasai: but without considering the descendants strikethrough may break
   jdaggett, dbaron: varying underline/decorations between lines does not
                     sound like a good idea for authors
   dbaron: I think considering descendants is a bad idea. it's not compatible
           with what browsers do today.
   dbaron: we should leave it as it is
   rossen: I am in favor of keeping this as it is
   fantasai: keeping the spec as it is?
   rossen, dbaron: keep the runtime behavior and update the spec
   fantasai: browsers do different things though
   fantasai: I have a test case where Opera appears to consider descendants...
   <fantasai> <p style="text-decoration: underline;"><big style="font-size: 64px">BIG TEXT</big> text <small style="font-size: 
4px">small text</small>
   <Rossen> http://jsfiddle.net/4sC2T/
   <glazou> or data:text/html,<p style="text-decoration: underline;"><big style="font-size: 64px">BIG TEXT</big> text <small 
style="font-size: 4px">small text</small>

   <fantasai> http://www.w3.org/mid/CAKA+Axm4o1r_LN0Q7v_XM8WQsMNEsdsES2r6K1Lp6rzH=vHC9A@mail.gmail.com
   fantasai: link above is the issue Aryeh raised
   fantasai: …about strikethrough. we discussed this before,
   fantasai: and resolved on the text describing averaging

   rossen: our underline behavior follows Word's closely
   fantasai: does this mean you have multiple decoration positions across line?
   rossen: there is averaging in more recent versions

   glazou: should we defer to f2f?
   fantasai: yes
   fantasai: most of the other issues relate to this so let's move on

   <Rossen> use case to consider for the underline issue above


   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Apr/0538.html
   fantasai: also better to push more flexbox issues to f2f; nothing easy


   <glazou> https://www.w3.org/Style/CSS/Tracker/issues/327
   glazou: where is calc() allowed?
   glazou: in particular, whether it can be used in a MQ?
   glenn: wouldn't be easier to define where it can't be used?
   fantasai: we should think about all the places where it can be used and
             consider examples
   glazou: who will do this review? when?
   fantasai: we can talk about media queries now
   dbaron: media queries can't take percentages for width so this limits
           its value
   dbaron: but I do not object allowing calc with different units
   glazou: are there use-cases for this? do authors ask for it?
   fantasai: yes I think some people asked for it
   glazou: I never needed it when I used MQ; I can't think of a use-case...
   <stearns>  @media screen and (min-width: calc(20em + 6px))
   <stearns> from http://lists.w3.org/Archives/Public/www-style/2007Nov/0227.html
   glazou: objection to allow calc?
   RESOLVED: calc() can be used inside media queries

Grid layout

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Aug/0309.html
   fantasai: we have prose about grid properties getComputedStyle; some of
             them return the used value
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Aug/0309.html
   fantasai: so do we want to allow getComputedStyle() to return these used
             values, or should it return the computed value?
   dbaron: isn't there work around CSSOM in this area? we should look at
           how this interacts
   fantasai: how does that change our decision?
   glenn: the CSSOM uses the term resolved values for getComputedStyle();
          in some cases you will get used value, in others computed value
          e.g. left, top, bottom return used values
   dbaron: I'm fine with the proposed resolution of returning computed values
   <glenn> https://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html#resolved-values
   <glenn> e.g., getComputedStyle().lineHeight always returns used value
   fantasai: essentially getComputedStyle() returns used value in some
             cases for legacy reasons; the issue is whether new grid
             properties could require used value or should be consistent
             and return computed values for all of them
   * fantasai has no opinion on these things, and hopes someone else figures
              out this issue

   rossen: how does this work for tooling? This is the reason we returned
           used values.
   rossen: currently some MSFT tools use this, for instance
   dbaron: I think we need to understand what your general strategy should
           be, especially in light of new APIs. But I agree we do not have
           a clear resolution for this specific issue
   glazou: so this remains an open issue
   <glenn> one resolution is to define resolved value line for each property
   <sgalineau> glenn, yes but what should it be in this case?
   <glenn> sgalineau: no opinion in this specific case

an+b grammar

   fantasai: we should not be making changes from the grammar of selectors3
   glazou: I think the current discussion is extending the set of allowed
   fantasai: right, I want to know why it can't be the same as in 3?
   glazou: everyone should review this item for next week
   glazou: we need to discuss this before it goes in a WD

glazou: anything else?
glazou: please add things we deferred for the f2f to the wiki

Meeting closed.

Received on Thursday, 16 May 2013 00:42:54 UTC