[CSSWG] Minutes Virtual F2F 2020-07-30 Part II: CSS UI, CSS Pseudo Elements 4 [css-ui] [css-pseudo-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.


  - RESOLVED: Limit 'appearance: button' to buttons once we figure out
              what buttons are (Issue #5174: Change appearance: button
              to apply only to buttons)
  - RESOLVED: outline-width may be ignored if outline-style is auto
              (Issue #4925: outline-width vs outline-style: auto)
  - RESOLVED: Add SHOULD requirement to spec about making sure caret
              is visible (Issue #4784: Add caret-width or add spec
              that browser maintains caret width despite transforms)

CSS Pseudo Elements 4

  - RESOLVED: Megan (GameMaker) replaces Tess (hober) as editor of
              Highlight API spec
  - There was interest in exposing a pseudo for when something has
      been searched within the page (Issue #5233: Highlight
      pseudo-element for find-in-page / scroll-to-text).
      - It could also solve use cases around framention and those
          should be considered as part of discussion.
      - This is exposing new information so privacy will need to be
          considered when writing the spec definition.


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

Scribe: fantasai


Change appearance: button to apply only to buttons
  github: https://github.com/w3c/csswg-drafts/issues/5174

  florian: General principle that 'auto' does magic by tag, and 'none'
           turns off magic
  florian: But we have some legacy stuff
  florian: As specified, appearance: button makes things look like
  florian: even when not actually buttons
  florian: We could reduce magic of button by only applying
           'appearance: button' to buttons
  florian: Mozilla was a bit skeptical

  fantasai: I think this is one of the things that may be useful to do
            on things that are not buttons, e.g. links
  fantasai: In a lot of cases they're styled to look like buttons,
            and if using native-looking buttons, that would require
            this feature to work on links.
  fantasai: I don't see a huge benefit from restricting this, given
            that <button> can already contain arbitrary content.
            If we need to make it work for such a broad range of
            content already, I'd lean towards not restricting it.
  florian: The current definition would allow you to turn stuff into
           buttons, but also weird cases where they should not
  florian: but do we reduce this to only compat necessity or do we let
           people make things into buttons when possible?
  <tantek> not sure about the compat details, however I'm in favor of
           less magic here

  iank: I think part of the work with the simplifying making
        appearance sane was to limit the magic in scope
  iank: It seems like a bit of a reversal if we say, actually, we do
        want these to apply to everything
  iank: so prefer to restrict this down as much as possible

  emilio: If compat allows it, prefer to put less magic here
  emilio: We have unprefixed appearance, heycam implemented it, and
          hacky internal property to support 'appearance: button'

  fantasai: Wanted clarification...
  fantasai: Are links explicitly called out? can they be used as
  florian: Current spec allows any element to look like a button
  florian: Chrome says not many people use it, not even on links

  emilio: To be clear, magic of 'appearance: button' applies to
          everything except input, textarea and non-listbox selects
  iank: I believe we've already shipped this in 80 which is quite a
        few releases ago
  florian: By this you mean the simplification you proposed?
  Rossen: That means you're not breaking anyone who depends on this?
  iank: Got a few minor reports
  iank: No large-scale breakage

  Rossen: Based on data, we can live with scoping 'appearance: button'
          to buttons only, is this something we can resolve on?
  Rossen: Proposed resolution is scope 'appearance: button' to buttons
  * fantasai is uncomfortable with not applying to links
  Rossen: Hearing no objections. Call it resolved. If there's issue
          wrt links, I'm sure we can re-open

  smfr: Are we saying that 'appearance: button' only applies to the
        BUTTON element?
  hober: <input type=button> ?
  smfr: file input button?
  florian: I guess it's BUTTON and <INPUT type=button>
  <tantek> and reset
  smfr: <input type=submit> ?
  florian: Chrome folks can you clarify?
  <tantek> Blink folks, what was implemented? <button> <input

  RESOLVED: Limit 'appearance: button' to buttons once we figure out
            what buttons are

outline-width vs outline-style: auto
  github: https://github.com/w3c/csswg-drafts/issues/4925

  florian: outline-style: auto is what you do when you want to opt
           into native-style outlines
  florian: some UAs may do a solid outline, but try to do native
  florian: UA might ignore the outline-color in that case
  florian: but doesn't say you can ignore outline-width
  florian: Maybe we should allow UA to also ignore outline-width in
           that case
  smfr: In webkit we definitely support this, don't want outline-width
        affecting native appearance
  [+1 from fantasai]

  florian: AmeliaBR thought the native outline looked bad and wanted
           to say outline-width to make it thicker
  florian: so alternative would be if you can't affect the
           outline-width on a native outline, the existence of
           outline-width causes a non-native outline
  florian: Personally I think if you want to style it, then don't use
           a native
  florian: If it's native, every other property is a hint, might
           influence rendering but not necessarily

  Rossen: Magic of having something like outline-width switching out
          of native one is really magic to me
  Rossen: This sounds like a broken feature
  Rossen: so either require to apply, or make optional, but don't
          switch out
  florian: Proposed resolution, just like outline-color, outline-width
           may be ignored when outline-style is auto
  <tantek> +1

  RESOLVED: outline-width may be ignored if outline-style is auto

CSS Pseudo Elements 4

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

  florian: In Pseudos 4 we have ::selection, ::grammar-error,
  florian: Another thing people sometimes want to style is
           find-in-page highlight
  florian: so maybe we want one of those

  florian: I think I'd like to point out two things
  florian: There is a work in progress spec to try to make it possible
           for authors to create custom highlights for any reason
  <Rossen> spec in reference is https://drafts.csswg.org/css-highlight-api-1/
  florian: On the JS side of things, you'd set ranges on the page
  florian: On CSS side you can style them

  florian: If you want to style the browser find-in-page
  florian: pointed out at least by Apple
  florian: unlike the others, the UI that is used by some browsers
  florian: isn't something you can create in CSS
  florian: so expressing through selector, you can't express those
           effects in CSS
  <tantek> curious about the visual effects that can't be expressed in
           CSS, screenshots?
  florian: So proposed resolution is partially no change, and
           partially poke the editors of that spec

  cbiesinger: scroll-to-text is that when searching for a thing and
              click search result, the browser will scroll to the
              first matching fragment
  florian: idk if we want authors to have control over the UI
  florian: or if want consistency across pages and should stay out of
           authors' hands

  <tantek> this is also used by the IndieWeb for annotations and
           marginalia with fragmention https://indieweb.org/fragmention
  tantek: 2 questions
  tantek: find-in-page seems like a well-established feature
  tantek: Effects might not be consistent across browsers, could study
          and figure out what the effects are
  tantek: Curious about effects that can't be expressed in CSS
  tantek: maybe add screenshots of the effect to the issue?
  tantek: Happy to defer decision until we have more info
  tantek: Don't seem to have a rush
  tantek: On scroll-to-text or marginalia use case
  tantek: in the Indie Web community, there's a diversity of how
          authors want to style this effect
  tantek: both from perspective of person linking, and from
          perspective of site linking to the text
  tantek: Sometimes author wants to say "these are the words I want to
  tantek: and leave up to destination to highlight / style or not
  tantek: Third case of browser doing something by default if neither
          author of link or author of page wants to do something
  tantek: so complex interaction between author of the link, author of
          the page
  tantek: Maybe want to decide text fragment, or whole paragraph, or
          section, or something
  tantek: and maybe browser does something
  tantek: Maybe need to investigate more
  tantek: I see the utility for a page to control the presentation of
          highlights and annotations
  tantek: but requires more study of possible effects to come up with
          a good solution
  tantek: Also sometimes animated
  tantek: fragmention to a blog post of mine, my site will scroll to
          that paragraph, not to the text itself
  tantek: and then do yellow highlight on that paragraph which then
          fades away
  tantek: non-intrusive, here's what you are looking for
  tantek: didn't want to pollute styling with something persistent
  tantek: not sure that's possible with pseudo-element either
  tantek: Bunch of ways people doing presentation effects with this
  tantek: so requires further documentation before designing a solution
  <tantek> example link to the animation effect I was mentioning:
           (should work in any browser with JS turned on, Fragmentions
           implemented with a polyfill on my site)

  smfr: I don't think the page can currently detect when the user does
        find in page
  smfr: If we allow highlighting, then that exposes that information
  smfr: so some privacy concerns there
  smfr: not sure I want that to happen
  fantasai: I don't think anything is exposed to the author
  fantasai: Highlight pseudos don't affect computed style or layout or
            anything except painting for the user
  smfr: Is there an API to detect?
  <tantek> yes that's what I remember
  florian: not yet determined
  smfr: user after finding, can hit ? to select the result

  florian: Back to tantek's point wrt research
  florian: One aspect not doable in CSS in general
  florian: these pseudos are non-tree-abiding, and cannot affect layout
  florian: so things that you can do in CSS in general, you can't do
           with these types of pseudo-elements
  florian: so need to know what authors would want to do, if it's even
  chrishtr: [asks for tantek to clarify]
  tantek: IndieWeb community is trying out different presentations of
          how to show fragmention when someone links to your site with
          a fragmention
  tantek: yellow paragraph highlight + fade is just one example
  tantek: others folks have used other effects
  tantek: Experimentation is happening on personal websites
  tantek: e.g. "scroll that into view, show specific effect"
  tantek: using polyfill right now
  chrishtr: So writing JS code that parses the text in the URL?
  tantek: I believe it's a fairly straightforward simple polyfill
  tantek: which then adds class names that you can style
  tantek: So that there's a separation between polyfill and provides a
          hook that author can style accordingly
  tantek: Not everyone has to write JS
  chrishtr: Main response to that is cool to be experimenting with
            this effect
  chrishtr: ...
  tantek: There are other interactions where select text in a blog post
  tantek: You'd have options to then tweet that text, or do something
  tantek: multiple phases
  tantek: method of causing a highlight to occur
  tantek: DOM hooks to style the highlight
  tantek: Independent of that you could potentially provide a UI to do
          something with the highlighted text
  tantek: e.g. +1 the highlight, or copy and post to Twitter
  Rossen: sorry to interject, but I think we're straying
  chrishtr: I agree with those use cases and would like to follow up
  <tantek> looks like the fragmention polyfill I'm using puts a
           "fragmention" attribute on the containing paragraph (or
           possibly nearest block-level element)

  chrishtr: Main point is, as long as we're making progress towards
            exploring this space so we can find the right APIs to
            expose that's good
  chrishtr: Right now feature in one browsers that does not allow
            customization of the color
  chrishtr: and quite a lot of dev requests to change color in that
            particular UI mode
  chrishtr: and want to respect that desire and make progress to
            authors customize look and feel
  florian: The challenge here is that these are very restrictive
           pseudo-elements, only a few aspects of rendering can be
  florian: so need to see if what is desired is possible to solve via
           highlight pseudo
  Rossen: Somewhat related to highlight API spec

  <tantek> color (and background-color) are just the beginning of
           these needs, that's the point
  <tantek> we shouldn't be prematurely optimizing for only color is my
  * fantasai thinks that find-in-page vs fragmention are slightly
             different in their needs
  <tantek> fantasai I agree and you should say that on the record :)

  hober: I'd like to step down as co-editor of highlight API, haven't
         had time
  hober: I'd like to suggest as my replacement Megan Gardner
  hober: She did the WebKit implementation
  florian: I don't plan to step down, and I look forward to work with

  RESOLVED: Megan replaces Tess as editor of Highlight API spec

  fantasai: think that find-in-page vs fragmention are distinct
            features with slightly different needs
  <tantek> +1 fantasai totally agreed the features are different
  fantasai: so let's keep those things distinct in the discussion
  Rossen: +1
  Rossen: People working on this need to figure out the boundaries
          between host or browser layer and the content layer
  Rossen: which exposes user interaction
  Rossen: if we are exposing something new, we are adding additional
          privacy-related exposure to the content layer
  Rossen: That is biggest sticking point, are we starting to expose
          something additional, and if so how so
  Rossen: outside of that, good thing to continue investigating

  <br duration=23min>


caret width vs transforms
  github: https://github.com/w3c/csswg-drafts/issues/4784

  florian: Have an issue with person reporting trouble with carets
  florian: particularly when element containing caret is transformed
  florian: sometimes caret becomes invisible because < 1px
  florian: Proposes a caret-width property that lets you make the
           caret big when it would be small so you can still see it
  florian: I'm not convinced this is the answer to the problem, but
           the problem is real

  florian: imho the caret is browser UI, and browser should just make
           sure it's visible
  florian: shouldn't need someone to tell you how many pixels that is
  florian: We already have an unimplemented caret-shape property which
           switches between various carets
  florian: There's room to say in this definition that the browser
           should make it thick enough to be visible
  florian: and then we can write tests for that
  florian: but maybe there's some other use case for caret-width

  astearns: I'll take the silence as lack of appetite for caret-width
  astearns: so proposal is to add caret SHOULD be visible through
            transforms etc.
  florian: Could even be a MUST
  florian: Would not say how, but make it visible anyway
  florian: Reasonable to say if there's a caret need to be able to see
  astearns: But we do tend not to get into browser UI territory
  TabAtkins: Also some extreme cases, like transforming entire
             textarea into 1px, not sensible to see the caret
  gregwhitworth: Would like to see bugs filed
  gregwhitworth: agree with should
  fantasai: If the text is visible, then the caret inserted into the
            text should also be visible
  florian: Could go three ways. 0) reject to do anything 1) add should
           about visibility 2) add caret-width

  RESOLVED: Add SHOULD requirement to spec about making sure caret is
            visible when text is visible

Received on Sunday, 16 August 2020 11:55:19 UTC