W3C home > Mailing lists > Public > www-style@w3.org > July 2015

[CSSWG] Minutes Telecon 2015-07-22

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 23 Jul 2015 07:51:14 -0400
Message-ID: <CADhPm3u-1wm=gMRk3EMyWgDtX4gr-kRu8NVkykrB7tbGxjDP-Q@mail.gmail.com>
To: www-style@w3.org
CSS Cascade 4 Publication
--------------------------

  - RESOLVED: Publish new WD for CSS Cascade Level 4

Selectors 4 Update
------------------

  - The group discussed a the e-mail from fantasai regarding what
      portions of Selectors 4 should be deferred or discussed as
      Selectors 4 is prepared to move to CR
      - The entire group received an action to read and respond to
          the entire e-mail
  - Most of the conversation centered around :has()
      - There is some disagreement about how :has() should work and
          there are no implementations to date and therefore it was
          suggested that :has() shouldn't be in CR.
          - It was agreed to put it at-risk for now with a note
              indicating what the disagreement is.
      - There was a feeling that :has() has been discussed so many
          times and that developers want has so much that just
          deferring it to the next level would reflect poorly on the
          group.
          - It was expressed that if :has() is dropped or deferred
              the group needed to publicly post an explanation in
              order to help the community that is so excited to
              understand the process of the decision.
          - In the meantime, several people will post and talk about
              :has()'s at-risk status in order to encourage the
              community to push for implementation if they really
              care about having it.
  - The draft still needs an updated WD publication, but fantasai
      expressed that she needed more time to do a through review of
      the spec.
      - There is a hope that the publication will be ready for
          voting next week.

CSS 2015 prose and prefixing policy
-----------------------------------

  - There was a desire to have more time to read the small details
      of the proposed text before any resolutions.
  - Some browser vendors expressed concern about the language aimed
      at limiting prefixing was imprecise and perhaps too harsh,
      though no one was disagreeing about trying to limit prefixing.
  - RESOLVED: add Florian as an editor to the snapshot
  - RESOLVED: add TabAtkins as an editor to the snapshot

CSS Break
---------

  - fantasai's proposal to drop cloned margins at any break seemed
      to be right to everyone, but the topic will wait a week for
      people to review the exact wording and look at examples.

user-select: none
-----------------

  - RESOLVED: user-select: none is a useful feature and we won't
              drop it.

===== Full Minutes Below ======

Present:
  Tab Atkins
  David Baron
  Bert Bos
  Adenilson Cavalcanti
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Philippe Le Hégaret
  Michael Miller
  Shinyu Murakami
  Edward O'Connor
  Anton Prowse
  Florian Rivoal
  Simon Sapin
  Alan Stearns

Regrets:
  Rossen Atanassov
  Sanja Bonic
  Chris Lilley
  Peter Linss
  Hyojin Song
  Lea Verou

  Scribe: dael

  glazou: Let's start
  glazou: We have a few additions to the agenda. There was a message
          from fantasai, I think a few hours ago, clarifying the two
          additions.
  glazou: We're adding CSS cascade and selectors 4 to the agenda.
  glazou: She'd also like to remove one item that's answered and one
          that's F2F. Anything else?
  Florian: Just a clarification, the two items that are if I sent a
           mail, I haven't.

CSS Cascade 4 Publication
--------------------------

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JulSep/0035.html
  fantasai: We had one outstanding issue on level 4 which was to
            rename default, we picked revert. I'm proposing a new WD
            and treat it as a LC. There's no more issues and only 2
            additions from level 3. revert and support syntax for
            @import.
  fantasai: If there's no comments between publication and the F2F
            we can go to CR.
  <glazou> +1 for a new WD
  <plh> +1 for new WD
  <bkardell> +1
  <Florian> +1
  glazou: I'm in favor. comments?
  <astearns> +1
  plh: Question from me. Oh, wait. Mine is for selectors.
  * plh :)
  glazou: Other comments?
  glazou: Objections?

  RESOLVED: Publish new WD for CSS Cascade Level 4

