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

[CSSWG] Minutes Telecon 2018-07-25: CSS Text, CSS Inline, CSS Shapes, CSS UI 4, Fonts 4 [css-text] [css-inline] [css-shapes-1] [css-ui-4] [css-fonts-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 25 Jul 2018 19:33:34 -0400
Message-ID: <CADhPm3tqpFnuK74PMdUYPDoSCS23ny2Rin+Zq1+Mu891G78E0A@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.
=========================================


CSS Text
--------

  - fantasai requested assistance from experts for issue #698 (cursive
      shaping breaks needs better scoping). myles offered to review
      and Rossen will ask a font expert from Microsoft to review.
  - RESOLVED: No to renaming hyphenate-character and add normative
              text describing how UIs are allowed to truncate
              additional characters (Issue #2809)

CSS Inline
----------

  - RESOLVED: Change the initial-letter value to initial-letters
              (Issue #862)
  - A new github issue will be opened (Issue #2950) to try and find a
      new name for initial-letters as the current name makes it seem
      like a selector.
  - RESOLVED: No change is needed (Issue #2703: Initial letter,
              sizing, and overflow)

CSS Shapes
----------

  - RESOLVED: Accept the changes as stated in the issue (Issue #2375:
              Degenerate polygons with positive shape-margin)
      - Issue summary:
          - Zero-area shapes still have edges and those edges impact
              float layout.
          - Zero-area shapes can be expanded by shape-margin values.
          - Zero-area shapes will not affect floated elements that are
              block adjacent -- there is no minimum of 1 pixel area
              applied to the shape.
          - Limit the inset rectangle to a minimum of zero width/zero
              height, using rules similar to how border-radius values
              that add to greater than 100% are adjusted.

CSS UI 4
--------

  - RESOLVED: Accept florian's proposal (Issue #285: Readonly form
              control and user-select)
              [Proposal (to be word-smithed into a PR for review): an
              editable element is either an editing host or a form
              control with normally mutable textual content such as
              textarea, even if this form control is in non mutable
              state.]

Fonts 4
-------

  - RESOLVED: Defer this issue (#528: May want different properties
              for font matching and variation value) to next level.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jul/0032.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  Tantek Çelik
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Tony Graham
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Ian Kilpatrick
  Myles Maxfield
  Thierry Michel
  Liam Quin
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Greg Whitworth
  Zheng Xu
  Fuqiao Xue

Regrets:
  David Baron
  Peter Linss
  Manuel Rego Casasnovas
  François Remy
  Melanie Richards
  Lea Verou

Scribe: dael

Administration
==============

  Rossen: As usual I wanted to check if there are any additional
          agenda items anyone wants to add or any changes.
  Rossen: We'll remove item #5 as suggested by florian
  Rossen: Anything else that we need to change?
  myles: Might be valuable to discuss should initial letter be plural
         along with should hyphenation-character be -characters?
  Rossen: Can you find the issue?
  myles: Yeah.

  Rossen: Admin items:
  Rossen: #1: Reminder to those going to TPAC, prices will go up soon.
          Register early, book hotels early. Just a reminder.

  Rossen: #2: As many of you have heard liam will be parting ways with
          W3C end of the month. We have a new staff contact, Fuqiao Xue
  xfq: Hi everyone my name is Fuqiao.
  * xfq waves
  xfq: I just joined the group and I'm very pleased to join. I've got
       a lot to learn and will like to work with you.
  <astearns> welcome, xfq
  <dauwhe> welcome!
  Rossen: Thank you xfq, we're excited to have you
  <fantasai> +1
  <florian> xfq, welcome! 欢迎!
  <xfq> thanks all!

CSS Text
========

cursive shaping breaks needs better scoping
-------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/698

  Rossen: Who wants this? fantasai?
  fantasai: This was from F2F. Not sure there's anything to talk
            about. Trying to figure out what to put. There was a lot
            of pushback when first drew up text to not being specific
            enough. There's a lot about shaping like Arabic doesn't
            need a lot of assistance like more complex scripts
  fantasai: Issues is because there's a certain amount of shaping you
            can do across font changes. In terms of what edits need to
            be made brings in a question as to how to handle other
            aspects of glyph shaping.
  fantasai: I don't know enough about this to figure out the issue.
            There's a long thread. I'd appreciate help from someone
            who knows more about this topic.
  myles: I can take a look. I have some opinions but no proposal. I
         can come up with something for next call
  fantasai: That's all on this one. I need help.
  Rossen: I'll get our fonts people to look and comment and ideally we
          can resolve on github and put on agenda for resolution.

CSS Inline
==========

should `initial-letter` be plural?
----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/862

  <myles> https://github.com/w3c/csswg-drafts/issues/2809
  Rossen: As myles pointed out there's another related issue ^
  Rossen: hyphenated-character
  fantasai: Slightly different issues, I think, in sense that
            hyphenated-character is one character and if it's more
            than one unicode code point it's one thing from user
            prospective
  <TabAtkins> (the word fantasai is searching for is "grapheme
              cluster")
  fantasai: From author prospective it's a character from what I've
            heard of
  Rossen: Let's do initial letter and then hyphen

  fantasai: initial-letter was originally plural and we decided to do
            that to make it clear that not only can you put multiple
            characters but also because it can apply to not just
            first-letter pseudo element but also the span which can
            have >1 character
  fantasai: Intent to plural was to make it more clear you can do that
  fantasai: Reason it's an issue is because it's already shipping in
            webkit
  dauwhe: prefixed
  fantasai: It becomes an issue about compat if we're going to change
            name
  <tantek> yes please keep it singular
  dauwhe: This was an editing error in early spec stages. Probably 99%
          of use cases will be a single letter so I'm relatively
          agnostic.
  <tantek> let's not design by edge-case
  fantasai: I would change if even for single letter case it's a
            property effecting multiple
  fantasai: Problem is it's not just webkit shipped, it's that
            documentation written uses current name.
  <tantek> also consistent with :first-letter
  <myles> initial-item?
  fantasai: I don't think it's an edge case as that it's not as common
            in English. Dutch it's more common to have multiple. We
            have had requests for "what about first word" and you can
            do that. That it says initial-letter guides people to
            assume you can't
  dauwhe: You can educate people, though.

  florian: From my pov I have slight preference for plural, but given
           slight compat issue I don't care strongly. I have another
           issue is that it describes what it applies to, not what it
           does. People keep thinking of this as a selector. In our
           last F2F there were questions making it seem like a
           selector. I don't have a good alternative, but I think this
           name is a problem because it looks like selector
  <tantek> agreed that it does sound like a selector
  Rossen: Valid point. Do we have counter proposals? If we don't I
          would prefer to take that discussion back to github.
  florian: It could be drop-cap but it also does initial. I don't know
           if there's a generic term for drop or raised caps
  fantasai: There isn't really which is how we ended up with
            initial-letter
  florian: But I think that's the problem more than pluralization. I
           don't think single or plural matters enough
  myles: Not sure how much compat is relevant because it's prefixed.
         But I think florian's point is right
  <myles> dauwhe: will you open up the other issue?
  <florian> Would "lettrine" work, or is that too obscure?

  Rossen: We have options. Resolve the current issue and it seems most
          people lean not plural. Then we continue discussion here or
          separate as to if this is proper name.
  jensimmons: I like the idea of thinking about another name. If we
              can't think of one I do like switching to plural. I
              don't think it's clear it would work on multi-letters. I
              don't think it's compat issue because not many people
              are using it.
  fantasai: I don't think we have a web compat issue in terms of
            content. Do you think there's a lot of documentation out
            there?
  jensimmons: No. I've been talking about it more than most in the
              industry. I think it would be easy enough when it ships
              for real to have a new round of education. The handful
              of docs could update or they're ancient.
  <gregwhitworth> +1 to what jensimmons - if we update MDN and caniuse
                  we'll be good
  fantasai: Then I lead toward make the change and then look for a
            less confusing word.
  fantasai: because if even members of WG are confused as to if it's a
            selector, we could hopefully do better.
  dauwhe: I'm fine resolve for plural and hope for a new word
  <tantek> how about take it github as Rossen suggested?
  <dauwhe> tantek: I will open new issue for property name

  Rossen: Objections to change the initial-letter value to
          initial-letters?

  RESOLVED: Change the initial-letter value to initial-letters

  Rossen: Rest can go to github and if there's a proposal we can go to
          the working group

  Rossen: myles still do hyphenated character now?
  myles: still relevant

CSS Text
========

hyphenate-character doesn't accept just a character
---------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2809

  myles: It allows you to put in a whole string so hyphenate-character
         seems disingenuous
  fantasai: I think from user view it's a single character that goes
            in there. hyphenate-string seems fine
  fantasai: But I think we have impl shipping
  <tantek> why *-letters vs *-string ?
  <fantasai> tantek, because initial-letters doesn't take a string,
             but this one does?
  myles: We are one of those implementors. I was thinking you could go
         other direction and have it accept a string and all grapheme
         clusters except first get ignored
  fantasai: Happy to have UA truncate appropriately. Not sure first
            grapheme cluster is enough. There's CJK punctuation that's
            >1 code point. If that's covered seems fine
  myles: How about we don't have to specific details and have that as
         a separate issue. We can say text is truncated to something
         similar to a grapheme cluster
  fantasai: At min include 1 grapheme cluster

  fantasai: Other comments?
  fantasai: Proposal: hyphenate-character keeps name, but UI may/can/
            should truncate if it's more than one grapheme cluster
  myles: Should be normative
  florian: Decide how strict?
  florian: If we're not sure may/can/should we should decide.
  Rossen: Let's resolve on renaming property. We're saying no and add
          normative text describe how UI are allowed to truncate
          additional characters
  Rossen: Objections?
  <florian> I'd go with "required to truncate" rather than "allowed to
            truncate"

  RESOLVED: no to rename and add normative text desc how UI are
            allowed to truncate additional characters

CSS Inline
==========

Initial letter, sizing, and overflow
------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2703

  fantasai: florian do we need to do anything on this?
  florian: I don't think need to discuss now. Probably fine, I'll
           re-read
  Rossen: Resolve no change?
  florian: Yeah and I'll re-open if I find something

  RESOLVED: no change is needed

CSS Shapes
==========

Degenerate polygons with positive shape-margin
----------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2375

  TabAtkins: The current shape spec has text about degenerate
             polygons. It makes them not create a shape, text can
             pierce through.
  TabAtkins: It doesn't have a special case for a positive shape
             margin where actual exclusion area is non-0. We should
             amend the spec so things with positive shape margin are
             treated as having a positive area
  TabAtkins: Issue goes further that the ruling about degenerate
             polygons is wrong and we should remove. SVG has similar
             issue where if trying to stroke a path and size of box
             for stroking is determined by fill rectangle. Can be 0
             area and triggers special cases where it isn't stroked
             and causes strange cases.
  TabAtkins: Get similar issues where if animating polygon and if all
             points line up you temporarily get entire layout to shift
             as it no longer excludes. Issue argues we remove special
             casing
  TabAtkins: I looked at our code with iank and he supports it because
             it's removing special case
  TabAtkins: Only complication is you can have negative margins and it
             can shrink spacing to 0. With degenerate rule you didn't
             have to worry about where 0 is. AmeliaBR's suggestion
             sounds reasonable at first glance to solve. It's
             relatively corner case.
  TabAtkins: Larger is should 0 area be an exclusion
  TabAtkins: Chrome supports the change.

  Rossen: Other perspective?
  astearns: I support what's discussed in issue. Question: you can
            have polygons with inverted areas, not just a line but
            they're crossing and inverted area inside. If you have a
            positive shape margin in that case does it have to
            overcome the inverted space or do we define inverted space
            to un-invert
  <myles> what is inverted space
  <myles> winding order?
  TabAtkins: Good question, don't have best answer. Related to when
             you over-deflate. Should a really big negative margin
             cause positive shape. Should they
  <tantek> there's a similar question / issue with negative outlines
  fantasai: They don't. We won't change that.
  TabAtkins: Why?
  fantasai: Right now if you have a float with negative margin on both
            sides that won't turn into a positive shape
  TabAtkins: It's a shape-margin not a normal one.
  fantasai: shape-margin is positive only?
  TabAtkins: Nope
  fantasai: I still think same principle should apply. Why can't you
            create a rectangle with the same behavior as a float.
  TabAtkins: There's a lot of difference with shape and shape-margin
             so I don't know yet. I'm happy to figure it out as we go
             along. Don't think we need to resolve to resolve this
             issue
  <tantek> regarding what astearns said about inverted areas, here is
           another way we end up with inverted areas (and incompat)
           https://github.com/w3c/csswg-drafts/issues/2892

  astearns: Clarification: It sounded like polygons with just lines
            and a positive shape margin will add their shape to
            exclusion area. Also polygons that are just lines will
            include line edge even without margins
  TabAtkins: Correct
  TabAtkins: There's a special case in our shape code and it skips by
             it currently. We just remove that check.
  astearns: I propose we take what's in the issue, put in spec, and
            attempt to spec inverted areas and bring to group

  iank: One other thing, I filed an issue, but there will be bugs if
        we do just a paragraph. When we do this change I'd prefer we
        define how a line-box intrudes into a float with a shape
        outside and write out algorithm.
  iank: Otherwise someone will do something slightly different and we
        get compat bugs
  iank: It's issue #2949
  iank: I looked at Mozilla code and they have same concept in their
        code
  astearns: Thanks

  Rossen: Going back to this issue
  Rossen: Can we take the resolution proposed by TabAtkins?
  astearns: I'm fine
  TabAtkins: proposal: we take what's in the issue, put in spec, and
             attempt to spec inverted areas and bring to group
  Rossen: Objections?
  astearns: Agree with issue and bring it into the spec to match
  Rossen: Accept the changes as stated in the issue. Objections?

  RESOLVED: Accept the changes as stated in the issue

CSS UI 4
========

Readonly form control and user-select
-------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/285

  florian: Recap: across all browsers afaict when you have editable
           text area regardless if form control or from
           contenteditable. When you start selection inside it it
           can't extend outside. Selection is trapped within
  florian: This behavior is exposed in user-select as contain. Current
           spec says on editable elements it always does contain.
           Currently spec as editable content is mutable form controls
           and contenteditable elements. Mozilla raised that read-only
           form controls are not mutable so we should update spec
  florian: Second part is once we do it for normally mutable but
           currently unmutable switching to user-select: none might be
           okay. Not clear how editing would work with selection
           disabled and no one wants to do that.
  florian: So making contain apply to normally mutable but not
           currently mutable and then making contain switch to none
           for those.
  florian: Should I wordsmith that into spec or do people think I
           missed something?
  * tantek reviews the issue
  Rossen: Opinions?

  Rossen: Objections to accepting florian's proposal to the spec?
  <tantek> I'd prefer to get Xidorn's opinion
  Rossen: I think it's time to force progress since it's gone through
          3 F2Fs.
  <tantek> can we discuss in APAC call?
  <tantek> otherwise I do not object
  Rossen: tantek xidorn can add his opinion on github.
  florian: We're resolving in favor of his opinion
  tantek: I'm asking that...florian if that's true can you put that
          into the issue? Just a back and forth to confirm. Why not
          make sure. You've got wordsmithing, put it in the issue,
          give xidorn a chance to say yes
  florian: Can I put in PR and merge when he says okay?
  tantek: Sure

  RESOLVED: Accept florian's proposal

  Rossen: Summary is form controls should be selectable?
  florian: More complicated
  florian: I'll create a PR with proposal and merge
  Rossen: We'll look at your PR

Fonts 4
=======

May want different properties for font matching and variation value
-------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/528

  myles: Right now for font variations the properties are partitioned.
         Set A effects font selection and set B doesn't. A is
         font-weight, font-style, font-stretch.
  myles: You use value of those to find a font and if it has range of
         values to which the requested width or slope is applied
  myles: For those properties they both are used to choose fonts and
         then they select a point in design space. Issue asks how to
         separate concepts. I want to select a font-weight but not
         have it effect font selected.
  myles: There is a way, you can use font-weight properties to do
         font-selection and after that you can use font-variation
         settings of 'wght' and that separates the values. It's not
         very clean, but it will work the way you want. It's just not
         as nice
  fantasai: If don't do that then...If you had a variable font and you
            just want to use for all weights on page and you're using
            3 weights then you would have to create a new @font-face
            rule for each weight that's pegged to that value and map
            that to a value on the variation axis
  fantasai: That would work if you had fixed number of weights and you
            knew what you would use.
  fantasai: If you were animating weight that won't work because you
            have no mapping for intermediate values
  myles: font-face descriptor allows range
  fantasai: Font variations doesn't. So if you have a font-weight
            descriptor that's 400-800 and then set font variation
            settings as a default of 500 then you've said this font
            which is gonna be rendered at 500 always is the 400-800
            range. If I ask for the 400 I get the 500 because it wins,
            right?
  myles: right
  fantasai: You can't create the mapping...you can do it for a single
            point but not a range

  florian: I think a use case would help
  florian: I think a typical thing is you're using your main font for
           lots of things, but for '&'' you want a different font.
           Non-variable you use unicode range to subset and you decide
           that it looks good at a different size. With @font-face you
           can do that. With variables you try and do the same thing
           where the '&'' font is about 200 more weight than main font
           you can't do that. You can lock it for specific values, but
           not on range
  florian: I think we want in the @font-face rule you can map a range
           to another range. At font-selection if there's a font
           between 500-700 I'm good and it corresponds to 700-900. Or
           something along those lines
  fantasai: Agree that's what needed to solve. Have a similar issue as
            related to size. It's a bit easier because it's constant.
  florian: I think the problem isn't too bad because you can slice per
           linear range you can do it if you have mapping

  fantasai: I think we should solve this, but defer to next level. not
            super critical, but we do need to...people are shipping.
            We should get set of features to ship and get the spec to
            CR. I agree it's a problem and we should look to solve
  myles: I'd like to hear from designers about the problems they're
         trying to solve
  fantasai: And defer would give time for that to happen
  Rossen: myles okay to defer or did you want to hear now?
  myles: defer is fine
  florian: Okay to defer
  Rossen: Objections to defer this issue to next level?

  RESOLVED: Defer this issue to next level

Admin
=====

  Rossen: myles any of the remaining topics we can do?
  myles: Don't think we can do any remaining in 2 minutes
  Rossen: Anything else that's 2 minutes?
  Rossen: If not we can adorn.
  Rossen: Then we're adjourned.
  * liam waves bye as this is my last css call
  Rossen: Next Wednesday is APAC time
  Rossen: Thanks xfq for joining
  Rossen: We'll chat in a week
Received on Wednesday, 25 July 2018 23:35:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 25 July 2018 23:35:11 UTC