[CSSWG] Minutes Telecon 2017-05-17 [css-writing-modes] [css-cascade] [css-pseudo] [mediaqueries-4] [selectors3] [css-scroll-snap] [css-overflow]

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

Spec Rec

  - RESOLVED: Request PR for Writing Modes.

How does 'inherit' keyword behave in a child of ::first-line?

  - Those who had done a review generally thought the proposal
      sounded sane, but conversation will continue on github to
      handle specifics and get more opinions.

Media Queries 4

  - RESOLVED: Close https://github.com/w3c/csswg-drafts/issues/841
              no change.
  - RESOLVED: Mark the various hover and pointer things as at-risk.
  - RESOLVED: Push scripting MQ values to L5.
  - RESOLVED: New WD of MQ4.

Better terminology for ~ sibling combinator?

  - RESOLVED: Change the title to subsequent. (In reference to
              better terminology for ~ sibling combinator:
              https://github.com/w3c/csswg-drafts/issues/1382 )
  - RESOLVED: Request PR on Selectors 3.

Scroll Snap

  - RESOLVED: Accept the spec text proposed in
  - There will be a request for publication next week.

FPWD for level 4 CSS Overflow

  - RESOLVED: FPWD of Overflow 4


Agenda: https://lists.w3.org/Archives/Public/www-style/2017May/0031.html

  Rossen Atanassov
  Tab Atkins
  Tantek Çelik
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brad Kemper
  Myles Maxfield
  Michael Miller
  Anton Prowse
  Liam Quin
  Matt Rakow
  Melanie Richards
  Florian Rivoal
  Geoffrey Sneddon
  Alan Stearns
  Greg Whitworth

  Rachel Andrew
  David Baron
  Dave Cramer
  Bert Bos
  Robert Flack
  Daniel Glazman
  Chris Lilley
  Jen Simmons
  Lea Verou

Scribe: dael

  astearns: Let's get started.
  astearns: Any extra items?

Spec Rec

  astearns: Writing modes.
  astearns: I think we're ready for PR.
  astearns: One of the last edits went in. Only thing I'm aware of
            is to fix a URL which is publishing a document to be at
            a URL I think.
  astearns: We don't have Bert or Chris on the call. I do see liam.
  astearns: Do we need to do anything else before PR?
  Florian: Is change section up to date & DoC and everything.
  astearns: Changes has everything. DoC is up to date. We've
            responded to all comments. We have impl report.
  liam: Have we met the exit criteria?
  astearns: Yes. Impl report shows we have enough passing tests and
            explains where things aren't working.
  astearns: All changes since last CR was editorial.
  astearns: As I understand we don't need another CR.
  liam: Dropped features were at risk?
  astearns: Yes, and mentioned in changes.
  liam: Then we just need a record of a request of PR.
  astearns: Objections to asking for PR transition for writing modes?

  RESOLVED: Request PR for writing modes

  <Rossen> Congrats!!
  <dauwhe> hooray!
  astearns: liam can you handle this?
  liam: Officially it'll have to be Bert or ChrisL.
  astearns: Great. I'll ask which of them can handle it since they
            couldn't be on the call.

  astearns: Fonts.
  astearns: myles is there an update on tests?
  myles: I reviewed them. Chris did pull to get them in.
  gsnedders: There's a new pull request.
  myles: I reviewed 2 yesterday. There's one from today I haven't
         looked at.
  astearns: Sounds like progress is being made.

  astearns: Only last is I'll add 2.1 to the things being tracked.
  astearns: Next thing we need on 2.1 is Bert to make some edits.

How does 'inherit' keyword behave in a child of ::first-line?
  github topic:

  fremy: We added this last week and people needed more time to
  fremy: Did people review?
  Florian: I did not.
  astearns: Looks like you added the summary which is great.
  astearns: Is it just Florian that needs to look?
  <TabAtkins> I haven't reviewed it, but now that Elika and I have
              thought more about ::first-line this week, we should
              be able to understand it better now.
  Florian: I don't think so. Reason I need to look is to see if it
           will scale to similar pseudos. That's forward looking.
           For now someone else needs to check.

  fantasai: I think...I was looking at proposal with that in mind.
            There's parts to the proposal.
  fantasai: The part that says if you inherit non-inherited you go
            directly to parent is fine.
  fantasai: There was some discussion I didn't follow about how
            ::first-line is text inside a span inside a
            ::first-line...it didn't make sense. Text inside a span
            should inherit from a span and text inside a
            ::first-line inherits from ::first-line.
  fantasai: There was something about how a styled ::first-line
            should act like the ::first-line isn't there.
  fantasai: There were three variants we need to preserve for things
            to work in the same way.
  fantasai: One part of proposal was about variables and I don't
            have a strong opinion on that. There was concern about
            setting display via a variable but has same problem if
            you set not via a variable
  fantasai: I'm not sure variable behavior in there is necessarily
            what we want, but at this point in time it doesn't much
            matter. It's a question for as we extend in the future.
            We might want variables to work more like normal
            inherited then.
  fremy: Reason we didn't want variables to work is because
         ::first-line is more special then fragment. There is
         condition that you need to be inline to be ::first-line. We
         didn't want to spend too much time figuring this out.

  Florian: From birds eye view it seemed sane. I didn't review
  fantasai: I suggest we go one by one for the proposal.
  astearns: Do we want to continue on GH?
  fantasai: I'm okay either way. I want dbaron's opinion on this.
  astearns: And dbaron can't be on so I suggest...this transcript
            will go into the issue. We can refine in GH and resolve
            next week.
  fantasai: Sounds good.
  astearns: fremy?
  fremy: Yes. It just should be done at some point.
  astearns: Yeah. There's a few things to hammer out. Getting dbaron
            next week. Please @ him on the issue if he's not there.
  fremy: He's in the issue.

Media Queries 4

any-hover can't be used to detect mixed hover and non-hover capable
  github topic: https://github.com/w3c/csswg-drafts/issues/841

  <Florian> https://drafts.csswg.org/mediaqueries-4/#any-input
  Florian: We have two pairs of media features. hover/any-hover and
  Florian: hover and pointed describe the primary way for
  Florian: The any variant are for additional peripherals.
  Florian: pointer can tell if things point accurately, hover is can
           it hover. Generally you should design without relying on
           hover or accurate point, but if you can detect that it's
           supported feel free to take advantage. Any is for if you
           have a bit more granularity.
  Florian: Issue being raised is there are scenarios this can't
           detect. Example, primary is a mouse but a non-primary
           can't hover and you can't detect that.
  <tantek> e.g. laptop with touch screen
  Florian: I agree that there are non-detectable cases. I disagree
           it's useful. If you know there is a thing that cannot
           hover, what do you style differently?
  Florian: The other argument to not do this is to do this we either
           make hover:none and hover media feature be able to exist
           at the same time.
  Florian: I think there's down sides to make it work and I still
           can't see how you would use it. But the person who raised
           it feels it's useful.
  <tantek> yeah I tend to agree with the problem the issue is

  fantasai: For hover/no hover proposal....
  fantasai: I was thinking if you had hover, no hover, and none...if
            the things that would possibly have hover if all are
            no-hover then you have none.
  Florian: So if you just query hover media feature it's supposed to
           be true. If one of the values other then none are
           true...you're saying no hover is true only if there's a
           no hover thing in addition to hover thing and if there's
           never a hover thing you query through none?
  fantasai: Through hover we only query primary, right?
  Florian: Yes. Question is on any-hover.
  Florian: When you have a set where some can hover you want to
           detect that some can and some can't.
  fantasai: Then any-hover would be true. any hover no hover would
            be true.
  fantasai: But any-hover:hover is false therefore hover:none is
  Florian: If we only do it the way it currently works we don't have
           to worry about if something is an input. If it can hover
           it clearly is one and if it can't it doesn't matter. If
           we do this we need to classify things that can hover and
           are a media device vs aren't a media device. We have to
           classify all sorts of fuzzy things.
  Florian: If we exclude keyboards it's kind of bad. If we include
           them the MQ will almost always return that you have a
           thing that can't hover.
  Florian: Overall I think we can tweak to try and expose, but any
           way is complicated and I don't see how the author would
           use this.

  fremy: I think I agree with you. I think we can fix it I don't see
         a strong use case and I would be fine resolving we don't
         need to fix.

  tantek: It's pointless to talk about devices that can never hover
          as causing exceptions. I would assume author is thinking
          about can the pointing device support hovering. I don't
          think if authors are considering this also has a keyboard.
  Florian: In general, yes. Quoted use case was if you know among
           the ways a user can interact there is one that cannot
           hover you shouldn't make any part of UI to hover.
  tantek: That's impractical. Every device with hover has a keyboard
          since hover was created. I disagree with that statement.
          Authors have known for a long time there's an input
          modality that doesn't support hover.
  <liam> [+1 to Tantek here]
  tantek: Existence of some other input modality should not impact
          authoring decisions about using hover.
  Florian: I think I agree. Where I'm disagreeing with commenter is
           if we were to take presence of things that can't hover,
           not taking keyboard would be weird.
  tantek: The presence of pointing things, not the presence of
  <tantek> "presence of things that can't hover" is not useful
  <fantasai> A pointing device is one that can spit out x y coords.
             Keyboards can't do that in general (unless you've made
             them control the cursor somehow)
  Florian: How is the presence of things that can point and not
           hover more useful? That's the point I don't get.
  tantek: This has nothing to do with things that can never hover.
          This is pointing inputs that can't or can't hover.

  astearns: One of the confusion points is in the comment Patrick
            talks about input devices, but clarifies that he's only
            talking about pointing devices.
  tantek: That's my understanding.
  fremy: What can you do differently as an author if you know
         there's a device that cannot hover.
  fremy: Every windows laptop has a touch screen. What would you do
  Florian: Maybe you may want to do something special for touch
           screen + touch pad, but the MQ wouldn't tell you that. It
           would just say there's something that cannot hover. You
           don't know what it is, just know it can't hover and it's
           not the main thing the user uses.
  liam: If you know the user has something that doesn't hover you
        can't rely on every press having hover pre-light.
  Florian: It's not primary way. We'd have an answer on the main way
           the user interacts.
  liam: Sure, but doesn't matter if it's primary. The user could use
        it. It's saying something useful.
  <MaRakow> +1 to feature not seeming useful

  <tantek> has anyone prototyped any of these?
  <tantek> IMO this is a good example of a feature that really ought
           to be incubated (prototyped) before we seriously consider
  <tantek> I really don't want to see browsers waste time
           implementing a feature that just makes things worse /
           more confusing for authors / users

  astearns: Even though the main device is hover capable, the
            presence of other non-hover modality makes it a better
            idea not to rely. Patrick points out he's happy with it
            saying try not to use hover with examples where there
            could be problems.
  astearns: Sounds to me like using hover affordances is usually a
            bad idea. Patrick is okay with the amount of warnings.
            I'm not hearing a huge push to add additional capability
            for these worse scenarios beyond what we have. Is that
  tantek: I'd agree.
  Florian: I'm trying to find that section. He's happy with that in
           addition to what he suggests.
  astearns: [reads last comment in issue]

  astearns: Given we don't have enthusiasm for designing a new way
            of detecting less hover capable devices, I'd be happy to
            close as-is and leaving open that we might design
            something in the future that has the additional case,
            but it should be prototyped. There should be an idea of
            the use cases and showing why it will be useful.
  tantek: Does that mean leave the feature in?
  Florian: any-hover is in the draft and it can take hover or none.
           You can detect if nothing is hover capable, but you can't
           detect a mix. We're leaving that as-is.
  <fantasai> Sounds good to me. We can extend in the direction I
             outlined later, too, if we want. :)
  astearns: And I understand the draft does have warnings that even
            if the MQ says something is hover capable you may not
            want to use hover affordances.

  tantek: Has anyone impl?
  Florian: I think pointer and hover are in Chrome. Maybe just
  TabAtkins: I think we do both, but not 100% certain.
  Florian: can i use says both on Chrome, edge & safari
  <tantek> well if we has so many impls, seems like we should be
           able to try it out with examples?

  astearns: Proposal is leave in draft and close no change.

  RESOLVED: Close https://github.com/w3c/csswg-drafts/issues/841 no

Rename 'scripting: enabled'

  Florian: I just noticed there's one issue on MQ DoC. Other then
           that we should do a new draft.
  <tantek> yes I'd like to see a new WD published please
  Florian: Last issue is fantasai saying scripting-enabled should be
           called something else.
  <Florian> https://drafts.csswg.org/mediaqueries-4/issues-wd-2016-01-26.html#issue-4
  Florian: fantasai do you remember what you wanted this to be
  Florian: We discussed, but never concluded. Are you happy with
           scripting: enabled | none?
  fantasai: I think that's fine.

  tantek: I think you're missing a massive use case, headless script
  Florian: That level of granularity was pushed to another level.
  tantek: Yeah, okay.
  astearns: Sounds like there's agreement.
  Florian: Can we resolve current naming is okay?

  fantasai: Enabled means if there's any scripting at all it's true,
            even if only runs first 10ms?
  Florian: Yes. There is scripting support. No fine grained
           knowledge of what.
  fantasai: Is that clear in description?
  <Florian> https://drafts.csswg.org/mediaqueries-4/#scripting
  Florian: [reads]
  fantasai: That's not sufficiently clear
  astearns: [reads more]
  fantasai: That's a different question. This is going to flip on
            for things that run until onload event.
  fantasai: An author won't think about those things. If they
            trigger enabled that needs to be super clear. This
            script may or may not run, this may only run for first
            few ms. It needs to be clearly spec what triggers it for
            both impl and developers. THat enabled doesn't mean you
            have event support.
  Florian: Just because we marked it as at-risk and removed
           something doesn't mean what we left behind makes sense.
  ACTION Florian clarify the scripting section as per fantasai
         description in minutes.
  <trackbot> Created ACTION-851

  Florian: Did we resolve name is fine?
  tantek: I'm curious if having this feature is worth it in level.
  Florian: You'd like to push to sort out variants together?
  tantek: That's what I'm hearing from the conversation that it may
          be needed.
  Florian: I think it's a good idea. Enabled value needs to mean a
           different thing depending on if loading should exist.
  astearns: Is there a value in none even though non-none doesn't
            work as expected?
  fantasai: Depends on what you're doing. If you're depending on
            event support you want to get none. But if you're
            depending on if this script will run then it's not
  fantasai: I agree with tantek that it's good to have this together
            in a level
  tantek: What people impl today in none in the static loaded
          website. I don't think we need another mechanism for only
  Florian: I'm happy to push it all to L5.
  Florian: Especially since that's the last issue on L4 and we can
           do a last WD.
  astearns: Objections to pushing scripting to next L of MQ?

  RESOLVED: Pushing scripting MQ values to L5

  astearns: Objections to new WD of MQ4?
  <fantasai> go for it
  <tantek> +1 new WD MQ4

  RESOLVED: new WD of MQ4

  astearns: That will go for wide review.
  <tantek> btw on previous issue, have we marked any-pointer
           any-hover at-risk?
  <tantek> or are we not doing so because of impls?
  Florian: tantek I don't think we need at risk b/c they're
  tantek: Are they impl the way we want them to be? We don't want to
          codify something that would create bad authoring or
  Florian: Agree. It's the part of the spec I'm least convinced we
           did right. If you want to at risk it now that's fine.
  tantek: And that communicates to Patrick we hear your concern and
          we're making as at risk to keep looking at it.
  Florian: Fair.

  Florian: Do you want any-* as at risk or also pointer and hover.
  tantek: I don't know how to separate.
  Florian: I'm okay with that.
  tantek: And I think that would support more input from Patrick.
  astearns: Do we need a resolution or is that editorial?
  Florian: Resolution, please.
  astearns: Objections to marking the various hover and pointer
            things as at-risk?

  RESOLVED: Mark the various hover and pointer things as at-risk.

Better terminology for ~ sibling combinator?
  github topic: https://github.com/w3c/csswg-drafts/issues/1382

  astearns: Can we do this without dbaron?
  fantasai: So far best suggestion to switch following with
            subsequent or any-following-sibling
  astearns: any-following-sibling is easier to spell.
  fantasai: You'll never type this in code.
  astearns: True.
  fantasai: dbaron was okay with subsequent.
  astearns: Since he did the issue, I'm okay with it as well.
  astearns: Objections?

  RESOLVED: Change the title to subsequent.

  fantasai: There was a substantive change that Chris pointed out.
  fantasai: [missed]
  fantasai: We do have the tests and the passes and the impl report
            is a test that tests all the things.
  astearns: Everything in the spec, or just this change?
  fantasai: Just this change.
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5188
  fantasai: test^
  fantasai: If you do the right thing it passes.
  <fantasai> passes in Chrome and Firefox

  astearns: Sounds like we should put that change in, get the tiny
            impl report, and ask for PR.
  fantasai: I think impl would be a link to this test case and
            statement FF and Chrome pass.
  astearns: There's a thread on this for the private list we can
            propose inlining and ask ChrisL. I suspect we'll have to
            say what browsers don't pass.
  astearns: Objections to asking for PR on this edited REC with this
            one change.

  RESOLVED: Request PR on this spec.

Scroll Snap
  github topic: https://github.com/w3c/csswg-drafts/issues/1084

  astearns: Looking for WG approval for this change.
  astearns: Objections?

  RESOLVED: Accept the spec text proposed in

  astearns: This was CR before, we're republishing CR. We have a
            good changes section?
  <fantasai> "https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+label%3Acss-scroll-snap-1
  fantasai: Here's issues ^
  astearns: DoC?
  fantasai: I think this should do, but I can use the link to the GH.
  fantasai: I do need to update changes section.
  astearns: Why don't you update the changes section and we'll put
            the publication next week.

FPWD for level 4 CSS Overflow
  github topic: https://github.com/w3c/csswg-drafts/issues/1374

  astearns: Is it correct that everything in 4 way already in 3?
  Florian: Correct. No new features.
  astearns: Any objections to FPWD of Overflow 4?

  RESOLVED: FPWD of Overflow 4

  Florian: I'll also make sure any L3 edits are reflected in L4.
  fantasai: I'd recommend just dropping those sections.
  Florian: That's better.

  astearns: We don't have time for the last item, so we'll end a
            minute early.
  astearns: Thanks everybody.

Received on Thursday, 18 May 2017 00:13:44 UTC