Firefox/Safari parse `break-before/after: avoid` without effect

[caugner]

Summary

Mentions that Firefox/Safari recognize the avoid value for the break-before/after CSS properties, but it has no effect.

Test results and supporting details

Related issues

• Relates to: https://github.com/mdn/browser-compat-data/issues/22723
• Follow up to: https://github.com/mdn/browser-compat-data/pull/27073

[github-actions[bot]]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[ddbeck]

These should be marked as partially implemented (see guideline). This has a noticeable incompatibility impact as compared to a plain non-implementation:

In a non-implementer (as implied by "version_added": false):

break-after: left;
break-after: avoid; /* still `left` because this line is rejected */

In these cases:

break-after: left;
break-after: avoid; /* now in some buggy non-functional state */

[caugner]

These should be marked as partially implemented (see guideline).

The guideline points to https://github.com/mdn/browser-compat-data/pull/3904 for additional background, which actually removed partial_implementation: true from CSS properties that were recognized but had no effect.

As for your example of non-implementation vs "parses without effect": I trust that your assessment is accurate, but I still don't think this justifies setting partial_implementation: true. In particular, I don't see a significant difference to other cases where using an unimplemented feature may have some (unexpected) side-effects.

Here's a visualization of where I think we are on the spectrum between "no support" and "full support".

| no   |        partial        |     full |
|   x                                     |

[ddbeck]

@caugner

The guideline points to #3904 for additional background, which actually removed partial_implementation: true from CSS properties that were recognized but had no effect.

That was a particular workaround for the peculiar situation of us not knowing when the partial appeared. To quote myself:

How about this as a compromise: merge this change as is, but open an issue inviting anyone who wants to to do to the research to find out when it was partially implemented. If we ever get that version number, we can switch to partial_implementation, but absent that data, leave this as false.

In this case we do have that information and have no such excuse. The current guideline (nor the more general one that I have proposed #26780, which you gave an LGTM) does not point to this outcome. If you think this should be the outcome, then I'd like to see what that a guideline would look like to permit such an outcome; this could have been a test vehicle for it.

@queengooborg I think it's disrespectful to merge this while there's still an active discussion about what needs to happen here, particularly before existing participants have had chance to respond to it. 👎