W3C home > Mailing lists > Public > www-style@w3.org > September 2013

[CSSWG] Minutes Paris F2F 2013-09-13 Fri I: CSS Masking, Display Tree or DOM, Flexbox

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 30 Sep 2013 19:55:23 -0400
Message-ID: <CADhPm3sVKok9zDd-7S3E6bmJpJDMaf0H_2B1YBsYG7VB4D3rgw@mail.gmail.com>
To: www-style@w3.org
CSS Masking - Review Request
----------------------------

  - RESOLVED: The WG will review Masking LC transition on 10/9 telcon

Any interest in working out selection/editing based on display tree rather
than DOM?
-----------------------------------------------------------------------

  - Though some interest was expressed, it was deemed currently not
      enough to proceed to an ED

Flexbox
-------

  - RESOLVED: Use 2-pass algorithm to resolve % height children of flex
              stretched items pending dholbert's feedback.
  - RESOLVED: Proposed issue-1 edits are approved.

 ======FULL MINUTES BELOW==========

Present:
   Glenn Adams (Cox)
   Rossen Atanassov (Microsoft)
   Tab Atkins (Google)
   Mihai Balan (Adobe)
   David Baron (Mozilla)
   Bert Bos (W3C)
   Tantek Çelik (Mozilla)
   John Daggett (Mozilla, via phone+IRC)
   fantasai (Mozilla)
   Sylvain Galineau (Adobe)
   Daniel Glazman (Disruptive Innovations)
   Israel Hilerio (Microsoft)
   Koji Ishii (Rakuten)
   Kawabata (NTT)
   Ian Kirkpatrick (Google)
   Håkon Lie (Opera)
   Peter Linss (HP)
   Ted O'Connor (Apple)
   Simon Pieters (Opera)
   Rivoal, Florian (Invited Expert)
   Simon Sapin (Mozilla)
   Dirk Schultze (Adobe)
   Alan Stearns (Adobe)
   Shane Stevens (Google)
   Leif Arne Storset (Opera)
   Jet Villegas (Mozilla)
   Yamamoto (NTT)
   Steve Zilles (Adobe)

[agenda/schedule wrangling]
http://wiki.csswg.org/planning/paris-2013#agenda

  * krit plinss: glazou In case we have 5min. Can I ask the WG for a
         review of CSS Masking? I incorporated the feedback of the CSS
         WG from yesterday and don't have any issues on the spec
         anymore.
  * krit plinss glazou I would like to get to LC after a review time of
         2-3 weeks (probably the later because of the other two specs
         need reviews)
  <glazou> krit, ok
  <glazou> that's just a review request right ? 5mins ?
  <krit> yes, nothing more
  <glazou> cool, np

CSS Masking - Review Request
----------------------------
  Scribe: sgalineau

  <krit> http://dev.w3.org/fxtf/masking/
  krit: I incorporated yesterday's feedback in the spec
  krit: We will only support one layer of masking.
  krit: Also, I updated the initial values we discussed.
  krit: I have no issues in the spec at the moment and would like to ask
        for review.

  krit: Child selector for the mask image would be at-risk.

  glazou: How much time do you need for review?
  krit: 3 weeks?
  glazou: Ok, so 2nd telcon from now
  fantasai: I'd prefer 4 weeks
  <dbaron> so that's October 9

  RESOLVED: The WG will review Masking LC transition on 10/9 telcon

Any interest in working out selection/editing based on display tree rather
than DOM?
-----------------------------------------------------------------------

  astearns: Selection/editing only works on the DOM tree
  astearns: When certain positioning modes/layouts get used, selection
            start looking funny
  astearns: How much interest is there in making selection/editing work
            on table columns, or select what is inside an absolute
            position and what is next to it vs selecting DOM ranges?

  glazou: The problem is selecting visually contiguous areas regardless
           of whether there are floats or whatever.
  astearns: Yes. You start selecting inside a float and drag outside, a
            lot of stuff comes in.
  michou: This gets fun with flex box and grids as well, especially when
          the content has been reordered.

  fantasai: My understanding was that the DOM APIs for selection allowed
            for discontinuous ranges and it was up to the UAs to do the
            right thing.
  astearns: Is this WG interested in coming up with an intelligent way
            to deal with this?

  glazou: I think there are two questions
  glazou: 1) Is the problem interesting? Yes.
  glazou: 2) Is it a CSS problem? I'm not sure it belongs to this WG
  glazou: This seems more a description of visual selection behavior in
          the UA
  astearns: Right. As michou pointed out this is left to UAs.

  fantasai: What is the interop we're looking for?
  glazou: I've gotten blue griffon bug reports due to surprises related
          to caret management.
  glazou: WYSIWYG editors behave one way, browser-based editing
          surprises users.

  krit: It's not only selection, it's also accessibility, isn't it?
  fantasai: This can be intentional though.
  glazou: I'm really interested in the topic but I do not think this is
          a CSSWG work item.

  plinss: Maybe we need APIs that produce ranges based on a geometry.
  astearns: The Region spec has APIs to get DOM ranges for a named flow
             so we're kind of going in that direction.

  glazou: Would you like to move this to a new ED?
  astearns: Not at this time; there doesn't seem to be enough interest
            in this area at the moment

Flexbox
-------

  http://dev.w3.org/csswg/css-flexbox/issues-cr-2012#issue-3
  tabatkins: A handful of clarifications and tweaks to the layout
             algorithm are needed.
  <projector> http://dev.w3.org/csswg/css-flexbox/#issue-dd911971
  tabatkins: There is a request to make percentages work well even if
             the flex item is auto height.
  tabatkins: If a flex item is stretched, the fixed container is a fixed
             height and a child of the flex item uses % the % is
             resolved against the stretched height of the flex item.

  dbaron: Is this horizontal only?
  fantasai: Apparently IE already implements this; if there is a flex
            row container and it's auto height, and an item inside it
            has a % height child.

  tabatkins: We used to not resolve this. We'll do layout as if it was
             auto and then resolve those percentage children
  dbaron: What is it that the height applies to?
  dbaron: Then I have to relayout
  tabatkins: You relayout the flex item but not the flexbox
  dbaron: Small incremental updates may require another pass

  [tabatkins draws a picture]

  dbaron: Does the flex box have a fixed height?
  tabatkins: No.
  tabatkins: This works well if the item in question is not the tallest.
  tabatkins: It's not ideal when the flex item in question is the
             tallest but it's still better.
  dbaron: It sounds a bit like table row sizing
  dbaron: In tables, % sizing of table cell children appears to be
          random...
  tabatkins: In this case, it's not hard to depend on.
  tabatkins: If you have a fixed height, it just works. Otherwise, it
             does its best attempt and it's workable in most cases.

  dbaron: I'd guess I'd be OK. What does dholbert and other implementors
          think?
  rossen: We're OK with it.
  rossen: I thought we had agreed to this at TPAC
  [short exchange ending with tabatkins: oh yeah, I'm making stuff up]

  RESOLVED: Use 2-pass algorithm to resolve % height children of flex
            stretched items pending dholbert's feedback.

  tabatkins: Issue-3 is the proposed text for issue-2
  tabatkins: Next is issue-1 about respecting the intrinsic aspect ratio
             of flex items.
  tabatkins: You don't want to abandon this ratio unless absolutely
             necessary.
  tabatkins: We never resolved the proposed edits.
  tabatkins: During the initial sizing, if it is stretched and auto in
             both dimensions, and the container has a definite
             cross-size and is single line; then we go ahead and
             pre-stretch the item and use its ratio to figure what is
             its main size
  [tabatkins clarifies the steps for dbaron]

  tabatkins: I don't recall any objections; IE already does something
             close to this.

  RESOLVED: Proposed issue-1 edits are approved.

  tabatkins: that's it for now; one issue left we need to discuss later.
  fantasai: and then we'll make diffs and move to LC

  * zcorpan_ Unrelated question: are css variables scoped to the
             stylesheet they're declared in?
  * fantasai no, they're effectively properties
  * fantasai that cascade and inherit just like regular properties, and
             are therefore scoped to a particular element
  * zcorpan_ fantasai: you mean the scope is all stylesheets that apply
             to a particular document?
  * fantasai Yes, the scope is all stylesheets that apply to a
             particular document, but it's also scoped by element.
  * zcorpan_ Ok.
Received on Monday, 30 September 2013 23:55:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 30 September 2013 23:55:51 UTC