[CSSWG] Minutes Telecon 2019-05-15 [selectors-4] [css-images] [css-values]

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


Selectors
---------

  - RESOLVED: Mark this as at risk and optional, remove profile (Issue
              #3925: Rescope :has to static CSS rather than
              .querySelector)

CSS Images
----------

  - Issue #3659 (lazyload) appeared to be duplicated by issue #1603
      (Define crossorigin, preload and async URL modifiers) and will
      be closed unless there's feedback to differentiate the two
      issues.

Values 3
--------

  - RESOLVED: Republish CR of Values 3

Toronto F2F
-----------

  - Anyone planning to attend should add their name to the wikis for
      CSS and Houdini

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2019May/0007.html

Present:
  Rossen Atanassov
  David Baron
  Amelia Bellamy-Royds
  Oriol Brufau
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brian Kardell
  Peter Linss
  Myles Maxfield
  Anton Prowse
  Melanie Richards
  Florian Rivoal
  Greg Whitworth

Regrets:
  Rachel Andrew
  Tab Atkins
  Daniel Bates
  Christian Biesinger
  Chris Lilley
  Alan Stearns
  Lea Verou

Scribe: dael

Selectors
=========

Rescope :has to static CSS rather than .querySelector
-----------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3925

  fantasai: It was pointed out nobody impl :has not even in
            .querySelector. Spec should align with reality and not say
            you can use it. It is implemented in Prince XML so maybe
            needs to stay in spec but scope to PDF renderers
  florian: I think we discussed in the past and wanted to ban it from
           PDF engines as well b/c worry it would creep out of that
           narrow use case and we'd be stuck for compat reasons. Or
           something along those lines. Couldn't find minutes
  fantasai: We did. And that's why it explicitly says shouldn't be
            used in CSS but reality is that's not what's happening
  Rossen: If this is reality than what fantasai suggested makes sense
  Rossen: Any additional comments or challenges to this?

  florian: Okay changing .querySelector but not sure about PDF render
  fantasai: Reused a definition about static not dynamic
  florian: Does [list of things] count?
  fantasai: Up to implementors if it counts
  Rossen: It is implementation specific

  fantasai: If you don't like this division either we remove and
            people are non-conformant or we convince more people to
            implement. So what do you want to do?
  florian: Since existing implementation violates spec about if they
           should implement and if we put a feature in the spec saying
           this is a thing you may or may not want to implement sure.
           I don't know if static render definition makes a
           difference, but if browsers aren't worried about creeping
           out sure
  dauwhe: Other instances of infections creeping out?
  florian: Intentionally yes, accidentally not sure
  dauwhe: Seems low risk
  fantasai: It's not we don't want this in browsers, it's that no one
            has figured out how to do it in a performant way.
  fantasai: If a browser figures out how to do it we'd be happy
  florian: Keep in spec, remove profile distinction, mark at risk
  Rossen: Have enough features not implemented, reducing that is a
          great goal. Lingering things in spec that's an idea that
          won't happen isn't good. There's history in github and repos
          that people could find. I'd move forward to drop now and if
          people want to make a case they will
  <gregwhitworth> +1 to what Rossen said

  bkardell: Sorry, didn't have sound early in call. We added
            distinction between profiles because it could easily be
            impl in JS in theory. I think we hear people saying it
            doesn't add much, I disagree with that. Isn't the way the
            spec is written, I thought it was specifically because if
            a vendor wanted to experimentally impl in full profile
            that's okay. Is that not the case?
  florian: Spec says browsers please don't do this. We didn't want
           someone to ship while others didn't know how. If that was a
           good idea is separate question, but spec says must not
           implemented in CSS, only JS.
  florian: To Rossen's point it's not just not going to happen, it's
           not going to happen probably in browsers, but it is
           happening in other vendors with the name. We put at risk,
           push to L5 if we go to rec
  Rossen: Should we then spec other features in JS library?
  florian: It's a feature we specced rendered by a CSS. Just not a
           browser
  bkardell: It's in jQuery for same reason, because it was in CSS when
            it was rewritten
  <gregwhitworth> bkardell: is that really the order of things, I
                  thought jQuery had it prior to any spec text existing
  florian: Maybe we go to rec with 2 implementations, jQuery and
           Prince. A bit of a stretch

  florian: I feel bad removing it after it's implemented in several
           places and freeing up the namespace doesn't sound nice.
  fantasai: I think disingenuous to remove completely given there is
            an implementation of something standardized. Seems like we
            only put things in spec if a browser implements but
            another non-browser implementation isn't worthy. If this
            was webkit not Prince we wouldn't talk about drop
  bkardell: What if Webkit only did it for print stylesheets
  fantasai: We be conformant to spec
  bkardell: I think florian just said it would violate current spec
  florian: Yes because extra restriction

  AmeliaBR: Question now is this whole idea of live vs snapshot
            profiles, is it implemented anywhere? No one is
            implementing things for .querySelector that's not for CSS.
            Only UA that does .has is as a css selectors. That part of
            spec needs reconsider, but what direct? .has is not in
            spec or drop the profile idea?
  florian: I'd go with later and mark at-risk
  fantasai: and optional
  florian: I don't know what difference it makes but okay
  fantasai: Means not required to conform
  bkardell: So Prince is in violation?
  florian: Is now, but if we do this it wouldn't be
  <hober> fwiw i agree with rossen, but i'm also okay with moving it
          from L4 to L5 as a compromise

  bkardell: Can someone recap? Remove the profile notion and mark at
            risk and options?
  fantasai: At risk makes it easier to remove later. It's a process
            thing. Optional means you can be conformant to module
            without doing this
  AmeliaBR: It's separate module you can implement or not but it's
            tucked inside main selectors
  fantasai: Yeah. When first did profiles there were many features,
            but now there's just this one
  bkardell: If someone implements for .querySelector only it's okay?
  fantasai: Yes
  bkardell: And a print stylesheet or static processing engine that's
            okay?
  fantasai: Yes
  bkardell: sgtm
  Rossen: Nearing consensus. Any other additional thoughts before we
          move this to L5 and mark at risk?

  AmeliaBR: How is @supports selector supposed to work with selectors
            impl only in JS and not CSS. Separate issue.

  florian: Another point. In past other proposed selectors such as
           focus-inside that were initially rejected by bodies because
           we have :has. We can rebuff with saying browsers don't do
           it. Can now with intent to implement
  bkardell: Begs the question of lots of documented use cases of
            possible withins that are solved by this. 100 withins is
            not wonderful thing
  fantasai: I think we should tackle that in separate issue
  fantasai: There's various approaches we can take
  <bkardell> also sgtm to tackle in another issue
  Rossen: Agree.

  Rossen: Objections to resolve by move this to L5 and mark at risk
          and optional
  fantasai: Leave in L4. It is impl. This isn't even CR yet. We're not
            trying to trim to 2 implementations yet.
  <bkardell> +1 to leave in l4
  florian: At risk is enough.
  Rossen: That's fine. Mark this as at risk and optional

  RESOLVED: Mark this as at risk and optional, remove profile

CSS Images
==========

lazyload
--------
  github: https://github.com/w3c/csswg-drafts/issues/3659

  Rossen: gregwhitworth is IRC only, let's do this later

CSS Text
========

pre-wrap and tabs at the end of the line
----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3869

  fantasai: I summarized issue. No agreement on if tabs can hang at
            end of line. Only use case is tab separated value files.
            No clear direction
  florian: I was actioned to give examples and haven't. Agree with
           fantasai we agree on break spaces, but pre-wrap is tricky.
  Rossen: Remove from agenda until have test cases?
  florian: May also want to do break-spaces resolution
  Rossen: Let's look at everything at once. Otherwise you might find
          some new evidence and we need to re-open
  Rossen: I'll remove agenda+

When to/not to include preserved trailing spaces
------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3440

  Rossen: Is koji on?
  fantasai: If koji isn't we should defer. Maybe koji florian and I do
            a separate call. No clear idea of what we should do.
  Rossen: No issue with that. If you move the conversation and then we
          can come back either before F2F or at F2F.
  florian: sgtm

CSS Values
==========

Define crossorigin, preload and async URL modifiers
---------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1603

  AmeliaBR: I didn't put this on the agenda, chris did. Is he on?
  Rossen: I don't see regrets, but he might still be on vacation
  AmeliaBR: We talked about this at last F2F. We resolved some
            syntactic details about URL functions with modifiers.
            General consensus we should pursue harmonizing with HTML
            for image loading modifiers. Waiting on someone to sit
            down and write a proposal. I haven't done that. Not sure
            what Chris wanted to do on call
  Rossen: If we need to wait that's fine. I'll remove agenda+ so that
          it doesn't come back until it's ready.

CSS Images
==========

