Intent to Prototype: CSS spelling and grammar features

[Delan Azabani]

Contact emails

<daza...@igalia.com>

Summary

CSS highlight pseudo-elements representing text that the UA has flagged as misspelled or grammatically incorrect, and text-decoration-line property values representing the UA’s default decorations for spelling mistakes and grammar mistakes.

This feature involves the implementation of two pseudo-elements (::spelling-error and ::grammar-error), and two new values for the text-decoration-line property (spelling-error and grammar-error).

Examples
Live version of everything below:
    https://bucket.daz.cat/work/igalia/0/1.html

UA stylesheet:
    ::spelling-error { text-decoration-line: spelling-error; }
    ::grammar-error { text-decoration-line: grammar-error; }

Styling spelling mistakes:
    p[contenteditable=true] {
        /* makes typical red squiggly lines hard to read :c */
        background: #BF3030;
    }
    /* highlight selector (only performant properties allowed) */
    p ::spelling-error {
        /* line is spelling-error, so UA may ignore this */
        text-decoration-color: white;
        /* line is spelling-error, but UA must not ignore this */
        background: white;
        /* line is underline here, not spelling-error */
        text-decoration: 2px orange wavy underline;
    }

Custom spelling and grammar checkers, using UA decorations:
    p .spelling {
        /* fallback for older browsers */
        text-decoration: 1px red wavy underline;
        text-decoration: spelling-error;
    }
    p .grammar {
        /* fallback for older browsers */
        text-decoration: 1px green wavy underline;
        text-decoration: grammar-error;
    }

Motivation

Authors should be able to customise the appearance of spelling/grammar mistakes. For example, the UA’s default colour for a mistake might be of inadequate contrast with some background colours.

The pseudo-elements would enable this, while the text-decoration-line values would allow the UA stylesheet to express the default decoration, as well as allow authors to decorate other text as if it was a spelling/grammar mistake (e.g. for a custom spell checker).

Design doc/spec
• https://drafts.csswg.org/css-pseudo-4/#selectordef-spelling-error
• https://drafts.csswg.org/css-pseudo-4/#selectordef-grammar-error
• https://drafts.csswg.org/css-text-decor-4/#valdef-text-decoration-line-spelling-error
• https://drafts.csswg.org/css-text-decor-4/#valdef-text-decoration-line-grammar-error

No TAG review request for these features, but all of them were resolved to be added by the CSSWG, and defined in the css-pseudo and css-text-decor-4 specs like the other pseudo-elements (e.g. ::target-text) and values (e.g. line-through).

We are also investigating the possibility of refactoring document markers (spelling/grammar errors in particular) and other text decorations to share some of their internals as part of this feature, to maximise customisability as recommended by the spec. The exact changes to be made, if any, are pending discussion with code owners and a design doc.

Risks

    Interoperability and Compatibility

    Main issue would be the lack of support in other browsers.

    • Gecko: No signal yet (<https://github.com/mozilla/standards-positions/issues/470>).

    • WebKit: No signal yet (<https://lists.webkit.org/pipermail/webkit-dev/2021-January/031660.html>).

        • WebKit has an old WIP patch from 2018 at <https://bugs.webkit.org/show_bug.cgi?id=175784>.

    • Web developers: Positive (<https://dev.to/lampewebdev/css-pseudo-elements-classes-you-have-never-heard-of-30hl#the-grammarerror-and-spellingerror-pseudoelement>).

    Ergonomics

    The new pseudo-elements depend on the new text-decoration-line values for UA stylesheet support. They are highlight pseudo-elements, which should pose minimal performance risk due to the limited set of CSS properties they allow.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Not yet. There are some tests in css/css-pseudo and css/css-text-decor, but we’ll improve test coverage for these features during implementation.

Link to entry on the feature dashboard

https://chromestatus.com/feature/4811776539492352

Tracking bug

https://crbug.com/1163437

[Mathias Bynens]

What kind of DevTools support do these feature require? Without any special tooling support, it sounds like developers would have to make typos on purpose in order to double-check their styles.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4e41f5b2-f5a6-4df9-bf84-84ea3a9a6fadn%40chromium.org.

[Delan Azabani]

At 6:23:10 PM UTC+11, Mathias Bynens wrote:

What kind of DevTools support do these feature require? Without any special tooling support, it sounds like developers would have to make typos on purpose in order to double-check their styles.

Good question! The pseudo-elements would, at the very least, show up in the rules panel even when there are no such highlights (just like ::selection below). With the text-decoration-line values, the idea would be that they could be applied to any element, including easier-to-test highlight pseudo-elements like ::selection (for correct painting semantics). This should allow for some testing without touching the spell checker, but it isn’t a very ergonomic solution.

Perhaps we could address this with a toggle — like the ones under “force element state” (:hov), but rather than forcing a pseudo-class, we force a highlight range over all of the text in an element?

[Delan Azabani]

(looks like embedded images don’t show up in the web client: https://bucket.daz.cat/c523c84ebdf39711.png)

[Sanket Joshi (Edge)]

Hi dazabani@, ffiori@ is planning to work on the highlight API (CSS Custom Highlight API Module Level 1 (w3.org)) - I2P coming soon - which will introduce another type of highlight pseudo. We should sync up if we are touching similar areas of code. We'd also like to stay in the loop on any changes being planned for document markers.

[Rune Lillesveen]

On Fri, Jan 8, 2021 at 2:35 AM 'Sanket Joshi (Edge)' via blink-dev <blin...@chromium.org> wrote:

Hi dazabani@, ffiori@ is planning to work on the highlight API (CSS Custom Highlight API Module Level 1 (w3.org)) - I2P coming soon - which will introduce another type of highlight pseudo. We should sync up if we are touching similar areas of code. We'd also like to stay in the loop on any changes being planned for document markers.

I noted in the gerrit review for these features that issue 1147859 needs to be attacked for painting when introducing new highlight elements. We need to rework the painting code to allow multiple highlight elements stacking and intersecting correctly.

On Thursday, January 7, 2021 at 2:57:57 AM UTC-8 Delan Azabani wrote:

(looks like embedded images don’t show up in the web client: https://bucket.daz.cat/c523c84ebdf39711.png)

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/347a0746-2547-446c-832c-b35ade3336f3n%40chromium.org.

[Arthur Sonzogni]

From the privacy/security point of view. It is important to make sure there is absolutely now way from the document to exfiltrate user's dictionaries.

Limiting the set of CSS properties to those 9 seems good, as long as the issue about "cursor: url(...)" is addressed.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeQ09EySkc3gicnobS3yRc7GovV07JBwaxOrqYdV85MYBQ%40mail.gmail.com.

[Rune Lillesveen]

Should also note that cascading does not match the spec: https://crbug.com/1024156

Same goes for other implementations as well.

[Delan Azabani]

Thanks for the feedback everyone!

On Friday, January 8, 2021 at 12:35:49 PM UTC+11 Sanket Joshi (Edge) wrote:

> Hi dazabani@, ffiori@ is planning to work on the highlight API (CSS Custom Highlight API Module Level 1 (w3.org)) - I2P coming soon - which will introduce another type of highlight pseudo. We should sync up if we are touching similar areas of code. We'd also like to stay in the loop on any changes being planned for document markers.

Sounds good. What works best for you? Something informal like chromium.slack.com, or email, or…?

On Saturday, January 9, 2021 at 2:50:15 AM UTC+11 Rune Lillesveen wrote:

> I noted in the gerrit review for these features that issue 1147859 needs to be attacked for painting when introducing new highlight elements. We need to rework the painting code to allow multiple highlight elements stacking and intersecting correctly.

Definitely. I’ve marked it as a blocker for the tracking bug (1163437).

On Thursday, January 14, 2021 at 12:56:29 AM UTC+11 Arthur Sonzogni wrote:

> From the privacy/security point of view. It is important to make sure there is absolutely now way from the document to exfiltrate user's dictionaries.

> Limiting the set of CSS properties to those 9 seems good, as long as the issue about "cursor: url(...)" is addressed.

Agreed. I didn’t notice that the spec allowed not just background-color (safe), but also cursor (unsafe unless restricted), so thanks for putting that on my radar.

On Thursday, January 14, 2021 at 2:09:29 AM UTC+11 Rune Lillesveen wrote:

> Should also note that cascading does not match the spec: https://crbug.com/1024156

Yeah, my colleagues raised this with me earlier today. I would imagine we can prototype without reconciling this gap, because the features are (to some extent) usable either way, but I do think this should block shipping. I don’t want to add to the potential backward-compatibility problems we’re already facing with ::selection, where — iiuc — all major engines still seem to violate the spec, even after the changes in csswg-drafts#2474.