[CSSWG] Minutes Telecon 2018-01-03 [css-selectors] [css-values] [css-paint]

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Berlin & Sydney F2F
-------------------

  - Anyone planning on attending the Berlin F2F should add their name
      to the wiki and indicate hotel & Typo Labs information.
  - RESOLVED: Mid-year Sydney F2F dates are July 2 to July 5- July 2
              is Houdini, July 3-5 is CSS

Selectors
---------

  - Data is still being gathered to make a decision on issue #2156:
      webkit-prefixed pseudo-elements are always treated valid in
      WebKit and Blink.
  - RESOLVED: Accept the proposed changes to improve grammar/clarity
              outlined here:
https://github.com/w3c/csswg-drafts/issues/386#issuecomment-354649902
  - RESOLVED: Accept the names Live & Snapshot for the selector
              performance profiles. (Issue #1694)
  - RESOLVED: Remove the descendant combinator from selectors 4 (Issue
              #641)
  - RESOLVED: Accept the proposal for :local-link with an added note
              about things that would cause a URL to change. (Issue
              #2010)
  - RESOLVED: Keep the :read-only and :read-write selectors in the
              spec and work on defining and test cases as appropriate.
              (Issue #127)
  - RESOLVED: Rename :nth-column to :nth-col (Issue #2157)

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

  - RESOLVED: Define lh unit resolution to be that of the parent when
              the lh unit is spec on line height or font size. (Issue
              #2115)
  - RESOLVED: 'normal' value of line-height will behave as strut.
              (Issue #1253)

CSS Paint
---------

  - RESOLVED: Accept proposal in https://github.com/w3c/fxtf-drafts/issues/107
              to have paint-order to affect non-SVG text.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jan/0003.html

Present:
  Rossen Atanassov
  David Baron
  Brian Birtles
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Dael Jackson
  Peter Linss
  Myles Maxfield
  Xidorn Quan
  Liam Quim
  Naina Raisinghani
  Manuel Rego
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Eric Willigers

Regrets:
  Rachel Andrew
  Angelo Cano
  Chris Lilley
  Lea Verou
  Greg Whitworth

Scribe: dael

Agenda Setting
==============

  Rossen: Let's get started.
  Rossen: We got a number of people, esp. those in Europe, sending
          regrets.
  Rossen: As usual, a call for any other agenda items or changes to
          the agenda?
  fantasai: I did have one. There's a paint-order property issue. We
            were thinking of speccing it to have it apply to HTML. If
            there's objections to that let us know. Otherwise I'll
            update the spec.
  <fantasai> Rossen, https://github.com/w3c/fxtf-drafts/issues/107
  Rossen: Let's see how we do on time. I know Dirk will join on the
          next call or after and he might have an opinion.
  Rossen: Any other topics? Especially the people whose time zone is
          favorable to them right now.

Berlin & Sydney F2F
===================

Berlin
------

  Rossen: Berlin dates are confirmed. Location and meeting room has
          been reserved and is not subject to change.
  <Rossen> https://wiki.csswg.org/planning/berlin-2018
  Rossen: For those of you that haven't booked, please go ahead and
          start booking.  Also please go ahead and add your name to
          the wiki. This will give the organizers an idea of number of
          people attending and if they'll need additional space.
  Rossen: For now as I said the meetings are confirmed.

  Rossen: One more date ask from Vlad & Typo folks is for those of you
          interested in also attending Typo please add yourself to the
          yes Typo Labs column. They have a strict amount of people
          they allow and the conference is sold out, but they will
          make an exception for CSSWG folks.
  Rossen: It's a great offer and it's free to CSSWG members. All you
          have to do is put yourself on the list.

  Rossen: Any questions on Berlin F2F?
  fantasai: There's a note on the wiki about being a part of the hotel
            room block to add your name to the wiki. What's the
            procedure for actually booking?
  Rossen: I'm re-reading Vlad's email.
  Rossen: He's working with the Typo Labs organizers to see if we can
          get in the block/discount rate. He had a brief exchange with
          them but nothing is locked. Based on # of people they'll try
          to work out whatever the discount rate will be if it's
          different then what's listed on the wiki.
  Rossen: I'll ask Vlad to post more details to the member list as
          soon as possible.
  Rossen: Does that answer your question?
  fantasai: It tells me there isn't an answer right now.
  Rossen: Not a definitive one.
  Rossen: I went to the hotel website and it does look like you can
          book for yourself for a similar rate.

Sydney
------

  Rossen: Okay, Sydney.
  Rossen: It was tentative on first week of July. That is between July
          3rd and 5th. Starting July 2 for Houdini.
  Rossen: Sydney folks can we confirm?
  nainar: Yep 100%
  Rossen: Are there any other...we have resolved on this in the past.
          At least for the date July 2 to July 5th is what's on the
          wiki.
  Rossen: If everyone is okay I propose we remove the tentative and
          make this a resolution so people can book.
  Rossen: Objections?

  RESOLVED: Mid-year Sydney F2F dates are July 2 to July 5- July 2 is
            Houdini, July 3-5 is CSS

  <nainar> I've changed the wiki page to reflect this:
           https://wiki.csswg.org/planning/sydney-2018

Selectors
=========

webkit-prefixed pseudo-elements are always treated valid in WebKit
    and Blink
------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2156

  ericwilligers: We don't have any useful statistics yet for webkit. I
                 don't think we have enough information to know how
                 often it happens.
  florian: Presumably while gathering stats if we can tell the
           difference between webkit prefix that exists vs nonsense
           with a webkit prefix. So we can see if we need a short
           whitelist or a wildcard.
  ericwilligers: I did distinguish but I don't have the data.
  <ericwilligers> Chrome bug is crbug.com/547869 The use counter was
                  added in December. We need to wait for this to reach
                  stable before we have useful stats.

  xidorn: It seems to be Chrome has some data for the unknown pseudo
          elements.
  xidorn: I think it's 0.003% of pages.
  ericwilligers: That's only people running like canary
  Rossen: Are you saying current data is only on canary which isn't
          very representative?
  ericwilligers: Yes.
  Rossen: So fair to say we need to wait a little longer for actual
          data?
  ericwilligers: Yes, before we can make a blink change.
  Rossen: Objections to moving on as the Chrome folks are collecting
          data?

Some inconsistent concepts and descriptions
-------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/386

  fantasai: Request to review some changes to selector grammar which
            are outlined in a comment.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/386#issuecomment-354649902
  fantasai: What I did was put the restriction on type selectors and
            pseudo elements into the grammar rather than just the
            prose. I wanted to check if there were concerns.
  <fantasai> * ordering thereof
  Rossen: I don't believe we, Edge, have an issue on this. I think we
          briefly discussed and it should be fine.
  Rossen: Seemed TabAtkins was also saying he's fine.
  fantasai: I believe it should make no difference to impl. If you
            don't understand a selector you have to throw it out
            whether it's ordering or not, but I wanted to check if
            it's okay to put in grammar.
  Rossen: Sounds good to me. Objections?

  RESOLVED: Accept the proposed changes outlined here:
            https://github.com/w3c/csswg-drafts/issues/386#issuecomment-354649902

More intuitive names for selector performance profiles
------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1694

  fantasai: Latest was to use live for the css profile and snapshot
            for the one shot API calls.
  fantasai: Wanted to ask if WG accepts that for if there's better
            ideas.
  florian: Sounds reasonable.
  Rossen: To me as well.

  dbaron: Do we have consensus that the snapshot profile will be used
          for things like query selector?
  fantasai: Thought it was but I'm not sure.
  Rossen: Have we discussed this? Is there an issue about it?
  fantasai: Whole point of having that profile was to do that. I'm
            pretty sure given the number of times we talked about the
            name there was consensus on having them.
  dbaron: I just remember it as a thing for selectors that print impl
          wanted.
  dbaron: impl producing pdfs, not interactive.
  florian: My memory is this was for the selectors everyone wants but
           are deemed too slow to use in normal CSS. I think we made
           it forbidden to support in pdf impl only. It needs to be
           web compat so if web can't they can't.
  dbaron: Makes sense. It just wasn't how I remembered the discussion.

  Rossen: I suggest we resolve on issue of naming. dbaron if you feel
          the snapshot part needs further discussion let's bring that
          separately.
  Rossen: In terms of naming, any objections?

  RESOLVED: Accept the names Live & Snapshot

Should the syntax for the descendant combinator still exist?
------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/641

  fantasai: We had introduced a double child selector syntax. The
            reason to do that was to a have a visually representative
            syntax for a descendant combinator but more was to bridge
            gap between child and shadow piercing descendant selector.
            Shadow piercing was removed or objected to and && syntax
            was removed. Do we want to pursue to have visible
            combinator or drop it?
  Rossen: dbaron I see you proposed the removal originally. Do you
          still favor removing?
  dbaron: I would. Introducing new syntax and dealing with compat
          isn't a thing we should spend time on without a good reason
          to do so
  Rossen: Other opinions or obj?
  <astearns> +1 for removal. It's nice but not worth it
  fantasai: What dbaron said made sense.
  Rossen: I'm also with dbaron.
  <florian> +1 especially given that selectors are fragile and don't
            fallback very well, we shouldn't add more opportunities
            for authors to shoot themselves in the foot

  RESOLVED: Remove the descendant combinator from selectors 4

Match local links
-----------------
  github: https://github.com/w3c/csswg-drafts/issues/2010

  fantasai: The proposal is summarized in leaverou's comment. It's
            common for authors to want to style the current location
            differently. They currently have to do something custom.
            Would be nice to have a selector to say this link is
            pointing to this page.
  fantasai: We previously had a local link pseudo class. We dropped
            it. leaverou's proposal is different because it also
            accounts for fragment identifiers. If it does have a
            fragment id it must match that of the URL.
  fantasai: I think it makes sense.

  dbaron: I think it needs a clear processing for what happens if the
          page's uri changes.
  <tantek> is it like :target in that regard?
  fantasai: It's a dynamic pseudo.
  dbaron: Does that cause anything interesting to happen with things
          like push state that change the url.
  fantasai: I have no idea. If it changes the uri [missed]
  tantek: That's the kind of thing :target will need to answer as well.
  <fantasai> If the current URL changes , then what :local-link
             matches changes; but :local-link can't cause the current
             URL to change.
  dbaron: I think :target isn't defined well as well. I think if this
          goes into spec it should point out existing features that
          could cause pages uri to change.
  tantek: I think that should happen regardless.
  tantek: If :target doesn't express the history state that's an issue
          regardless.
  dbaron: I remember a lack of interop with dynamic changes
          originally, I don't know about now.
  tantek: My point is it shouldn't be different then the :target impl.
  dbaron: My point is the spec should point out to implementors things
          that could cause the uri to change. If the spec designers
          don't know that they should figure it out so it gets impl
          right.
  * tantek agrees with dbarons point

  fantasai: You're asking for a note?
  dbaron: Yes.
  fantasai: Okay that's fine.
  Rossen: So the note you're referring to is?
  fantasai: Providing the information to point out all the things that
            could possibly change the URL.
  Rossen: Sounds more normative then the note.
  florian: Point is to find these spec if you're not aware of them.
  tantek: It's the kind of thing that's good as a note to start, but
          could turn into test cases. So it sounds normative-like but
          doesn't need to be.
  florian: It's a back reference to existing prose.
  tantek: An expansion to what we thing the normative thing is. Either
          way you can make test cases.
  <florian> +1 to test cases
  fantasai: You can make test cases easier because you have a list of
            what they should be.

  Rossen: So I'm hearing people are in favor of the proposal for a
          local link as spec by leaverou with the additional
          requirement as well as at the very least put a note and
          point back to :target and hope things are spec well as to
          what could cause a URL change and make the pseudo class
          invalidated.
  Rossen: Anything else to add/change on this proposal before we
          resolve?
  Rossen: Obj?

  RESOLVED: Accept the proposal with an added note.

:read-only and :read-write
--------------------------
  github: https://github.com/w3c/csswg-drafts/issues/127

  * tantek vaguely remembers this got delegated to the Editing TF?
  fantasai: Issue was filed to say they don't have a sensible
            definition or interop. FF doesn't support them. Proposal
            was to remove them. Alternative was come up with a useful
            definition that's specced.
  fantasai: Easiest is remove, but it's a question for the WG.
  Rossen: Based on Chrome 52 data seems like it's below threshold of
          what google would consider not removing.  Question to the
          chrome folks, are you willing to remove this?
  ericwilligers: If it's low I think if that's what the group pref. We
                 haven't discussed.
  Rossen: I don't want to resolve now and then someone say nope we
          won't remove. Good we took exersize to review but no action
          will follow. It's good to have more commitment before we
          resolve. If you guys aren't okay to remove from the get go
          no reason to talk.

  <fantasai> Testcase -
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%3Aread-write%2C%20body%20%7B%20background%3A%20green%3B%20%7D%0A%3Aread-only%2C%20body%20%7B%20background%3A%20green%3B%20%7D%0A%3C%2Fstyle%3E
  <fantasai> It is not supported in Firefox afaict.
  <fantasai> and parses as invalid
  <dbaron> I think Firefox supports :-moz-read-only and
           :-moz-read-write

  florian: Seems to be that the discussion isn't that it's useless but
           that it's not specced right. Maybe something saying this
           might be useful but we didn't get it right, feedback please
           in the spec.
  ericwilligers: Has anyone come up with a different spec for that?
  tantek: I think it came from a really old draft of css ui and then
          was assimilated into selectors.  I recall there was some
          type of x-forms back in the day but I don't know if that's
          used anymore. Probably fine to drop from a modern we don't
          have use cases. Esp. if the threshold is low enough.
  Rossen: Is FF only one not supporting?
  dbaron: We have support with moz prefix, but not unprefixed.
  tantek: Regarding fixing b/c it's web exposed now there's a race
          condition where if it's low enough to remove we should do so
          to avoid having an emerging compat issue while we figure out
          how it should work. Then it can proceed without pressure.
  <florian> tantek, fair enough

  ericwilligers: I think usage has gone up. It seems to be 0.4% on the
                 counter. So the thing you worried about has happened.
  <ericwilligers>
https://www.chromestatus.com/metrics/feature/timeline/popularity/1377
  Rossen: We're shipping unprefix. Chrome too. Not sure webkit. myles
          are you shipping it?
  myles: Give me a second.
  * fantasai notes testcase above
  <ericwilligers> 0.2% for read-write
https://www.chromestatus.com/metrics/feature/timeline/popularity/1378

  Rossen: While we wait. ericwilligers you're suggesting current stats
          say we can't remove?
  ericwilligers: Correct.
  Rossen: So I guess this is a moot point. That's why we wanted to
          have the willing to deprecate discussion. So the uptick in
          usage is too large to remove. So as brought by florian we
          can't remove so how do we fix them?
  Rossen: If we're not ready to discuss we can resolve this issue as
          not removing from spec and then we can work on further
          definition sep.
  Rossen: Not sure about fantasai if she's still trying to connect.
  <fantasai> sgtm

  Rossen: Objections to resolve on keeping the properties as-is based
          on usage data and work on further defining their behavior?
  myles: Our rendering is same as chrome, different then FF.
  Rossen: FF passes if you add the prefix.
  Rossen: Proposal is keep the selectors in the spec and work on
          defining and test cases as appropriate.
  Rossen: Obj?

  RESOLVED: Keep the selectors in the spec and work on defining and
            test cases as appropriate.

Rename :nth-column to :nth-col
------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2157

  fantasai: Reasoning is we have often discussed adding a pseudo
            element to select the columns and that would be ::column.
            If we do that we have the column pseudo class and ::column
            pseudo element that have nothing to do with each other.
  fantasai: We don't normally abbreviate, but HTML uses col already so
            maybe we can break the conflict.
  florian: This is impl nowhere?
  fantasai: As far as I'm aware it's not impl.
  dbaron: My worry is that it makes it sound like has something to do
          with nth col element rather then the nth column. Those
          aren't necessarily the same.
  dbaron: Tables have col elements with weird spanning mechanism.
  fantasai: Yeah. Col is also used in html syntax in other places like
            scope=col. Col element is relatively obscure. I think it's
            fairly well understood that col is a column not a column
            element.
  dbaron: I'd slightly prefer :nth-table-column but I won't hold up.
  fantasai: There are potentially other syntactic constructs, like
            there's a data grid. This can also be applied to non-html
            languages as well.

  Rossen: :nth-col will only match table columns? Or grid as well?
  fantasai: It doesn't have anything to do with styling. Just markup,
            so it has nothing to do with grid. You might have a grid
            element in your markup and if the browser decided to
            support your mark up it would work, but you'd have to have
            built in understanding of the markup language.
  fantasai: These are based on the underlying data structure.
  Rossen: Okay.
  Rossen: That's good.
  fantasai: Styling the table as all 'display inline' would have no
            effect on whether these pseudo-classes matched

  Rossen: So, I heard slight preference for table col and table
          column. dbaron is :nth-col something you can live with?
  dbaron: Yeah.
  Rossen: Obj?
  <florian> go for it

  RESOLVED: Rename :nth-column to :nth-col

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

Cyclic definitions with relative units
--------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2115

  florian: There's already a bit of prose that says if you try to use
           the em units in font size property or any unit that depends
           on font size in the font size property we say you fetch
           from the parent to avoid a loop.
  florian: There was a poorly worded way to attach this to lh when
           defining line height. The mis-phrased part meant we still
           have a problem if trying to do line height in terms of font
           size.
  florian: What I tried to do is say all font dependent units go to
           the parent and in addition lh also goes to the parent if
           you use it in line height. That breaks the loops.
  florian: We could have a less blunt approach, but I don't think
           there's use cases for the more subtle variants.
  florian: Precise wording is in the issue.
  fantasai: Works for me.
  myles: I agree we shouldn't be in the business of trying to do a
         complex dependency analysis.
  Rossen: I'm waiting for others to have a moment to consider.
  dbaron: The proposal is that lh goes to the parent if used in font
          size or line height.
  florian: Yes.
  dbaron: Okay.

  ericwilligers: Other things like height?
  florian: No, there's no loop.
  ericwilligers: I know there's no loop, but seems confusing if lh
                 appears 5 times and means 5 different things.
  ??: we have that with ems
  ericwilligers: Don't want to make it worse.
  florian: We need to keep other cases working because that's the
           point of the lh unit. Only sensible option would be to ban
           it from line height.
  Rossen: But for the same reason we should have banned em from font.
  florian: And we didn't
  Rossen: And I think anyone that used em in fonts understands how
          they did it.

  Rossen: So, objections to define lh unit resolution to be that of
          the parent when the lh unit is spec on line height or font
          size?
  <myles> +1
  <dbaron> The cases that go to the parent here are probably cases
           that can be safely recommended against.

  RESOLVED: Define lh unit resolution to be that of the parent when
            the lh unit is spec on line height or font size

  dbaron: Should the spec have a not saying we suggest not using that
          behavior? Suggest it's poor practice to use it that way.
  myles: Is there one for em?
  dbaron: I don't think so.
  florian: If we had a plh unit I would say it is, but since we don't
           I'm not sure it's bad practice.
  Rossen: I'm fine with either note or no note. If dbaron you feel
          it's really necessary?
  dbaron: I don't. It's just a thought.

'lh' and 'rlh' unit need to explain how to convert to an absolute
    length
-----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1253

  florian: We used to say they need to convert to absolute height. Was
           ambiguous. We fixed that. Now it's not ambiguous. There's
           not question how they should work for values other then
           normal. For normal we need to say something. I suggest
           strut.
  <fantasai> +1 to Florian's proposal
  florian: Reasonable?
  Rossen: Yes to me.
  dbaron: Behavior as strut sounds good to me.

  RESOLVED: Behave as strut.

CSS Paint
=========

Add paint-order property
------------------------
  Github: https://github.com/w3c/fxtf-drafts/issues/107

  fantasai: We have a spec to apply fill & stroke from SVG to text in
            html and css style doc. It was a question of also applying
            paint-order property.
  fantasai: Makes sense to me it should apply.
  Rossen: Makes sense to me.
  Rossen: Okay
  fantasai: If there's no objections we should go ahead.
  Rossen: I don't have any objections from Edge PoV
  Rossen: Objections?

  RESOLVED: Accept proposal in https://github.com/w3c/fxtf-drafts/issues/107
            to have paint-order to affect non-SVG text.

  Rossen: florian we can do overflow first thing next week. Is that
          okay?
  florian: Sure.
  Rossen: Quick reminder to add yourself to Berlin wiki if you haven't
          done so. Also give an indication as to if you want to attend
          typo labs. With that we're done. Thanks for calling in!

Received on Thursday, 4 January 2018 02:34:24 UTC