55 Chrome implementation notes 0 paint originating content (suppressing text where highlighted), then paint highlight overlays. perhaps chrome seems to clip highlight shadows as part of a solution for ligatures (including e.g. hebrew, arabic), because a naïve “paint glyphs 0..n except for p..q, then paint glyphs p..q” might be incorrect for ligatures depending on how it’s done? 67 https://github.com/w3c/csswg-drafts/issues/3932 we probably shouldn’t clip highlight shadows if we can avoid it. 68 https://bucket.daz.cat/work/igalia/0/3.html current painting order seems to be • original k shadow • original k text • original uic shadow (over original k text!) • selection background • selection uic shadow (clipped!) • original q shadow (over selection background!) • original q text, original uic text 1 https://drafts.csswg.org/css-pseudo-4/#highlight-bounds 2 2008-10-16 https://www.w3.org/Style/CSS/Tracker/issues/67 3 2006-05-09 https://lists.w3.org/Archives/Public/www-style/2006May/0060.html asks for clarification on how inheritance works in ::selection, whether your ::selection styles can be overridden by your children’s (originating?) styles, and whether your ::first-{letter,line} styles can override your ::selection styles. 4 2008-06-27 http://lists.w3.org/Archives/Public/www-style/2008Jun/0356.html asks if an inner ::selection specifying color only inherits background-color from an outer ::selection specifying both. this seems to touch on two parts of the modern spec: the general inheritance model for highlight selectors, and the specific relationship between color and background-color. 5 2008-06-28 https://lists.w3.org/Archives/Public/www-style/2008Jun/0360.html suggests that ::selection pseudos form a kind of “::selection inheritance tree” where all properties (even non-inherited) are inherited from outer ::selection pseudos. 6 2008-06-28 https://lists.w3.org/Archives/Public/www-style/2008Jun/0361.html hints at ::first-line’s inheritance being underspecified, and that ::selection is similarly underspecified. 7 2005-10-23 https://lists.w3.org/Archives/Public/www-style/2005Oct/0163.html asks how your children’s styles interact with your ::first-line styles. 8 2005-10-24 https://lists.w3.org/Archives/Public/www-style/2005Oct/0164.html “fictional tag sequence [<div::first-line>] is just an explanatory concept, and not an implementation requirement” — hixie. 9 2006-01-21 https://lists.w3.org/Archives/Public/www-style/2006Jan/0091.html ::first-line has interop problems, especially around the inherit keyword. 10 2006-01-31 https://lists.w3.org/Archives/Public/www-style/2006Jan/0209.html https://lists.w3.org/Archives/Public/www-style/2006Jan/att-0209/test.html Chromium/87 and Firefox/83 still don’t agree on this test page. 11 2008-10-16 http://www.w3.org/mid/20081016131706.127795F74D%2540stu.w3.org inaccessible. 12 2008-10-19 https://lists.w3.org/Archives/Public/www-style/2008Nov/0022.html F2F minutes. 13 > David: Pseudo-elements have this thing where their boundaries don't line up with the tree > David: The question is do you split the <span> into 2 pieces, or do you split the pseudo-element into 2 pieces? > David: The current spec says you split the pseudo-element > Daniel: Can the pseudo-element contain more than pcdata and replaced elements? > <dbaron> The question is: Does <span>A<pseudo>B</span>C</pseudo> give the tree <span>A<pseudo>B</pseudo></span><pseudo>C</pseudo> or <span>A</span><pseudo><span>B</span>C</pseudo>? general premise: we need to decide how to reconcile ::selection (as a pseudo that is very much non-tree-abiding) with existing CSS concepts that are defined in terms of tree structures, such as inheritance. 14 > Daniel: Question remains, do I have multiple outlines for richtext::selection? concrete question that sparked this discussion. 15 > David: What Mozilla actually implements now, I think, is something that sounds even more complicated than these two > David: We do both > David: We do one for the inherited properties and one for the non-inherited properties > David: I'm not even sure if that's quite what we do not sure whether David means “split pseudo” for inherited and “split element” for non-inherited, or the other way around, or something else? but more importantly, i don’t understand how either of these “tree conversions” would work in practice. clearly we wouldn’t use them everywhere, because that would break the author’s selectors/DOM expectations in their styles/scripts. but even reading those fictional tag sequences as a way to describe how ::selection inheritance would work, i still don’t understand. 16 > [...] 17 > ACTION: fantasai or dbaron write double-cascade proposal for ::selection see below. 18 2008-10-26 http://www.w3.org/mid/20081026221002.GA12528%2540pickering.dbaron.org https://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html 19 > (1) The appearance of a piece of text when it is selected should not vary depending on the root container of the selection. 20 > (2) The system's default selection style should be representable in terms of CSS selectors (although we may not currently have properties for all aspects of the style), in the UA style sheet. 21 > (3) Author styles should override the system's default selection style. 22 > (4) The background color and foreground (text) color of the selection style should always cover/override the background and foreground that apply when the text is not selected. 23 > (5) Authors should be able to change the selection style within a specific element. (Because of (1), such changes apply to any selected content inside that element, whether or not the element is an ancestor of the root container of the selection.) If they can do so, such a change should apply to all of the descendants of that element. 24 > [...] This means that the ::selection pseudo-element must be innermost (i.e., the text "the" is wrapped in the selection pseudo-element which is in turn inside the span), even for background-* (which are non-inherited properties). Making the ::selection pseudo-element innermost also helps satisfy (1). i guess this means we can’t just compute the ::selection style for the root container of the selection, and apply that to the whole selection. but the “even for background-* (which are non-inherited properties)” part is confusing to me. it sounds like a pre-highlight-overlay concept where there’s only one background and the ::selection background needs to override the originating element’s background? 25 > A) nested ::selection pseudo elements (one for each ancestor in tree) so this would be like a “::selection tree” that reflects the hierarchy of the element tree? 26 > - handles background colors with alpha badly (though perhaps depending on requirements) i guess the current spec solves this by saying “Each box owns the piece of the overlay corresponding to any text or replaced content directly contained by the box.”, regardless of whether the spec is (A) or (B). my understanding is that only the innermost ::selection or piece of ::selection (with the deepest possible originating element) at any given point participates in any rendering. 27 > B) single ::selection pseudo element, cascaded by (tree depth, weight/origin, specificity, order) this sounds like the current spec, in that there’s conceptually one instance of ::selection, with special context-dependent style (varying depending on which innermost originating element is associated with that location), and it “handles *::selection badly”. 28 > C) single ::selection pseudo element, cascaded by (weight/origin, specificity, tree depth, order) so if i understand correctly, the usual cascade is (weight/origin, specificity, order), and in both (B) and (C) the special criterion being added is “tree depth”, as a concrete way to create that special context-dependent style i mentioned above. 29 > In all cases, a ::selection pseudo-element would never contain any real elements; they would always be split at any boundaries and created as the innermost position. 30 > However, I haven't yet considered the effect of declaring the 'outline' property on ::selection pseudo-elements, which might make an outermost rather than an innermost pseudo-element desirable, assuming that supporting 'outline' on ::selection is really a requirement. 31 https://lists.w3.org/Archives/Public/www-style/2008Oct/0277.html links to early tests. 32 http://www.w3.org/mid/CADhPm3szi2g4V%252B9aJnNtB6uAozD3gLyB50iwT_xt4aSQuYvcjw%2540mail.gmail.com https://lists.w3.org/Archives/Public/www-style/2015Nov/0306.html (relevant discussion in next message) 33 https://lists.w3.org/Archives/Public/www-style/2015Nov/0307.html mostly a discussion of :host, whether :host or ::host makes more sense, and whether :host(...) or :host... makes more sense. only briefly touches on ::selection. 34 2010-05-14 https://lists.w3.org/Archives/Public/www-style/2010May/0247.html 53 https://lists.w3.org/Archives/Public/www-style/2010May/0248.html https://lists.w3.org/Archives/Public/www-style/2010May/0250.html https://lists.w3.org/Archives/Public/www-style/2010May/0251.html https://lists.w3.org/Archives/Public/www-style/2010May/0252.html https://lists.w3.org/Archives/Public/www-style/2010May/0253.html https://lists.w3.org/Archives/Public/www-style/2010May/0254.html https://lists.w3.org/Archives/Public/www-style/2010May/0257.html https://lists.w3.org/Archives/Public/www-style/2010May/0259.html https://lists.w3.org/Archives/Public/www-style/2010May/0264.html https://lists.w3.org/Archives/Public/www-style/2010May/0265.html https://lists.w3.org/Archives/Public/www-style/2010May/0267.html https://lists.w3.org/Archives/Public/www-style/2010May/0268.html https://lists.w3.org/Archives/Public/www-style/2010May/0271.html https://lists.w3.org/Archives/Public/www-style/2010May/0273.html https://lists.w3.org/Archives/Public/www-style/2010May/0274.html vendor prefix discourse. 35 https://lists.w3.org/Archives/Public/www-style/2010May/0275.html black-box analysis of ::selection behaviour circa 2010, including whether child::selection inherits from parent::selection (“propagates through the DOM Tree”), bounds of ::selection background (and how safari’s approach here relates to the opacity of those backgrounds), generated content, and replaced content (“IMG selection overlay”). suggests spec for color and background-color (or all properties?) quoted below. 36 > Find the nearest element of the DOM which is parent of the selected text node (or part of it). > While there's no special ::selection rule on the element, or while the element has no parent, we consider its parent. does this literally mean finding the closest ancestor where any active stylesheet contains any *rule* with a matching selector, regardless of the contents of that rule? so adding “p::selection{}” to my stylesheet could stop this traversal and change computed values? surely not. 37 > If an element with ::selection has been found, we use the value that applies to that ancestror hmm so maybe “no special ::selection rule” and “with ::selection” didn’t literally mean *rule*, but rather the closest ancestor whose ::selection sets a value for the given property (as in CSS21 § 6.1.1 step 1). that makes more sense. 38 > If no element has been found, we use the normal behavior for the selection. initial value. would color and background-color have a special case requiring them to be considered together before this step, allowing us to stop at an ancestor that sets only one, as in the current spec? 39 https://lists.w3.org/Archives/Public/www-style/2010May/0278.html bzbarsky asks similar questions and discusses gecko behaviour. 40 https://lists.w3.org/Archives/Public/www-style/2010May/0280.html hyatt expands on webkit behaviour. 41 https://lists.w3.org/Archives/Public/www-style/2010May/0282.html https://lists.w3.org/Archives/Public/www-style/2010May/0288.html the difference between background:none and background:transparent. 42 https://lists.w3.org/Archives/Public/www-style/2010May/0291.html https://lists.w3.org/Archives/Public/www-style/2010May/0293.html favouring a special case for color and background-color. 43 https://lists.w3.org/Archives/Public/www-style/2010May/0304.html https://lists.w3.org/Archives/Public/www-style/2010May/0305.html https://lists.w3.org/Archives/Public/www-style/2010May/0307.html https://lists.w3.org/Archives/Public/www-style/2010May/0309.html opposing a special case for color and background-color. 44 [...] 45 https://github.com/w3c/csswg-drafts/issues/2474 “::selection style propagation section doesn't reflect reality in any way” — emilio. 46 https://lists.w3.org/Archives/Public/www-style/2014Dec/0299.html most enlightening single message by far. 47 > [...] 48 > ::selection - Inheritance there’s more than one way to propagate parent ::selection styles to children ::selection styles: we can add tree depth as a cascade criterion (CSS21 § 6.1.1 step 1), or we can replace the inheritance step (CSS21 § 6.1.1 step 2) for ::selection with a step that inherits through an imaginary “::selection tree”. this tree roughly resembles dbaron’s option (A), except that for all other purposes, there would still be a single ::selection pseudo-element for the whole document (“highlight overlay” where any given point is “owned” by the innermost element). the latter raises the tricky question of whether the inherit keyword should refer to the originating element or the originating element’s parent’s ::selection. we ended up writing the former into the spec. 49 > Each element draws its own portion of the highlight overlay, which receives the styles specified by the highlight pseudo-element styles for which that element or one of its ancestors is the originating element. When multiple styles conflict, the winning style is the one belonging to the innermost element after cascading. old quoted text. so this sounds like dbaron’s option (B), where there’s a single ::selection pseudo-element, cascaded by (tree depth, weight/origin, specificity, order). 50 > What happens at least in WebKit, Blink and Gecko (haven't tested IE / Edge) is that the closest element ancestor's selection style is matched, inheriting from the ancestor style, and nothing else. does this mean finding the closest ancestor whose ::selection sets a value for the given property (as in CSS21 § 6.1.1 step 1), or just using the ::selection style of the innermost element at all times, or something else? what does “inheriting from the ancestor style” mean? 51 > <dael> emilio: Annoying part of how it's spec is you need to start resolving status to the top. > <dael> fantasai: There's different ways of getting same result. THere was an alternative way to have selection inherit from itself in a sep tree. > <dael> emilio: You have to resolve the entire tree which is different then what browsers do. I could say that, but I care about browser compat. 52 https://github.com/w3c/csswg-drafts/commit/e84201097a3f71adf0db02e397e4576659d7007a spec changes from “depth as cascade criterion” to “inheritance through imaginary ::selection tree”. the inheritance applies to all properties, not just inherited properties. 57 tests 58 https://annevankesteren.nl/test/css/temp/004.xml 59 https://web.archive.org/web/20080220154944/http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/html/tests/css3-modsel-40.html 60 https://web.archive.org/web/20081101111105/http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/html/tests/css3-modsel-162.html 61 https://web.archive.org/web/20090118122822/http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/html/tests/css3-modsel-164.html 62 https://web.archive.org/web/20090116230908/http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/html/tests/css3-modsel-165.html 63 questions for emilio 64 so let’s start with csswg-drafts#2474. i think a big part of what confused me was that, based on your original post, i expected the updated spec to revert to current impls’ behaviour (where styles for p::selection don’t “propagate” to descendant ::selections in any way), but when i read the diff, it looked like they rewrote the same behaviour using different words. 65 after rereading everything (and reading some new posts), my understanding is that the resultant spec change (from “depth as cascade criterion” to “inheritance through imaginary ::selection tree”) is invisible to authors (except inherit/unset keywords), while addressing your performance concerns. but because the updated spec still introduces the ability to style descendant ::selections, all impls still violate. have i missed anything so far? 66 why is the cascading approach slower than the inheritance approach here? i guess this is basically “how is CSS implemented?” because the extent of my CSS internals “knowledge” is basically that selectors are tested from right to left (which i learned way back when reading about rule performance and why :has doesn’t exist).