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

[CSSWG] Minutes Telecon 2013-03-27

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 27 Mar 2013 18:15:30 -0700
Message-ID: <515399B2.1000008@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - New ED of CSS3 Overflow, needs review for WD publication next week
       http://lists.w3.org/Archives/Public/www-style/2013Mar/0600.html
   - RESOLVED: Publish grid layout WD
   - Recently-posted issues against CSS3 Text Decoration; need to file
     and address in DoC:
       http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013
   - RESOLVED: We copy the behaviour of % margins/paddings from grid to
               flexbox: they are relative to their respective dimension,
               not always the inline dimension (as in block layout)
   - Discussed problem of always loading style sheets even when qualifying
     MQ does not match:
       http://lists.w3.org/Archives/Public/www-style/2013Jan/0434.html
       http://lists.w3.org/Archives/Public/www-style/2013Jan/0522.html
   - RESOLVED: Wrt propagating events up through regions parent chain
               (rather than DOM parent chain), propose solution based
               on using a property to switch behaviors.
   - Discussed offsetParent and region parenting
   - RESOLVED: publish new CR for css3-values with above edits
   - Checked in on :matches() naming discussion
   - Discussed 72-hour resolution-by-email proposal.

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

Present:

   Glenn Adams
   Rossen Atanassov
   David Baron
   Bert Bos
   Jim Dovey
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Rebecca Hauck
   Israel Hilerio (Microsoft)
   Dael Jackson
   John Jansen
   Brad Kemper
   Chris Lilley
   Peter Linss
   Alexis Menard
   Anton Prowse
   Florian Rivoal
   Simon Sapin
   Dirk Schulze
   Alan Stearns
   Nick Van den Bleeken
   Lea Verou
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2013/03/27-css-irc
Regrets: hober, molly, TabAtkins, SimonPieters, plh
Scribe: AntonP

No extra items for agenda.

