W3C home > Mailing lists > Public > www-style@w3.org > November 2014

[CSSWG] Minutes Telecon 2014-11-26

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 26 Nov 2014 15:33:25 -0500
Message-ID: <CADhPm3viL81K8_B29m74pKZAsNdZz2zxHvjBeiKpfs58V5rYtg@mail.gmail.com>
To: www-style@w3.org
New WD for CSS Transforms
--------------------------

  - Everyone should review Transforms in order to be able to vote on
      publishing a new WD next week.

Fixed position creating a new stacking context
----------------------------------------------

  - Microsoft is going to test out the changes.
  - If it works well, it will be brought back to the group and
      likely written into the spec.

Extend :matches() to pseudo-elements
-------------------------------------

  - RESOLVED: extend :matches() to pseudo-elements

Specificity of :matches() inside :not()
---------------------------------------

  - RESOLVED: The specificity of a :matches() inside a :not() is the
      specificity of the most specific

:has-focus
----------

  - RESOLVED: reuse the hook from :active on :focus
  - RESOLVED: define a new :focus-within that matches on the same
      things as :focus, plus parents, including if there are Shadow
      DOMs

Applying pseudo classes to the label based on labeled content
-------------------------------------------------------------

  - RESOLVED: both :hover and :active should propagate from the
      labeled control to the label, in addition to the other
      direction.

CSS3-UI issues
--------------

  - For text-overflow, the conversation about handling items where,
      due to other properties, the text can't overflow ended up
      being too complex for the time on the telecon and will go back
      to the mailing list.
  - RESOLVED: Drop the text that says: "The resize property applies
      to elements whose computed overflow value is something other
      than visible. If overflow is different in a particular axis
      (i.e. overflow-x vs. overflow-y), then this property applies
      to the dimension(s) which do not have the value visible."
  - For outline offset, everyone agreed that there needed to be
      constraints on how far in the negative direction values can
      go, but there were several different options as to how the
      should be written. Options included:
      - Setting 0 as the minimum.
      - Set a floor as soon as any two lines of the shape touch each
          other.
      - Changing the outline of the shape itself and making it
          shrink.
  - Florian will try and write up a clear and relatively simple
      proposal for the mailing list.

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

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Angelo Cano
  Adenilson Cavalcanti
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Daniel Glazman
  Koji Ishii
  Dael Jackson
  Brad Kemper
  Peter Linss
  Matt Rakow
  Florian Rivoal
  Andrey Rybka
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Greg Whitworth
  Steve Zilles

Regrets:
  Simon Fraser
  Mike Miller
  Simon Pieters
  Keshav Puttaswamy

  Scribe: dael

  glazou: Let's get started.
  glazou: I saw a few additions from Florian.
  glazou: Let me get them on my screen. Since we have tantek and
          Florian we can do them. Are there other extra beyond what
          Florian sent?

New WD for CSS Transforms
--------------------------

  TabAtkins: I'm all for it.
  Florian: Sure.
  <dbaron> +1
  <tantek> +1
  <andreyr> +1

  krit: Are the objections since we discussed transform styles at
        the last F2F. We still have issues in the spec. It shouldn't
        be a huge issue, but people may want to wait. I'd like a new
        WD to reflect the changes we have.
  MaRakow: I'm still concerned about the implications of some
           changes, but I haven't gotten a chance to look at it
  fantasai: Do you want to review and publish next week?
  MaRakow: I'd prefer that.

  glazou: So any comments besides MaRakow's?

  Action: everyone review for next week

Fixed position creating a new stacking context
----------------------------------------------

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Nov/0384.html
  gregwhitworth: You can see the link in the agenda. 2 years ago
                 Rossen and I talked and we were going to make the
                 change and see if we got egregious issues. We're
                 going to go ahead and make the switch so our
                 enterprise customers will say if there's problems.
                 It would be good to get a resolution.

  Florian: You want a resolution first?
  Rossen: We'll flight the solution...It would be good to discuss
          and see what the area is where we want to be. We don't
          want to go back and forth between stacking context and not.
          It's hard to gage what blink and webkit intend to do.
  TabAtkins: I haven't been able to talk to the implementor, but I
             suspect we want to have it. I think maybe Jacob Rossi...
             one of our implementors said it makes it easier. I have
             to check the thread.
  glazou: smfr sent a message just recently saying webkit has no
          plan to change in the foreseeable future.
  <dbaron> I'd be hesitant to agree firmly to change the spec before
           you've done the experiment, but I'm fine with you doing
           the experiment and seeing how it goes, with the idea that
           we'll change the spec if it goes well.

  gregwhitworth: I think us flighting will help the discussion.
                 Webkit and blink might not get bugs but we may.
                 We'll flight it and we can come back, I want to get
                 the discussion going. It would be good to look back
                 once we get it tested and get a full solution.
  gregwhitworth: Does gecko have opinions?
  dbaron: I just wrote in IRC. I'm hesitant to agree to change the
          spec pre-experiment, but I think you should do the
          experiment and we'll change if it works. We'll want to
          know if it's a compatible improvement to do it.
  gregwhitworth: Sounds good.

  glazou: Anything else on this? Is it done?
  tantek: gregwhitworth, you're talking about changing the spec so
          the first example is a blue sq?
  gregwhitworth: Yep. It would create a stacking context essentially.
  glazou: Can we move on?
  group: Yes.

  glazou: I suggest we do item 3 before moving on to CSS3 UI

