W3C home > Mailing lists > Public > www-style@w3.org > October 2019

[CSSWG] Minutes Fukuoka F2F 2019-09-16 Part II: CSS Pseudo 4 - Highlight APIs [css-pseudo-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 4 Oct 2019 18:51:16 -0400
Message-ID: <CADhPm3u-nMpRiua5yCHT=1XHOxr0oCYYtPgF_8qZbXQAMkihnw@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 Pseudo 4 - Highlight APIs
-----------------------------

  - sanketj introduced the proposal to have Highlight APIs
      GitHub: https://github.com/w3c/csswg-drafts/issues/4307
      Explainer:
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/highlight/explainer.md
  - This proposal extends styling from the predefined UA
      pseudo-elements (such as ::spelling-error) to user defined
      values. To do so it introduces two new concepts
      HighlightRangeGroup and HighlightsMap, and allows the style to be
      set on the HighlightRangeGroup. HightlightsMap is a maplike
      object that maps a name to a HighlightRangeGroup object.

  - Priority can be set on the styles and all default to 0. In the
      case of a tie it will be the first style set via timestamp.
      There is already a priority order for custom pseudo elements so
      it was suggested that they should be the same.
      - With priority defined this way there is a general concern that
          this will be another case like z-index where several
          libraries compete with each other to be the highest
          priority. There's not clear path around this issue, though.
      - If they expose the native highlights, author-defined goes
          below UA-defined for default priority.
      - There is still much more to discuss on priority before a
          solution can be reached including concerns about
          interweaving and background vs foreground painting.

  - The proposal does address ShadowDOM by specifying that if you have
      a range where some is in ShadowDOM and some outside, it is all
      styled by global map.
  - There was interest in seeing if there's a use case to style
      differently when more than one highlight pseudo apply to the
      same element and also if there's a use case to expose the native
      highlighting pseudo elements to JS API.
  - A concern was raised that the API structure forced an author to
      create all their global errors up front rather than initialize,
      and that this would be awkward.
  - There is an open issue on handling DOM mutations; currently
      considering using StaticRange but also have a scheduled meeting
      with the Editing TF.
  - How to handle the a11y use cases is also an open issue with all
      highlight properties, not just these new APIs.

  - No one was clear the current implementation interest for the other
      items in Pseudos 4, but if there is little interest it was
      suggested to move this forward first (and move other Pseudo 4
      parts to L5) while making sure it can accommodate the use cases
      currently in Pseudos 4.
  - RESOLVED: Adopt css-highlight-api as ED with sanketj, florian ,
              and hober as editors; add issue into css-pseudo-4 for
              where it might be integrated pointing at the ED

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

Agenda: https://wiki.csswg.org/planning/tpac-2019#agenda

Scribe: fantasai
Scribe's Scribe: florian

CSS Pseudo 4
============

Highlight APIs
--------------
  github: https://github.com/w3c/csswg-drafts/issues/4307

  sanketj: Want to talk about new proposal about highlight API
  sanketj: builds on top of existing css-pseudo-4 spec
  sanketj: Existing spec allows styling native highlights of the
           browser: selection, grammar-error, spelling-error
  sanketj: can style how you want
  sanketj: This is useful for editing apps
  sanketj: To implement own selection, spell-check, grammar error
  sanketj: Currently authors use spans
  sanketj: some problems
  sanketj: Can be complicated, particularly if span across multiple
           subtrees
  sanketj: then adding/removing creates perf problems
  sanketj: wrt invalidation etc.

  sanketj: Proposal is users can add/remove highlight using dom ranges
  sanketj: since can span multiple subtrees, easy to code
  sanketj: Invalidation is only paint invalidation, due to how
           highlight pseudo elements work in css-pseudo-4
  sanketj: will overview first, then ask for feedback, also some issues
  sanketj: If people support concept, would like to move towards
           official spec

  sanketj: Two key pieces: one is cssom piece, one is a selector
  sanketj: Adding two new types:
  sanketj: HighlightRangeGroup provides a group of ranges to be
           handled together
  sanketj: similar to find-in-page, range per instance of term
  sanketj: Want to style at once
  sanketj: so style all together
  sanketj: HighlightsMap takes a name key and group as a value
  sanketj: Introducing a global map per document, contains all
           user-defined highlights
  sanketj: Way user adds a highlighRangeGroup is calling .set(), user
           will give a name and use that as key into the map
  smfr: User meaning author?
  sanketj: Yes

  sanketj: Two properties on highlightRange which are interesting
  sanketj: .style property and .set(?)
  sanketj: Connection from highlightMap to group is needed to make it
           stylable
  sanketj: Can only style stuff registered in the highlightMap
  sanketj: To style, introducing new pseudo, ::highlight(
           highlight-name)
  sanketj: Same properties supported as other highlight pseudo elements
  sanketj: can also use .style property on object
  sanketj: Works just like cascade: inline style wins

  sanketj: Wrt multiple highlight ranges covering same content
  sanketj: Example:
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/highlight/explainer.md#example-with-overlapping-ranges
  sanketj: Here we have two overlapping ranges, some text contained in
           both ranges
  sanketj: each in its own highlightRangeGroup
  sanketj: one is background yellow, one is background orange
  HeWenli: What color is the overlap?
  sanketj: What is the order?
  sanketj: We use the timestamp of adding to the map
  sanketj: If author wants to change that, they can set higher priority
  sanketj: Default priority is zero
  sanketj: but can change .priority attribute on the rangeGroup

  sanketj: That is core pieces of the proposal
  sanketj: want to pause and ask for feedback
  Rossen: already have a queue, so let's go through that

  TabAtkins: Question about the reasoning for having rangeGroup
             instead of multigroup, but you explained with priorities
  TabAtkins: wrt that, is priority 0+ or can be negative?
  sanketj: Can be negative
  sanketj: Want to discuss how priority relates to other pseudo
           elements
  TabAtkins: Any ties, then fall back to timestamp order?
  TabAtkins: One more question, is intention that, if took that example
             calling foo again, would it have a newer timestamp?
  sanketj: no, timestamp is established when first added to the map
  plinss: timestamp order same as iteration order of the map?
  sanketj: yes
  <TabAtkins> Yeah, so that means even setting "foo" with a
              *different* highlight group would also not change the
              timestamp.
  <TabAtkins> (Which totally works for me; phrasing it more explicitly
              as the map iteration order would make me a little
              happier.)

  florian: First comment, really like this, many of us have been
           thinking of doing something like this for awhile, actually
           doing it is great
  florian: There already is a similar notion of ? for built-in
           highlights
  florian: not only important to say which one wins, but what does it
           mean to win, which can be different for different things
  [ e.g. text decoration layers, but text paints in topmost color
      only ]
  florian: so important not to re-invent a new solution for custom
           pseudo than for highlights
  florian: and have the resolution be the same mechanism
  sanketj: That's one of the issues I wanted to talk about

  emilio: Few questions, first how does this interact with shadow DOM
          and general scoping?
  emilio: CSS map is global, but rules that apply...
  emilio: global ::highlight pseudo that spans shadow tree and part of
          light DOM, what is the style of that?
  sanketj: Good question
  sanketj: As currently specced, you have a range in ShadowDOM and
           some outside, all styled by global map
  emilio: Do normal css scoping rules apply?
  emilio: Global parent group, that will apply to non-shadow-dom
          group, but not shadow dom group
  emilio: Do you explain how different groups intersecting priority,
          have to decide
  emilio: When you specify some properties in some range and not
          others, do you still apply properties of the other range?
  sanketj: You have one group applying bg color and one applying
           color, overlapping portion gets both of those
  emilio: How do you specify that
  florian: We have this problem already, and it's specified in
           css-pseudo-4
  florian: because we have same situation with selection/spelling-error
           /grammar-error
  florian: Whichever way we resolve it, must be same for custom ones
           and normal ones
  emilio: A bit annoying but fine I guess

  dauwhe: Higher-level question, Web has been struggling with
          identifying arbitrary ranges of text for a long time
  dauwhe: stuff like Web annotations etc.
  dauwhe: Does this complement those efforts? Is it independent of
          them? How does it relate?
  BoCupp: I would say that they are complementary. This doesn't do
          anything to identify arbitrary text fragments in a URL to
          identify a range, etc.
  BoCupp: Some places in DOM you can get a range, some cannot
  BoCupp: This is just about applying style over a range
  hober: There is a proposal right now for some kind of find-i-page
         fragment syntax, and would be useful to talk to those people
  Rossen: Who has proposal?
  hober: Will drop in minutes
  <tantek> See Fragmentions for existing work on this too:
           https://indieweb.org/fragmention
  <tantek> deployed on a bunch of sites
  <AmeliaBR> Text fragment in URL proposal: https://github.com/WICG/
             ScrollToTextFragment

  atotic: Any restriction on styles you can apply?
  sanketj: Set of properties you can apply to highlight pseudo is same
           as for other highlight pseudos
  sanketj: Fairly limited

  cbiesinger: Have you considered making priority part of ::highlight()
              pseudo syntax rather than in JS?
  fantasai: It's more a question of order. For regular element, we
            have the DOM order, but for pseudos we don't. For the
            built-in ones, we specify that order into the spec
  fantasai: but for custom ones, we need to specify where they fit
  fantasai: This isn't something you want to redo everytime you select
            something, so it doesn't belong in the selector.
  fantasai: We could have a declarative mechanism in addition to JS,
            but selectors isn't it.

  heycam: I like the proposal, wanted to be able to do for awhile
  heycam: Two questions:
  heycam: Is there a need to style ranges that match multiple
          highlights at the same time
  heycam: rather than just styling all of the individual highlight
          pseudos
  heycam: if you have a comma separated name of highlight pseudos?
  sanketj: Trying to understand
  sanketj: if you have multiple ranges, would you need to style them
           separately if the same content?
  heycam: Would you need to be able to style, say I want this style
          when I match both "a" and "b" type of highlight
  sanketj: Scenarios we're looking at, they are independent
  sanketj: one implementing spellcheck, one implementing selection,
           etc.
  sanketj: want both of those styles to show up
  heycam: Two styles of text decorations are underlining, maybe you
          want to style slightly differently if two underlines
  BoCupp: So if you have a range that is overlapping two range groups,
          e.g. this section is currently selected and also a found word
  BoCupp: When combination comes together, you want to pick a
          different color for that?
  BoCupp: don't have a good scenario for that

  heycam: The built-in highlights, they're not exposed in the JS API,
          would it be beneficial to expose those?
  heycam: So you could set .style on them, too
  sanketj: Maybe

  dbaron: I'm also a big fan of this, we've talked about having a
          feature like this for awhile
  * hober is also a big fan of this and has wanted something like this
          for years
  dbaron: Some questions

  dbaron: A little concerned about ergonomics of the JS API
  dbaron: One common thing a user will want to do is create a range
          and add it to the set of something
  dbaron: say the set is called grammar-error
  dbaron: My reading of what you have in the JS API is that the way
          you do that is going to be different depending on whether
          you've added a grammar error before
  sanketj: In scenario you're adding a grammar-error
  sanketj: if you are creating range for grammar errors
  sanketj: user types something, new grammar error appears
  sanketj: grammarly made the group and has to keep track of the name
  sanketj: they need to keep track of that info
  iank: Mentioned someone making such a library would ...
  dbaron: Seems awkward to create all your global errors up front
          rather than initialize
  dbaron: Reminds me of various set APIs that have e.g. get APIs that
          have "get this object out of the set, and if it doesn't
          exist make me one"
  dbaron: It seems like this API should have that mode
  dbaron: maybe some other way to structure API

  dbaron: Other thing is that I'm not sure, there's a bunch of new
          work in pseudos spec
  dbaron: Unsure if implemented
  sanketj: Wanted to check status of implementation interest of
           pseudo-spec
  dbaron: If those are not implemented, I'd prioritize interests of
          getting this implemented over those
  dbaron: Having generic mechanism work reasonably is more important
          than having existing spec work
  florian: The thing that makes them tricky to implement isn't which
           one exist, but how do they work?
  florian: We have to figure that out for built-in and for custom
  florian: If we implement custom things and drop built-in grammar and
           spelling-error standard, I don't mind
  florian: but defining how the cascade work etc. is still needed
  dbaron: Yes, but if that work doesn't extend well to an arbitrary
          list rather than a specific list, then given that at least
          it's not implemented, we should fix the cascading/etc to
          work for arbitrary list of classes

  chrishtr: Wanted to ask your current thinking wrt performance of DOM
            mutations
  sanketj: Open issue on this
  sanketj: StaticRange is one of the options thinking about
  sanketj: might be useful
  sanketj: also going to discuss this topic in Editing TF later this
           week
  sanketj: Any other APIs to make this useful
  sanketj: If you have static range, do you still need live ranges?
  sanketj: I'm not sure
  sanketj: but would like to not just restrict it to ranges
  chrishtr: Appreciate taking it seriously, ranges have been a
            significant perf problem
  chrishtr: each API that changes DOM has to check that range is still
            correct, it's a problem

  skk: We are developing viewer for weak eyesight
  skk: using text-to-speech using SpeechSynthesis API
  skk: Is it possible to synchronize with speech?
  sanketj: Currently, the accessibility concerns haven't been addressed
  sanketj: True for all highlights, I think. Don't think have a way to
           say spelling error exists here
  sanketj: so still need to figure that out

  birtles: Priority field feels a bit like z-index
  birtles: Are there any alternatives like a relative ordering?
  birtles: I'm concerned that an extension highlightRanges in the
           page, going to be a highlight war to get higher priority in
           the page
  sanketj: Regardless of option, need to have some kind of
           recommendation of how priority would interact with
           application priorities
  fantasai: I think that setting the priority relative to the priority
            of the built-ins is easy, you just set it a priority.
  fantasai: Probably you just set it to 0.
  fantasai: That doesn't answer brian's question, which is multiple
            liberties competing.
  fantasai: So how do they coordinate rather than just assigning
            random numbers?
  fantasai: cuz most of them will then try to assign max-int
  BoCupp: I don't think you can coordinate things that are inherently
          uncoordinated themselves, there has to be an integrator
  BoCupp: When frameworks brought together in the web app, maybe grab
          each one and set its priority to say which is more important
  BoCupp: Extensions like grammarly, go app by app, look at how do I
          integrate with each app?
  BoCupp: Don't do it blindly, do it after investigating the app
  BoCupp: Today have to figure out how to integrate spans into app
          without breaking, this would be much less invasive
  birtles: Quick example of relative ordering
  birtles: My app does highlights for a short time, so should be above
           grammarly's highlights
  birtles: with priority approach, I might see that grammarly uses
           1000, so I use 1001.
  birtles: but then grammarly upgrades to 2000
  birtles: Maybe have an API that give me the highest available
           priority, or priority above this particular name
  sanketj: Currently best could do is iterate map and get the highest
           priority
  johannes: Grammarly tries to integrate with other apps, in cases
            where it cannot, it usually just breaks the app
  johannes: In gmail, can't integrate with it, your email is just gone
  johannes: grammarly is trying to do this for awhile, but it's not
            working unless you have central registry

  rune: Thinking about cascading and inheritance
  rune: div::selection, implementations aren't using that style for
        span::selection in the div
  rune: concerned there will be too much inheritance
  BoCupp: A few questions about priority and inheritance
  BoCupp: Maybe we should go to the issues?
  rune: Just a general worry
  rune: Maybe we should fix that in implementations before adding lots
        of new ones?

  sanketj: Priority property is currently just distinguishing stacking
           order for user-defined highlights
  sanketj: Want to discuss how that relates to native highlights and
           combination of the two
  sanketj: If we extend to native highlights, two pieces here, what is
           default priority for user-defined highlights relative to
           native highlights
  sanketj: if user wants to customize that, what is mechanism?
  sanketj: Some scenarios are useful
  sanketj: when author is building some editing capability, but using
           native capability for something else
  sanketj: might implement find-on-page, but use UA's selection
  sanketj: and want that to show up above their find-on-page
  sanketj: In other cases might want to show over the UA selection
  sanketj: solution I propose is that by default, author-defined goes
           below UA-defined
  florian: I agree

  BoCupp: Is there a need to interleave with the UA highlights?
  BoCupp: Having phase above or below that is probably easiest
  fantasai: The painting rules are already interleaved
  fantasai: background is painted before, text decorations are on top
  fantasai: it's inevitable that things interleave
  sanketj: spelling-error and grammar-error, is one group
  fantasai: But if you've got multiple of them trying to set the same
            property, the one needs to win

  sanketj: Selection, find-on-page different
  sanketj: Let's say user wanted to implement their own spell-check
           and use their own styles
  sanketj: but wanted to use browsers' grammar-error, is there a way
           to maintain that stacking order?
  sanketj: Because selection and spelling error are different styles,
           then would get both
  fantasai: There might be a way to allow the UA defined ones to be
            manipulated the same way as the custom ones
  fantasai: If you had the native ones in that same map, using
            standard names, the author could style them, change their
            priority...
  fantasai: the author could possibly also replace the range objects
  fantasai: so the author could take over built in ones, instead of
            duplicating
  <heycam> +1 I was just thinking the author may want to use the
           browser's native styling for grammar etc. with their own
           range, so it may make sense to expose them in the map to
           allow that
  fantasai: Also worth noting that we have spelling-error and
            grammar-error text-decoration styles, so you can duplicate
            that styling if you want to for other types of highlights

  florian: Need to be careful about priorities
  florian: and thinking about them
  florian: It's not quite about in front / behind
  florian: because even if you have lowest priority, your foreground
           will be over the background of the highest priority
  florian: Some degree of interleaving is inevitable
  florian: if there is a priority that doesn't allow ?
  florian: not sure banning it would solve the implementation problem
  florian: backgrounds are behind, shadows, then text

  BoCupp: ....
  BoCupp: We reasoned, does anyone need that, what are scenarios?
          would you replace grammar/spelling errors?
  BoCupp: fishing for scenarios that would require a more capable API

  Rossen: One procedural recommendation, since running low on time
  Rossen: hearing quite a bit of support and interest from CSSWG
  Rossen: something that has been needed for quite some time
  Rossen: I suggest that we transition into figuring out where this
          work is going to go
  Rossen: and start transferring text into an actual spec, and start
          tracking issues in our GH tracker
  Rossen: If going back to explainer, where would work need to be
          split out?
  Rossen: there's some selectors and then some actual pseudo
          explanation
  fantasai: I'd say either its own spec or the pseudo elements module.
  florian: Starting as own thing, maybe merge into pseudo maybe
           split it
  <astearns> +1 to OM concerns mixed in the feature, instead of in a
             separate spec

  sanketj: Also question on name
  sanketj: earlier proposal was range-decoration?
  fantasai: css-highlight-api
  <tantek> +1 fantasai
  Rossen: Any objections to adopt as ED, with sanketj as editor?
  dbaron: Adopt as new ED or integrate into css-pseudo-4?
  dbaron: I'd prefer integrating into css-pseudo-4
  dbaron: Would prefer the closely related things be in the same
          document
  iank: That said, might be easier to iterate on API if separate
  florian: Can revisit during FPWD time
  Rossen: So maybe start as separate spec and integrate later?
  TabAtkins: An issue into css-pseudo-4 pointing at draft to be
             integrated later

  Rossen: Any co-editor?
  florian: Propose myself
  sanketj: ok!
  hober: Me too

  RESOLVED: Adopt css-highlight-api as ED with sanketj, florian, and
            hober as editors; add issue into css-pseudo-4 for where it
            might be integrated pointing at the ED

  <br type="lunch">
Received on Friday, 4 October 2019 22:52:09 UTC

This archive was generated by hypermail 2.3.1 : Friday, 4 October 2019 22:52:09 UTC