W3C home > Mailing lists > Public > www-style@w3.org > June 2018

Minutes Telecon 2018-06-06 [css-ui-4] [css-align] [css-values] [css-display] [css-variables] [css2] [css-nesting]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 7 Jun 2018 20:13:37 -0400
Message-ID: <CADhPm3tS-q+wwRjsuupRMKg77ey_xoA9u_Ox6PhG6ew7ZRb8EQ@mail.gmail.com>
To: www-style@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================

CSS UI 4
--------

  - RESOLVED: Accept the suggestion in the issue plus a prefix for
              unless otherwise specified. Edits to be added UI 4
              (Issue #2664)

CSS Align
---------

  - RESOLVED: Accept proposal in
https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-392854468
      [Proposal text:
          - If justify-content on the static position containing block
            is start, use the start edge of the static position
            containing block and the end edge of the actual containing
            block (as CSS2.1 requires).
          - If justify-content on the static position containing block
            is end, use the start edge of the actual containing block
            and the end edge of the static position containing block.
          - If justify-content on the static position containing block
            is center, use the start edge and end edges of the static
            position containing block.
      ]

Values & Units
--------------

  - RESOLVED: Allow calc to handle negative 0s (Issue #545)

CSS Display
-----------

  - RESOLVED: Close this issue (Issue #2546) by adding a note
              mentioning the difference between line box and other
              boxes.

CSS Variables
-------------

  - RESOLVED: Reserve "--" for future use and it is not a valid custom
              property name. (Issue #2692)

CSS 2.2
-------

  - dbaron created a proposal
(https://dbaron.org/css/test/2018/stacking-context-z-order )
      for issue #2717 (anything that creates a stacking context should
      sort in the positioned descendants z-ordering list ). The
      working group needed time to review and will discuss again
      during a future meeting (perhaps the next F2F).

CSS Nesting
-----------

  - No one was objecting to the purely syntactic nesting proposal
      TabAtkins had written (http://tabatkins.github.io/specs/css-nesting/ )
      however the call was running out of time so the group will
      revisit next week to ensure everyone has time to look. (Issue
      #2701)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jun/0000.html

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Tantek Çelik
  Elika Etemad
  Javier Fernandez
  Dael Jackson
  Dean Jackson
  Brian Kardell
  Chris Lilley
  Xidorn Quan
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Lea Verou
  Eric Willigers

Regrets:
  Angelo Cano
  Emilio Cobos Álvarez
  Benjamin De Cock
  Simon Fraser
  Tony Graham
  Vlad Levantovsky
  Thierry Michel
  Manuel Rego Casasnovas

Scribe: dael

CSS Align
=========

  astearns: We have enough people
  astearns: Any extra items for the call?

Rules for align/justify-self on static position of
    absolutely-positioned boxes need more detail
--------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-392854468

  astearns: I believe we just need Rossen's take on fantasai's comment.
  Rossen: I did review it.
  Rossen: It should be fine.
  Rossen: Just before I sign off on it...let's get back to this. I
          need to sort out a network issue.

CSS UI 4
========

Require link-pointer when pointer is over a link
------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2664#issuecomment-388344661

  florian: CSS UI defines what a link pointer looks like but doesn't
           say it has to apply to links, esp. Chrome noticed they
           don't apply in SVG. Chrome fixed itself. I think we have
           interop, not 100% sure on Edge. Request is UI spec says
           there needs to be something in UA stylesheet instructing
           browser to use link in the link format for that style of
           document.
  florian: Seems reasonable. AmeliaBR approved. What do you all think?

  fremy: I would recommend we say we recommend it to be there. I don't
         think we can require it. I don't think we should be normative
         on other doc formats.
  florian: So we can either put it as a note or say unless otherwise
           specified.
  fremy: Second is good.
  florian: Same sentence [UAs must apply cursor: pointer to hyperlinks
           for all supported document formats via the UA stylesheet,
           using a normal (i.e. not !important) declaration] from the
           issue with the prefix.

  <tantek> UA stylesheet suggestions in CSS UI are non-normative anyway
  astearns: [reads tantek IRC] Is that the case?
  <tantek> https://www.w3.org/TR/css-ui-3/#default-style-sheet
  <tantek> This appendix is informative.
  <tantek> so should it be in css-ui-4
  florian: Draft has appendix with non-normative UA stylesheet
           suggestions. I'm not suggesting writing a stylesheet, but
           creating a requirement for other UA stylesheets.
  florian: Yes, level 4 not 3.
  <tantek> and keep the UA stylesheet in an informative appendix

  astearns: Other opinions?
  astearns: fremy you're okay with the wording in the issue plus the
            prefix?
  fremy: Yeah, why not?
  <AmeliaBR> The SVG user-agent stylesheet would be the normative spec
             (https://svgwg.org/svg2-draft/styling.html#UAStyleSheet ).
             But good to have consistent guidance from CSS.

  astearns: Objections to the suggestion in the issue plus a prefix
            for unless otherwise specified

  RESOLVED: Accept the suggestion in the issue plus a prefix for
            unless otherwise specified for UI 4

CSS Align
=========

Rules for align/justify-self on static position of
    absolutely-positioned boxes need more detail
--------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-392854468

  Rossen: Only thing to ask is...I had to re-read...now is time to
          discuss and resolve. The ask was to swap out the direction
          and have it overwritten for justify-content so static
          position and sizing used for abspos items effected by
          justify-content. That's the gist, correct?
  TabAtkins: Yes.
  Rossen: I was making sure we want to resolve that justify-content
          takes precedence when calculating position. So if I have
          direction rtl and nothing inside the containing block and I
          have a justify-content:end then basically I will have 0 size
          for the available width.
  fantasai: I'm having trouble with your example. If you have abspos
            and a size containing block which is the parent.
            Containing block we do calc switched on direction
            property. Initial value of justify-content is start,start.
            If you did justify-content:end and rtl it would we same as
            direction ltr.
  Rossen: Not quite.
  fantasai: That's the proposal
  Rossen: This wasn't clear from the linked comment.
  fantasai: Not sure. Point is right now we have different behavior
            for ltr and ltl for static pos. Also size of an auto size
            abspos depends on direction of static pos containing. We
            prop we depend on justify-content which then itself
            depends on direction.
  Rossen: Okay, that should work out

  Rossen: When you have orthogonal changes in direction between parent
          and containing block?
  TabAtkins: No behavior change. What happens today it's the same
             behavior we want with a slight complication since center
             is new.
  Rossen: Center is the half way between?
  TabAtkins: More or less, yes.
  Rossen: Then I'm more or less okay with it :)
  Rossen: With all the information I've heard and read I'm fine with
          it.

  astearns: Other opinions on the new center behavior?
  astearns: Objections to accepting
https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-392854468
?

  RESOLVED: Accept proposal in
https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-392854468

Values & Units
==============

Allow division of same types in calc(): should calc(1 / calc(1/(-1/0)))
    produce positive infinity or negative infinity?
-----------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/545#issuecomment-394474713

  TabAtkins: In the course of porting typed OM into calc, typed OM
             depends on float semantics but in calc CSS values don't
             theoretically have a float semantic bound. I have to
             define certain cases. Division by 0 produces postive or
             negative infinity and it's clamped. I followed ieee754
             semantics. ieee754 semantics track positive and negative.
             CSS doesn't normally care about it.
  TabAtkins: Depending on what you're doing you can construct
             something that resolves to positive or negative infinity.
             So far for simplicity I've omitted them but it's not hard
             to add them back in. I suspect we would want that because
             it's simpler for typed OM and calc to match in these
             cases. Wanted to verify
  <TabAtkins> calc(1 / calc(1/(-1/0)))
  TabAtkins: In issue I have an example ^
  TabAtkins: Resolves differently. It double inverts a negative
             infinity and will be positive or negative depending on if
             a negative 0 escapes the inner calc.
  TabAtkins: I propose we track 0 signedness to be consistent with
             general float semantics.

  fremy: No objections. Still wondering why track infinity. We can say
         it's not a number so it doesn't matter.
  TabAtkins: If you're approaching a 0 in the denominator of something
             you don't want to suddenly flip. The infinities have to
             be something. If they're all positive if something is
             approaching infinity it'll flip to positive and go from
             really big to really small.
  TabAtkins: Typed OM is just math over JS numbers and they have
             infinities.
  TabAtkins: We could expose extra semantics but it doesn't buy us
             anything.
  fremy: If you animate the denominator from -1 to 0 when you get to 0
         it's positive. There isn't a browser supporting it so it's
         not a huge use case.
  TabAtkins: I know it's a new feature. There's no compat to worry
             about.
  TabAtkins: If all infinities go 0 and you have -1/-1 and then bottom
             goes to 0 -1/0 should be negative.
  fremy: -1/-1 is positive.
  TabAtkins: Sorry, meant the other way. -1/1
  fremy: -1/-1 goes to a positive 0. But okay, it's fine. I'm fine
         with whatever you want.
  TabAtkins: I'm not making up semantics. I'm saying follow ieee as
             close as possible.

  AmeliaBR: I agree with TabAtkins that it makes sense to be
            consistent with standard computer math that's already in
            JS. Also important b/c CSS we are animating values and
            once we're allowing people to divide different lengths
            like font size/viewport width and animate to 0 this could
            come up. Continuous animations until something turns
            infinite makes sense.

  astearns: Other impl opinions?
  astearns: dbaron do you have an opinion?
  dbaron: No strong opinion.

  astearns: Other opinions?
  astearns: I'm hearing people call for dealing with negative 0. No
            opinions against.
  astearns: Objections to allowing calc to handle negative 0s?

  RESOLVED: Allow calc to handle negative 0s

Filter Effects
==============

filter should be defined to establish a containing block for fixed and
    absolutely positioned elements
----------------------------------------------------------------------
  github: https://github.com/w3c/fxtf-drafts/issues/11#issuecomment-360240933

  astearns: We discussed once before.
  astearns: Looks like krit and Chris H. have been discussing. Are
            either on?
  chrisl: I did discuss but not prepared to present.
  astearns: krit said he didn't have an opinion either
  chris: It was Chris Harleson (sp?) contributing.
  TabAtkins: I'll get him on the call next week.

CSS Display
===========

Rename 'line box' to 'flow line'
--------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2546

  fantasai: Loirooriol posted asking if we can change name to flow
            line because it's not a box in the box tree sense. We have
            flex line why not flow line. No strong opinion on what to
            call. We've been using line box term for a long time. We'd
            have a lot of specs to change and a disconnect between CSS
            1 & 2 and other specs.
  fantasai: flow lines sounds more obscure too, people who know text
            layout. It's easier to guess what the term means with line
            box -- it's a boxy thing which contains a line of [text]
            content. Not a strong opinion and if WG wants change I'll
            do it.

  <dbaron> I would prefer not to change.  See also the history of
           "simple selector".
  <tantek> I am against this change
  chris: I agree this term has a long history and it's easier to add a
         note saying why it's not behaving like a traditional box
  leaverou: I would have no idea what flow line is. Line box makes
            more sense.
  <tantek> can we time box renaming line box?
  florian: If we switch I'd want something like "line fragment" but
           there's so much history.

  astearns: Anyone argue for changing line box to another name?
  astearns: I'm hearing no one. There's enough arguments against.
  astearns: Objections to close no change?
  florian: I think the suggestion of a note is good.
  <TheRealChris> go for it
  astearns: Objections to closing this issue by adding a note
            mentioning the difference between line-box and other boxes

  RESOLVED: Close this issue by adding a note mentioning the
            difference between line box and other boxes.

CSS Variables
=============

Should "--" be a valid custom property name?
--------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2692

  TabAtkins: Custom property names is anything starting with --
             including -- by itself. I had intended to make a variable
             specific version of the all property and to claim the --
             name for it.
  TabAtkins: Browsers allow -- as a custom property. I expect it's
             rare. I propose we officially disallow -- as a custom
             property name and add -- as an 'all' eq for variables
  TabAtkins: Only compat is if someone is using a plain -- and I
             suspect most people don't even know it's valid.
  <AmeliaBR> Making `--` an official part of the spec sounds kind of
             horrible, so I don't like that reason for disallowing
             author use!
  <AmeliaBR> (But I'm still happy to disallow it for author use.)
  <tantek> +1 on TabAtkins proposal, seems reasonable

  astearns: Let's separate proposed future use from the current point
            of disallowing.
  astearns: You can disagree with using -- with how TabAtkins has
            suggested and still be okay to disallow.
  <tantek> +1 on reserving it for possible future use that is
  TabAtkins: I don't see why disallow if not using it for something in
             the future.
  tantek: [missed] disallow because it shows up in html with a
          meaning. It feels like it is throw away syntax rather then
          have meaning. To keep a bit of line noise out of stylesheets
  <fantasai> +1 on reserving for possible future use from me as well
  fremy: I wanted to say I reviewed and I'm fine with TabAtkins
         proposal. My PoV this is a good change
  <tantek> Let's resolve on just the first half. We can defer debating
           if it means anything in the future
  astearns: Objections to reserve -- for future use?

  RESOLVED: Reserve "--" for future use and it is not a valid custom
            property name.

CSS 2.1
=======

Anything that creates a stacking context should sort in the positioned
    descendants z-ordering list
----------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2717

  dbaron: I think at this point it's calling attention to it rather
          then resolve.
  dbaron: Underlying issue is due to how we structured our specs we
          changed things relating to paining order and stacking
          context without patching this central stuff.
  dbaron: I proposed that everything that creates a stacking context
          paints where css 2.1 paints
  <fantasai> dbaron++++++++
  dbaron: I tried to create test cases. Lots of non-interop.
          Underlying principle seems entirely followed by chrome and
          webkit. Mostly followed by gecko. Edge might be further, but
          might be due to bug. Cases where gecko didn't follow is when
          an impl literally followed spec and did nothing else and got
          different.

  dbaron: Other thing worth discussing is if people agree anything
          creates a stacking context should cause something painted as
          a descendant.
  <fantasai> dbaron, makes sense to me
  TabAtkins: I think Chris H. would be in favor of it. I'll ping him
             into the thread.
  dbaron: Chrome follows the principle exactly I think
  dbaron: I wrote a comment in the issue with the exceptions. Chrome
          and webkit are eq.
  dbaron: When you start looking at which properties are supposed to
          create stacking context there's lack of interop.

  florian: Suggestion is patch css 2 for more generic worded statement?
  dbaron: Part of it is css 2 needs to introduce terms other specs can
          add. It says positioned element. We need a term...I thought
          it's in the issue...I didn't propose a name. But we need a
          term.
  florian: Other terms?
  dbaron: We need a second that's for elements that create a stacking
          context and become a containing block. Since that doesn't
          exist in L2 it could be introduced in an L3 spec.

  Rossen: I looked briefly a couple weeks ago. Thought at the time
          is...we have opacity which is a stacking context but not
          containing block. display:fixed which is stacking not
          containing. We have transforms that are stacking and
          containing blocks including fixed.
  Rossen: Is that what you're proposing to add...all of this?
  dbaron: There's other pieces
  <dbaron> https://dbaron.org/css/test/2018/stacking-context-z-order
  dbaron: In the big test case ^ there's a lot of details
  dbaron: Things I think are supposed to...everything on the left
          except red background should create stacking. Things with
          green box I think also create containing block for fixed pos.
  dbaron: Based on current spec and current resolutions that aren't
          yet edited in.
  Rossen: This is a really good summary of all the different
          combinations which I had not seen. Sorry. I want to go over
          this and make sure we can cross our t's and dot our i's.

  dbaron: I think if anything I might want resolution on general
          principle we'd like to make them equivalent if we can get
          away with it, stacking context and position descendants
          layer. fixed pos is only somethings definitely.
  dbaron: But totally fine taking time.
  dbaron: I tried to make a list of bugs at the bottom.

  Rossen: Other thing that I don't see in write up or matrix is there
          are...also the discussion about body and html in the root
          and filter on html or body would behave.
  dbaron: I think we had separate resolution on that
  Rossen: filter should effect scrolling for viewport or not for
          example?
  dbaron: I remember we discussed that for filter or mask. I'd like to
          keep root stuff separate.
  Rossen: That's fine. When it comes to, especially the fixed
          containing box drama would be great. And that's where all
          the root and body and filter drama comes into play
  Rossen: Without considering the reverse style propagation it's hard.
  <dbaron> we had some discussion about filter and body/root in
           https://github.com/w3c/fxtf-drafts/issues/11
  dbaron: I'll link to another issue where we discussed that, I think

  astearns: Sounds like we all need to look more and come back to see
            if we can resolve. It'd like to in part to get these tests
            into wpt.
  Rossen: Want to make sure we'll cast a wide net and put this to rest.
  astearns: Right
  astearns: Anything more to discuss this week?
  dbaron: I'm fine with later.
  astearns: Maybe a F2F.
  Rossen: One more to add, filter opacity vs. opacity does the right
          thing per spec.
  dbaron: Yeah. I just picked a random filter for my test, but yes.
  Rossen: Reason why is this on we've had confusion where people
          expect opacity and filter opacity behave the same and it
          doesn't for fixed pos.

CSS Nesting
===========

Request to pick up the css-nesting proposal
-------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2701
  <TabAtkins> Proposal on http://tabatkins.github.io/specs/css-nesting/

  TabAtkins: The proposal is relatively simple. Wrote a spec a few
             years back. I'm fine but it's a syntax nicety where we
             didn't get it past the community. If that's changed we
             can move it forward.
  fantasai: leaverou's comment talks about wanting different
            specificity handling or the cascade. That's not syntactic
            only where you can do it with a preprocessor. There was
            @scope proposal before. I don't know if that's wanted or
            something different. I want to see more of that discussed.
            Do we want to effect cascade, if yes how. If we do this we
            should find out what's desired.
  TabAtkins: I strongly believe nothing new on specificity. Because
             nesting is in every preprocessor in existence doing so
             would be a major behavior change.
  fantasai: No, not with same syntax.
  TabAtkins: Second reason is it wouldn't be same as @scoped and it
             would produce things that some ways resemble but some way
             don't. @scoped wasn't popular and doesn't do what people
             want for scoping.
  * bkardell agrees
  leaverou: I agree with TabAtkins, people are used to using nesting
            for preprocessors. I disagree with my earlier comment. I
            think scoping is useful, Not sure usability of scoping
            proposal. It shouldn't hold nesting back.
  TabAtkins: Happy to have that separate.

  astearns: Objections to working on a purely syntactic nesting
            proposal?
  astearns: One concern is if you can do it in a preprocessor why do
            it, but even the preprocessor authors are asking us to do
            it.
  chris: preprocessor expands to a ton of stuff and we don't want that
         expansion
  <gsnedders> It's one less reason to use a preprocessor, IMO.
  <gsnedders> And that's a good thing.
  <bkardell> better for authors, better for network, very slightly
             worse for processing perf maybe?

  astearns: Maybe an issue that we want to avoid the explosion of
            combinations that can happen.
  florian: For OM representation yes, but effect that's unavoidable.
  TabAtkins: CSS style rules gain a child. OM doesn't explode.
  chris: That's a big advantage.
  leaverou: Huge advantage you can hover or focus styles on a one off.
  TabAtkins: Originally a proposal to do rules inside style attribute
             and this doesn't have that. You need only one token of
             look ahead.

  astearns: Objections to resolving we want to move forward with pure
            syntactic nesting?
  TabAtkins: And I want the impl to say if they actually don't want it.
  <tantek> I'm too confused to comment on this last minute on the call
  dbaron: If you're discussing changing what's in proposal it would be
          good to have that written to share around.
  TabAtkins: Entire proposal is linked in the issue to a spec on my
             personal github. It's laid out with no odd changes.
  TabAtkins: We can go to next week.
  astearns: We're over time. I don't hear objections. I think we are
            going to move forward, but let's give people time and
            we'll come back.
  <dbaron> I think for Gecko implementation it's probably worth asking
           heycam and emilio rather than me.

  astearns: Thanks everyone for calling in.
Received on Friday, 8 June 2018 00:14:33 UTC

This archive was generated by hypermail 2.3.1 : Friday, 8 June 2018 00:14:33 UTC