Baseline inconsistency between `position-area` and `::details-content`

[jakearchibald]

Over on MDN, there's imo an inconsistency in how Baseline banners are applied:

• position-area
  The banner suggests the feature is supported in Chrome, yet many of the properties, particularly the likely-to-be-used ones, have missing behaviours that can result in obscured content.
• ::details-content
  The banner suggests that Safari is the single hold-out for this feature (boo Safari boo!), but when you dig into the support table, this is due to a lack of support for ::details-content::before, which… I feel most users of this feature will not encounter.

There's some subjectivity here, but the banner seems, in this case, very lenient to Chrome, and unfair to Safari.

I'm not sure what the solution is, but it feels like there needs to be some way to mark sub-feature failures as serious enough to consider the whole feature 'not baseline'. Whereas some partial failures don't matter so much.

[jgraham]

For position-area in particular, it seems to be part of the anchor-positioning focus area where we compute_from 3 BCD keys (css.properties.anchor-name, css.properties.position-anchor, css.types.anchor) but claim that the feature covers 195 different BCD keys, which have multiple different levels of browser support.

This is obviously problematic; even if css.properties.position-area was marked as partial in some browser, we'd still claim the entire feature was supported in that browser.

In this case I think it likely makes sense to move all the BCD keys that are actually required to have a useful anchor positioning implementation to compute_from and everything else out into different (sub) features.

In general large discrepancies between compute_from and compat_features seems like a warning sign that we're doing something suspect; I'd suggest that discrepancies always need documentation. In this case I couldn't find anything in the file, in the git history, or in the PRs themselves to suggest why this set of three keys was considered representative of the overall feature.

[rviscomi]

Related issues: #1690 #2880

[nt1m]

Given that Baseline is being advertised as the source of truth on whether you can use a technology or not, I think it's rather unhelpful to developers to suggest that you can't use ::details-content at all on your website because of missing Safari support for an edge-case they are unlikely to run into...

[othermaciej]

Maybe there are three separate issues here:

• position-area support determination is too generous
• ::details-content support determination is too strict
• The system should more automatically check for discrepancies between compute_from and compat_features for meta-features.

[captainbrosset]

For ::details-content, I think we need to make a fix in BCD. Separate the base support from the ability to chain pseudo-elements to it. This way we can map our feature here to the base support (and therefore it works be Baseline), and create another feature just for the pseudo-elements chaining thing (or not btw, that part could be hidden by a compute_from field).

@nt1m would you be able to make the BCD change? That would be super helpful!

[nt1m]

The PR was done here: mdn/browser-compat-data#27995

[ddbeck]

#3456 fixes details-content.

For anchor-positioning, I think we just need to know what to expect across browsers, to find the right place to slice the feature up (or not); see @jamesnw's #3389 (comment) for background.

A question I have is roughly: to what extent Firefox is implementing position-area? I'd like to know more about how central the position-area values are to the concept of anchor positioning or if it's plausibly a follow-up embellishment to the feature.

[jamesnw]

A question I have is roughly: to what extent Firefox is implementing position-area? I'd like to know more about how central the position-area values are to the concept of anchor positioning or if it's plausibly a follow-up embellishment to the feature.

I'd say anchor positioning is usable without position-area, so it could plausibly be a separate feature. Based on my testing, Firefox will ship position-area similar to Chrome, with the core working in most cases, but with a set of behaviors that is either not to spec or not yet defined by the spec. Frustratingly, this set of edge cases will likely not be the same as Chrome's (or Safari's).

I'm not sure what the solution is, but it feels like there needs to be some way to mark sub-feature failures as serious enough to consider the whole feature 'not baseline'. Whereas some partial failures don't matter so much.

I think this is the subjective question here. Chrome's bug is not sufficient in my mind to say that all of anchor positioning is unsupported in Chrome. I'm not even sure I would say that it's sufficient to say that a separate position-area feature is unsupported in Chrome. position-area is usable in Chrome in many situations, but it could still be useful to warn users of this issue.