W3C home > Mailing lists > Public > www-style@w3.org > September 2020

[CSSWG] Minutes Telecon 2020-09-09 [css-conditional-3] [css-pseudo-4] [css-text]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 9 Sep 2020 19:08:19 -0400
Message-ID: <CADhPm3utpK+ScuqTzsZoAEDNMFbr7Ha36ee7JVzxjdG0hTnx-g@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 Conditional
---------------

  - RESOLVED: Add chris and fantasai as editors to CSS Conditional 3
              (Issue #5315: Let's finish the specification)

CSS Pseudo Elements
-------------------

  - Though they seem similar the discussion find-in-page and
      scroll-to-text needs to be separated into two issues (Issue
      #5233: Add a highlight pseudo-element for find-in-page or
      scroll-to-text).
      - There were concerns that find-in-page may be a mis-match with
          the highlight pseudo elements because several browsers have
          additional styling.
      - The original developer request was to style scroll-to-text but
          there are use cases for both properties that should be
          documented.
  - RESOLVED: We're interested and would like chrishtr to pursue and
              come back with proposal text [for find-in-page and
              scroll-to-text] (Issue #5233)
  - RESOLVED: Continue working on standardizing these 3 pseudos
              (::range-thumb, ::range-track, ::range-progress) (Issue
              #4410: Standardizing input[type="range"] styling)
  - There's interest in having a joint meeting with OpenUI to discuss
      the more holistic approach to defining parts of controls that
      they're working on.

CSS Text
--------

  - RESOLVED: Change the spec to say tab-size applies to inlines but
              when that happens the number values apply to advance
              width from block container (Issue #5489: 'tab-size' de
              facto applies to inline boxes)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2020Sep/0003.html

Present:
  Rachel Andrew
  Adam Argyle
  Tab Atkins
  Christian Biesinger
  Mike Bremford
  Oriol Brufau
  Tantek Çelik
  Daniel Clark
  Hui Jing Chen
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Brian Kardell
  Una Kravets
  Daniel Libby
  Chris Lilley
  Rune Lillesveen
  Alison Maher
  Myles Maxfield
  Tess O'Connor
  Anton Prowse
  Florian Rivoal
  Jen Simmons
  Lea Verou
  Greg Whitworth

Scribe: dael

  astearns: One extra item is a reminder we're having an extra meeting
            tomorrow to talk MathML topics
  astearns: Same time, just tomorrow
  bkardell: Looking forward to it. Invited some CG members

  astearns: Any changes to today's agenda?

CSS Conditional
===============

Let's finish the specification
------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5315

  chris: CSS Conditional 3 is almost ready and almost done. Very few
         open issues
  chris: Test suite is fully passed but API section doesn't have
         tests. Can write script test easily. 3 must items are
         untested but fairly easy
  chris: Most open issues don't look hard. Maybe push some until
         further level.
  chris: One problem, don't currently have an editor. If needed I
         could do the work and happy to help. If there's a bunch of
         work we can finalize
  fantasai: Vaguely recall 14 or more open issues but not sure if
            they're in GH
  chris: 7 open, 22 closed in GH. I did a bunch of getting out of
         older requests and putting into GH a year ago
  fantasai: Okay

  fantasai: I think we should invite dbaron as an invited expert if
            he'd like. If he wants to edit is separate question. I'm
            happy to help with editing. I think I did make a list of
            issues at some point
  chris: That would help, thank you
  <gregwhitworth> fantasai if you need help spelunking or split up the
                  reviews let me know

  chris: Call for dissenting opinion, help is appreciated. Unless
         there are dependent issues I think we can finish this topic
  astearns: Anyone else volunteering to edit?
  TabAtkins: I'm interested in general. I'll be happy to look if you
             need help on something specific
  chris: Thanks

  astearns: Agree we should get dbaron back as invited if he likes

  chris: This was last published in 2013 so it needs some tlc
  astearns: Shall we make fantasai and chris editors?
  chris: Fine for me

  RESOLVED: Add chris and fantasai as editors to CSS Conditional 3

CSS Pseudo Elements
===================

Add a highlight pseudo-element for find-in-page or scroll-to-text
-----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5233

  TabAtkins: I can run with it
  TabAtkins: Thread talks about general highlight API. This is about
             find in page or scroll to text stuff. That they're not
             exposed is inconsistent and means authors can't have
             consistent highlight. Proposal is expose those two under
             same or separate items.
  TabAtkins: If same group like UA-selection. Is separate
             ::find-in-page and ::scroll-to-text
  TabAtkins: Opinions? Okay to pursue?
  <gregwhitworth> TabAtkins: how does this relate to
                  https://drafts.csswg.org/css-highlight-api-1/ ?? As
                  this was created for that if I recall correctly
  <fantasai> gregwhitworth, this one hooks into the browser UI
  <TabAtkins> gregwhitworth: It doesn't, and that's not - that's for a
              *generic* highlighting mechanism controllable by authors
  <gregwhitworth> gregwhitworth: ahhh

  florian: We talked a month ago. This question doesn't take into
           account that conversation. If I recall find in page effects
           by browsers are way beyond highlight pseudo element. Safari
           does whole page darkening. Not something normal pseudo
           could do.
  florian: Conceptually similar but style is very different. We should
           do some research about what browsers do and what authors
           want to do and if that fits within existing things
  TabAtkins: Browsers do go beyond but they all currently do the same
             selection-ish highlight. May have other styling but still
             highlight the selection. It's a pretty basic UX that we
             feel will be stable across time. being able to customize
             highlight still seems reasonable to do

  GameMaker: My comment is that Safari does darken page. Also I'm not
             entirely on board where we'd need 2 to do what Chrome
             does. Highlight whole page in one color and the one
             you're at is in a different color. This only suggests one
             thing
  GameMaker: Browsers do different things. If we make this a highlight
             element, elements are styled in more ways. With selection
             you can do more, but opening to highlight pseudo element
             there's a whole host of things we can do
  GameMaker: I can see why we're considering. I don't know what devs
             are asking for. I don't know right thing to do it
  GameMaker: Summary- Chrome would need 2 colors because they
             highlight all words and the one you're looking at is
             different. Opening to full pseudo highlight is more than
             just color and it's opening more than we can do. Need to
             be cognizant of that and I'm not sure devs are asking for
             this

  smfr: One question is if author provides styles does that disable
        browser built in find highlighting?
  TabAtkins: What would be tricky about that?
  smfr: If styling is simply color no but if more involved later there
        might be something like appearance where browser decides to
        turn off built in
  myles: Related point where if some elements have pseudo and others
         don't do we auto-darken the page when at elements that don't
         have this and when you cmd + G to the next would we change
         darkening?
  TabAtkins: I don't think we'd turn off darkening. I was wondering if
             problems darkening and turning on author supplied
             highlight colors

  chrishtr: Like to point out there are 2 use cases. Find in page and
            scroll to text. Chrome has received dev desire on scroll
            to text. When you use this it will highlight bg of
            selected content in yellow for short period then fades.
            Many devs find that color doesn't fit with theme
  chrishtr: Added find in page because thought would be good to think
            together. Agree find in page is more complex. I think
            scroll to text is pretty simple
  gregwhitworth: I've likewise heard developer requests for this.
                 Having a browser hook would be good. Very valid
                 points on open questions. Feel it warrants a more
                 concrete proposal. As you denoted chrishtr it may
                 vary between the two
  gregwhitworth: For a use case there is developer interest and worth
                 exploring

  florian: How it would work if it's a highlight is defined. But
           details on use case would be good to see if they fit. It
           was mentioned it's a fading yellow highlight. If the fading
           exposed, timing, control? Knowing this would help us figure
           out if this is the right thing to do
  florian: We know what pseudo highlights do but we know less what
           we're trying to achieve. Good to document. Probably
           different between find in page and scroll to text. Maybe
           document both separately. See if it fits the use case

  una: Bringing this up as opportunity to be consistent. Some browsers
       highlight all words, some only active. Some difference in
       colors cross browser. Lots of considerations here. Not just
       contrast but browser experience. And what happens with dark
       mode, how do we make sure the highlighted word stands out.

  leaverou: Another thing is this is a pseudo element that will span
            multiple sub elements. Is there precedent? Is it a special
            pseudo element?
  florian: There's precedent
  TabAtkins: Defined in ::selection. Constrained properties that make
             it hard to tell number of boxes
  leaverou: currentColor?
  TabAtkins: It's however it works in ::selection
  <fantasai> See https://drafts.csswg.org/css-pseudo-4/#highlight-pseudos
  florian: It's pretty cool, the definition. Not tree abiding and
           weird, but defined weird.
  <fantasai> The properties supported are not allowed to affect layout
             in any way
  una: Because of the contrast issue it might be good to allow this so
       you can style borders and other parts of highlight to make it
       stand out. Would help authors make sure text style stands out
       in their specific design
  <fantasai> properties currently specified to work is
             https://drafts.csswg.org/css-pseudo-4/#highlight-styling
  chrishtr: dark mode- can't dev prove a dark mode style for this?
  una: Yes, just additional overhead. Good to do because author makes
       sure whatever preference mode these styles have clear visibility
  TabAtkins: Support that. Because we all do dark mode I'm of opinion
             any UA provided color should be under author control to
             make sure it looks good with both dark and light

  florian: I suggest we split the issue in 2. Document what browsers
           do today and which aspect authors want to control. From
           there can judge if it's a good fit. Good chance for scroll
           to text. Find in page, maybe, maybe not.
  florian: Split the issue, document use cases. Does that sound
           reasonable?
  astearns: Anyone argue it should be a single way?
  florian: It might be. If we say highlight pseudo is right that's a
           single way. That some browsers highlight all and some only
           active. I think there's also highlight in scroll bar.
           There's a number of things being done.
  florian: If we want to say the find text thing is easy and the other
           less then we split. But we explore in parallel and if
           they're easy we do both
  chrishtr: Makes sense to split. Scroll to text is much simpler. It's
            a progressive enhancement of linking property. In
            Chromium-based it shows a yellow that disappears after
            user interactions. It's pretty simple
  chrishtr: I can file a new issue and go into more detail with
            examples
  florian: Thing I wonder about this is the timeout. Other highlight
           pseudos aren't timed. Other than that it doesn't sound hard.
  <tantek> we have examples with much more interaction, such as
           marginalia, e.g. what Medium does with highlight UI
  fantasai: Just like with selection I think UA controls when it exists
  florian: Probably
  florian: Is this transition out and the transition out is defined by
           UA? Maybe.
  astearns: We'll open at least 1 new issue to separate the two

  chrishtr: Great to confirm if there's any objection to trying to
            move forward and spec scroll to text?
  hober: I don't think I object. I do think that the find in page one
         is supported across all browsers and has more complex
         styling. Tackling harder first means you get easier for free
         later.
  florian: Not sure. At this point we're trying to see if the
           definition fits more problems
  TabAtkins: The text find thing is a soft problem already. Not just
             easy, it's a non-problem once we define it exists

  astearns: I think we have a way forward to open another issue
  gregwhitworth: Wanted to make sure chrishtr was good with where
                 we're at
  chrishtr: Great to resolve that it's useful for scroll to text. Come
            back with a proposal text to verify with the group
  astearns: Proposal: We have this facility for browsers that impl
            scroll to text
  astearns: Objections?
  florian: Still curious about how animation works. If we'll come back
           with a definition of how that works, yes

  tantek: I think framing the scroll to text in terms of highlight is
          too narrow a framing. Don't object to exploring but object
          to limiting to just that
  tantek: Medium, for example. If you scroll to a selection of text
          additional UI occurs where you can annotate. At least couple
          indy web where you can comment in margins and when you
          highlight it highlights text you commented on.
  tantek: Have in the wild that kind of text that's far beyond simple
          background highlights. I don't oppose exploring, just want
          to make sure we're not trying to collapse it with something
          like find that's more limited
  chrishtr: Responded to those use cases in github. Those would need
            script involvement. Similar to how we discussed accent
            color on form controls this is low hanging fruit. It by no
            means precludes more customization in the future
  tantek: Okay, thanks

  florian: From my PoV I would like to know if entire fade in and out
           is UA controlled or if its timing is UA controlled but the
           actual fading is controlled from css.
  chrishtr: I think that's out of scope for resolution and I'll come
            back with a precise thing.

  astearns: Resolution is we're interested and would like you to
            pursue and come back with proposal text?
  chrishtr: Yes

  RESOLVED: We're interested and would like chrishtr to pursue and
            come back with proposal text

Standardizing input[type="range"] styling
-----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4410

  gregwhitworth: I can try and take if it the person isn't on the call
  emilio: These people proposed standardizing a model similar to
          Gecko. Subtle differences. Added to get feedback. Model is
          fairly simple. Could go one way or other. Would like to hear
          from WK and Blink if it's interesting to using more
          Gecko-like model and if there's interest in standardizing.
  <fantasai> Proposal:
  <fantasai> ::range-thumb { /* Styles the thumb of the input*/ }
  <fantasai> ::range-track { /* Styles the track of the input*/ }
  <fantasai> ::range-progress { /* Styles the progress/fill below the
             thumb of the input*/ }
  gregwhitworth: To get more specific the proposal is 3 different
                 items. Range-thumb, range-track, and range-progress.
                 Concrete is missing
  gregwhitworth: Did a decent amount of research because I was
                 hesitant we'd design into a corner. These 3 are
                 unanimous. I'm in favor of standardizing. Would need
                 concrete what can/can't they do analysis.

  iank: From blink...I don't know if Mason is on...quick look this is
        interesting. Would welcome improvement. I don't think we have
        concept of progress element, but could be wrong. Agree with
        gregwhitworth and analysis of what properties would/wouldn't
        be respected would pave way for easier implementation
  gregwhitworth: I will note WK you have a concept of tracking. I
                 don't know if you have an element.
  iank: I don't believe we have an element.
  gregwhitworth: Okay, okay
  iank: Just purely a paint effect I believe
  gregwhitworth: I had requested the research. We can action me and
                 I'll re-ping the person to know what's interop so we
                 can get a concrete proposal
  iank: Sounds great

  smfr: WK has html range which is pre-fork. Certainly interested in
        participating in standardizing the range pseudo elements
  astearns: Sounds like we have consensus to work in this area

  ACTION gregwhitworth respond to commenter on #4410 to see if they
         can do the research

  gregwhitworth: Yep. smfr if you can see what you limit that would be
                 great. I'll compare with Maz in Chromium

  iank: We recently did a bit of work to simplify in this area so may
        be pretty different to WK
  gregwhitworth: Got it. I'll definitely test

  <florian> I wonder if we're painting ourselves into a corner, and
            excluding alternative designs (dial like, or other things)

  jensimmons: I want to advocate for a holistic way to get at these
              problems. Similar space to other conversations. Jumping
              to we should make pseudo elements. We should look at the
              whole system, not just this one control. gregwhitworth I
              think said this in the thread. Terrific we're doing
              this, but should look at whole thing and not just design
              separately
  leaverou: Agree with jensimmons. We standardize pseudo elements on a
            piece by piece basis. There was proposal for parts to
            standardize. What happened to it? Why create different
            pseudo elements when can make one for all form controls.
  <tantek> +1 jensimmons, take a look at the whole system
  <una> +1 jensimmons and leaverou as well -- forms need holistic
        review
  gregwhitworth: I really do think, and maybe there's an OpenUI joint
                 meeting that makes sense, I don't want to paint into
                 a corner. OpenUI is holistic approach. There's 3 or 4
                 topics where we talk in meta and go in circles while
                 we do ad hocs. But I don't disagree with accent color
                 and these where it technically exists
  gregwhitworth: We should do the holistic thing but web is the web
                 today. There are valid use cases not supported in UAs
                 that should be documented.
  gregwhitworth: I'll throw together and ad hoc agenda for joint
                 meeting with OpenUI. There's 3 or 4 topics we could
                 cover. There's enough overlap between the groups. I'm
                 in favor of resolving on these 3 elements but it
                 won't allow you to go to the extent of content
                 swapping
  gregwhitworth: Also point to explainer that Google, Edge, and
                 Salesforce did which is put together a model
                 definition. I think that's worth exploring in joint
                 meeting. Get opinions on that model because does
                 allow part access instead of one offs
  emilio: I think gregwhitworth had good points. I agree to finding a
          holistic solution is useful and needs to pursue. This is
          standardizing reality. The prefixed pseudo elements won't go
          away. Allowing authors to not write same style in 3 selector
          lists is good
  astearns: Agree we should consider holistically and happy to see
            people like gregwhitworth and Mason are doing the research.

  <florian> Doesn't seem that these pseudos would let you do this sort
            range controls (or style a UA that had them):
            https://cdn.shopify.com/s/files/1/0017/2972/products/PX5-chromcapsprodcutpage_580x387.jpg?v=1596119507

  astearns: It seems like we are doing the holistic consideration. If
            there are gaps in the analysis it would be great to raise
            those in the issues
  astearns: For this issue we have the next step of figure out what
            things could be used on these pseudos.
  astearns: Should resolve we do want to make progress on the proposed
            range pseudos
  astearns: Proposal: Continue working on standardizing these 3 pseudos
  astearns: Objections?

  RESOLVED: Continue working on standardizing these 3 pseudos

  astearns: Where it goes, I'm assuming pseudo spec?
  fantasai: Yes or do we want a spec of form controls and their pseudo
            elements?
  astearns: Yes, does make some sense to have form control pseudos by
            themselves
  gregwhitworth: We could add that for discussion at joint meeting. I
                 would love to not duplicate. If they're just pseudo
                 elements they go in pseudo. If we spin up a form
                 control spec it goes same patch as OpenUI.
  astearns: That okay fantasai?
  fantasai: Okay. If we end up adding lots that's specific to a form
            control at that point it should move to its own spec.
            Currently mostly specific to page
  gregwhitworth: That's what I was trying to take away from is that
                 overlap. Pseudo elements are a part but ultimately
                 define an anatomy. If we go that route do we spin a
                 new spec for parts? This can be in holistic
                 discussion about where things live. this is part of
                 Open UI anatomy discussion

  <gregwhitworth> florian: that's where the model explainer I referred
                  to as you're correct somewhat but it's primarily due
                  to to the current capabilities of pseudos

CSS Text
========

'tab-size' de facto applies to inline boxes
-------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5489

  florian: Currently applies to block but in implementations it
           applies to inline as well. Question is how? Stack or
           independent? From tests seems independent
  florian: If you have a preserve-tab with a value of 7 you measure
           from edge and push to next independent of if other ones.
           All browsers seem to do this so would like to spec it
  <chris> sounds like we could standardize reality there
  fantasai: Defined to apply to block so when font changes in
            paragraph tab stops line up. We knew at time impl didn't
            do that. I think it's not a question about line up with
            reality, there's a reason the spec is different. We can
            decide we can't do thing that is correct, but there's a
            reason why it was spec as different.
  <chris> ok, fair enough
  florian: I did not know that, thank you

  oriol: I proposed in issue that maybe could go in between current
         spec and current impl. Could say property applies to inlines
         and let authors change values in line boxes. If value spec is
         a number say it refers to advance size of space character of
         containing block.
  oriol: In common cases keep good alignment but closer to current impl
  fantasai: Works for me
  astearns: And likely more web compat
  florian: Works for me
  astearns: Proposal: Change the spec to say tab size applies to
            inlines but when that happens the number values apply to
            advance width from block container
  astearns: That would change for all browsers?
  oriol: Yeah, right now they use width of space of inline box.
  florian: I will add a test for that
  astearns: Objections?

  RESOLVED: Change the spec to say tab-size applies to inlines but
            when that happens the number values apply to advance width
            from block container

  astearns: Thanks oriol for the solution

  astearns: One additional thing, proposed meeting with i18n group
            during TPAC. Need to have an agenda. Some suggestions for
            xfq but would like more

  chrishtr: Issue #4792
  <astearns> https://github.com/w3c/csswg-drafts/issues/4792#issuecomment-689099191
  chrishtr: Don't have time to talk but got a very detailed update
            with proposed solution. Has a lot of detail and design doc
            as well as prototype. In order to make next week
            discussion useful please look in advance

  astearns: Thanks for everyone for calling in. Talk to some of you
            tomorrow
  <tantek> Thanks astearns
Received on Wednesday, 9 September 2020 23:09:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 9 September 2020 23:09:04 UTC