[CSSWG] Minutes Telecon 2018-09-26 [css-text-3] [selectors] [css-scoping-1] [css-text-4]

  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 3

  - Since word-wrap:break-word cannot affect min-content due to web
      compat there is now a need to achieve that behavior through
      another method. Discussion is ongoing in github #2682 to
      determine the best approach and anyone interested is encouraged
      to participate.

February F2F

  - Location is still unknown for the February F2F but there is work
      in progress to produce alternate locations.


  - RESOLVED: Add :blank for input selectors (Issue #1283)
  - RESOLVED: :empty does cover white space (Issue #1967)


  - RESOLVED: Specificity of :host() is 1 pseudoclass + specificity of
              argument. (Not just specificity of argument.) (Issue

CSS Text 4

  - RESOLVED: Accept the proposal from fantasai and Kobayashi-sensei [
              keep the full size of the larger glyph and trim smaller]
              (Issue #1668)


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Sep/0018.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Emilio Cobos Álvarez
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brian Kardell
  Chris Lilley
  Nigel Megitt
  Thierry Michel
  Anton Prowse
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Lea Verou
  Sean Voisen
  Greg Whitworth

  Tantek Çelik
  Peter Linss
  Stephen McGruer
  Manuel Rego Casasnovas
  Jeff Xu

Scribe: dael

Agenda Setting
  Rossen: Reminder to book TPAC travel if you haven't already. Airfare
          is going up, hotel availability is going down.
  Rossen: Let's get started
  Rossen: As usual I wanted to see if there are additional agenda
  florian: Did you see my email?
  Rossen: I did not. Let me see.
  [email hunting]
      There's been two more issues marked Agenda+ since you compiled
          this list, and since the agenda is quite light, maybe we can
          take them on as well:
      5. [css-values] Define <'property-name'> notation to exclude
          listification https://github.com/w3c/csswg-drafts/issues/3146
      6. [css-text-4] text-transform: full-size-kana
  Rossen: Sure. We can try. Thank you. Anything else?

  Rossen: Is TabAtkins on?
  Rossen: I wanted to see if there was Feb F2F updates.
  Rossen: Perhaps someone can ask him or he'll see the minutes since
          he's not on

CSS Text 3

word-wrap/overflow-wrap: break-word should affect min-content
  github: https://github.com/w3c/csswg-drafts/issues/2682#issuecomment-421705575

  fantasai: Summary: we discussed making word-wrap:break-word affect
            min-content since that's desired. Mozilla implemented and
            found it not web compat. We reverted changes and re-opened.
  fantasai: What do we want to do to solve this use case.
  fantasai: I don't think we have a concrete proposal. There have been
            comments. One option is tie this to word-break:break-word
            which is impl by webkit and has that behavior. Another is
            add a different value to overflow-wrap property
  fantasai: Another is to have a property that sets the min content
            size explicitly, dbaron has proposed that in the past.
  fantasai: Those are options discussed. I don't have a clear idea of
            what I think is best. Wanted to bring up.
  florian: Obvious thing to do is standardize what webkit shipped, but
           that value doesn't make sense on the property where it was
           added. That's weird and confusing so we're looking for
  Rossen: Any other opinions?

  Rossen: Should we perhaps put this back for discussion on github and
          once there's a concrete proposal we can try to resolve?
  fantasai: I'm happy to take back to github but I wanted to make sure
            this is on people's radar. I want to resolve, but not
            right now since there isn't a clear path.
  Rossen: So move back to github and encourage discussion?
  fantasai: Yeah.
  Rossen: Thanks.

February F2F

  TabAtkins: After getting approval from my manager and looking into
             hotels I got word from higher management that Hawaii
             isn't best to go because there's a policy to host in
             Google places
  TabAtkins: Alternates: Google Malaysia and Google Singapore. Do
             either sound good?
  leaverou: Nice but further.
  <astearns> +1 to either
  dbaron: From bay area they're further then Australia
  florian: For me closer
  fantasai: Google LA or something? In terms of getting people there
            that's less painful flights
  jensimmons: Want to vote for something that's not such a long haul.
              No events in north America is hard.
  TabAtkins: We have LA and that's fine.
  florian: I have 3 meetings in north America between Jan and June so
           not really looking for another but maybe that's me.
  TabAtkins: Hawaii was equidistant, but we don't have an office there
             so we have to go with one side.

  fantasai: Japan or SF/LA is one long flight rather than 2.
  Rossen: San Diego?
  TabAtkins: I don't think so but I'm not sure.
  Rossen: That was great when plinss hosted.

  florian: Should I try for Kyoto? Or would people rather another
  Rossen: TPAC next year already.
  chris: Prefer to avoid because I've already got multiple meetings
  fantasai: I suggest west coast US then. I think putting a lot of
            people on back to back long haul isn't great for F2F. When
            we had a lot of people in Sydney it made sense, but now we
            don't have anyone so maybe not a general policy.
  florian: If it's just me, whatever
  fantasai: If you want east Asia, Taipei or Seoul
  TabAtkins: We rejected Seoul due to mid-winter
  <gsnedders> I suppose also Vancouver if we're still mildly trying to
              avoid the US? There's a Google office there, no? Though
              I have no idea of size.
  dbaron: I'd prefer Japan twice over Singapore or Malaysia. Between
          Singapore and Malaysia, Singapore is easier to get to right
          now due to competition in SFO-SIN flights. But it's an 18h
          flight from SFO

  Rossen: We have, from what I hear, Singapore, perhaps Japan though
          that's 2x in one year, West Coast US
  TabAtkins: San Diego probably doesn't have meeting space for us
  Rossen: More space in LA?
  TabAtkins: Looking.
  Rossen: Or we head to Europe again but that's twice Europe.
  florian: I'm loudest complaint on west coast and Europe doesn't help.

  Rossen: TabAtkins thank you for the update and we appreciate the
          effort. Let's end here and once you have an idea of the
          possibilities for locations of west coast or Singapore we
          can come back next week or over mail.
  Rossen: Thank you.

  <jensimmons> I definitely prefer west coast of North America. Let’s
               pick a major hub city for international flights — like
               Vancouver or LA. We also have a lot of office space
               available in San Fran, Mountain View…. lots of options.

  <TabAtkins> Okay, LA is out too. It's got setups for *much larger*
              meetings, and *slightly smaller* meetings (16-18), but
              nothing in our sweet spot.


decide on :blank
  github: https://github.com/w3c/csswg-drafts/issues/1967

  fantasai: There's a related issue to decide first.

Add selector for blank inputs
  github: https://github.com/w3c/csswg-drafts/issues/1283

  fantasai: Adding a selector for blank input fields
  fantasai: If we want to do that blank is the best name. If we do
            that we can't use blank for meaning empty.
  fantasai: Comments, thoughts?
  fantasai: We can reserve the name and not resolve to add or decide
            we don't want to do this.
  dauwhe: Also have blank selector in pages
  <bkardell> :blank seems right for inputs to me

  fantasai: Yeah. That's a different scope so not a naming conflict
  Rossen: Opinions?
  fantasai: Options:
  <fantasai> a) Decide to add :blank for input selectors
  <fantasai> b) Decide to reserve :blank but not resolve to add yet
  <fantasai> c) Decide we either don't care about blank inputs or
             don't want :blank for them regardless
  fantasai: We should decide on a/b/c and then go back
  <bkardell> my opinion is above -- a)

  Rossen: This was 1283, right?
  fantasai: Yeah
  Rossen: I see one opinion
  fremy: I just looked and I like using a function on empty and
         specify if whitepsace is a parameter.
  fantasai: That's issue 1967

  dbaron: One proposal in the past is have an attribute selector like
          syntax that you can use with form control. A way to put form
          value into attribute selector syntax.
  fantasai: Would it handle all the relevant use cases?
  dbaron: White space variations on empty string? Or does that not
          matter as much?
  <dbaron> e.g., input[:value=""]
  <bkardell> i would think it would matter for input
  fantasai: Don't know. If we go with functional notation for empty we
            might want same here.
  Rossen: We can add 'ish' param ^-^

  Rossen: Back to original options, can we narrow those down?
  fantasai: I suggest a or b which means not use :blank in 1967
  <bkardell> are we not considering @dbaron's idea
  Rossen: 1283 is we're supposed to use blank. That's option a
  fantasai: I think for the question of blank inputs we can go with
            dbaron option or we can decide to reserve blank or we do
  <bkardell> can we say the value is trim'ed in dbaron's?
  fantasai: Is blank a thing we would want to apply to inputs or empty
            elements that might contain white space

  Rossen: Opinions?
  nigel: I like the input value idea, it's nicely extensible. If you
         need a keyword is an interesting question. You can also
         define a regex and have a valid/invalid keyword.
  nigel: For input controls, nonvalid and invalid are the obvious
         categories as a min. If you need a test for particular
         strings is a bit much
  <fantasai> nigel, see Chapter 12 in https://www.w3.org/TR/selectors-4/
  fantasai: Have required and optional, but we don't have hey is this
            input empty or not.
  <bkardell> nigel I think part of the question is still whether " "
             is the same as "" or null
  <nigel> @fantasai - thank you for the pointer!

  gregwhitworth: I don't hear strong opposition to blank [missed]
  fantasai: Empty wouldn't work on inputs because they're empty
  gregwhitworth: I think I lean toward a
  nigel: Blank being different from some white space can be considered
         to be the same as opposed to empty which can be literally the
         null string
  gregwhitworth: I don't disagree but I feel we're in a weird world
                 with empty and invalid. Invalid would hit the regex
                 pattern I think.
  gregwhitworth: Trying to solve a lot of same problems with 3
                 classes. That's probably why fremy wanted to lean
                 toward functional. I think we can bikeshed name later
                 but I don't know anything better.
  <fremy> @gregwhitworth: I was thinking about `:empty(value)` for

  <bkardell> dbaron's thing sidesteps the naming issue if we can say
             the value is trimmed?

  Rossen: I agree with gregwhitworth. I would prefer to make more
          progress so we can go back to 1967.
  Rossen: Objections to "Decide to add :blank for input selectors"

  RESOLVED: Add :blank for input selectors

  Rossen: nigel to gregwhitworth's point we might come back and

  <nigel> I don't follow why we don't use the same definitions for
          blank and empty as are in selectors §13.2 and 13.3