Selectors 4 Update
------------------

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0296.html
  glazou: plh sent a message about a new WD for selectors 4 because
          the one of TR is large and the time is too long.
  glazou: fantasai posted a proposal for features to keep and to
          defer/drop
  glazou: There was a proposal about deferring :has() to level 5
          that had a lot of conversation on the mailing list.
  * bkardell wonders if glazou will recount the thrust of his
             comments on thread?
  <glazou> bkardell: I could, yes

  plh: I said that because the DOM spec was linked to Selectors 4. I
       was also wondering about the stability of the path.
  plh: For the purpose of defining query-selector and query-selector
       all how to deal with scoped elements we don't use a :scope
       selector, but we do talk about scope selection so I was
       wondering if those parts are stable or nowhere near stable
       and will move to 5 for example.
  fantasai: Is there anything specific you needed to keep that
            wasn't on my list?
  plh: We didn't talk about the parsing of selectors. Is that kept?
  fantasai: Yes. All the other stuff will be kept. We'll keep
            everything that wasn't on the defer list.
  plh: And the scoped selector?
  fantasai: Absolutely.

  glazou: For the people that missed it on the mailing list, I would
          like to repeat what I said about :has()
  glazou: The proposal from fantasai is to defer to level 5. The
          proposal for this feature is >15 years old. We've put it
          in documents several times and we've been advertising it
          for years and we've been so vocal that web authors are
          demanding it. Deferring now would give a bad picture of
          the working group.
  <gregwhitworth> I haven't been here for 15 years, can someone
                  summarize why its sat for 15 years?
  glazou: It's a question of the image of this WG. In the past we
          had a bad image because we couldn't deliver. I'm afraid
          deferring :has() will give us that image. We have to
          deliver or say we can't and drop it.
  TabAtkins: It's not any different status than yesterday. We're
             dropping out the parts that aren't stable so we can
             push to CR. We're not doing anything different with
             :has() than we were doing yesterday.

  glazou: To answer gregwhitworth's question, its been on and off
          for 15 years because [missed] It was at risk and then
          people proposed again and its just been a cycle.
  gregwhitworth: So it's not implementation complexity?
  glazou: No, the initial refusal was implementation complexity.
          That's why I'm saying in the ML that the current argument
          to refuse it is the same as 15 years ago and if we can't
          implement we have to drop it. It's not fair to let web
          authors expect this if we can't do it.
  <dbaron> This is what happens when the reaction to "not sure if we
           can implement it" is "well, let's put it in the spec and
           see what happens".
  <glazou> dbaron: absolutely
  <tantek> I thought it was "let's put it in the spec for broader
           review / feedback"

  bkardell: Two things. First is going into a little bit more of the
            history of this. To do it in CSS as originally proposed-
            it's really difficult. We have ideas, but they will take
            a long time. Conceptually it's plain as day you want
            that feature. But it is really hard and that's what kept
            it out. In the meantime we've come up with qsa and
            variants that let you do this in JS.
  bkardell: Query has had :has() and people have been clamoring for
            it more. Because it's conceptually obvious that people
            want this, this has been a long running thing. Any time
            it's mentioned people get excited. Doing it in the
            static profile isn't very complex. It's a couple of days
            work by an impl.
  bkardell: That was hard fight to get that far. My second point: I
            feel like it sends bad messages to authors. Dropping, I
            mean, deferring it seems to send subtle signals. If it's
            in level 5 people think it's not as important.
  <tantek> just mark it at risk and let's move on

  TabAtkins: It can't be in the CR because it's not stable. It's
             either dropped or in level 5.
  <tantek> how is it not well defined?!?
  <tantek> what are the open issues on :has() ?
  fantasai: We're going to CR. That doesn't mean every feature has
            to be completely implemented. If everyone says they will
            implement and don't expect issues, we can keep it in the
            draft.
  fantasai: What concerns me more about :has(), there have been
            discussions about having different syntax from query or
            something like that. As long as that's not resolved the
            feature isn't stable. If the discussion about what we're
            going to do isn't final we have a consistency problem.
  fantasai: I would like for us to work through the issues before
            :has() is in CR. If we want to leave it for now and drop
            it if we can't work through the issues before everything
            else is done that's fine.
  fantasai: :has() hasn't existed in a CSS draft before it was in
            JQuery

  glazou: I proposed on the ML to keep working on :has() until the
          Aug F2F and make a decision at that time.
  fantasai: That's possible, but it depends on the rate of
            discussion on the ML.
  fantasai: The other features in the draft that we want to keep, if
            we remove everything else that's unstable, publish with
            :has() and then work on all the open issues, as it
            happens we can discuss has and we can decide to drop at
            CR transition. We can leave a note saying that if the
            issues aren't resolved we'll drop at CR transition.
  fantasai: There is still some refining for the rest of the draft
            anyways.
  <bkardell> +1 to that plan
  glazou: I prefer that plan, I think.
  <tantek> I am for keeping more features in CR and labeling them
           at-risk, especially if *anyone* has expressed
           implementation interest.

  Florian: Agreeing with something fantasai said earlier, as to if
           something without implementation can go to CR depends on
           the issues. In the list of things to defer to level 5 I
           think there are things to keep. :focus-within has a
           reasonable chance of implementation soon and it's
           straight forward enough to keep at-risk. I think there
           are more things like :read-only. I don't think we'll
           change and we might implement soon.
  <tantek> Thus I support Florian's proposal to keep :focus-within,
           and general criteria.
  Florian: That's the criteria I'd apply here.
  plh: +1 to what Florian said. We can keep it at-risk and push to
       CR sooner because we can still drop.
  <tantek> putting things into CR is a way to iron out issues too -
           because some issues are only ironed out when
           implementations try to build it!

  fantasai: A lot of the things on this list were because they had
            open issues or we're not sure because we didn't have
            enough feedback to know if the issues had a chance to be
            ironed out.
  fantasai: If people have thoughts on any individual thing I'd like
            them to reply and talk about it.

  <bkardell> the static profile is actually a compromise between the
             two (authors and vendors)

  ACTION everyone to review this document and make comments.

  glazou: Both bkardell and I made a comment about the image of the
          WG. If we do decide to drop :has() I'd like to work with
          plh to craft a blog as to why we decided to drop it.
  plh: Sure, I agree with you. I wasn't a part of the debate before,
       but one of the comments W3C hears a lot is that we're not
       listening to devs enough. Devs want :has() and we're not
       getting implementations of this. I don't know why there's
       such discrepancy.
  tantek: So that's why we should not drop :has() from CR. Since
          there is high demand the right answer is don't politically
          drop it, leave it in CR at-risk and put up a proactive
          blog post saying that it's at-risk because there's 0
          implementations and if you want this feature you need to
          go rally your favorite browser and push the community to
          push the implementors and that the WG is a conduit to the
          communication. If the community cares they can rally for
          it.
  tantek: Then the browser vendors prioritize and it's hard or they
          don't prioritize and explain why.
  <bkardell> +1 to tantek's comment
  <bkardell> well said
  <Florian> +1 to tantek, IF we are sure that it is specified the
            way we want it
  <glazou> +1 too
  fantasai: I'd 100% agree with you if the reason not to include it
            in CR is implementation issues. The reason I'd drop if
            we were going to CR tomorrow, it's that there are issues
            as to if the impl even want to go in that direction.
            It's not like we have a feature and they're proposing to
            add a different feature, it's also about what about
            doing it this way instead and that's an open issue about
            the design of the feature.
  tantek: If it is documented as an open issue, that should be
          documented in a blog post today. :has() might not make it
          because there's open issues and if you care help us
          resolve it.

  glazou: I'm hearing a majority that doesn't want to drop :has().
          Second, we need some time to work on this and push on
          implementors or devs. It's another signal saying lets give
          us a few weeks and publish a CR with better feedback. We
          have a F2F in Aug and that's the time to do this.
  tantek: If we agree to decide in Aug, anyone blogging now should
          point out that timeline to the community. Say 'hey we're
          going to make a call at this meeting and you need to give
          feedback before that'.
  glazou: I'll use my superpower of chairmanship to publish that on
          my blog and draw that attention.
  <gregwhitworth> just made a MS Edge uservoice:

https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8977591--has
  plh: I believe you have all the rights to publish on the W3C blog
       too if that helps.
  <bkardell> https://twitter.com/briankardell/status/623892832953200641

  plh: I'm happy with the plan, but in the meantime can we update
       the WD in /tr? I'm not asking for CR- just updating the
       issues draft and publish it in CR.
  <tantek> +1 updated WD
  <tantek> is Selectors still using the old pub system?
  fantasai: The next publication will be a WD and we'd rather do it
            soon, but I need to go through the draft. Before we
            publish I want to make sure everything is correct. I
            think we might want to defer non-controversial things so
            there's less to review. We'll keep :has() in the next
            WD, but I'd like us to go through some of the other
            items.
  plh: If you can do it in the week that would be nice. The draft in
       tr is just too old. The sooner we can update the better.
  fantasai: A week isn't reasonable because it takes a week to
            publish and I have to review. Maybe 2 weeks.
  plh: I was asking you to give a +1 to publish next week.
  fantasai: If I go through the entire document and there's nothing
            that needs fixing we can resolve to publish next week. I
            likely will have a bunch of issues and have to push it
            off.

  tantek: What's the delay with another WD?
  fantasai: I don't know of anyone else that was reviewed the
            changes in this WD over the last years. I'd like someone
            to review it to make sure that nothing has been dropped.
  glazou: Publishing the WD is a call for the review.
  fantasai: I'm an editor and either we can remove me as an editor
            or we can wait until I review.

  dbaron: A bunch of what's in here hasn't been discussed in the
          group. It's stuff where there was a ML post and it got
          into the draft.
  glazou: Yes. It's sometimes more of an idea sink. That's why the
          list from fantasai has almost a dozen features to drop.
  fantasai: The list in the draft are ones that have been discussed
            in the WG.

  tantek: The right criteria for TR is if it's better than the last.
          I find it hard to believe that publishing this wouldn't be
          better than having a draft that's 2 years old. However I
          sympathize with fantasai's concerns about not having
          reviewed as a co-editor. Can you consider what's the
          minimum level of review you need to publish? I understand
          wanting to be thorough, but I think we need to update.
  fantasai: If I review I'm going to be thorough. The changes that
            need review are detailed.
  tantek: Okay, fair.
  <dbaron> I'd want section 3.2 either removed or rewritten if we're
           going to publish on TR.
  <TabAtkins> dbaron: The thread on 3.2 died off waiting for a
              response from you, iirc
  <dbaron> TabAtkins, there's one message from you in the thread, to
           which I replied

