[CSSWG] Minutes Telecon 2019-01-30 [css-text] [css-sizing] [css-pseudo]

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

CSS Text/CSS Sizing

  - Progress is being made on Issue #3440 (When to/not to include
      preserved trailing spaces). fantasai needs some more
      clarification on comments from xidorn and will then put together
      a proposal for working group review.

CSS Pseudo Elements

  - Originally the pseudo element object hung off the window to allow
      for future use in multiple element views. However many other
      decisions made by the group have made multiple element views
      hard anyway, so using element will not make it any harder in the
      future and will be clear to authors now.
  - RESOLVED: Add Element.pseudo(type) (Issue #3541)
  - RESOLVED: Specify the current behavior and use the currentColor
              name (Issue #2850)
  - RESOLVED: Specify stroke-color and fill-color are accepted in
              highlight styles (Issue #2362)
  - RESOLVED: Add stroke-width to the set of properties (Issue #2362)
  - There is a desire to create a standard set of principles for the
      list of highlight properties instead of evaluating properties
      one by one, however there's also a need to make sure these can
      fully replace the prefixed properties.
  - fantasai is looking for feedback on issue #3540 (Mark
      unimplemented CSSPseudoElement features at-risk) prior to next
      week's call


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

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Oriol Brufau
  Benjamin De Cock
  Elika Etemad
  Tony Graham
  Dael Jackson
  Chris Lilley
  Peter Linss
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Lea Verou
  Greg Whitworth

  Tantek Çelik
  Jen Simmons

Scribe: dael

CSS Text/CSS Sizing

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

  Rossen: There's a proposal put forward and discussion on the issue.
          Who wants to summarize?
  Rossen: Do we have anyone from the topic? fantasai, florian, koji?
  florian: I'm here, but was hoping to participate rather than lead
  fantasai: I'm here, but I want more clarification from xidorn before
            we do this one
  Rossen: Is xidorn on?

  Rossen: This one is a rather old topic that was kicked from call to
  fantasai: With xidorn comments I think we have an idea what we can
            start to do. I want to clarify and get a solid proposal
            before brining to WG
  Rossen: His last comment he said it seems to match his understanding
          in reply to your post yesterday
  Rossen: There was some acknowledgment. If we should continue working
          in github that's fine. Prefer next week?
  fantasai: Yeah, I want clarity on other comments and put together a

  florian: fantasai in github can you clarify your last comment?
  fantasai: Okay

CSS Pseudo Elements

Decide between Element.pseudo(type) and
  github: https://github.com/w3c/csswg-drafts/issues/3541

  Rossen: fantasai can you summarize?
  fantasai: Two proposals for how to get the pseudo element object.
            One was a .pseudo function on Element and the other way
  fantasai: They were in different specs, never discussed which we
            wanted though one was dropped. I wanted to know which
            should go in pseudo element spec
  gregwhitworth: I like heycam proposal that hanging it off the
                 element makes sense but passing the domstring
  fantasai: I thought that's what it was, but sure
  TabAtkins: I was also confused by heycam. It's element.pseudo()
             taking a type
  gregwhitworth: Okay
  Rossen: Title of the topic is element.pseudo(type)
  Rossen: I think heycam is more or less a summary of that and making
          a case for it.

  Rossen: Is there a reason why we couldn't want Element.pseudo(type)?
  Rossen: I know we have gCS hanging off the window
  dbaron: I think one historic reason is people envisioned multiple
          presentations of same document but we've abandoned that.
          Given that hang off element makes sense. It's simpler
  Rossen: To reiterate, if you have multiple presentations where we
          resolve a MQ 2 ways due to view- one is small and the other
          is large for example- based on this you might cascade styles
          differently so in one case you have a pseudo and the other
  dbaron: That's what I'm guessing it was
  Rossen: This is far fetched even today
  florian: Even more than it used to be
  dbaron: Early API designs envisioned you might use a single doc
          object in 2 presentations. That's the thing we've admitted
          we're not going to do
  TabAtkins: Yeah
  Rossen: I totally buy the historic reasoning on this

  Rossen: If we already have a decision I don't know where it's
          recorded that we're not pursuing the multiple view. I don't
          think there's much choice here besides hanging off element
  fantasai: Are there places we've locked into not having multiple
  dbaron: Element offsetWidth and offsetTop, those kind of things
          locked us in well
  Rossen: Even if we get to a point where we have to disambiguate...If
          there was a case where we need to support multiple views you
          should be able to get element somehow. Provided there's an
          api to return the element for a given view, hanging off the
          element is still valid. Hiding the view information and give
          all the elements and you figure out which is which is worse
          ergonomics for such API
  plinss: I was an original proponent for multi view and idea was it's
          literally the same element so there's no different version
          per element. But I do accept it's way late in the life of
          the web to change that and we have many APIs presuming one
          view. I'm not thrilled about adding more APIs that lock us
          in if we ever want to fix. But if we're dealing with
          functions you can add an argument for an extra view and if
          it's not passed you get default. We can work around
  TabAtkins: Without considering this issue typedOM added style based
             elements as well. View will have to bend around reality
             if they ever happen.

  Rossen: Back to topic at hand, any reason to not go with
          Element.pseudo(type) ?
  <gregwhitworth> That sounds like consensus to me
  Rossen: Given all the arguments to how we got to where we are, any
          objections to resolve to add Element.pseudo(type)?

  RESOLVED: Add Element.pseudo(type)

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

  Rossen: It's a level 4 question
  fantasai: I think this was about defining currentColor to represent
            color of the previous layer. You have the document which
            has colors for text and then spelling error and the
            selection layered on top. Proposal was use currentColor
            keyword to use the color. This seemed a neat way to
            represent that concept
  fantasai: Given the way inheritance is working in the ::selection
  florian: Model makes sense to me. Concept of layers- is that
           abstract way to describe or do implementations work like
  fantasai: Implementations- I don't know how they work, selection is
            only thing implement. Selection is painted over rest of
            doc. Text that specifies how things is painted say it's
            painted over, but it's really in replacement of original
            text. If each pseudo element specifies a color, only last
            will paint the text
  fantasai: That's a separate question on how things are painted. This
            is can we use currentColor to be the color I would
            otherwise be or do I need a new keyword?

  <Rossen> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/highlight/explainer.md
  Rossen: There was an explainer that I was told would be proposed and
          discussed soon ^
  <dbaron> I'm a little worried this might be too clever...
  Rossen: You may or may not have gone through it. I'm raising
          awareness of something discussed in context of editing
  Rossen: This is being worked on more actively and there is some
          interaction with CSS for styling and handling of overlays
          and colors.
  Rossen: I was a little involved in the beginning so this proposal is
          at least in a sane state it's in currently. If fantasai you
          were looking for new words this could be a good primer to
          see if we can extract something
  fantasai: This is about defining new layers. In the section linked
            from the explainer it's future custom pseudos. This isn't
            new layers of highlights. This is how to represent in the
            CSS properties model the color for a highlight that's
            'don't give me a color'. I think most straightforward is
            currentColor keyword.
  fantasai: On color it says inherit from whatever I inherit from.
            That would be the ::selection's parent. We need to a way
            to say ::Selection doesn't have a color. We can do magic
            and say you can't spec that, or we use this, or I invent a
            new word
  florian: Using currentColor makes sense. The thing from Rossen
           doesn't change that

  dbaron: This is only doing something special for currentColor on the
          color property, not any other uses?
  fantasai: Yeah because rest will refer to color property
  dbaron: That makes it seem a little less scary

  Rossen: Some support for currentColor
  Rossen: Objections to specify the current behavior and use the
          currentColor name?

  RESOLVED: specify the current behavior and use the currentColor name

  florian: I'm very interested in that explainer and I'll look into
           this. It's great that you're doing it, it was on my to do
  Rossen: Please do, this is getting traction.
  Rossen: Discussion is on WCG or Editing TF
  gregwhitworth: I think it's Editing TF
  florian: I'll look there.
  Rossen: If you're really interested I can connect you with folks on
          our end. Shoot me an email.

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

  Rossen: AmeliaBR wrote a nice long overview. This is back to the WG
  AmeliaBR: We talked about this previously. Question is about which
            properties should be allowed on highlight pseudo elements
            like selection
  AmeliaBR: Discussion last week was disagreement about what factors
            should disqualify a property from that set. We talked
            about if something would trigger scrollbars, but feedback
            from impl is there are performance impacts from recall
            painting dirty boxes as styles change

  AmeliaBR: First question is for the group- what should be allowed in
            a highlight style and what should be disqualified. From
            there we can look at specific properties
  AmeliaBR: As far as implementations go, we're talking about
            properties that are defined for SVG but want to extend to
            all CSS style text. New fill and stroke spec is not
  AmeliaBR: Another thing to remember is selecting styles on svg text
            has lots of interop issues that go beyond this issue.
            Solving this will not solve all svg text.
  AmeliaBR: Non-svg text I don't believe there are any impl that
            support fill and stroke as def in new spec. We do have
            implementations of webkit prefixed version which has
            different syntax and relationship between the properties.
  AmeliaBR: At the end of my comment I said I'm not sure we can make a
            decision on fill and stroke because they're not specified.
            Should we address interop in properties that are impl? The
            prefixed ones that don't have a spec. That's the question
            worth asking
  AmeliaBR: I outlined a bunch of questions without answers. Anyone
            want to jump in with an opinion?

  fantasai: smfr webkit has stroke and fill for selection?
  smfr: Don't recall, but I think we could easily

  fantasai: My inclination is for the spec in current state I would go
            more restrictive for now and add more as requested. We
            should do subset of what is impl plus spelling and grammar
            error. That's why we have text decor and color
  fantasai: Other properties in that list I don't know if they're
            problematic. I'm happy to include if impl want to impl,
            but if not there's no reason to put it in the spec unless
            someone asks.
  fantasai: I prefer color, background color, text decoration, and
            whatever impl want to implement
  fantasai: Then we can consider what else we want to allow. A core
            set would be good

  chris: I previously argued stroke-width, but I withdraw that. I
         would like to see stroke and fill if impl interest. Makes
         sense for fill
  <dbaron> I think it's also worth trying to write down principles
           that lead to the choices -- I think one of those principles
           should be that anything that triggers scrollable overflow
           probably shouldn't be included...
  <AmeliaBR> https://codepen.io/AmeliaBR/pen/84c95eb4cd697f031f12487cbf239480
  AmeliaBR: As far as what's impl, for SVG text all are supported I
            think. Haven't tested. That's ^ the test for prefixed ones
  AmeliaBR: Chrome and Edge support changing stroke-color and
            stroke-width. Firefox does not. Don't have Safari
  myles: Why is stroke-width hard?
  chris: Causes additional computation so it's not just damaged pixel
  smfr: Have to do layout to recalc visual overflow
  chris: Also heycam from Mozilla said problematic
  dbaron: Text decorations also require recomputing visual overflow
  chris: True
  smfr: We used to cheat, but they can project out
  AmeliaBR: We're talking about selection because that's where
            performance comes in. But we're using same set of
            properties for all highlight pseudo classes so that also
            means spelling & grammar error. If we restrict from
            performance we might need to split the category so there's
            flexibility for things like highlighting spelling errors

  dbaron: I don't know we're far enough along on interop on this that
          we're at that point
  dbaron: I think it is worth trying to write down principles that
          lead to these choices. I think anything that triggers
          scrollable overflow should not be on this list. Discussing
  smfr: Things that trigger resource loads?
  chris: Definitely disallowed. If you're bringing a network transfer
         you don't want that
  dbaron: Resource loads are async and you see something else in the
  florian: I don't think that's much of a problem. Triggering network
           since async isn't
  dbaron: Worry about background images is we have to define
          background position for these
  fantasai: Right, this is why I'm against background images. I think
            stroke and fill images are pinned to geometry of element
            box so wouldn't have same issue. We could do that for
            backgrounds in theory
  fantasai: For these images you don't want the to reset tiling on
            every element. As you highlight and there's a span it
            breaks the tiling. I don't know how you fix that and make
            it consistent, but also give controls to author. For that
            reason I think don't allow images. Unless geometry is
            tagged to what's in document and not selection area, then
            we can consider it
  fantasai: I can come up with definition pegged to document element
            or controllable by author, but not both.

  smfr: I'm not sure original motivation of the issue was
  daniel: For completeness. I didn't think this required a re-flow at
          the time. I was filling out for completeness
  AmeliaBR: It's worth discussing because we have impl of
            webkit-text-stroke where some implementors support it.
            There are different decisions out there. But that's not a
            proposal in a spec. We need to discuss properties in the
            spec and where should images be anchored when painting a
  fantasai: That's specified in the spec now. We had to get it right
            to make it useful. There's a property to control that
  daniel: I must have missed something. What are we trying to decide
  fantasai: What is the list of properties for section 3.2. I'm happy
            to include stroke-color and fill-color. That seems
            straight forward
  AmeliaBR: Only difficulty there is currently the shorthand stroke
            property which is what's impl if you're switching color to
            none it's not defined how it effects the stroke-color
  fantasai: There is a definition in fill stroke spec. I think it
            doesn't quite match SVG and we created a shorthand/
            longhand relationship and we figured it was backwards
            compat on existing content
  fantasai: We're going with fill stroke spec, it doesn't matter if
            it's shorthand it will reset the longhand. CSS expands and
            looks at longhand, doesn't look at shorthands. If author
            says stroke:blue it sets stroke-color:blue
  AmeliaBR: So deciding which properties apply you can use stroke
            shorthand in the ::selection rule and some parts will have
            effect and some not?
  fantasai: Yeah. We ignore properties not supported

  AmeliaBR: I can't remember who said it, but we can start with the
            more restricted set and expand it
  AmeliaBR: I think it's reasonable to say stroke-color and fill-color
            are acceptable in the highlight styles, implementation can
            extend that to prefixed similar properties if they choose
  daniel: For right now just exclude stroke-width?
  AmeliaBR: Yes since that seems the controversial one
  daniel: I'm fine with that
  AmeliaBR: I do think it's probably a good longterm strategy to think
            about and outline the underlying principles for that set
            of highlight styles and what should be considered when
            allowing/disallowing styles.
  AmeliaBR: Not sure who wants that job
  fantasai: Main principles is they can't effect layout, including
            scrollable. Can't trigger resource load (for now). Can in
            some cases trigger ink overflow because we've got text
            decoration in there?
  fantasai: Not sure how we want to deal with that

  Rossen: Should we take that later on and try to resolve on this
  Rossen: There was some agreement around having stroke-color and
          fill-color participate in highlight styles
  Rossen: Anything else we need before I call for objections?
  dbaron: Summary of how our proposal disagrees with current impl?
  Rossen: dbaron, we need to include it as part of the resolution? Or
          capture it someone?
  daniel: I have a patch for webkit and I'm implemented it for
          stroke-color and fill-color in that patch.
  Rossen: I just wanted to hear from dbaron
  dbaron: I was saying I thought it was useful to understand what was
          going to have to change as a result of the resolution
  Rossen: Wasn't that it needed to be in the resolution, but it has to
          be clear in the issue what the effect of this is to the
          current impl
  dbaron: Just like to know how far from current impl is the thing
          we're going to resolve on
  Rossen: Sounds like webkit is implementing. Blink?
  AmeliaBR: I think the only issue is we do have impl that support the
            width effect which we're not including.
  AmeliaBR: If there's any ones that don't...FF is only one that
            doesn't support stroke and fill color changes. But we're
            talking a mix of prefixed property impl. We don't have
            impl of stroke-color as spec.
  fantasai: We want to make sure there's a path to change from prefix
            to standard. If we have features in prefix we don't allow
            in standard we have to revise

  fantasai: We can say stroke-width is supported, but ink overflow may
            not recalculate
  florian: Not sure what effect of not recalc would be
  fantasai: Glitchy rendering
  dbaron: Typically glitchy rendering at future repaints
  Rossen: Let's see if we can resolve
  Rossen: Are we ready to resolve?
  Rossen: Objections to specify stroke-color and fill-color are
          accepted in highlight styles?

  RESOLVED: Specify stroke-color and fill-color are accepted in
            highlight styles

  fantasai: What about stroke-width. If it's supported in prefixed
            version, what do we do?
  dbaron: Does stroke-width trigger scrollable or only ink?
  AmeliaBR: Only ink
  fantasai: Which implementation support webkit-stroke and fill for
  AmeliaBR: Chrome and Edge. I assume safari, but I need someone to
            confirm using the codepen
  Rossen: We're certainly supporting
  AmeliaBR: Edge doesn't support fill and stroke on SVG text, but FF
  Rossen: Depends on version of SVG. In last one we released that
          should be fixed
  fantasai: If it's webkit prefix it's strong enough compat that we're
            going to have support the functionality that maps to.
            Otherwise we don't give authors ability to transition out
  fantasai: We need to figure out what the functionality is and put it
            in the list. What do other people think?
  florian: Reasonable to me, but I'm not an implementor
  <AmeliaBR> Correction to my last comment: FF doesn't support
             selection fill & stroke on SVG text, either. Demo of
             selections on SVG text:
  daniel: What's the question?
  fantasai: First is if safari supports webkit prefixed stroke and
            fill properties in selection. Second is if webkit prefixed
            stroke-width is supported in selection, does that mean we
            have to put it in the spec? If we all impl under a prefix
            we should do it in the regular.
  daniel: I'm looking
  <leaverou> AmeliaBR: codepen seems to work in Safari (and has
             somewhat better rendering in fact)
  <AmeliaBR> HTML strokes and selection:
  daniel: We do support stroke-width
  fantasai: Then we have to do it, regardless of it's a good idea
  florian: I think so unless other browsers have a good reason

  smfr: Might mean selection is slightly slow/choppy because we're
        doing relayout.
  fantasai: Or are you assuming you left space?
  smfr: I'll have to check
  fantasai: Adding stroke-width to spec or will browsers remove?
  smfr: I don't think we'll remove.
  dbaron: I'm fine with adding it.
  Rossen: User PoV it's better behavior
  Rossen: Objections to add stroke-width to the set of properties?

  RESOLVED: Add stroke-width to the set of properties

  Rossen: That's the top of the hour

Mark unimplemented CSSPseudoElement features at-risk
  github: https://github.com/w3c/csswg-drafts/issues/3540

  fantasai: I have ^ open for having properties at-risk. I'd like to
            invite feedback for next call
  Rossen: Let's put it on agenda for next week and we'll give people a
          week to review
  Rossen: That's the end of today's call.
  Rossen: We'll chat in a week.

Received on Thursday, 31 January 2019 00:53:33 UTC