decide on :blank
  github: https://github.com/w3c/csswg-drafts/issues/1967

  fantasai: The discussion was about...one of the problems with empty
            selector is it does not select elements with only white
            space. Those are fairly common. <li>enter<li> will auto
            close and have a line feed and therefore is not empty.
  fantasai: Issue was can we have a selector that means actually empty.
  fantasai: Last conversation was either add a second selector that
            means empty and ignore white space or redefine :empty
            where if it contains white space it's still empty
  fantasai: Discussion on webcompat, weren't many instances of empty.
            Daniel wanted a distinction somehow. Point that
            empty-cells ignores whitepsace the same way we proposed to
            redefine :empty.
  fantasai: After that discussion Brad proposed making empty a
            functional pseudo class to have different kinds of empty.
            That's where we're at.

  Rossen: What's the favored proposal in your PoV?
  fantasai: Ideally :empty would look from the author prospective and
            ignore whitepsace. If need more options make it a
            functional pseudo class
  <TabAtkins> I agree that :empty's current definition is just plain
              too strict to be worthwhile. I bet we can loosen it by
              default, and don't need to make it controllable.
  <gregwhitworth> I agree with TabAtkins here. Probably a good default
                  is not to include white space
  bkardell: Definition of :empty is so strict that I feel part of the
            ask is to lessen that strictness. I don't know that
            getting that wrong will be more helpful.
  bkardell: Example if it has a link tag or style tag would an author
            consider that empty? What about a hidden attribute?
            Comments are a different node type so they don't count.
            This raises a lot of questions we should carefully
            consider or it'll be similarly disappointing.
  bkardell: How close can you come to what people want.
  florian: Good idea to consider these things you've listed. Driving
           use case is indenting and self-closing tags. Just loosening
           to consider white space would pretty much cover the use
  bkardell: Lots of comments and articles about editors. Closing is
            one, but Daniel brought up last time an editor when you
            create something with nothing in it how to style that is
            tricky. Other blog posts looking for that. Other blog
            posts wanting more.
  bkardell: Not sure why we say the use case is that unless we're sure.
  <TabAtkins> We can't ignore <style>, unfortunately - you can display
              those! (and make them contenteditable, for live-editting
              of a stylesheet).
  <TabAtkins> But yeah, ignoring white space-only text nodes seems A-OK
  florian: Not sure I see the use case for a selector that only
           selects link elements.
  florian: Why would you want to select these things specifically?
  bkardell: Not only things with link. Select something that from
            author standpoint thinks is empty. Functionally if you add
            something from an editor it may have content, but from the
            viewer/author prospective it's empty.
  florian: I hear you but don't agree.
  <TabAtkins> You can display a <link> too...
  <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6230
  fantasai: A lot of these selectors won't work if you don't
            understand your markup. That's true for :nth-child and
            :only-child. The structural selectors don't work with
            stray elements in the markup. That as a driving use case
            doesn't make a lot of sense. If you're in that world you
            need to put classes on. You can't use these without
            control on markup.
  florian: As TabAtkins put in IRC you can display most of what you
  fantasai: Definitely we can't change :empty to solve that. We can't
             make things depend on styling. So where there's tags but
             no text if you style that it's very visible. From author
             view it does not look empty. It comes down to are you
             understanding your markup. If you're not the tree
             selectors can't help you. Can't write selectors that work
             based on styling of element.
  fantasai: If a wysiwyg author thinks the thing is empty depends on
            what you see. We can only help authors in markup
  bkardell: Yes, I think what a lot of people want is not possible.
            Thinking through and making the least surprising thing
            seems good.

  florian: I wonder about comments. Are they gone before we do
           selector parsing?
  TabAtkins: They don't show in the dom tree that selectors see
  florian: Only white space means white space and comments
  TabAtkins: And other nodes
  florian: As long as it falls out
  bkardell: Empty clearly specifies that
  fantasai: If our goal is not surprising [missed]
  TabAtkins: Selector modal only sees element and text nodes. Other
             elements aren't seen by selectors.

  florian: I think we circled around. Can we resolve on :empty also
           allowing white space?
  fantasai: sgtm
  <TabAtkins> +1
  Rossen: Proposal is :empty does cover white space?
  florian: Yep.
  Rossen: Other opinions?
  Rossen: Objections to :empty does cover white space?

  RESOLVED: :empty does cover white space

  bkardell: Wanted to clarify we're changing the existing definition
            of :empty?
  florian: Yes.
  bkardell: Last WG there were concerns about that where someone left
            an :empty that was false as a test. No concerns on that?
  fantasai: Last discussion I recall Rossen said he checked and didn't
            see enough use of :empty. Author mistakes or author
            intention it's possible someone put a stray :empty or the
            author put :empty and it didn't apply to every element due
            to white space. Not sure if this would break more uses or
            fix more uses
  florian: But it's rarely used anyway
  <bkardell> yes, me too, what fantasai said
  Rossen: And I just looked at the data since then and I don't see an
          uptick of usage. If there are different numbers we can
  <bkardell> ok, no real objection then
  Rossen: Anything else to resolve?


Specificity of :host, ::slotted, and :host-context doesn't seem to be
  github: https://github.com/w3c/csswg-drafts/issues/1915

  emilio: We resolved on :host and ::slotted for specificity of inner
          selector. Should :host account for own specificity? There's
          incompat. Should *:host be same as :host(*)?
  Rossen: Does anyone have an opinion?
  <fantasai> Question was whether :host(*) should be the same as *:host
  emilio: Should specificity of function a host selector be only the
          selector or selector+pseudo class for specificity. I think
          2nd. That is consistent and increases specificity of the

  TabAtkins: This is inconsistent with :matches, but host on its own
             just making a * argument should be 0 makes me lean toward
             your argument.
  emilio: Works great
  Rossen: Other opinions?
  fantasai: +1 from me

  Rossen: Objections?
  <bkardell> that's a new precedent right?
  <bkardell> nothing else works like that I think?
  <TabAtkins> bkardell: Yeah, new precedent, kinda sorta.
  bkardell: It's the only decision that makes sense, but it's new.
            Nothing else works this way today.
  emilio: Yeah, don't have many pseudo classes with selector arguments.
  <bkardell> +1
  <bkardell> it makes sense
  Rossen: Makes sense as a pattern going forward.
  <TabAtkins> I mean, :matches()/:not() mean *absolutely nothing*
              absent their selector; there's nothing there otherwise.
              :host *does* affirmatively select an element all by
              itself, and then the selector narrows it down.
  <bkardell> right, I agree tab - you explained it well... I was just
             thinking I think that is new and wondering if I was right
             about that - it wasn't about objecting or anything

  <TabAtkins> Proposed resolution: specificity of :host() is 1
              pseudoclass + specificity of argument. (Not just
              specificity of argument.)

  RESOLVED: Specificity of :host() is 1 pseudoclass + specificity of
            argument. (Not just specificity of argument.)