Extend :matches() to pseudo-elements
-------------------------------------

  glazou: This created a long discussion because someone from webkit
          already implemented. Before we discuss the mobile, I'd
          like to understand why we would do it.
  TabAtkins: The use case is like that of :matches, but without the
             :matches pseudo it's hard to do. So like without this
             spec'ed in style sheets I can use :matches, but I have
             to repeat it for the before and after.
  fantasai: I think it's effectively a syntactic sugar. You can
            write the selectors longhand to be equivalent in such a
            way that it should work exactly the same. There's not a
            reason not to make it accept a pseudo-element, but we
            have to be careful to make sure the syntactic
            constraints are there for the shorthand as well as
            longhand.

  fantasai: TabAtkins, you were having trouble spec'ing it. It
            shouldn't be hard, we can do that together.
  glazou: Any other opinions? Everyone okay with extending?
  TabAtkins: Or having the functionality in some form.
  dbaron: I'd want to catch up and see the proposal, but it sounds
          reasonable.
  glazou: Okay then.
  <SimonSapin> +1 with what fantasai said, keep the same constraints
               as when written the long form

  RESOLVED: extend :matches() to pseudo-elements

  glazou: We have two other things on selectors.
  <tantek> let's keep going with selectors
  Florian: 2 of the things I have are selectors related

Specificity of :matches() inside :not()
---------------------------------------

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Oct/0530.html
  glazou: So Benjamin asked about this on the list and he has a
          weird explanation. The two definitions collide and it's
          hard to understand what to do.
  TabAtkins: The definition of :matches() talks about which selector
             matches. If you nest inside a :not() he's arguing that
             none of them match so you can't get any specificity.
             And wrapping two nots does something really weird with
             specificity.
  TabAtkins: So he says when this happens, pretend it's the most
             specific one.
  dbaron: This sounds right to me.
  <tantek> this sounds like a good spec clarification
  fantasai: Also me. It's making :matches() behave like the longhand
            which is how it should be.
  <SimonSapin> +1 for most specific
  TabAtkins: Using :matches() like the e-mail doesn't add anything.
             For continuity, even if you nest inside the large
             selector inside a :not() we should act similarly.

  RESOLVED: The specificity of a :matches() inside a :not() is the
            specificity of the most specific

  glazou: Can one of the editors reply on the list?
  TabAtkins: Yes.

  glazou: There's the last last on the agenda, that's Florian's. We
          can go as you wish for the rest of the time.
  <dbaron> where's Florian's long list of stuff?

:has-focus
----------

  <Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0271.html
  Florian: The :hover and :active pseudo classes match on more than
           themselves, they also attach to other elements and pierce
           shadow DOM. The :focus pseudo doesn't do this and we
           probably can't change that for backwards compat reasons.
  Florian: It would be useful to do, though, so I suggested a new
           :has-focus pseudo class which would propagate through
           ancestors.
  <fantasai> I think we also don't want to change that, since you
             want to know exactly what's in focus

  Florian: There's fairly obvious use cases. If you have a form and
           want to highlight it you can't do it without JS right now.
           Same thing if you want to go through a shadow-DOM. Since
           we can't change :focus, I suggest introducing this.
  fantasai: I think we don't want to change :focus.
  Florian: We can't, but we want something that does the same with
           the extension.

  fantasai: I think there's reasons why you'd want to go up the
            ancestors and reasons why you wouldn't. I think it's a
            good idea to add this because it handles a lot of use
            cases.
  Florian: Also some people suggested we didn't need it because it
           was handled by :has, but it doesn't pierce shadow
           barriers unless you specifically make it do so.
  TabAtkins: Agreed.

  fantasai: I think :has-focus, I'm not sure about the label
            propagation, I'd prefer that via :focus, but if this is
            an ancestor for a focus element it matches.
  Florian: Opening the possibility for the host language to match is
           appropriate, but if it should do the same is a slightly
           different conversation. Opening the possibility is
           appropriate and we can leave :focus as is since it's got
           a long history of backwards compat.

  tantek: I have a concern about confusion from web developers. You
          learn about :has and :focus but :has-focus doesn't do what
          you think it would from the pieces. Having it named like
          that would be confusing.
  Florian: I'm happy to bikeshed. It's been called :focus-within and
           other options. I'm not attached to the name.
  fantasai: I think I agree with tantek. It should function like
            :has(:focus) if it has :has-focus as a name.
  fantasai: I think that it's okay for it to also pierce shadows, I
            don't think it's okay for the host language to customize
            :has except through customizing :focus
  Florian: I'm a bit confused. Are you saying it should be unfocused
           directly?
  fantasai: If the host language wants to change, it changes through
            :focus and can't change :has-focus except that it is
            defined in terms of :focus. It's a general principal I'd
            want, but the name makes it more important.
  tantek: You want to minimize the number of interface points
          between specs. If you use how the host language uses
          :focus, that's the hook for the host language.
  Florian: So if the host language can modify :focus, that's great.
           If not I'd like to introduce it on the new thing, no
           matter the name. It currently does on :active, not on
           :focus. :focus just matches the focus thing.
  Florian: That's why I'm trying to introduce this on the expanded
           focus.
  tantek: I'd rather allow a hook on :focus that's reused instead of
          saying you can hook into :has-focus.
  Florian: If we can I'd prefer that too.

  fantasai: Is this the label thing? I think there's no backwards
            compatibility issue, just implementation issues.
  tantek: Can we re-use the hook on :active?
  Florian: We can try and say it's the same hook as :active if
           there's no backwards compat issues. If we can do that
           that's best.

  Florian: Should we try and resolve on that? So we resolve that we
           use the hook on :active for :focus and we create a new
           element that is like :focus but pierces shadows
  tantek: If you're looking for a name to use, :focus-within works.
  Florian: Especially if we're using the hook on :focus.
  tantek: And we can bikeshed on that name later.

  <Florian> RESOLVED: reuse the hook from :active on :focus
  <Florian> RESOLVED: define a new :focus-within that matches on the
            same things as :focus, plus parents, including if there
            are Shadow DOMs

  Florian: Alright.
  <tantek> Sounds reasonable
  glazou: No objections on those two resolutions?
  glazou: Adopted! Let's move on.

Applying pseudo classes to the label based on labeled content
-------------------------------------------------------------

  Florian: The other topic is related to this. Currently the hook on
           :active and the definition of :hover both propagate from
           the label to the labeled control, but not backward. If
           the control is active the pseudo won't match on the label.
           I think it's better to go both ways.
  Florian: I raised that on whatwg and there were few answers. The
           answers was that the current direction is 1-1, but the
           other direction was 1-to-many.

  gregwhitworth: We ran internal tests and we've never had issues
                 regarding this. Their math works, but in the real
                 world you won't hit this problem. I ran something
                 with 5,000 <div>s inside a label and it was only
                 milliseconds of difference, so I don't think it's a
                 problem.
  Florian: In general, it makes sense to go in both directions. Now
           that the hooks are separate we might want to decide
           separately.

  glazou: Other thoughts?
  <tantek> Curious what dbaron thinks about this.
  <dbaron> I don't particularly care.
  <tantek> Then I'm willing to go with consensus as well.
  <tantek> No strong bias.
  fantasai: I think having it go in both directions make sense.
  TabAtkins: I agree as well.
  Florian: So we should go back to the whatwg and say the CSS group
           agrees it should work both ways.

  <Florian> RESOLVED: both :hover and :active should propagate from
            the labeled control to the label, in addition to the
            other direction.

  glazou: no objections?
  [silence]

  Action: Florian to ping the whatwg on the above resolution
  <trackbot> Created ACTION-662

  Florian: So to CSS3-UI or finish the agenda?
  glazou: We finished the regular agenda.

CSS3-UI issues
--------------

  Florian: We'll do these one at a time and see how far we get.
  <Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0425.html
  Florian: This is the first comment, it was half of a change was
           done. Did you forget the other half or decide not to do
           it?
  tantek: Likely accidental. I was trying to be conservative with
          the edits, but that was probably unintended.

  tantek: So this was line box. I'm reading.
  Florian: So, basically, do we overflow onto the float?
  tantek: The suggestion is reasonable. I can make the change. I
          guess I just didn't make the edit.

  Florian: I have no opinion- just trying to guess why you didn't do
           it. Browsers are interoperable along the current spec.
           The question would be to implementors, would you make the
           change if we spec it?
  Florian: It seems reasonable, but we're interoperable in another
           way currently.
  Florian: If you have text-overflow ellipsis and we're overflowing
           onto the float, does the text overlap or do we apply the
           ellipsis?
  Florian: Currently the spec says you overwrite. Everyone does it
           according to text.
  tantek: I think Gecko would change to have the better behavior.
          There's aspects that are interoperable, but things like
          handling scrolling aren't. So do we look at this as a
          forward looking change, or is it a compat issue?
  Florian: If browsers will change I'm happy.

  Rossen: With this edge case, and it's very edge, from a usability
          point of view, let's say you apply the ellipsis, but if
          your text is colliding, how would you scroll that? I'm
          assuming in that test case you can't scroll, so why would
          you hide?
  tantek: So that you don't overlap and have it look ugly.
  Rossen: How can you get to that case? Do you have a test case that
          shows it? I just can't picture how the text would overlap
          with the float. Unless this is a bug, the float for the
          text should be one over the other.
  Florian: I have a test case, hang on.
  <TabAtkins> https://bug944200.bugzilla.mozilla.org/attachment.cgi?id=8340052
  <Florian> https://bug944200.bugzilla.mozilla.org/attachment.cgi?id=8339998
  tantek: I think the test case from TabAtkins is the right one.
  Florian: Yes. We're talking about the third line.
  Rossen: The one that you just pasted?
  Florian: The third line in TabAtkins's linked example.
  tantek: In this case the third line, what happening is the text is
          overriding...normally text would wrap around the float.
          It's only overlapping because the white-space no wrap.
  Rossen: Yes, I see. I missed that part.

  Florian: So what we're currently seeing is correct by the spec.
           We're proposing a change
  tantek: Rather than drop the visible requirement, there's
          something else causing the overflow. That's why we should
          consider the case. Or the line box has a whitespace that
          doesn't allow wrapping, we're basically talking about
          conditions where the text can't overflow.
  Florian: I think that's already addressed by the spec. I think so.
  tantek: I didn't think it was but okay.

  tantek: This seems deeper than we thought it would be. It sounds
          like the spec change to make this requires more iterations.
  Florian: Take it back to the list?
  tantek: Does that seem reasonable? The whitespace no wrap
          relationship should be well understood.
  Florian: That is, but the float bit needs to be looked at. Back to
           the list. Next one?
  tantek: Sorry, I thought that would be easy.

  <Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0445.html
  Florian: Still on overflowing. This is issue 37. We have it
           spec'ed that the resize applies to non-visible overflow
           and if that's the case in only one direction it applies
           in only one direction. But you can't have that in only
           one direction because everyone is interoperable that if
           you have overflow in one direction visibility is set to
           auto.
  Rossen: Anything other than that behavior would be a nightmare to
          implement.
  Florian: I'm suggesting we remove that bit of text since it's
           trying to hook into something that doesn't happen. If we
           have visible in only one direction we have it become
           auto, so visible set in only one direction doesn't happen.
  fantasai: It's a case that doesn't happen.
  tantek: So we need to say something else.

  Florian: So I proposed a note that says it's not possible, but if
           later that becomes possible we'll need to define the
           behavior.
  tantek: So we apply both directions?
  Florian: Yes. Currently the spec pretends there's another
           possibility.

  tantek: I agree with TabAtkins that we drop it with no note.
  fantasai: We have a case that's slightly different where there's
            regions where you paginate in one direction and scroll
            in the other. That's a case to think about.
  Florian: For regions the fragment isn't on the overflow property.
           Even if you're fragmenting you only have one direction.
           There's no need for something special. For the overflow
           fragments, the spec isn't stable and we don't know what
           will happen.
  Rossen: I agree. Regions, the only extra constraint is how much
          content you have, not what happens with content layout. I
          don't think we can get in situations where one direction
          overflow is visible and the other one it's not.

  Rossen: So dropping this?
  Florian: That's my recommendation and add a note if someone is
           concerned
  Rossen: I'm up for it.
  glazou: Everyone agrees?

  RESOLVED: Drop the text that says: "The resize property applies to
            elements whose computed overflow value is something
            other than visible. If overflow is different in a
            particular axis (i.e. overflow-x vs. overflow-y), then
            this property applies to the dimension(s) which do not
            have the value visible."

  <SimonSapin> Florian,
http://www.w3.org/Style/CSS/Tracker/actions/662 lacks some context

  <Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0449.html
  Florian: The spec doesn't put any constraints on the outline
           offset, so you can put it -9000 which isn't interoperable.
           There's been discussion, but no conclusion. There's no
           reason to forbid small negatives, it's only a problem
           when the outline smashes into itself.
  Florian: The option C in the e-mail isn't great. Another is when
           it slams into itself, but you preserve 1 pixel, or
           preserve the entire thickness which is my favorite.

  tantek: What do implementors do?
  Florian: They disagree. In Chrome it disappears, in Firefox if you
           have 1 pixel outline and a large negative offset it has a
           large black area. So a 10 pixel high box and a -9000
           offset, you get a 1000 pixel black thing. It's not
           interoperable
  Rossen: The outline offset to me...the reasonable behavior to
          expect is if you consider the content box and border box
          you use padding to offset them and that lets you move the
          border box from the content. We don't allow negative
          padding, I don't see a reason that outline offset
          shouldn't be considered the same way. Once you distance
          outline box from padding box, I don't think why you'd want
          to constrain inside.
  Florian: So allow no negative values?
  Rossen: Yes.
  Rossen: If you draw parallels between how padding is used, it's an
          offset for border box, so outline-offset is the same thing.
          We don't allow negative padding.
  tantek: It's because the use cases for drawing an outline are
          different than a border. I appreciate simplifying the
          model, this was deliberately allowed.

  fantasai: I think we should say the area constrained by the
            outline is floored at 0 so you can't have overlap no
            matter the shape. If it's an hourglass it might turn
            into a 0 width square.
  Florian: But if you start non-rectangular and shrink, I would
           block as soon as two sides hit each other.
  <BradK> +1 on stopping the offsets once two edges touch each other
  * fantasai happy for UA to have higher limits
  * fantasai e.g. letter-spacing has UA-defined limit on negative
             values

  dbaron: I'm a little worried that you're getting into defining a
          complex algorithm for an obscure case.
  Florian: I'm trying to define and make it not disappear because
           it's useful for :focus.

  Rossen: tantek, can you explain the major use case you're trying
          to achieve?
  tantek: There's UIs that have a glow where you want to overlap. I
          believe that's why it was introduced. I share the concern
          about trying to over specify an algorithm. We might be
          able to say use the metrics of the border box and you
          can't go negative beyond what would 0 out the border box?
  tantek: You can go negative into the border box, but you can't
          completely eliminate it.
  Rossen: So you want the inner border box edge?
  tantek: It has dimensions and overall width. You divide that by 2
          and that's a clamp.

  fantasai: Maybe define as not changing the outline set, but
            changing the outline of the shape being drawn. Right now
            you have various border boxes and we can say this
            shrinks the box you're wrapping around. If you have a
            non-rectangular shape, the boxes you're wrapping around
            shrink.
  Rossen: What do you exactly define as shrink?
  tantek: I was trying to specify in terms of the border box.
  <tantek> computed value

  Florian: To make it more complex, presto does it differently where
           if you have a way to flow outside the box you can also
           get it non-rectangular. Something sticks out and you draw
           outside that non-rectangular.

  tantek: We have no obvious solution. We need someone to make a
          simple proposal on the mailing list that isn't too
          algorithmic but also handles it reasonably.
  Florian: I can try and do that. So are we looking for perfect
           interoperability or just keep boxes from disappearing?
  Rossen: We want interoperability and please consider inline and
          outline where they overlap.
  Florian: And we don't have interoperability on outline.
  fantasai: I want interoperability. We should have to spec so we
            limit bad things.
  Rossen: And we want interoperability because without that there's
          no reason.
  Florian: Short of defining it, we need to make it so that it works
           for people trying to do common things.

  fantasai: Letter-spacing says you can do it but there's UI limits,
            those just aren't defined.

  tantek: We need simple limits that don't make it useless.
  Rossen: And real examples so that we can see what reasonable means.
  Florian: I'll give it a shot and get back to the list. Rossen,
           I'll send you an e-mail to help me understand IE behavior.

  Florian: I have more, but that's next week.
  glazou: Thank you.
Received on Wednesday, 26 November 2014 20:33:53 UTC

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