CSS 2015 prose and prefixing policy
-----------------------------------

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0261.html
  glazou: So fantasai and Florian requested review.
  Florian: It was fantasai and TabAtkins, but I was a part of
           writing an older draft. I have reviewed the latest and it
           matches my memory, but I didn't review enough to speak on
           details so I'd like another week. High level, though,
           it's good to me.

  Bert: I like it overall. It's a bit vague in some places, but I'm
        not sure that can be helped. It mentioned browser instead of
        UA and I'm wondering if that could be a problem for the
        features that are only done by UA.
  Florian: There's a difference between things exposed to the web
           and things that aren't. So if we define browser as
           something exposed to the web...we need to clarify, but we
           need to clarify the difference between exposed to web and
           not.
  glazou: A batch processor prints something without a dynamic
          environment.
  Florian: It should be a browser.
  glazou: It's going to be tricky.
  Florian: That's why I want a week.

  hober: The blog post write-up I think makes assumptions about how
         browsers are shipped that aren't necessarily true.
  hober: I think we shouldn't as a WG impose specific release
         strategy on browsers. In section B there's a line that says
         "experimental features ship only in non-release builds"
         which assumes there's a thing as a non-release build and I
         don't think we should demand that.
  TabAtkins: It's an implicit case.
  hober: Where do you ship experimental features?
  fantasai: You don't. You're not allowed.
  Florian: You could tweek the wording to allow a flag. Taking one
           step back I remember what you said and when trying to
           word that I remember that the general way to do it didn't
           match with Apple and it was generally a 'you should do
           this' rather than a 'you must do this'.
  hober: I think your suggestion of a run-time flag improves the
         degrees of freedom that we're giving browsers. What I was
         trying to say is it's a mistake for the WG to impose a
         release strategy so allowing a diversity is better.
  TabAtkins: We want a policy that works well for the web in the
             future. If it's something like that make a suggestion
             in the thread and we'll word-smith it.

  smfr: Historically iOS apple hasn't had experimental releases so
        we can't ship if we follow these rules. So we wouldn't have
        shipped transitions, animations, etc. It feels like it's
        impeding progress. I understand wanting less prefixing, but
        I don't want to prevent browsers from innovating.
  <tantek> smfr is making good points
  <tantek> OTOH we're now stuck with having to support -webkit-
           prefixes for some properties on mobile because they've
           taken root in some geos
  <TabAtkins> Note: transitions/animations/etc, while great, are
              PRECISELY THE SITUATION WE'RE TRYING TO AVOID because
              of how crazy annoying and painful they've been to iron
              out inconsistencies that were baked in due to early
              shipping.
  <tantek> TabAtkins it's a tradeoff - no easy answer :(
  Florian: We considered this specific case. It was good that Safari
           pushed for innovation, but the standardization wasn't
           good. That's why in general the prefixing policy says you
           shouldn't release what hasn't been discussed. It also has
           'if you end up doing it, here's how you prefix and here's
           how others should react'. We realize you will and it's
           innovative, but will also screw up with standardization.
  smfr: I think that's why we're okay since it's a should.

  * fantasai reminds everyone that this text is attempting to
             reflect http://www.w3.org/blog/CSS/2012/08/30/resolutions-53/

  smfr: Another high level question, is any of the text actually
        normative?
  Florian: Given that it's shoulds and musts it sounds normative.
  fantasai: This is the in the boiler plate for every module. In
            that instance it's most definitely normative.
  fantasai: We discussed how the snapshots used to be WD because we
            wanted it to be non-normative. The WG resolved to make
            it a note. You can conform to a note, but it's not a
            required. In regards to a note its status isn't REC
            track. So you can conform, but I don't know what the W3C
            thinks of that.
  fantasai: We do need this stuff to be normative. You're
            non-conforming if you, for example, you parse things you
            don't support.
  smfr: That sounds fine. I think that this will appear in every
        spec means we must agree.

  gregwhitworth: TabAtkins have you spoken with Chris Wilson and the
                 other people that were working on it so that
                 authors can rely on it working?
  TabAtkins: We've discussed it, but not beyond 'maybe this is a
             cool idea'.
  gregwhitworth: It might be good to loop those people in. Come up
                 with even above the WG so authors can have the
                 flags and can turn them on so real users are
                 supplying real feedback.
  TabAtkins: It might be good to bring to TAG so they can discuss.

  fantasai: This is intended to reflect a bunch of resolutions three
            years ago and a bunch of discussion we had around this.
  hober: I haven't clicked through to the minutes, but I was
         surprised to see that we thought this was resolved. My
         recollection was we didn't resolve anything. It was three
         years ago so I can be mis-remembering.
  <fantasai> hober: yeah, you're right, we didn't put final approval
             on it
  <fantasai> hober: due to lack of proposed text
  <tantek> yeah, agreed
  Florian: We did on some high level concepts but not all the
           details. Based on the agreed high level ideas I was
           tasked to write it, I did it with fantasai, passed it on
           to SimonSapin and we've juggled the hot potato.
  hober: Okay, that makes sense. It seems risky to resolve without
         details. I guess if we resolved on a bunch of things
         without details that could effect how people felt.
  Florian: There's tension between discussing first and shipping
           first-discussing later. The rules are drafted in favor of
           browsers who can discuss before shipping, but they don't
           ignore that it happens.
  hober: I like what you just said. I wish this said that. If you
         can do it, do blah. If you can't, don't.
  Florian: The intent is the same. It's details in the wording and
           that's important, so let's take a week or two and decide.

  fantasai: While we're here, Florian would you like to be an editor.
  Florian: Sure.
  glazou: Objections?

  RESOLVED: add Florian as an editor to the snapshot

  fantasai: Can we add TabAtkins?
  glazou: And objections?

  RESOLVED: add TabAtkins as an editor to the snapshot

  glazou: We have 8 minutes.
  Florian: And we've done topic 1.
  <fantasai> hey, we pre-emptively dropped a bunch of topics already!