CSS Text 4

text-spacing, closing-opening bracket fullwidth punctuation collapsing
  github: https://github.com/w3c/csswg-drafts/issues/1668

  <fantasai> ] [
  fantasai: Earlier version of text spec...this is about combo of
            closing full width bracket and opening full width bracket ^
  <florian> or )( or 」「 etc
  fantasai: Typically it takes up a full em but that's too much so
            Japanese typesetting cuts that in half. Usually by
            deleting white space of second glyph. Not right if they're
            different font sizes
  fantasai: Kobayashi-sensei says correct behavior is keep space of
            larger or trim 1/4 of each. Change we made was incorrect.
            We should change to 1/4 of each glyph or always use the
            full glyph of larger and cut smaller in half
  florian: He said both is acceptable, but keeping larger is preferred.
  florian: Impl what do you think? Is it hard to keep the bigger? If
           yes we can settle for the good enough.

  <bradk> Seems weird that kerning in the font doesn’t handle that on
          its own
  <florian> bradk, it cannot just be kerning, because that's optional
            behavior, and also when on, needs to work across fonts.

  fremy: I'm not sure we support this kind of font features across
         text nodes. I'm not sure we'd have a path to this
  florian: I suspect it's easier to trim half of the smaller one
           because we might be able to invoke open type features. If
           we do 1/4 of each I don't know open type can do that.
  fantasai: I think I agree.
  fantasai: If there's no feedback from implementors we propose keep
            the full size of the larger glyph and trim smaller.
  dbaron: I'm still trying to understand how much action at a distance
          there is. How much is that making changes at arbitrary
          distance in text.
  fantasai: It's the adjacent character. It's two adjacent characters
            and you have to trim to reduce amount of space.
  dbaron: Just adjacent characters?
  florian: Yes. If there's anything, border, linebreak, anything, it
           doesn't count.
  TabAtkins: Same boundary we use to determine if we can do kerning?
  fantasai: Yeah.
  florian: Don't think. If you switch fonts I think no kerning, but
           this should work.
  fremy: I don't think we have something like this right now.
  fantasai: I don't think anyone does this as L4

  Rossen: From use case PoV it seems this behavior makes most sense. I
          don't believe anyone has impl experience so we can make the
          call on if this is expensive.
  Rossen: What if we try and decide on what makes most sense and when
          we get more impl experience we revisit?
  fantasai: That's fine. And as florian pointed out there's open type
            to help with trimming and they don't 1/4 trim so it's more
  Rossen: Objections to resolving as proposed by fantasai and
          Kobayashi-sensei ?

  RESOLVED: Accept the proposal from fantasai and Kobayashi-sensei

  Rossen: We've got some topics left, but we're at time. Thanks very
          much for joining. Book your trip for TPAC if you haven't.

Received on Thursday, 27 September 2018 00:00:28 UTC