lazyload
--------
  github: https://github.com/w3c/csswg-drafts/issues/3659

  Rossen: Don't know if gregwhitworth made it
  gregwhitworth: I'm here
  gregwhitworth: This isn't my issue, but I dug into what I think this
                 person wanted that bg images weren't be loaded by
                 lazyloading. I'm not sure what this person wanted so
                 I suggest we close until more clarification. Chris
                 pointed out there is already an issue from AmeliaBR
                 about modifiers. I'd close as dup and ask for more
                 details.
  Rossen: Close the issue back to the owner and ask for more details?
  gregwhitworth: I pinged him and asked to clarify. I'd close as dup
                 to the one Chris L referenced.
  Rossen: Any other members that read or want to discuss this?
  Rossen: If not we can do that
  Rossen: No hearing takers. I'll clear up the labels and move the
          issue back to the owner

Values 3
========

Republish Values 3
------------------

  fantasai: We discussed bracketed range notation at last F2F.
            TabAtkins and I folded that in last month. We need to
            republish. It's a CR
  Rossen: Sounds good.
  florian: This new thing is arguably editorial. The bracket notation.
  <fantasai> Changes list https://drafts.csswg.org/css-values-3/#changes
  Rossen: Still want to have WG resolution
  florian: Just that it's the lighter form or republication
  <fantasai> New section is
https://drafts.csswg.org/css-values-3/#numeric-ranges
  Rossen: Trying to gage if people want time

  AmeliaBR: I do have an open PR. Trusting that'll get integrated
            before republication
  florian: Doesn't have to be before
  AmeliaBR: It includes Values 3 edits. It's clean up on top of what
            fantasai pushed. Major ones are already on there.
  Rossen: Do you have PR?
  AmeliaBR: #3894
  <AmeliaBR> https://github.com/w3c/csswg-drafts/pull/3894
  fantasai: Happy to add in the changes you're suggesting, but I will
            want to hold off on merging changes to other specs until
            after Values 3 is published.
  Rossen: Values 3 changes are straightforward.
  <fantasai> Amelia's changes
https://github.com/w3c/csswg-drafts/pull/3894/files#diff-c3798e248ee6e7eeb80c7b12f053a5de
  <fantasai> Just Editorial fixes

  AmeliaBR: My changes are minor. fantasai already merged major
            changes into ED which introduce new syntax. Is defining a
            new syntax with no normative effects on impl is that
            sufficient to count as editorial change for CR
  fantasai: Good question
  Rossen: Not sure
  AmeliaBR: florian, does this count as editorial where we define new
            syntax but it has no normative impact requirements.
  florian: I don't think process is clear. Probably isn't editorial
  fantasai: Change to spec convention of how they describe, but
            doesn't change definition
  florian: Definition of what's editorial is quite limited and
           probably this isn't under it. Borderline probably not
           editorial.
  florian: There's 2 categories of what's editorial, Markup and titles/
           grammatical error but correcting clarification is not
           editorial. I think that's all that editorial
  bkardell: Is this the second?
  florian: It's not a bug in an example
  bkardell: Clarifying.
  florian: Clarifying non-ambiguous. You'd have to make the argument
           it's not obvious
  fantasai: I don't think we care. If it's REC might be worth
            quibbling, updating a REC requires like three publications
            and an AC vote. It's CR let's go through normal process.
  <florian> +1 to fantasai, let's just do it.
  Rossen: [missed]
  hober: If this were a change in webIDL it's not a hard question
  florian: Same kind of question
  hober: Trying to say it is a change that impacts specs that depend
         on it. I think it's okay that it's not editorial
  Rossen: Seems to be agreement around that

  Rossen: Anyone need additional time to review? Or we can resolve?
  Rossen: Objections on Republish CR of Values 3
  florian: With AmeliaBR's PR?
  Rossen: Yes since AmeliaBR PR doesn't introduce anything that
          changes the way this would be republished.
  * fantasai doing that right now
  AmeliaBR: And if fantasai wants to cherry pick markup fixes that's
            fine.
  Rossen: I'm sure fantasai will figure it out.
  Rossen: Objections?

  RESOLVED: Republish CR of Values 3

  Rossen: fantasai you'll handle this?
  fantasai: Yes, I can
  <florian> I have reviewed the multicol part of that PR, that too can
            be landed

F2F
===

  <dbaron> https://wiki.csswg.org/planning/toronto-2019
  dbaron: Please make sure you have listed yourself as an attendee and
          if you're attending Houdini
  dbaron: If you have dietary requirements please email me.
  Rossen: Should we add a column for that on the wiki?
  dbaron: I've got a bunch in emails so I'd prefer that.
  bkardell: How would you like us to err on maybe attending
  dbaron: Put yourself on the list and put you're a maybe.
  Rossen: Thanks dbaron. Please add yourself if you haven't
  Rossen: Anything else?

  Rossen: Everyone gets back 20 minutes. Thank you

Received on Wednesday, 15 May 2019 21:58:31 UTC