W3C home > Mailing lists > Public > www-style@w3.org > April 2015

[CSSWG] Minutes Telecon 2015-04-29

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 30 Apr 2015 09:07:44 -0400
Message-ID: <CADhPm3vodAs3xAZrT4Of1s6GX6GfkaYdjLY-teYTN4iw=G8jmw@mail.gmail.com>
To: www-style@w3.org
Paris Houdini F2F
-----------------

  - Rossen confirmed that the Houdini task force would be meeting 28
      and 29 August after the CSS F2F hosted by Mozilla.
  - If anyone is planning on attending, please add their information
      to the wiki: https://wiki.css-houdini.org/planning/paris-2015

Rounded Displays and Flexbox
----------------------------

  - Most of the group was supportive of an exploration of the
      relationship between flexbox and rounded displays.
  - It was agreed that this didn't belong in level 1 of flexbox, but
      should instead exist as an exploratory section of the rounded
      displays spec and/or a wiki and mailing list thread with the
      conclusions potentially being integrated into flexbox 2.

@media not
----------

  - RESOLVED: In media queries, use 3-valued logic with maybe semantics
              to handle unsupported syntax, i.e. false and unknown =
              false. (Re-evaluate if this ends up with back-compat
              problems.)

AnimationEnd events and display: none
-------------------------------------

  - RESOLVED: No animation events when subtrees are destroyed.
  - RESOLVED: Start a next level of transitions with dbaron as an
              editor.

/deep/ combinator
-----------------

  - RESOLVED: Drop /deep/ from dynamic profile and record an issue
              about keeping it in the static profile.

Splitting up the Containment Value
----------------------------------

  - RESOLVED: Do layout containment, split containment into three
              pieces as per TabAtkins' proposal
              (https://lists.w3.org/Archives/Public/www-style/2015Apr/0364.html)
              and have overflow: clip

CSS 3 UI
--------

  - It was agreed that the coordinate systems need to be better
      defined, but that the definition belongs in CSS Image.
  - The CSS Image authors will do more research and create edits to
      the spec and CSS 3 UI will reference CSS Image.

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

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Bo Campbell
  Adenilson Cavalcanti
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Peter Linss
  Michael Miller
  Edward O'Connor
  Anton Prowse
  Florian Rivoal
  Andrey Rybka
  Simon Sapin
  Hyojin Song
  Alan Stearns
  Steve Zilles

Regrets:
  Sanja Bonic
  Brad Kemper
  Greg Whitworth

  scribe: dael

  plinss: Let's get started
  plinss: Anything to add?
  Rossen: I have one.
  Rossen: Just an update about the Houdini meeting in August.

  plinss: Anybody else?
  bcampbell: I am going to NY as long as we can talk about some of
             the things we spoke about earlier with flexbox. I'd
             like to know who to speak to about the agenda for the
             NYC and if we can set aside some time for the a11y and
             flexbox.
  plinss: Generally for a F2F there's the wiki and you can feel free
          to edit that and add topics and we schedule exact times at
          the first day of the meeting.

Paris Houdini F2F
-----------------

  Rossen: Mozilla has agreed to host us and the meeting will take
          place Fri and Sat following CSS with ends on Thursday. I
          don't have a calendar but I believe that's Aug 27 and 28.
          So please, there is a wiki set up so if you haven't please
          sign up. That's about it.
  <dbaron> It's August 28-29.
  <dbaron> https://wiki.css-houdini.org/planning/paris-2015
  Rossen: Any questions?

  plinss: First two items on the agenda were resolved.

Rounded Displays and Flexbox
----------------------------

  <dbaron> https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0064.html
  TabAtkins: I'm mildly opposed to doing new rounded display stuff.
             I want to wait for everything else to catch up and
             exist. Especially for expansions to flexbox which would
             be complicated.
  Rossen: Why would you assume these would be in the current flexbox
          draft?
  TabAtkins: They don't have to obviously but then we're working
             further into the future than we'd like.
  Rossen: That's kinda preventing or slowing the work of rounded in
          favor of existing flex or grid, I don't feel I'm okay with
          that. I think it's worthwhile to keep in mind rounded
          displays as we make progress and close on flex and grid
          with the mind where we're not preventing anything for
          rounded completely.
  Rossen: However, I don't want to delay these specs for rounded.

  glazou: This is a surprise to me. We didn't let hyojin go first so
          he can explain why this is a good match. I'd like to hear
          hyojin.
  * glazou notes that another major vendor announced rounded
           displays this week : samsung...
  * Florian saw that too. Happy that LG is leading the
            standardisation
  hyojin: I'm pleased to meet you. I see the flexbox spec, I think
          it is related to round display. I'm wondering is it right
          to progress on finding round display now.
  hyojin: I don't know about the progress of flexbox.
  fantasai: I think exploring how flexbox and rounded work together
            in better ways is worth exploring. We can't do that in
            current flexbox, but the rounded display module can have
            an exploratory section for flexbox and in that case when
            things become more settled we can put it into flexbox
            level 2. It's good to explore these things and to see if
            these settings you're prop solve the problems.
  fantasai: If we get to a point where we're ready to add to flexbox
            we can start a level 2
  hyojin: If it's reasonable to progress, I can describe properties
          or technology. I can prepare those things. I don't want to
          delay flexbox spec progress.

  Florian: I don't know if we can directly reuse the flexbox
           properties, but at least reusing the concepts certainly
           sounds useful. Polar coordinates as proposed in css-round-
           display suffer from the same kind of problems as abspos
           in terms of collision. Having flexbox-like abilities to
           decide which elements should stay fixed size, and which
           should grow or shrink depending on available space sounds
           useful. I don't know exactly how that would work, but it
           certainly is worth exploring.

  <tantek> was going to say the same thing about polar coordinates
           and flexing. Thanks Florian :)
  <TabAtkins> In general, I'm mildly opposed to new display modes in
              general ("round flexbox" is effectively something new
              compared to "flexbox"), as I think we should just
              focus on custom layout, and *then* only develop new
              layout modes that are proven to be popular in practice.

  tantek: [expresses a desire to see use cases or diagrams about the
          desired effects of the combination of rounded display and
          flexbox]
  <fantasai> tantek++
  <tantek> would be nice to see a separate draft that documents
           diagrams and use-cases of the desired design effects
  <tantek> and that can better inform our discussions

  Scribe: TabAtkins

  hyojin: I agree that Flexbox level 2 is a good place to start
          thinking about rounded display.
  Florian: I agree with tantek that seeing diagrams or use-cases
           would be good. I'm not sure it should be a draft yet; a
           mailing list or wiki would be more appropriate.  But
           regardless, having some examples would be very
           interesting.
  plinss: Agreed.
  hyojin: Okay.
  <tantek> (and yes - format draft/wiki/email is up to author)

