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

[CSSWG] Minutes Telecon 2019-03-27 [css-easing] [scrollbars-1] [css-inline] [css-transforms] [selectors-4] [css-env]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 27 Mar 2019 21:57:13 +0300
Message-ID: <CADhPm3tZbPdtbamNqKG9wzXhF6XV9iXVmHz2d2f-8ZgMafNXBA@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.
=========================================


Can we move Easing Functions and Scrollbars to CR?
--------------------------------------------------

  - There were no objections to moving Easing Functions to CR, however
      the editors were not on the call so resolution will be called
      for next week.
  - Scrollbars was not quite ready for CR. There are still some open
      issues that need to be resolved and myles said he has some more
      to file. However, work is definitely progressing toward a CR.

Houdini meeting at TPAC?
------------------------

  - Houdini will request a room to meet on the Friday of TPAC.

CSS Inline
----------

  - RESOLVED: Return 'normal' for line-height (Issue #3749: A question
              for the procedure to compute the resolved value of
              "line-height")

Republishing drafts with dev.w3.org links updated
-------------------------------------------------

  - RESOLVED: Republish Selectors Nonelement as a note and we are
              abandoning this work

CSS Transforms
--------------

  - RESOLVED: For SVG Transform attribute there is no requirement for
              space or comma between transform functions (Issue #3719:
              SVG transform attributes: transforms don't need to be
              separated)

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

  - RESOLVED: Defer complex selectors for all of these selectors
              [:nth-child()/:nth-of-type()/:is()/:where()/:not()/
              :has()] and have a note in the current level mentioning
              this is an enhancement we'll get to in the next level
              (Issue #3760: Defer complex selectors inside
              :nth-child() etc. to L5)

