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

[CSSWG] Minutes Telecon 2018-01-16 [css-snapshot] [css-pseudo]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 16 Jan 2019 19:47:45 -0500
Message-ID: <CADhPm3tEn-MGrupZ9WGP_eppEDrGb0UUaZmCy6AUtX_3-b2=4w@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Upcoming F2F

  - The group affirmed that Houdini Task Force didn't need a separate
      day to meet.

More WPT reviewers needed

  - There are many tests that have been submitted, but not reviewed.
      This frustration is shared by several people, but no solution
      was immediately forthcoming.
  - Some people expressed that if they are needed to review an email
      prompt may be more effective then a github mention.

Snapshot 2018

  - RESOLVED: Add CSS Transforms to the 2018 Snapshot
  - RESOLVED: Move Grid from stable to rough interop in 2018 Snapshot
  - RESOLVED: Once these edits have been completed republish 2018

CSS Pseudo

  - The resolution to Issue #2850 (How should a selected spelling
      error be painted?) is related to the decision on cascading /
      inheritance model for ::selection (Issue #2474) so that will be
      reviewed further to see if it helps in reaching a resolution.
  - RESOLVED: Add a .element property that brings pseudos back to
              their element (Issue #2816)
  - RESOLVED: Make all the types include the :: prefix for consistency
              (Issue #2815)
  - RESOLVED: Rename letter and line to ::first-letter and
              ::first-line (Issue #2815)
  - RESOLVED: Accept and add the :placeholder-select pseudo class and
              add a note for ::placeholder that we're interested in
              working on it (Issue #2517)
  - RESOLVED: Add stroke-color, stroke-width, fill-color and
              paint-order (Issue #2362)


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

  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Oriol Brufau
  Emilio Cobos Álvarez
  Dave Cramer
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Peter Linss
  Nigel Megitt
  Michael Miller
  Manuel Rego Casasnovas
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou
  Eric Willigers

  Greg Whitworth

Scribe: dael

Upcoming F2F

  Rossen: Let's go ahead and get started
  Rossen: Welcome. As usual, the first item is a call for additional
          items or changes you would like made to the agenda
  Rossen: I did have one F2F question.
  Rossen: Thanks to those who added themselves to the wiki. If you
          haven't done so, please do. It will give organizers an idea
          of who is coming. It also gives you a chance to add items to
          the agenda if they're not tagged in github
  Rossen: Question I had was, we had decided there would be no
          separate Houdini date. That was decided during TPAC.
  Rossen: I wanted to do an additional check to make sure this hasn't
          changed. Still good with that?
  TabAtkins: No intention of doing it. I thought we'd do a separate
             track for Houdini during something like Text if it's
             necessary. We do not have enough topics to warrant a full

More WPT reviewers needed
  github: https://github.com/w3c/csswg-drafts/issues/3496

  ericwilligers: I wanted to bring attention, there are a few specs
                 with essentially no reviewers. Some people may be
                 listed but don't check their review emails.
  ericwilligers: It would be helpful if more people volunteered. I can
                 get Blink people to review, but that's not available
                 to everyone. More people should be able to submit
                 tests without going through a browser
  Rossen: In general we've had this discussion many times in the past.
          Both tests and test reviewers have been a struggle to come
  Rossen: Was there anything you were doing to gather external
  ericwilligers: No. This is tests I wrote that I thought it
                 unfortunate no one is reviewing

  gsnedders: It's notable that CSSWG specs are much harder to get
             review than any other spec. People who work on layout
             aren't interacting with wpt the way other groups are. Be
             interested to know reasons
  chris: I've tried to review tests. I share ericwilligers
         frustration. I'll submit tests and they sit
  dbaron: I review tests when I have time, but I think it may be more
          useful to bug individuals then bug the whole WG for reviews
  ericwilligers: I specify a person and nothing happened
  dbaron: Some of us have hundreds of things in github queues. If you
          want me to review something, send an email
  ericwilligers: That's all for this issue, thanks

  Rossen: Thank you for bringing it to attention again. For us to be
          successful as a WG and making sure standards are pushed
          through, tests are a huge part. If anyone submits tests,
          please be accommodating. I'm bad at following all repo build
          up, but I try and respond to direct emails
  Rossen: Let's see if we can drain that queue

  <tantek> Last time this topic came up, the larger problem of WPT
           being poorly documented (processes etc.) was the key
  <tantek> pretty sure there was an issue filed too
  <gsnedders> tantek: that doesn't explain the disparity between CSS
              and pretty much every other group, though
  <dbaron> gsnedders, There may be issues with difficulty of mapping
           tests to engineering areas, and also things specific to not
           liking the wpt reftest setup

  <dbaron> ericwilligers, btw, I think it may be more useful to bring
           up specific specs that are short of reviewers or where
           they're not responding to both github requests and emails
           than to bring up the topic generally

Snapshot 2018

2018 Snapshot Rough Inteorp List

  Rossen: Is fantasai on?
  chris: 2018 or 2019? 2018 has been published
  Rossen: I'll paste the mail thread
  Rossen: It is 2018 unless it was a mistype in the title
  <Rossen> https://lists.w3.org/Archives/Member/w3c-css-wg/2018OctDec/0179.html
           [note: link is member only]
  <astearns> given that it's 2019 now, we should probably be looking
             to make changes to 2019
  <chris> CSS Snapshot 2018 W3C Working Group Note, 15 November 2018
  Rossen: It was 2018 snapshot publication

  fantasai: These are on 2018. We didn't put transforms in 2018 and it
            seems it should be there
  <chris> seems a bit late tbh.
  fantasai: Transforms didn't make it because it hit CR right after we
            published the snapshot. But spec is stable and there's
            implementations and interop there.
  fantasai: Second issue was to move grid not in the main line of the
            snapshot because spec hasn't been that level of stable.
            We'd put it in a note with something like Animations to
            say spec isn't quite there.

  <AmeliaBR> Transforms Level 1 is still published as a WD, not CR. Is
             that a mistake? https://www.w3.org/TR/css3-transforms/

  chris: What's point of doing that? We're in 2019 and we had WG
         consensus grid would be in
  fantasai: We didn't
  florian: That was my mistake and I put it in the wrong category
  chris: Worth republishing to back it down?
  fantasai: epub specs have started to rely on snapshots. We might
            want to rethink what snapshot is, but these are specs not
            rec but only because there's a few bugs. But they're
            almost there.
  chris: Grid isn't almost there?
  fantasai: If you look at state of spec in 2018 we got a lot of
            issues. It'll get there in 2019.
  florian: Is it there now?
  fantasai: No. There are a bunch of open issues. When they're
            resolved and we republish and impl are up to date
  chris: I worry about mixed messages. When do we plan to publish 2019?
  chris: If we're going to do it in a couple of months not worthwhile.
         We ought to be doing 2019 snapshot in spring 2019
  fantasai: I'll do the publishing
  chris: Adding a note is easy
  * chris has made his point and is happy either way

  Rossen: Do we want to add CSS transforms and update the 2018
          snapshot for those taking dependency on it? The snapshot
          will retroactively present a more realistic picture. Or
          chris do you object to that?
  chris: Not objecting, good either way. Don't want to send mixed
         messages or incorrect ones
  Rossen: Additional feedback from the group?
  nigel: I'd prioritize fixing incorrect statements over inconsistent
         messages. Incorrect information is more dangerous
  Rossen: That's a +1 for adding it
  <tantek> +1 to adding it
  Rossen: Anything else?
  Rossen: Objections to add CSS Transforms to the 2018 Snapshot?

  RESOLVED: Add CSS Transforms to the 2018 Snapshot

  Rossen: fantasai back to you, there were more questions
  Rossen: Grid. Do we need to make a change?
  florian: I screwed up, let's fix it
  fantasai: Grid was supposed to be in the bucket of notes about specs
            that are widely deployed but not as stable. I understood
            grid would be in that category, not the main. I'm asking
            to move it into that position
  fantasai: We have several specs which are widely deployed but need
            more bug fixing. They're listed in a different section
  florian: It is what we resolved, I implemented it incorrectly
  <tantek> Link to current editor's draft of snapshot?

  Rossen: Since we're going to update the snapshot, what is the ask?
          You want to move it?
  fantasai: From stable to rough interop
  Rossen: Feedback from WG on this?
  <tantek> I'm not going to nitpick on section. Happy that it's
  Rossen: Objections to moving Grid from stable to rough interop?

  RESOLVED: Move Grid from stable to rough interop in 2018 Snapshot

  Rossen: Resolution to republish snapshot?
  fantasai: Yes, please
  Rossen: One more. Once these edits have been completed republish
          2018 snapshot

  RESOLVED: Once these edits have been completed republish 2018

CSS Pseudo

How should a selected spelling error be painted?
  github: https://github.com/w3c/csswg-drafts/issues/2850

  Rossen: fantasai or AmeliaBR can you summarize?
  fantasai: Let's see where we're at
  florian: I thought semi reviewed and waiting for additional feedback
  fantasai: Yeah
  <AmeliaBR> I'm not sure there's much more to discuss. Needs proposed
  florian: I think agenda+ was left on rather then added
  Rossen: Bot didn't resolve?
  <dbaron> the bot only removes agenda+ when there's a resolution, btw

  Daniel: I had a chance to digest this. We described in terms of
  Daniel: I wrote a comment, so to restate. currentColor would solve
          this and for all color properties, but not for caret and
          text shadow
  Daniel: In 2.2 of the same spec we solved this for the first-letter
  fantasai: first-letter is different kind of pseudo element. It
            inherits fundamentally through the tree. What we're doing
            for selection, a selection for a span inherits from the p,
            not the span. That has to happen for all the different
            properties that inherit
  Daniel: I read 2.2 and how it's impl in webkit
  fantasai: Webkit impl isn't like any other browser
  Daniel: I like webkit where you cascade and then inherit
  fantasai: The thing currently implemented, if you have selections
            like <p>::selection and inside the p you have a span, you
            lose the selection over the span
  Daniel: Currently in webkit?
  fantasai: That's in every other browser
  Daniel: That doesn't happen. I could be wrong, but in my memory of
          code that's not what happens. For the span...we do the
          cascade, find the parent with the section...right now we do
          the cascade
  Daniel: I would like what webkit does for first letter. It cascades
          first and then does inheritance against first line.
  <dbaron> I don't know what you mean by "does the cascade" --
           cascading what together?
  Daniel: If you had some span that has a first-letter and it's inside
          a parent with a first-letter inside a parent with a
          first-line, you cascade for first-letter and inherit from
          cascade result of first-line. That's my interpretation of
          section 2.2
  <fantasai> testcase has some emphasized text
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?<!DOCTYPE%20html>%0A<style>%0Ap%3A%3Aselection%20%7B%20background%3A%20green%3B%20%7D%0A<%2Fstyle>%0A<p>this%20is%20some%20<em>emphasized%20text<%2Fem>
  fantasai: 2.2 just changed
  <fantasai> Cascading / inheritance model for ::selection was changed
             in https://github.com/w3c/csswg-drafts/issues/2474

  florian: The thing fantasai just pasted run in safari agrees with
           what fantasai stated about current behavior.
  florian: In the spec we're trying to get away from...it's different
           then current, but current implementations aren't useful. If
           you're trying to style ::selection applied to particular
           elements it breaks if they have children. That's why we
           want different model
  Daniel: One thing; did fantasai post the example? I can explain.
          That's broken. I have a patch for webkit. We only do it for
          first-letter and first-line. I'm saying why can't we make
          selection have same model as first-letter
  fantasai: That's a different issue, that's about fundamental
            inheritance and cascade for selection. That still is a
            thing that needs to be defined
  Daniel: I filed this issue because I wanted to solve
  fantasai: There is an issue where we're discussing in general. You
            can compare the model. One is cascade one is inheritance.
            Both are discussed and you can see both in spec. Cascade
            is in the TR and inheritance is in the ED
  Daniel: I'll read it and comment on it
  florian: To add one thing, the one on TR is what was previous and
           the new on is in the ED because we objected to doing it the
           cascade way
  Daniel: Let me read through both and I'll discuss in github
  Rossen: Excellent. Thank you for chiming in.

Add CSSPseudoElement.parentElement
  github: https://github.com/w3c/csswg-drafts/issues/2816

  fantasai: This one was filed by birtles and I don't know too much
            about the APIs. They have a big red notice saying this was
            just an idea. It seems Mozilla is shipping some form of
            this API.
  fantasai: We should probably put something there
  Rossen: Currently suggested API, parent element was suggested and
          then pointed out that was not necessarily the best name at
          the very least. It's the originating element and fantasai
          suggested .element
  Rossen: If this is about naming, we can discuss if we want to add
          the API. I think adding is warranted
  TabAtkins: Agree having the attribute to get back to the real
             element is a necessary part. I like .element suggestion
             for the name
  Rossen: Additional comments?
  <florian> sounds good
  Rossen: Objections to adding a .element prop that brings pseudos
          back to their element?

  RESOLVED: Add a .element property that brings pseudos back to their

Should CSSPseudoElement.type value include the "::" prefix?
  github: https://github.com/w3c/csswg-drafts/issues/2815

  TabAtkins: As birtles points out, in some other APIs which mention a
             pseudo element name, they name with :: prefix. We should
             defer to them and do the same
  <fantasai> https://drafts.csswg.org/css-pseudo-4/#CSSPseudoElement-interface
  TabAtkins: Also, spec defines first-letter and first-line and just
             letter and line, we should fix that too so they have the
             same name
  Rossen: Would be wonderful
  Rossen: Additional comments?
  Rossen: Objections to making all the types include the :: prefix for

  RESOLVED: Make all the types include the :: prefix for consistency

  <fantasai> https://drafts.csswg.org/css-pseudo-4/#cssom
  fantasai: While we're on this I'd like to note that entire section
            of the spec is 30% red issues. If anyone is shipping that
            can they review and if it's what they're shipping we can
            remove the issues?
  Rossen: Good general idea for anything we're shipping. I support
          your call for review
  fantasai: Does anyone impl these?
  dbaron: Gecko impl something, but I don't know what
  fantasai: Can we ask the person who impl to look?
  emilio: I think it's preffed for animations, I can check
  <dbaron> conditional on a pref related to web animations
  Rossen: You don't have to do it real time. Just do it and comment
  <gsnedders> fantasai:
              shows no stable browser having any FWIW

Clarification: do ::placeholder/:placeholder-shown apply to <select>s'
    "placeholder label option"?
  github: https://github.com/w3c/csswg-drafts/issues/2517

  Rossen: Opened a while ago, added to agenda after a pass through
  fantasai: In case of a select the placeholder text is an element
            rather than an attribute
  fantasai: Question is should ::placeholder match that so text inside
            can be styled? A little weird because not generating a new
            element, but it serves the same function
  TabAtkins: Understand the use case and the complaints in the
             original post about how difficult this is to match this
             with a selector. I get the use case. A little concerns
             about compat, I'm betting :placeholder-shown is mostly on
  TabAtkins: ::placeholder matching is complicated because
             inheritence, but we semi have that already
  dbaron: Compat question is if people write input:placeholder-shown
          or :placeholder-shown
  fantasai: And if they want the styling applied to those kinds of
  florian: As for the pseudo element it's fuzzy because select is a
           replaced element so you can say actual isn't rendered and
           it is a pseudo. If that make sense with appearance: none is
           an interesting question
  TabAtkins: Don't want to get to idea select is entirely replaced.
             Doing some level of styling is useful
  dbaron: One point of having web components is we can do something
          like that
  TabAtkins: It would be be most optimal but we could come up with
             parallel pseudo class and pseudo element

  TabAtkins: Maybe we can just do pseudo class for now since it
             applies on the select?
  fantasai: Probably solve the issue easiest because
            :placeholder-shown makes the placeholder the first child
            and you can style it
  TabAtkins: True
  TabAtkins: While a theoretical other language select would have more
             complex, in HTML it's the first child. Don't need an
             extra selector. Let's go with that
  florian: Does styling of children of selection work?
  TabAtkins: Don't remember, but I want to allow it
  florian: We can start with that and see

  Rossen: Hearing yea for the pseudo class and wait on pseudo? Is that
          the proposal?
  TabAtkins: I like that the best
  Rossen: Additional points?
  fantasai: I can add a note in spec for ::placeholder that we're
            interested in doing this and looking for feedback
  Rossen: Proposal: Accept and add the :placeholder-select pseudo
          class and add a note for ::placeholder that we're interested
          in working on it
  Rossen: Objections?

  RESOLVED: Accept and add the :placeholder-select pseudo class and
            add a note for ::placeholder that we're interested in
            working on it

  florian: I tested and if you try and style an option in a select it
           doesn't do anything
  Rossen: Okay
  Rossen: Where did you test? I think we support some of this in Edge
  florian: FF and Chrome. Tried to style color
  Rossen: Interesting. Okay
  Rossen: We'll add the note and continue
  <florian> same thing in safari
  TabAtkins: florian did you jsut look or open it? When I open it in
             chrome options are styled
  TabAtkins: I'm red color and bold stuff and non-selected are both.
             Selected is bold.
  <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6514
  <TabAtkins> on chromeos
  florian: Not here. Maybe OS dependent. It's a native appearance
  florian: Let's take it offline
  Rossen: Same works in Edge

Should CSSPseudoElement.type value include the "::" prefix?
  github: https://github.com/w3c/csswg-drafts/issues/2815

  TabAtkins: Accept issue to rename to first-letter and first-line
  Rossen: Objections to renaming letter and line to ::first-letter and

  RESOLVED: Rename letter and line to ::first-letter and ::first-line

Add stroke-color and stroke-width to the list of highlight properties
  github: https://github.com/w3c/csswg-drafts/issues/2362

  Rossen: Discussed a number of times. Seems there's some agreement on
          the issue
  Rossen: chris do you want to take this?
  chris: Been a bit of discussion. General consensus on properties.
         Suggestion that they're the long hands. Support that
  chris: We've pretty much worked out what this effects.
  fantasai: I think we'll look for 2 resolutions. 1 to clarify these
            are only ink overflow and second is to make them usable
            with selection
  chris: Agree with first

  fantasai: Question about applying all long hands. One limitation we
            have here is we don't want anything that will expose
            boundaries of box represent element.
  chris: But would it? Someone suggested it would but that was fairly
         quickly shown to be wrong
  fantasai: Then we're fine

  Rossen: Proposal is add stroke-color and stroke-width, fill-color
          and paint-order? Is that the list?
  chris: I think so. It's in the issue
  Rossen: I'm reading from issue. Making sure I'm not missing anything.
  Rossen: stroke-color, stroke-width, fill-color and paint-order
  Rossen: Objections to adding stroke-color, stroke-width, fill-color
          and paint-order

  RESOLVED: Add stroke-color, stroke-width, fill-color and paint-order

  chris: And the suggestion to add the long hands?
  fantasai: My understanding from last time is they need to be
            properties that can be handled at a high performance
            level. Dashing and filter and fill images and these
  chris: Dashing has nothing to do with filters or images. It's common
         in animations so can't say it's not performance
  fantasai: Question is would impl be up to implementing that for
  chris: If you look in graphical editors there's marching ants and
         I've seen people use stroke-offset and stroke-array to get
  leaverou: That's commonly done

  fantasai: I don't know answer, but I think implementors need to say
            yes they're willing to implement
  smfr: [missed] I'm okay with dashing here
  <smfr> for webkit, dashing has some painting cost, but not serious
         enough to justify excluding it from this list
  <smfr> I’m ok with dashing here
  Rossen: smfr is okay with dashing
  chris: Other implementors?
  Rossen: I'll take that as a silent no

  fantasai: Next question is what about paint servers and tiling
            images. Is that something implementors want to do on
  Rossen: Ooph
  TabAtkins: That's backgrounds in css
  <smfr> don’t want selection to trigger an image load
  fantasai: CSS only allows color, not image
  leaverou: Are background images not allowed for reason of showing
            element boundaries?
  TabAtkins: Probably. We got around the issue by only allowing 0
             dimensional images, aka colors
  chris: I think that's the same for border images
  leaverou: I don't think even borders are allowed
  fantasai: Right
  <AmeliaBR> For stroke/fill images, the boundaries (in SVG, anyway)
             are always the boundaries of the full <text>, not the
             given span, so it shouldn't be affected by changes in
             selection span.
  Rossen: So, no on this one? Soft no? To be consistent with previous
          soft no or weak maybe?
  fantasai: Stroke and fill will be based on geometry of element so
            won't expose border. I don't think it's that useful.
            Probably better not to do them. If someone wants them in
            the future we can add
  Rossen: Easier to add than remove.

  Rossen: Let's not add for now. There's enough feedback from silence
          and pushback that this isn't comfortable at the moment. When
          they're more widely used we can see if shorthands are
  Rossen: Sound good?
  chris: Okay
  Rossen: That's this issue
  <fantasai> I'm noting that you can still specify the shorthands,
             we'd just ignore the longhands of it that aren't supported

  Rossen: That brings us to top of the hour
  Rossen: We couldn't get to text and inline so next week we'll start
          with those
  Rossen: We'll chat next week.
Received on Thursday, 17 January 2019 00:48:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:12 UTC