CSS Break
---------

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0285.html
  fantasai: I'll summarize. First issue is a concern about
            break-before 'any' and 'always'. Second is margins. When
            you have a forced break and you preserve the margins
            after the break. If you're doing unforced we collapse
            the margin into the page break so your content is flush
            with the top.
  fantasai: Because of how cloning works you might have a clone
            margin at a forced break and you might end up with it at
            the top of the page. I wanted to add a rule that drops
            the cloned margins even if you're at a forced break,
            because the element requesting the margin isn't the one
            forcing a break.
  fantasai: Just wanted to make sure people are okay with that or if
            anyone has a different opinion on how things work.

  Florian: Conceptually I understand, but I can't decide without
           examples to look at. You're probably right, but it's too
           abstract for me.
  fantasai: So do cloned margins ever get kept at page breaks at the
            top of the page or do we always drop them?

  SteveZ: I think you're moving in the correct direction. I just had
          trouble understanding the wording you put it as saying
          that. My concern is a bit like Florian's. I'd like to make
          sure you're still preserving the behavior on first pages,
          but not when it's not quite first page. It's not clear to
          me that it's only the cloning case.
  fantasai: It's just the clone case.
  SteveZ: I'm happy with that, but people need to look at the
          wording.

  bradk: Could this be solved with collapsing the page margins?
  fantasai: Sort of. That's sort of what happens.
  bradk: There are really big margins if you want it off the top of
         the page.
  SteveZ: These are fragments, not elements.
  fantasai: Please continue to think about it and if you're still
            not sure next week we can talk more.
  glazou: So let's defer to next week. 2 minutes on the call.
  glazou: I don't think we have a 2 minute item.