CSS Environmental Variables
---------------------------

  - florian introduced his proposal to be able to reuse the title of
      the document inline such as making it always present in the
      header or footer (Issue #3685) . There was concern about if
      using title was the best way to solve the use case, but there
      wasn't enough time on the call to dive deeper.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2019Mar/0016.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Oriol Brufau
  Tantek Çelik
  Emilio Cobos
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brad Kemper
  Brian Kardell
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Nigel Megitt
  Anton Prowse
  Melanie Richards
  Florian Rivoal
  Dirk Schulze
  Lea Verou
  Sean Voisen
  Fuqiao Xue

Regrets:
  Manuel Rego Casasnovas
  Greg Whitworth

Scribe: dael

Can we move Easing Functions and Scrollbars to CR?
==================================================

Easing Functions
----------------

  astearns: I don't think we have an Easing Functions editor on call
  fantasai: I can summarize where we are
  <smfr> https://drafts.csswg.org/css-easing/
  fantasai: Easing spec, aka Timing Funcitons has been stable since
            last changes went in during the summer.
  fantasai: Current status is there is no open issues except adjusting
            wording to be more generic. Aside from that it's
            implemented, deployed, stable, should be in CR. I think
            editorial work could happen in CR. WE shouldn't hold it
            back.
  fantasai: It's ready for implementation and can encourage
            implementation

  astearns: Concerns with direction?
  <florian> Sounds good to me
  astearns: I will ping the editors in case they don't read minutes.
            We can take it up next week with one or both on call

Scrollbars
----------

  astearns: Scrollbars? Ready for CR?
  fantasai: No but close. It's impl and deployed in Gecko. Most of the
            issues feel can be closed with a little editor effort.
            Nothing contentious open. Not far but can't publish to CR

  smfr: We'd like 1958 resolved. Scrollbar width as a length
  <smfr> https://github.com/w3c/csswg-drafts/issues/1958
  astearns: Any other concerns with scrollbars?
  tantek: I'm not seeing that in query
  fantasai: Was marked as closed
  <@fantasai> https://github.com/w3c/csswg-drafts/issues/1958#issuecomment-417146619
  tantek: What additional are you looking for smfr ?
  smfr: Reading through. Not sure what resolution was
  astearns: xidorn put in scrollbar width to spec with auto|thin|none
  smfr: ED not up to date or am I not looking at it?
  <@fantasai> https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width
  smfr: ED still has length value and mentions the note
  astearns: There is a note in the draft but issue is not open
  smfr: So spec needs updated
  tantek: Thanks for pointing out
  chris: If you use edits needed tag on issue and open it again

  astearns: Okay, so we can work through that issue and other edits
            and possible look for CR in near future?
  tantek: I think there were a few issues that applied to other spec
          and features that were open regarding scrollbars. Don't know
          if want to include or resolve or punt to another version
  tantek: I guess I disagree with fantasai summary for a few issues. I
          agree for most issues. Some require responding to folks that
          want more features and saying we're not doing that.
  tantek: 2899 is a good example
  fantasai: I think if we need to defer to next level we can do it.
            Given you are shipping and there's no sign. Issues we
            should put in CR
  tantek: Because scrollbar-gutter not ready?
  fantasai: Not impl. You can try editing it in if you feel there's
            enough detail. I don't have strong opinion on this level
            or not. I don't want it to hold back CR because we have
            stable and shipping
  <smfr> https://www.w3.org/TR/css-overflow-4/#scollbar-gutter-property
  florian: We had significant design discussion but no one has tried
           implement. We can put in as at-risk or just put in next
           level
  tantek: Is it ready for implementation?
  florian: I think so
  tantek: It's got tests?
  florian: I don't think it has tests. Should get some. I don't think
           wait for spec work, we should write tests and impl. Trying
           to get to CR doesn't sound crazy, but it doesn't have impl.
  tantek: If we haven't had tests I don't feel good putting in CR
  myles: I have some issues I haven't filed yet on this spec
  florian: People looking at impl is good way of getting tests.
           Signaling it's ready for impl may get tests
  fantasai: CR means spec is as stable as it will get with us
            discussing in a room. We're done with design, have to work
            out details based on experience of impl and writing tests.
  fantasai: I don't mind either way. If the editing work or issues
            will hold back CR I'd prefer to hold, but if it's doable
            we can put it in as at-risk
  florian: I don't think there are open issues on scrollbar-gutter
  astearns: May be because no one looked from implementation standpoint
  florian: Maybe
  florian: I think it's significantly more stable then other things in
           overflow 4

  tantek: Have implementors indicated interest in scrollbar-gutter? I
          don't know for Gecko
  florian: When we discussed significant interest to solve that
           problem and agreement this would solve. I'm not sure if
           that's same as impl interest
  tantek: It's not. Implementor interest is an implementor saying we
          want to implement.
  florian: I heard we want to solve a problem and that looks good way
  astearns: Any implementors on the call want to speak up?

  astearns: Let's move on. Good to get status. Sounds like
            conversation is settled where it needs to.
  tantek: I can go ahead and do edits and put the scrollbar-gutter
          into current and we can try the at-risk approach to see if
          it gathers the attention.
  tantek: Was it myles that said he had more issues?
  myles: Yep
  tantek: Those would be good to see as well. That's what we have to
          do to take toward CR

Houdini meeting at TPAC?
========================

  astearns: Signed up for Mon and Tues. Interest for a half day
            Houdini. Do people care if it's Thurs or Fri?
  astearns: I know krit concerned about overlap on SVG
  smfr: Prefer contiguous with CSS
  <AmeliaBR> I'd also prefer not-Thursday because of SVG overlap.
  astearns: Can't do it entirely because Wed can't pick
  chris: Prefer Fri
  leaverou: Me as well. I have interest in participating in SVG
  chris: Having said that I have conflicts Thurs & Fri
  leaverou: AmeliaBR would have a problem because she would need both
  <myles> SVG is on Thursday, right?
  astearns: Yes, SVG is Thurs.
  nigel: I did wonder...maybe it's best to do a poll
  astearns: Definitly possible
  florian: A doodle or something light
  <tantek> ok with either day
  <tantek> Yes Friday makes slightly more sense because it avoids AC
           meeting conflict on Thursday

  Rossen: If SVG is on Thursday and so are A/C meetings. Traditionally
          didn't use Friday but I didn't hear anyone say no Friday
          because I'm out. How about we pencil in Friday and if we
          don't hear otherwise we reserve the room and move on.
          Elsewise we might miss deadline for sign up.
  astearns: That's true. I wasn't considering deadline
  chris: It is important to get rooms, they do fill up.
  astearns: Objections to having Houdini meeting on Fri of F2F?
  astearns: Alright, I will send in a request for a room on Friday for
            Houdini

  <myles> by the way, everyone should remember to re-join the newly
          rechartered SVG WG
  astearns: [reads myles IRC comment]
  chris: Almost everyone needs to rejoin

CSS Inline
==========

A question for the procedure to compute the resolved value of
    "line-height"
-------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3749

  florian: Bit of discussion in GH was first a suggestion maybe
           line-height isn't special because many types of boxes that
           can fragment and we always return first. Two buts: we're
           talking contiguous runs of text which is poorly defined to
           say first. This is not what Gecko or WK return, both return
           more theoretical rather than actual layout
  florian: But it is similar.
  florian: I maintain given that we're not providing a post layout
           usable value we may as well preserve as keyword as Chrome
           does. But alternative isn't hard to spec so if people feel
           strongly, why not. I'm not sure there's a use case for it.
  florian: If we want to drill down to font metrics it's more houdini
           space.

  myles: I was reading conversation from last week and I think I
         didn't make something clear. Philosophically I think you're
         right. There is no px value that will always be correct. My
         concern was web compat. If we do keyword and not number and
         line of JS tries to parse it could cause exceptions
  myles: I brought up we should do analysis.
  florian: Question on compat concern. Anything we change from any
           engine could break amount of web. The fact that Chrome
           ships other behavior tends to make me think it's probably
           okay. Do you have a specific reason to worry about this one
           or is it a general case of changing might break?
  myles: Why this might be different is line-height and
         getComputedStyle have been around forever. Changing behavior
         that's been consistent in engine for decades is scary
  fantasai: If we want interop someone needs to change. Either Chrome
            to return px or other engines return 'normal'
  fantasai: Is that not correct?
  TabAtkins: myles, given we have real life compat data that Chrome
             returns keyword, what information do you want obtained?
  myles: A blunt tool is how many times getComputedStyle called where
         result is 'normal'
  TabAtkins: Potentially obtainable, but a fairly invasive use counter
  florian: Would that data from Chrome help? We know Chrome is fine.
           If there's a problem it's because websites are build
           differently perhaps on mobile where Chrome has less market
           share. So would it help?
  <@Rossen> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/line-height/
  <@Rossen> in case this helps a bit ^
  <@fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0Ax%0A%3Cscript%3E%0Aw(window.getComputedStyle(document.body).lineHeight)%3B%0A%3C%2Fscript%3E

  emilio: I'm somewhat concerned...result of getComputedStyle on form
          controls have particularly weird computation. WK and Blink
          mangle line-height to give computed line-height. I suspect
          there are cases where if you have a select element if this
          change impl in Gecko it could return keyword and Blink
          returns pixel. I recall something where like if the height
          is fixed it becomes a fixed height value.

  emilio: Willing to try and change, but that's my concern
  nigel: Observing this seems a bit of a tie here. Current behavior is
         return 'normal' and that's closer to computed value. Resolved
         isn't always computed, but being as close as possible seems a
         reasonable rule to use to break the tie.
  fantasai: I think if Gecko is willing to try that should resolve web
            compat concerns. I agree that's probably the direction to
            try and go in.
  myles: If Gecko makes this change and there's no problem that's
         sufficient. I agree with fantasai. Don't need a use counter
         in that case
  astearns: Way forward is spec we return 'normal' have Gecko try it
            out and hope for the best
  fantasai: And if problem open issue

  astearns: Objections to return 'normal' for line-height?

  RESOLVED: Return 'normal' for line-height

  astearns: Thanks emilio for being the guinea pig
  emilio: I'll add a use counter and not blindly change, but happy to
          give a shot

Republishing drafts with dev.w3.org links updated
=================================================

  astearns: I'm not sure if the republishing in this email thread is
            required. I'm assuming links will continue to work and we
            don't have other dependencies on machinery being shut
            down. Is that correct?
  xfq: It's not required because the redirection will continue working
       although it's an old server that will be read-only and some
       spec haven't been updated for 3, 4, or 5 years on /TR
  astearns: I agree we should update some specs. I don't know if it's
            useful to have a mass repub
  <tantek> does this effect CSS 2.2 publication? what legacy systems
           are we talking about?
  xfq: We can do that case by case. Refreshing some old specs I think
       we can discuss the ones that might need retirement like
       non-element selectors. Concern in retiring?
  chris: We should certainly retire at least that.
  xfq: And page floats we got 2 need editors last year so maybe hold
  <@fantasai> FTR, the specs xfq has listed are css-lists-3,
              css-scoping-1, css-gcpm-3, css-ruby-1, css-line-grid-1,
              css-regions-1, css-exclusions-1, css-page-floats-3,
              selectors-nonelement-1
  florian: Page floats we should not republish because if I am an
           editor I haven't been able to work for a long time but
           there are outstanding resolutions that have not been
           editing in. Publishing when knowing text is wrong is bad
  <@fantasai> +1
  florian: They're difficult edits
  fantasai: I think line grid spec I don't think much is changed so
            fine to republish. I would skip announcing it
  astearns: I think there are enhancements to examples agreed on but I
            have not made edits. It's in the same boat where
            republishing is not quite right
  chris: Some of these spec have changes with PRs so there is
         outstanding stuff incorporated but not published since
  astearns: Those PRs are part of the big PR backlog. If you are an
            editor on one of these specs for the changelog please
            approve
  xfq: And thanks to those that reviewed

  astearns: I think there is no reason not to publish selectors
            nonelement as a note.
  astearns: Objections to republish selectors non-element as a note?
  florian: Gutted note or note with content?
  chris: With content. But status says not worked on
  xfq: Agree
  <tantek> sounds more like abandoned by the WG
  <tantek> "not worked on" sounds temporary for now
  astearns: tantek mentioned it sounds abandoned and that's purpose of
            note
  chris: Note can say it's retired when you publish. The idea is that
         people don't get confused by a slew of stuff

  dbaron: At some point I thought that a bunch of pseudo elements
          removed from selectors with the thought to move. Where are
          they?
  TabAtkins: Pseudo spec. This is just for attr nodes
  chris: I don't think it's been lost
  <tantek> Lists would be good to republish, since we're implementing.
           And realizing looking at it I was formerly an editor 😂
  astearns: I'm hearing no objections

  RESOLVED: Republish Selectors Nonelement as a note and we are
            abandoning this work

  astearns: Any other things to talk about with old drafts?
  astearns: People look at the list. If you are editing anything
            mentioned or you are a former editor it would be good to
            update
  tantek: Good to get Lists repubished. It's almost 5 years out of
          date and we're impl the current set of resolutions to having
          it published would be good
  TabAtkins: Next thing I'm working on so agreed
  tantek: Thanks

CSS Transforms
==============

SVG transform attributes: transforms don't need to be separated
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3719

  krit: There is a historical difference between SVG and CSS. If we
        just look at SVG there is a case of full interop that's not
        covered by spec. There's no space or comma between any
        transform list. Spec requires it but impl don't. I request we
        relax the syntax to follow impl
  TabAtkins: This falls out of CSS definition where you don't need
             spaces if you can distinguish
  AmeliaBR: Not that simple because rest of syntax can't be desc with
            CSS syntax. Have special parsing for transform based on
            SVG1. This happens to be where all browsers don't match
            SVG1 so might as well match other browsers
  AmeliaBR: Found other weirdness that's inconsistent but I'm happy to
            ignore certain browsers allow mangled syntax. But if
            everyone supports we should include in spec
  krit: Requested is for SVG Transform attribute there is no
        requirement for space or comma between transform functions
  astearns: Just transform attribute?
  krit: For CSS that falls out with the tokenizer so yes just for
        transform attribute
  astearns: Objections?
  myles: IN SVG transform definition just links to css
  krit: Correct
  AmeliaBR: There's a section in css transforms that gives special
            rules for parsing the attribute
  <krit> https://drafts.csswg.org/css-transforms/#svg-transforms
  krit: Link ^
  astearns: It's in css draft where this is defined
  krit: Yep

  RESOLVED: For SVG Transform attribute there is no requirement for
            space or comma between transform functions

Selectors 4
===========

Defer complex selectors inside :nth-child() etc. to L5
------------------------------------------------------

  astearns: Discussed earlier but didn't resolve
  fantasai: These selectors have been highly requested for years. We
            know that WK had implemented the full functionality
            allowing combinators and everything but no one else has
            impl. There is a question of should we reduce scope of L4
  fantasai: Question I wanted to ask is do we take this back to only
            allow compound for now and add complex in the future to
            make impl easier or is that not relevant concern?
  fantasai: Interop of reduced subset solves most of the problems
  AmeliaBR: No one would ask WK to rollback it's jsut defer to next
            level?
  fantasai: Yes

  astearns: Concerns from WK?
  smfr: I think we're okay moving those bits to next level
  astearns: In issue question of how many selectors we defer complex
            selectors for.
  astearns: Question is do we defer complex for :nth set or also the
            is/where/not/has collection?

  myles: For specs to get to rec we need two impl so why not start
         there?
  astearns: With everything?
  myles: If not 2 impl and no plan for another one...
  myles: We have to defer
  myles: Sooner or later
  fantasai: I don't want to have someone not impl and push off impl of
            these features in general because doing all at once is too
            much. If reducing size gets us an impl fast that's good.
  fantasai: I want to hear from Gecko and Blink are you planning to
            impl and if yes would trimming make it faster
  TabAtkins: I have to ask, I'm not certain. We're not against it but
             I don't know scheduling
  AmeliaBR: Comment in issue from Eric W that he started but hasn't
            worked recently
  emilio: We don't have immediate plans to impl, but complex selectors
          really complicate getting invalidation right so it would
          definitely take more if we had to figure out combinators
  fantasai: Is that true for the nth set only or also is/where/not
  emilio: If we solve we have to do for all at once
  fantasai: That seems like a good argument to refer to next level if
            can get Gecko impl sooner

  dbaron: I think if the result you want is finding out...is A
          encouraging impl and B finding out if extra parts will cause
          pain I think perhaps best way is add a note to spec that
          says we're considering dropping. If they make your impl
          harder please impl without and let us know. Because then
          there's clear intent WG is interested in feature as a whole
          but also just those parts
  fantasai: Could do opposite and just add subset and note we're doing
            the rest in L5 and these already impl in WK but seemed too
            complex for others
  florian: That's harder editorially. Do you think subset is easy to
           figure out in reading spec? Or is note saying can do subset
           is enough so don't have to editorially split it up
  fantasai: If we're doing it for all at once it's quite simple
            editorially.
  astearns: For myself it would be clearer reading spec to have
            complex selectors broken to next level with a note saying
            intend to add in future level. It's easy to look at
            production with complex selectors and miss the note and
            think it's too much
  astearns: My preference is to defer complex selectors for all of
            these and have a note in the current level mentioning this
            is an enhancement we'll get to in the next level
  astearns: Objections?

  RESOLVED: Defer complex selectors for all of these selectors and
            have a note in the current level mentioning this is an
            enhancement we'll get to in the next level

CSS Environmental Variables
===========================

Getting access to the document title
------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3685

  florian: There is a feature in GCPM that lets you in paged media
           generate header and footer with repeating document title in
           box. Interesting, but highly specific so not impl by a
           mainstream browser. Base feature to take document title and
           inject somewhere visible is useful. nth function seems like
           it could achieve that. Proposal is to have nth-doc-title
           expose the title of the element to be used in generated
           content
  <tantek> q+ to note "title of the document" is not necessarily
           <title> but sometimes (often) <h1> etc.
  florian: I'm specifically referring to a title element, not an h1.
           This isn't regions. H1 can have complex markup which
           wouldn't transfer to nth. HTML title element is just text
           so it's useful as well. Regions is useful but bigger
  <tantek> right, I know that. I'm saying your use-case is
           disconnected from your solution.
  tantek: Not about extra markup but typical title elements contain
          things from name of website to author to doc name. If
          looking to solve use case and you want to repeat the human
          readable title of document that information is often in
          first H1. If the use case is the repeating thing that
          doesn't solve with how people publish on web today.
  florian: I think will work with most eBooks but you have a point
  tantek: I would want to double check solution
  <AmeliaBR> +1 to tantek's argument on practicality. But I like the
             general idea of env() to access document properties.

  astearns: We're out of time. Thanks everyone for calling in
Received on Wednesday, 27 March 2019 18:58:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 27 March 2019 18:58:08 UTC