@media not
----------

  Florian: On the call it seemed like a good idea to have 3-valued
           logic to deal with unknown media features or general-
           enclosed.
  Florian: On the ML, though, we realized there are two different
           types of 3-valued logics we can use - a "maybe" or a
           "bottom".
  Florian: "maybe" makes more sense, but has a greater chance of
           breaking backwards compat.
  Florian: Tab also proposed a 4-valued logic with both values, but
           it's probably too complex.
  TabAtkins: I agree that it's too complex.
  * fantasai is confused, but will be satisfied if dbaron thinks the
             proposal is sane
  Florian: I'd prefer to go with "maybe"; it's nicer, and I think
           the compat risk, while it exists, is moderate.
  Florian: But if browsers disagree, then we should use "bottom".
  Florian: The difference between "maybe" and "bottom" is that if
           you have "(false-thing) and (maybe-thing)", it's false.
           If you have "(false-thing) and (bottom-thing)", it's
           bottom.
  Florian: False and unknown being unknown is safer for backwards
           compat. but false and unknown being false is a nicer
           system to work with.
  TabAtkins: Yes, because it preserves De Morgan's laws.

  Scribe: dael

  fantasai: False and unknown = unknown is bottom. Other is maybe.
            Maybe makes sense to me.
  Florian: But maybe semantics are less backwards compat.
  TabAtkins: The ones that were problems, in MQ 3 semantics it
             became not all. In the new semantics the prefix would
             be a 'maybe' or 'bottom', then a not screen and when
             screen is false when printing you have the same problem
             with a big 'not' negating everything.
  <fantasai> The example was "not screen and (-webkit-foo)"
  <fantasai> Which would evaluate to true when printing
  <fantasai> But is currently thrown out by non-webkit browsers
  TabAtkins: When false and bottom equals bottom it stays false when
             exiting which matches MQ3 semantics. It looks to be
             very very rare. In order to get it you have to have a
             MQ starting with 'not' and a prefix thing ending with
             it. It happened twice in the database we looked at.

  TabAtkins: Unless somebody feels bad with this I'd like to go with
             'maybe' and allow, if necessary, to change to bottom
             later. I think the compat risk is small enough we don't
             have to worry.
  fantasai: That makes sense to me, I'd like dbaron's take on it.
  TabAtkins: Okay.
  <dbaron> I don't really have an opinion (right now, anyway)

  plinss: Objections?

  RESOLVED: In media queries, use boolean maybe semantics to handle
            unsupported syntax, i.e. false and unknown = false. (Re-
            evaluate if this ends up with back-compat problems.)