CSS3 Overflow
-------------

   <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Mar/0600.html
   glazou: Request from dbaron to publish FPWD of css3-overflow
   dbaron: I added Section 2
   dbaron: Would be great if others could read that
   florian: I like the draft but have issues with overflow-x/y and so I'd
            like to review that section to flag possible problems
   ?: has there been any implementation activity on this?
   Alan: Where does this sit in the group's priority list, charter etc?
   florian: I wonder how much interest in Opera there is
   glazou: Old charter expires in Sept, and this isn't currently charter
   glazou: We occasionally enforce the deliverables in the charter
   dbaron: This is mostly moving things from other docs into this one
   dbaron: which is not generally a charter problem
   ChrisL: That's correct
   dbaron: The new thing [fragment overflow?] is new but is an alternative
           to something that already exists in another doc
   glazou: Are you OK with a week for the WG to review?
   dbaron: yes
   glazou: What is the priority of this spec, to you?
   dbaron: I've heard implementers say that they are interested
   florian: I'd like this to make progress, though I'm not implementing
            anything
   <stearns> whether overflow:fragments is an alternative is debatable -
             I consider it an addition

   Rossen: Is this targetting various layout models, not just block?
   Rossen: A lot of text is copied from css21 but it should be generalized
   dbaron: It applies to block and flex containers.  It's intentional that
           it doesn't apply to eg inline
   Rossen: Grid is a valid target spec
   fantasai: "Grid containers" are defined in the grid spec right now
   dbaron: OK

   florian: You specified overflow-x/y but don't carry over the definition
            of overflow-style - yet there is overlap.  Although I don't
            like overflow-style we should avoid overlap.
   dbaron: overflow-style is pretty much dead as far as I can tell
   florian: overflow-paged?
   dbaron: yes
   florian: <something about Opera>. Probably nobody
   Bert: overflow-style came from Marquee spec
   ChrisL: sounds fairly dead
   <sgalineau> iirc IE10 uses overflow-style to trigger auto-hide scrollbars
   Bert: We introduced it to allow various different ways of overflowing,
         not just Opera's but things like marquees and thumbnails
   glazou: I don't think this discussion is relevant to the current topic
   florian: (It's a good discussion)
   florian: we should have it at some point.
   <fantasai> I think fragments should not be an overflow-style, but paged
              vs. scroll should be
   glazou: 1 week for WG to review, then decision next week?
   dbaron: OK
   ACTION on everyone: review doc

Grid Layout
-----------

   (followup from last week)
   glazou: Rossen wanted a week to review the doc
   Rossen: We're OK overall with going forward with a publishing a new WD
   Rossen: I have feedback, but can use mailing list for that
   Rossen: No blockers for now
   glazou: Any objections to advancing the doc?
   RESOLVED: Publish grid layout spec

CSS3 Text Decoration
--------------------

   Topic: issue 6 for css3 text decoration
   dbaron: I have a better URL for Issue 6 other than the one in the
           Disposition of Comments from yesterday
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Mar/0529.html
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Mar/index.html#msg534
   dbaron: I also sent a bunch of other messages <see second URL>
   dbaron: I don't quite know how to proceed, given the other issues
   dbaron: I'd rather discuss on the mailing list; I haven't seen responses
           to them.  Don't know if fantasai agrees
   fantasai: I haven't seen all of these yet
   glazou: OK, let's move on

Flexbox
-------

   Topic: vertical % margins and padding on flexbox
   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0143.html
   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/thread.html#msg143
   dbaron: Not necessarily /from/ me, but I wanted to poke the issue
   dbaron: People are shipping implementations of flexbox and this is a
           change proposal.
   dbaron: I'm curious about the status

   fantasai: When you have margins on a block element, the vert margins
             (block direction margins), they resolve against the size of
             the container in the inline dimension
   fantasai: Flexbox doesn't say anything about this being different for
             flex items, whereas grid does specify that % margins are
             relative to the same dimension
   fantasai: so there's an inconsistency

   fantasai: For blocks, height of containing block typically isn't defined,
             so % margins relative to that would fall to zero.
   fantasai: Resolving against the containing block width gives better
             behavior in the common cases there.
   fantasai: However for flexbox that reasoning doesn't apply so much
             (nor for grid). These layout models are frequently used
             with a defined height.
   <fantasai describes flexbox behaviour>
   fantasai: Another issue is that the inconsistency in dimensions is
             particularly confusing for Flexbox: e.g. for row flexboxes
             percentage margins would work in the main axis, but for
             column flex boxes they wouldn't.

   glazou: Implementors?
   dbaron: I'm fine with switching, but it seems odd for different display
           types to behave differently.  I'd prefer to do it sooner rather
           than later though.
   Rossen: Matching flexbox behaviour to grid makes sense, will help app
           developers
   Rossen: The inconsistency will be overcome by authors soon enough.
   RESOLVED: We copy the behaviour of % margins/paddings from grid to flexbox

Media Queries
-------------

   Topic: media queries and data transfer
   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Jan/0434.html
   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Jan/0522.html
   dbaron: Henri raised this is an issue initially.  I don't want to solve
           it today, but again I wanted to poke it.
   dbaron: Lack of a CSS solution is pushing other groups to push HTTP
           solutions, which I and others don't think is ideal
   <dbaron explains the issue>

   dbaron: The proposal is a proposal to add something to HTML, to the LINK
           element which links to the stylesheet, saying that the stylesheet
           shouldn't be retrieved [....]
   fantasai: Can't we do that by default, that UI shouldn't fetch stylesheets
             if it thinks it's not used (matched)?
   fantasai: and not loaded into object model unless explicitly requested
   dbaron: Implementations would be unhappy about doing it for print
   fantasai: The browser wouldn't download SSs that it knows it's not going
             to use, e.g. device-width doesn't match. But if it thinks it
             might use the SS then it could load it, at lower priority,
             just not load into the object model until it matched.
   dbaron: device width/height can change when you rotate a mobile device

   dbaron: Original design was to make it harder for authors to mess up
           accidentally
   dbaron: Consider the mail as authoritative about the summary/description
           of the topic
   dbaron: This is probably and HTML group topic; but people here should
           be aware of it.

   florian: Thought/Question: a stylesheet included from within a CSS
            conditional (supports) should also be deferred?

   <fantasai> I'm worried we're going to get "async all the things!" from
              some authors and "what's an async? i don't know that feature,
              so my sites don't use it" from others
   <fantasai> would be best if the default behavior was more optimal
   <fantasai> then add syntax to force loading or not loading if needed
   * Rossen agrees with fantasai

   florian: If we allow 'defer' or whatever on the style element so that
            it applies to inline style, I'd like it to be compatible for
            @import inside @supports
   florian: Can we put suggestions to the HTML group
   dbaron: I'll ask Henri to

   <Bert> (I wonder what this does to phishing and privacy. One reason
          to favor MQ over CC/PP was that MQ can hide the UA's
          characteristics and user preferences.)

CSSOM View
----------

   Topic: CaretPosition.getClientRect() (new API)
   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Feb/thread.html#msg323
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Feb/0323.html
   dbaron: I wanted to seek comments from non-Mozilla people
   dbaron: CaretPosition is interesting; it usually corresponds to a
           collapsed range, but allows to get caret position from inside
           input or text area
   glazou: makes sense
   smfr: Fine for me

   Rossen: I'm still catching up on the topic, sorry
   Rossen: if this isn't urgent I'd like to involve someone else and get
           back to you
   dbaron: That's fine, but I wanted to poke it
   glazou: let's revisit later when we have Rossen's input

Regions and Reparenting Side-effects (pointer-events / offsetParent)
--------------------------------------------------------------------

   Topic: click events and ::hover styling in styleable fragment containers
   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0573.html
   <stearns> http://lists.w3.org/Archives/Public/www-style/2013Mar/0414.html
   stearns: I have a long message on the list, with only one response

   stearns: main issue: DOM tree, visual box tree; click events and :hover
            styling propagate only from DOM tree, which leaves out fragment
            containers
   stearns: would be good to apply these to fragment containers
   stearns: 4 options
              1. Interleave frag container into event propagation somehow
              2. Fork the propagation to have two different propagation chains
              3. (Only works for events)
              4. Have a switch: either use the current DOM tree behaviour
                 or with a switch allow you to move up the visual container
                 hierarchy.

   glazou: I responded, saying I like the 4th solution, especially thinking
           about pointer events
   glazou: solves an old issue about hovering positioned elements too,
           which exists as a note in the selectors spec
   stearns: The solution that I put out would only deal with the frag
            containers, but I suppose it could be extended to this
            situation too
   glazou: It's a similar situation.
   Rossen: Talking about containing block chain, instead of DOM structure,
           glazou?
   glazou: yes
   Rossen: I can see this potentially being extended to cover both
   glazou: yes, there's a possibility to extend it.
   glazou: overall, pointer-events strategy seems good
   BradK: I don't like switch

   dbaron: I'm concerned about CSS properties changing event propagation
   dbaron: Generally CSS doesn't affect DOM behavior
   <stearns refers to example in his mail, about pages>
   <fantasai> I'm sympathetic to dbaron's concern about layering, but
              I'll also note that propagating through the region parenting
              is entirely controlled by CSS

   <sgalineau> dbaron, doesn't pointer-event do that to some extent already?
   <fantasai> not really. It changes the geometry of the target only, atm
   <sgalineau> you can use it to prevent an element from capturing events
   <fantasai> That's equivalent to making its geometry match the empty set
              of points

   stearns: I'm happy to try out option 4, unless there's anyone who prefers
            any of the three previous options
   fantasai: I'm not DOM or events person, but second one also looks like
             it could be OK
   stearns: 2nd one is about duplicate event which goes up the visual hierarchy

   fantasai: concern with 4th one: pointer events changes the geometry with
             respect to pointer clicks, but doesn't change how the events
             are propagated
   fantasai: Do we need a separate property?
   sgalineau: You're changing which way it's routing
   fantasai: It's like making it hidden
   sgalineau: if a different node gets the event, you get a different route
   fantasai: no
   sgalineau: yes
   <fantasai> You're just changing what got hit, not what the routing is
              after the hit
   <sgalineau> disagree; another node behind you gets the event and may
               not be your parent afaik.
   <fantasai> right, but you didn't hit that because it wasn't "visible".
              You didn't change the routing of the event bubble chain,
              you changed its target
   <sgalineau> if a CSS property causes a different element from
               capture/bubbling then we already are doing this

   glazou: there are use cases for web designers
   glazou: we need a solution.
   glazou: Is it OK if stearns starts proposing a solution of some kind,
           e.g. based on 4th option?
   * fantasai thinks that's fine
   stearns: I'll post to list saying we're going with option 4.
            Some of the discussion we've just had should be replicated
            on the list please
   RESOLVED: stearns to post to list with a solution based on option 4
   * BradK wonders if the switch is needed for DOM event propagation,
           but not for writing selectors

   Topic: Changes to offsetParent in styleable fragment containers
   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0573.html
   stearns: Question for named flows and a bit for shadow DOM and its
            insertion points
   stearns: What are the offset attributes for?
   stearns: Are they for getting some relative position to a box on the
            page, or is it meant to provide the offsets to the closest
            visual ancestor which has something to do with the box's position?
   stearns: DOM structure vs Visual box
   stearns: I wanted to poke this issue because I didn't get any response
            on the list

   smfr: Why do authors use the offset attrs?
   smfr: we've talked about adding API allowing point conversion between
         elements
   smfr: if we have that, we don't need offsetTop stuff
   smfr: Maybe we should push for that API
   smfr: We'd have to do something sensible for offsetParent, but doesn't
         matter too much if implementations differ a bit
   stearns: I'm ok with the idea that if it's not interoperable anyway
            then let's not fix it
   * scribe is not sure he captured stearns' opinion correctly
   glenn: suggest discussing with roc and bzbarsky

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

   TOPIC: Reissue css3-values CR?, followup from last week
   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JanMar/0349.html
     Tab and I think it's time to reissue CR on css3-values, since
     we've made a few clarifications. They're listed here:
        http://dev.w3.org/csswg/css3-values/#changes
     Let us know if we missed any; I remember Alan mentioned something
     and I can't remember if it was one of these or something else. :/
   <stearns> I don't remember what my issue might have been

   <SimonSapin> http://www.w3.org/mid/514AD389.8060008@exyr.org
   ACTION fantasai clarify interaction of viewport units and scroll
   <trackbot> Created ACTION-551

   fantasai: Any other issues to be handled before CR?
   dbaron: I wonder if viewport units should say that it counts the
           scrollbars when overflow is scroll, rather than the current
           cumbersome description
   <fantasai> ACTION fantasai Edit in Simon's issue
   <trackbot> Created ACTION-552

   Publishing...
   SimonSapin: I'm fine with resolving with last weeks resolution
   glazou: any objections?
   RESOLVED: publish new CR for css3-values with above edits

   fantasai: I'll prepare it for Tuesday (doing edits today) and I'll inform
             the mailing list
   fantasai: there'll be time to tweak it between now and next week

Selectors 4
-----------

   Topic:  Renaming :matches(), followup from last week
   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0275.html
   fantasai: SimonSapin sent the e-mail that we said someone would send
             last week
   fantasai: Doesn't seem to be a conclusion on the ML.
   glazou: so no resolution right now?
   SimonSapin: feedback: currently does not allow combinators inside matches,
               so matches with only one argument isn't very useful
   fantasai: Selectors 4 is concerned with performance, but we can remove
             that restriction
   fantasai: Tab and I discussed the idea of different levels of selector
             support for this feature.
   fantasai: E.g. batch processors wouldn't have a problem with supporting
             complex selectors in :matches() / :not().
   glazou: let's defer to mailing list

Administrative
--------------

   glazou: 72 hours e-mail: in case of a decision which has to be made
           technically on the mailing list, there's a tag in the summary
           indicating 72 hours for providing objections
   glazou: it's a clean way of making a decision to avoid topics dying off
   fantasai: Pretty good idea, but don't pull it up with no warning
   ChrisL: if it's kicked off by a telecon, then we should be ok
   <general agreement>
   antonp: if we do this, please mention it in the summary of the minutes
           of the telecon so that it's easy to see that it's happened
   <general agreement from various speakers>

Meeting closed.

<fantasai> ok, so publish grid-layout and css3-values...
Received on Thursday, 28 March 2013 01:15:59 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 28 March 2013 01:16:00 UTC