[CSSWG] Minutes Virtual F2F 2020-07-30 Part I: CSS Inline, Open UI Presentation, Selectors [css-inline] [selectors]

  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 Inline

  - There was no strong contender to rename inline-sizing (Issue
      #5189: inline-sizing is too similar to inline-size), but a long
      list of options. People are asked to review and think through
      what's the best name.

Open UI Presentation

  - gregwhitworth presented the current status of the Open UI
      community group. The slides are available here:
  - A lot of research has been done into the problems web developers
      face with form controls, why they feel the solution isn't
      sufficient, and if there is demand for a better solution.
  - There is a lot of desire to be able to have form controls where
      the developer can control some level of presentation but not
      have to rebuild from scratch.
  - The hardest to do elements, especially select, are also the most
  - Work will continue but the group was very excited by the
      possibilities this would open and grateful for the presentation.


  - RESOLVED: Rename to ::file-selector-button [from
              ::file-chooser-button] (Issue #5049: Can you standardize
              a pseudo-element selector for file inputs?)


Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#thursday

  Rachel Andrew, Fronteers
  Adam Argyle, Google
  Rossen Atanassov, Microsoft
  Tab Atkins-Bittner, Google
  Christian Biesinger, Google
  Mike Bremford, BFO
  Oriol Brufau, Igalia
  Tantek Çelik, Mozilla
  Elika J. Etemad, Invited Expert
  Simon Fraser, Apple
  Megan Gardner, Apple
  Daniel Holbert, Mozilla
  Jonathan Kew
  Una Kravets, Google
  Chris Lilley, W3C
  Peter Linss, Invited Expert
  Alison Maher, Microsoft
  Myles Maxfield, Apple
  Nigel Megitt, BBC, and Chair TTWG
  Tess O'Connor, Apple
  Melanie Richards, Microsoft
  Florian Rivoal, Invited Expert
  Devin Rousso, Apple
  Jen Simmons, Apple
  Sam Sneddon, Apple
  Alan Stearns, Adobe
  Greg Whitworth, Salesforce

Scribe: TabAtkins

CSS Inline

inline-sizing is too similar to inline-size
  github: https://github.com/w3c/csswg-drafts/issues/5189

  nigel: Semantics of the feature aren't in question, but name is.
  nigel: Many proposals that people have added to the thread
  nigel: A bit of side topic - if you think about the problem
         differently, this is about extending the background area in
         the inline direction, at the end of each line, so the text
         isn't up against the edge of the bg, often used in captions
  florian: I think we're confusing two features here.
  florian: line-padding is still called line-padding and is in Text 4.
  florian: This is a different feature. Hence its name is confusing,
           since it confused you about it. ^_^
  nigel: Ah right, so this is more about expending the size in the
         block direction
  nigel: But line-padding did come up as a similar topic in the
         thread, as a possible direction to think about things
  nigel: Not sure they should be, they seem distinct to me

  Rossen: So I see line-fit, inline-fit, inline-area
  Rossen: Then a long list from twitter
  <Rossen> box-decoration-fill, line-height-sizing,
           inline-background-painting, inline-logical-height-sizing,
           line-stretch or inline-stretch,
           inline-cross-direction-sizing, inline-fill-type,
           inline-box-sizing, line-sizing, vertical-sizing-rule,
           line-fill or line-fit

  TabAtkins: suggest we avoid the word inline
  florian: That's also the trick, it's not about "the line". It's
           about the block direction of inlines.
  TabAtkins: Right, I just meant "line" was okay re: my objection.

  faceless2: This feels similar to leading, could use that in the name.
  Rossen: Do we have other terms of art we could try to borrow?
  astearns: 'leading' seems fair game in this
  fantasai: It's not about leading - it doesn't affect layout.
  fantasai: It just changes the size of the background/border area of
            inline boxes, in the block direction.

  fantasai: Other thing to consider is possible future directions for
            this property.
  fantasai: So ultimately it's about the height of the inline box
  fantasai: So we might want to change *how* we fit around text,
            and add options for that.
  fantasai: Right now it's just "fit the text" or "fit the line".

  Rossen: Is layout not in scope for this property, then?
  florian: inline-paint-height?
  Rossen: inline-background-extent?
  fantasai: It affects all the box edges, in terms of where they
            apply graphically.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/5189#issuecomment-661268373
  fantasai: Amelia created some nice illustrations
  florian: I think "inline-*-extent" would have the same confusion
  fantasai: I liked inline-fit because it does describe how it
            actually works. So like "inline-fit" or "line-fit" or
            something else?

  <TabAtkins> inline-block-fit
  <fantasai> it doesn't apply to inline blocks
  <TabAtkins> i know, it's the block axis of inline elements ^_^
  <fantasai> it also affects borders
  <astearns> text-background-fit?

  florian: At some point Amelia proposed box-decoration-*, I assume
           we're not doing that?
  fantasai: That implies more general. It's super long for one.
  florian: inline-box-decoration-height? A mouthful...
  nigel: inline-box-height?
  Rossen: That'll excite people - it says layout to me.
  faceless2: *-shape, we kinda use that elsewhere?
  Rossen: Shape implies geometry, not just size.

  fantasai: I feel like this is something we come back to during a
            break, after people have some time to think about it.
  <tantek> +1 come back to it during a break
  <fantasai> inline-box-fit?
  Rossen: Sounds good, we got awareness on the issue.
  Rossen: So we'll continue discussion during the break.
  <dholbert> maybe "decoration" is fine after all; it was making me
             think "text-decoration", but now I'm remembering we have
             box-decoration-break etc. as well

Open UI presentation
  github: https://github.com/w3c/csswg-drafts/issues/5350
  <gregwhitworth> Here's the link to the slide deck:

  [greg presents]

  gregwhitworth: I met with ARIAWG 3 weeks ago about this; after last
                 weeks' discussion about accent-color, and previous
                 about file-input button, I thought it would be good
                 to go over the Open UI CG and what it's doing.
  gregwhitworth: Hopefully leave time for discussion/comments/etc

  gregwhitworth: Edge and Chrome worked to update their form controls
                 in Chromium to update a11y, touch, and a visual
  gregwhitworth: Gave talks about this with Nicole Sullivan, the
                 Chrome half of things.
  gregwhitworth: Here's high-contrast working, for example.
  [shows slide of some widgets in high-contrast mode]
  gregwhitworth: Lot of people when we show them get excited we've
                 spent time on the built-ins.

  gregwhitworth: A common question afterwards is "how come when I'm
                 navigating the web I don't see these controls?"
  gregwhitworth: Lot of reasons, onion-peeling things.
  gregwhitworth: Did a lot of surveys.
  gregwhitworth: Wanted to understand why webdevs recreate form
  gregwhitworth: 37% is changing the appearance, 32% is more
                 functionality, 27% is browser inconsistency, 3% is
                 a11y, 2% is other
  gregwhitworth: These are consistent answers.

  gregwhitworth: There are low-hanging fruit in each category, we think
  gregwhitworth: A big consistent one is browser inconsistencies.
  gregwhitworth: Like Chromium's color input
  gregwhitworth: The site would say "what's the lowest common
  gregwhitworth: Chromium historically is the native Windows color
                 widget, which is real old-school and W95-looking. And
                 if it didn't give them what they needed, they'd throw
                 it away and do their own.
  gregwhitworth: So if there isn't interop, it doesn't matter what we
                 ultimately introduce across browsers.
  gregwhitworth: So if we can't standardize across many respects, the
                 rest of the work is fruitless. So that's a big reason
                 Open UI came into existence.

  gregwhitworth: The top 10 list of recreated form controls
  gregwhitworth: select, checkbox, date, radio, file, progress,
                 button, dialog, textarea, text
  gregwhitworth: Workhorses of the web
  gregwhitworth: button/textarea/text are near the end, as they're
                 less problematic in general
  gregwhitworth: And more importantly, we asked which is most
                 frustrating, and select beats everything by a *lot*
  [ 42.7% select, 17.3% date, 9.3% file, 8.0% checkbox, 6.7% radio,
     4.0% range, < 3% the rest ]
  gregwhitworth: You see complex ones at the forefront; simpler ones
                 seem less frustrating.

  gregwhitworth: I think it's become so status quo that this problem
                 is part of the web
  gregwhitworth: So people come up and say "should the platform even
                 invest in this?"
  gregwhitworth: I often hear there's a bunch of component libraries,
                 the big sites have big teams focusing on the same
                 stuff browser devs do, so all these fundamentals
                 aren't gaps on those top sites.

  gregwhitworth: We looked at a bunch of menu/popup libraries. Spent
                 30min, found *numerous* a11y problems, can't use in
                 keyboard, etc
  gregwhitworth: This is 8 months old, hopefully a little better today.
  gregwhitworth: I tested high-contrast but didn't show here; due to
                 the checkbox/radio hackarounds, high-contrast would
                 often make the entire form disappear. That's extra
  gregwhitworth: In addition to this, I spoke with partners, major
                 sites, component libs, ssg, pretty much everybody I
  gregwhitworth: All of them had no desire to rebuild these things.
  gregwhitworth: My favorite quote is us asking "would you leverage
                 these if the platform gave better ones, or would you
                 keep using your own?" and someone's VP said "yes,
                 dropdowns aren't our product"
  gregwhitworth: Another project, I was talking to the component
                 engineer leading the dropdown, and they pinged me
                 asking for select behind a flag, because they want to
                 stop owning that component; it's just always buggy
                 and annoying.

  gregwhitworth: So there's obviously a hunger and desire for better
  gregwhitworth: So this is an opportunity for us.
  gregwhitworth: Don't want to pretend this is new. Rossen, when we
                 worked together, emphasized this has been tried many
                 times before.
  gregwhitworth: The way I tried to frame this is...
  gregwhitworth: A designer builds out a new control design.
  gregwhitworth: Recall the earlier problem zones, the spot that
                 people spend the most time on is often a11y
  gregwhitworth: And then ultimately we make a spec.
  gregwhitworth: Literally everyone is doing this, including browsers
                 and OSes.
  gregwhitworth: I got OS devs saying "yeah, this is web-specific, but
                 it overlaps a ton with our designs as well"

  gregwhitworth: So I view Open UI as very similar to how we entered
  gregwhitworth: We started exposing certain parts for certain things,
                 we saw devs start adopting.
  gregwhitworth: But we haven't yet taken a step back and started
                 holistically talking about controls in general.
  gregwhitworth: There is not a desire to lock things in place to
                 stifle innovation in UI, but we do want to pave
                 cowpaths as possible.
  gregwhitworth: And would like there to be a single source of truth
                 for like "what makes a select"
  gregwhitworth: Linked at the end here is a massive explainer

  gregwhitworth: We started with the select, but realized quickly we
                 were actually defining a more general term, which is
                 "what is a control?"
  gregwhitworth: It was pointed out that controls follow an MVC model
  gregwhitworth: As you manipulate the input, the model changes and
                 influences the view.
  gregwhitworth: So we want Open UI to define the model and the
                 controller, without defining the view.
  gregwhitworth: So I tried to take the whole explainer and scrunch it
                 down here
  gregwhitworth: [reads the slide]
    Control: a type of component that allows some form of user
    interaction. The control has controller code that managers the
    transition of the component's states and the model based on end
    user interaction with defined parts.

  gregwhitworth: So a quick thought exercise
  gregwhitworth: Everyone envision a select
  gregwhitworth: What does it look like, what are the behaviors
  gregwhitworth: [shows W95 screenshot]
  gregwhitworth: I wonder if anyone had this in their head
  [shows very old Apple UI - Mac OS 7.0]
  gregwhitworth: No scrollbar, but a checkbox, and some colors next to
                 the options. Actually can't even do this on Web
                 platform today
  [shows a more modern filtering UI from a webpage]
  gregwhitworth: You could imagine this being a composite control as
                 well, being an type=search actually that just has the
  [shows a contact selector]
  gregwhitworth: Or maybe like this, showing off select limitations
                 today. This uses a grid to show the pictures, name,
                 and title.
  gregwhitworth: But ultimately it's just a select underneath
                 everything, giving some values.
  [shows old iOS "roller" select]
  gregwhitworth: Emphasize again that the model and behaviors aren't
                 changing, but controller does a little - scroll
                 events are scrolling this, but site might want to
                 take over.
  gregwhitworth: So wanted to break down the anatomy of the inputs
  gregwhitworth: If there's standard terminology on the web already,
                 we use that

  [shows off a select's anatomy]
  gregwhitworth: A particular bit of controversy here is whether the
                 "top" part of a select is a button (as currently
                 noted) or a textbox, given how many UI frameworks
                 already give type-in
  gregwhitworth: This ties into the accent color from last week, can't
                 define it without knowing where it'll be applied
  gregwhitworth: Then once you have the parts, you can define how
                 events transition between parts.

  <astearns> some selects highlight the portion of each option that
             the typeahead is matching on, which I like

  gregwhitworth: Based on research across component libraries,
                 figuring out if it was nailed down due to user
                 research, or accidental, or if it needs to be
                 standardized at all, etc
  gregwhitworth: What we want overall is to obviate the need for
                 authors to go to WAI-ARIA's big list of conditions
  gregwhitworth: Complicated mapping of a11y conditions back to your
  gregwhitworth: And since so much of the issue is just "I want to
                 make slight cosmetic tweak", but they have to
                 reinvent all the rest themselves
  gregwhitworth: We find that if you provide the core functionality,
                 with type-ahead searching, almost nobody actually
                 wants more functionality at that point. They just
                 want cosmetic control.

  gregwhitworth: Another part of the explainer is the part=""
                 attribute, giving it meaning in the control itself.
  gregwhitworth: So we've exposed that there are actual slots and
                 parts in our Open UI components.
  [shows off a custom select's HTML code]
  gregwhitworth: Note here, on the "button" container, I want to
                 replace that top part with my own UI, but let the
                 rest of the control code work as normal.
  gregwhitworth: So by noting the part="", the component just grabs
                 that, and otherwise hooks up everything as it would
                 with its own button.
  gregwhitworth: So this becomes powerful - so long as the element is
                 child of the select, the select can give it meaning
                 and behavior.
  gregwhitworth: Then the controller comes along, adds in appropriate
                 ARIA, tabindex, listeners, etc.

  gregwhitworth: So I feel like people are often "that sounds cool in
                 theory", but we've gone and built a WC that follows
                 this model.
  gregwhitworth: Not done yet.

  [shows off control]
  gregwhitworth: When I hit spacebar we move to the options, I can
                 arrow and hit Enter and it selects that one.
  gregwhitworth: Here's a Bootstrap example; the text of the select
                 option doesn't bring up the popup, but the arrow does.
  gregwhitworth: And here's a more extreme radial design, that still
                 works exactly per normal select interactions
  gregwhitworth: And here's a typeahead select, giving minimal
                 customization and hooking into the underlying search

  <tantek> great presentation gregwhitworth
  Rossen: I applaud you for not stopping on this journey
  tantek: I tried to work on this 20 years ago, greatly sympathize,
          great work.

  tantek: For select, one common thing I saw in your examples is the
          button and list being different widths
  tantek: Having two [unrelated] things in CSS match their
          shrink-to-fit width is, hm, hard or impossible?
  gregwhitworth: Because they're just block-level siblings, you can
                 use grid to make them the same width if you want
  gregwhitworth: This select is no longer a separate window - we can't
                 do that without security issues.

  fantasai: I know that select dropdowns have special behavior when
            natively implemented, to avoid falling off the edge of the
            screen. Does this mean if I style my select, I need to
            re-implement that?
  gregwhitworth: Expect us to come with proposals for exactly that. I
                 don't expect you to re-implement, we should make it
                 easy to add in.
  <tantek> that seems like a new layout / positioning feature

  fantasai: Looks like you're looking at how to build UI from scratch
            - have you looked at how to take existing markup and make
            it more stylable, so people don't need to bring their own?
  <tantek> +1 fantasai - we want to solve *both*
  gregwhitworth: My one hesitance is, say, take checkbox. If we don't
                 allow replacements, but let you change color of the
                 glyph - people quickly start asking for animation, or
                 adding a label, etc.
  gregwhitworth: Gets more complex really quickly.
  fantasai: Not saying to stop there, but we should go in from both
            sides, so we can minimize the number of people that need
            to rebuilt their control.
  fantasai: While also making it possible for people rebuilding their
            components to make it easy.
  Rossen: Last time, in Toronto, we decided not to use CSS to expose
          or define parts.
  <TabAtkins> That's not a relevant address to fantasai's concern -
              she's not talking about defining parts in CSS.
  tantek: Strong agree to also let people fix native markup.

  <br dur=15min>

  <gregwhitworth> hey folks, if you want to be a part of the meta Open
                  UI + CSSWG collaboration I've setup a doodle poll
                  for mid-August to try and drive clarity:

CSS Selectors
  scribe: fantasai

Can you standardize a pseudo-element selector for file inputs?
  github: https://github.com/w3c/csswg-drafts/issues/5049#issuecomment-639161484

  emilio: We came up with name "file-chooser-button-thing"
  emilio: OpenUI folks debated came up with different name
  emilio: I feel like we should still get a CSSWG resolution
  Rossen: So this is renaming ::file-chooser-button
  emilio: Yes
  emilio: Proposal is ::file-selector-button
  gregwhitworth: That name is from looking through various components
  gregwhitworth: Most don't have a button, but of the ones that do,
                 that's the naming trend
  <fantasai> wfm
  <astearns> +1 from me
  florian: Sounds good to align with OpenUI
  florian: Second thought is how to coordinate better with OpenUI
  Rossen: We have plenty of liaison here in the WG
  Rossen: The meta-question here, we can debate later
  Rossen: Ideally most such work can involve WG members and the WG
  Rossen: See mostly support, no counterproposals. Any objections?

  RESOLVED: Rename to ::file-selector-button

Received on Sunday, 16 August 2020 11:54:50 UTC