AnimationEnd events and display: none
-------------------------------------

  TabAtkins: If you have a running animation and a display: none it
             stops, but does it throw an end? Currently browsers
             don't. Later if we add animation cancel events that
             will change the subtree. Right now no events get fired
             when an animation stops due to a display: none
  smfr: I agree with that.
  <andrey-bloomberg> no issues
  dbaron: I agree as well, though I have a follow up.

  RESOLVED: No animation events when subtrees are destroyed.

  dbaron: Are people okay with starting the next level of
          transitions and animations where we add in cancel events?
  <dbaron> transitionstart, transitioncancel, animationcancel
  <dbaron> (and as a delta spec)
  plinss: Any objections?
  <astearns> +1 to new diff draft
  Rossen: Go ahead
  <glazou> +1 to what dbaron said

  RESOLVED: Start a next level of transitions with dbaron as an
            editor

/deep/ combinator
-----------------

  TabAtkins: In the recent shadowDOM meeting there was discussion on
             simplifying. One of the conclusions was the ability for
             CSS to easily reach into shadows like this is probably
             bad. They resolved to remove that combinator. The other
             option is removing from dynamic profile. A few people
             preferred that. So either removing it or just having it
             in the static profile.
  TabAtkins: I'm not sure if we need to resolve, it might be better
             to let webapps decide, but we need to be aware.
  plinss: That's why I added it to the agenda, to have discussion.
  TabAtkins: Related there are simplifications to shadowDOM to make
             it a bit easier.
  plinss: Other thoughts or opinions on shadow combinators?
  <glazou> +1
  hober: It was a strong consensus to drop /deep/ I'd rather that
         than keep in static.
  plinss: I tend to agree. There was discussion in TAG and the
          opinion is people want a better module to describe the
          style instead of reaching into the DOM. It might be
          dangerous to keep this.
  TabAtkins: The reason people argued for it is there's nothing
             preventing you from walking the DOM manually. The point
             it to make that unnecessary. It doesn't expose worse
             information, it just makes it possible to do from the
             query selector. We can discuss that with webapps.

  fantasai: So no resolution on that?
  TabAtkins: I'm not seeking a resolution.
  plinss: Did you want one fantasai?
  fantasai: If we have consensus I think we should resolve
  Florian: I think we have it on dropping from the dynamic profile.
  fantasai: So maybe mark it as an issue.

  RESOLVED: Drop /deep/ from dynamic profile and record an issue
            about keeping it in the static profile

Splitting up the Containment Value
----------------------------------

  <Florian> http://dev.w3.org/csswg/css-containment/
  <plinss> https://lists.w3.org/Archives/Public/www-style/2015Apr/0364.html
  TabAtkins: At the extensible web summit we had a nice session
             about the containment value. It came out that the issue
             in the spec where we should maybe split is something we
             should address. What I proposed is to split it into the
             3 things it does.
  TabAtkins: Layout containment, the element doesn't pay attention
             to children in terms of layout so nothing can cause
             extra layout. Paint containment so you have a clipping
             boundary. Style containment which is a couple of styles
             that can influence the rest of the document can no
             longer do that. The effects of things in the style
             element can't effect the rest of the doc like counter
             increments.
  TabAtkins: These are the three general areas that the proposal
             addressed. I split this to three keywords, layout,
             paint, and style and keep the strict keyword to turn on
             all three of them. If you need to be flexible in some
             ways you can just turn on what you're okay with.

  Florian: First you say split everything in the sec, but the spec
           currently doesn't have layout containment right now and I
           really want that.
  TabAtkins: That was an oversight on my part. It'll be there.

  Florian: For paint containment, it does three things. Do the same
           as overflow: hidden, don't allow scrolling, establish a
           containing block for abspos and fixedpos
  TabAtkins: It doesn't do anything with scrolling.
  Florian: If you define the way you have you can get clip overflow
           without the ability to scroll with containment: paint and
           overflow: visible, and clip overflow with the ability to
           scroll using containment:paint and overflow: auto. What
           you don't get the ability to do is containment: paint
           and overflow: visible, but still be able to use properties
           like overflow-text and resize, which depend on overflow
           not being visible. I would suggest add to overflow:
           something, perhaps clipped, that does the same as hidden
           but with no scrolling.
  Florian: So that first if you use containment: paint and overflow
           is visible it will do clip but will allow you to resize
           and other related properties. It also allows you to do
           this without establishing a new containing block for
           abspos and fixedpos, which you couldn't do if you only
           had containment: paint.
  TabAtkins: This all makes sense. I am okay with this. So add an
             overflow: clipped and have overflow: visible if it's
             doing paint compute to overflow: clip as well.
  * fantasai suspects Mozilla has a clip value already

  smfr: Is containment supposed to effect other properties?
  TabAtkins: It has some effects, but not the computed values.
  smfr: In other cases we say it doesn't effect computed values. I'm
        worried about properties that override other properties and
        creating circularity.
  TabAtkins: This is why we track computed values on the wiki to see
             if we introduce a circularity. So far we haven't.

  <andrey-bloomberg> just my 2 cents - this is quite useful from
                     developer perspective

  SimonSapin: When we split things between style and layout in
              paint, is it something that's related to the feature,
              or just the current impl do things in a way?
  TabAtkins: Layout and paint are completely different things.
             That's not impl specific. They are usefully independent.
             We can come up with use cases that want one or the
             other. Style containment, I don't think it has an
             independent life, but having it separate works better
             for the overall design.
  Florian: I have a hard time thinking of containment style without
           layout, but I'm okay with it separate.
  SimonSapin: It's not the same as containment, but we think of
              layout transition being different than paint. That's
              impl specific though because when you animate the top
              property it requires layout, but some times you can do
              it in the thread.
  TabAtkins: The general definition of layout vs paint is somewhat
             impl specific, but in the case of contain they're
             different.
  Florian: And in the containment case, the definition isn't
           ambiguous.
  ??: Correct.

  Florian: To answer a comment from fantasai earlier, she says that
           she thinks Mozilla has this, and she's correct. They have
           this.
  <Florian> -moz-hidden-unscrollable

  dbaron: When I saw the split property I thought style was
          referring to selectors so I'm not sure the name gives a
          good sense of what it's containing. I wouldn't want
          something to refer to selectors.
  TabAtkins: Agreed.
  dbaron: I don't have a better idea on name.
  TabAtkins: I can put in style isn't an ideal name and we can
             bikeshed on the mailing list.

  plinss: Do we want a resolution on overflow: clip?
  Florian: I think we can resolve to do layout containment, split
           into three values, and have overflow: clip
  plinss: So objections to those proposed resolutions?

  Rossen: Can you repeat?
  Florian: One is to make sure the containment spec does layout
           containment. Next is split the values of containment as
           described by TabAtkins. Last is to have effects of
           containment: paint go through overflow: clip
  Rossen: Question: in overflow: clip in the case where clipping
          element isn't the containing block, will the effects also
          clip?
  Florian: Overflow: clip visually does the same as overflow hidden,
           but you don't get access to scrolling.
  Rossen: In hidden your fixed element is still a fixed element and
          effects layout of the root element because there may be
          scrollbars.
  Florian: Overflow: clip alone doesn't change that, but if you do
           containment: paint it switches.
  TabAtkins: One of the main reasons is to invoke the machinery that
             relies on overflow being non-visible.
  Florian: When you do containment paint you want overflow: clip and
           the containing block.
  Rossen: And a stacking context. So this is kind of the god
          property.
  Florian: So overflow: clip does the same as hidden minus the
           scrolling and the rest of what you need for paint goes
           through the containment: paint property.
  Rossen: Sounds reasonable.
  <dbaron> That sounds pretty different from overflow:
           -moz-hidden-unscrollable, which is otherwise like visible
           except it clips overflow
  <fantasai> it should be equivalent to overflow: visible, except
             you don't draw outside the box
  <Florian> dbaron: overflow:clipped is the same as overflow:
            -moz-hidden-unscrollable as far as I can tell. But
            containment:paint invokes this PLUS the rest (containing
            blocks, stacking context)
  <dbaron> Florian, I think they're different w.r.t. establishing a
           new BFC.
  <Florian> dbaron, That's not documented on MDN.

  smfr: It needs some wording for if you try and scroll and if you
        transition to clip do you snap to the top.
  TabAtkins: I don't know if anything in visible says you can't
             scroll, but that's what it does. If it doesn't we'll
             make up language and you can reset to your scroll
             position. It'll be immediate.
  fantasai: It'll be exactly like visible but you don't draw outside
            the box.
  plinss: objections?
  <andrey-bloomberg> all for it
  plinss: To any of the resolutions.

  RESOLVED: Do layout containment, split containment into three
            pieces as per TabAtkins' proposal
            (https://lists.w3.org/Archives/Public/www-style/2015Apr/0364.html)
            and have overflow: clip

CSS 3 UI
--------

  Florian: There aren't many issues left. Let's start with this.
  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Apr/0193.html
  Florian: When you specify an image for a cursor you can specify
           the coordinates of the hotspot. What they mean is obvious
           when you point to a bitmap via url(), but since <image>
           also lets you do gradients or image-set(), it's less
           obvious how coordinates work then. If you have different
           resolutions you can only set one set of coordinates.
           We need to define how it would work in all kinds of
           <image>s.
  Florian: For gradients they don't have a natural size in pixels,
           the unit could be set so that 50 gets you in the middle.
           The way I propose we solve it is we define the coordinate
           space of every possible <image> type in css-images and
           refer to that in css-ui.

  smfr: If you set a repeating linear gradient as your cursor image
        what happens?
  Florian: The size is defined as impl dependant, through the
           "default" and "concrete object size".
  Florian: This is defined so the UA decides how big the painting
           area should be. The UA defines and then you have a size
           and coordinates, but you don't know what those
           coordinates are. I suggest that 50 is right in the
           middle.
  Florian: Currently the spec says these coordinates are in the
           coordinate space but we don't define what the coordinate
           space is, but I think we should do that.

  tantek: For these more challenging image types, do we have
          support?
  Florian: I think we have at least interest in implementing or
           actual support for image-set.
  tantek: My understanding is we don't for things like gradients. I
          don't think there's browsers that support that.
  Florian: I think for image-set someone does or has intent.
  tantek: I don't think...image-set is new for browsers in general.
          I'd be surprised if they support them for cursors.
  Florian: I think someone said they want to but haven't done it.
  tantek: We might want to capture informative guidance, but I think
          normative language, I would oppose that.
  Florian: Now we have wording that doesn't mean anything we say
           it's in the coordinate space. I just suggest we defer to
           image values.
  tantek: That I agree with. I resisted specifying it in css3 ui.
  Florian: We might want a note in css3 ui, but not define. We might
           want a note on image-set.
  tantek: That's reasonable. If we have a reasonable note that
          reflects what's going to happen. Who edits image?
  * fantasai and Tab
  Florian: TabAtkins and fantasai
  fantasai: I think spec coordinates makes sense.
  <TabAtkins> I'd actually prefer we allow %s, and define that
              integers, when used on an image without coordinates,
              all refer to the start/start corner.
  tantek: Will you take an action?
  fantasai: We can to edit the spec, but we have the same problems
            in other places. We can take an action to see what Media
            Fragments is up to.
  fantasai: We need to define for CSS formats anyway.

  Action: fantasai to edit CSS Image and specify how to determine
          the coordinate system of the image
  <trackbot> Created ACTION-683

  Florian: There are some values where it's not obvious for what it
           should be, but we can get vocabulary quickly even if the
           behaviors are in the air. We can anchor to the right
           terms.
  tantek: And now we can put a note in CSS 3 UI to check that draft
          for details.
  plinss: It sounds like a plan.
  Florian: So a note for now in CSS 3 UI and text is added to image.

  fantasai: For x and y can it take percentages?
  Florian: Only numbers.
  fantasai: It might make sense to spec as percentages. Especially
            if you have multi resolution, especially if you have
            pixel values.

  plinss: We don't have time to discuss it, but I have a follow-up
          on why we don't allow any lengths.
  <tantek> short answer is: current support

  plinss: We're at the end of the week. Thanks everyone, talk to you
          next week.

  <fantasai> tantek: I'm not so sure we need <length>, but I think
             <percentage> would've been more useful than <integer>.
             Maybe for the next level
  <fantasai> tantek, florian: Also, <x> and <y> should be <integer>
             {1,2|
  <tantek> fantasai - yes to next level
  <fantasai> (in the spec)
  <Florian> fantasai: why {1,2}?

  <Florian> tantek: for the other css-ui issue
  <Florian> tantek:
https://lists.w3.org/Archives/Public/www-style/2015Apr/0328.html
  <Florian> tantek: do you mind if I just go ahead and add the may
            to the spec?
  <tantek> Florian - checking for context of "may"
  <Florian> Implementations may substitute a more language, script,
            or writing-mode appropriate ellipsis character, or three
            dots "..." if the ellipsis character is unavailable.
  <Florian> tantek: I'm just adding writing modes to the list
  <tantek> yes that looks good go for it
Received on Thursday, 30 April 2015 13:08:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC