- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 4 Oct 2019 18:51:16 -0400
- 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