user-select: none
-----------------

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jun/0132.html

  Florian: This is user-select: none and a question of should we
           have it. I think we should, but a number of people say it
           can be abused horribly as copy-protection. Given its been
           raised a couple of times it would be good for the WG to
           decide. It can be abused, it has valid cases, there are
           warnings not to misuse it and permission to browsers to
           work around the abuse.
  glazou: I'd like a week of review. I want to make absolutely sure
          it won't harm my software.
  <tantek> I think the abuse is more likely than the valid
           use-cases, thus I'm leaning towards drop
  <tantek> especially since there's already sites working even
           harder to block users
  <tantek> the evidence is there that sites would abuse
  <tantek> let's not make abuse easier

  Florian: If you disagree with how it behaves we can keep working
           on it.
  TabAtkins: We consider it a useful feature.
  <tantek> if you consider it a useful feature, then perhaps we need
           specific documentation of such use-cases
  <Florian> tantek: I have that in the spec already

  Florian: So if we agree it's useful and we may need to tweek it,
           but won't drop, I want a WG resolution that I can point
           to next time someones says it should be dropped.
  glazou: I consider it a useful feature.
  SteveZ: abstain
  glazou: Anyone else?
  smfr: I think in webkit we have valid use cases.
  tantek: I have mixed feelings. I sympathize with useful features,
          but the evidence I have from sites that try to hone the
          experience more make me think that if we lower the barrier
          to abusive sites it makes it more likely sites will be
          abusive. I'm not sure the usefulness outweighs the abuse.
  TabAtkins: Its been in webkit and blink for years and there isn't
             much abuse.
  tantek: Okay. That's a good data point.
  <Florian> Mozilla has had it as well for years.

  glazou: tantek, can you live with it's a useful feature and we
          don't drop it.
  tantek: Yeah.
  glazou: Any objections?
  <tantek> 0

  RESOLVED: user-select: none is a useful feature and we won't drop
            it.

  glazou: Thank you for today, talk to you next week.
Received on Thursday, 23 July 2015 11:52:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC