[css-cascade][CSSOM] Protected properties

[Crissov]

Reading up on the current state of two-value syntax in the display property again recently, reminded me of a thought I first had a couple of years ago:
Should CSS introduce write-protected, read-only properties which have a standardized name, whose value cannot be set directly (neither in stylesheets nor by scripts), but can be retrieved via scripting?

CSS currently considers a property (of an element or box) as something that always exists in a default state and an author can explicitly assign a value to.
A protected property would be special in that it could not be declared, but – I think – it would be cascaded and therefore specified, so it also was computed, possibly becoming used and actual.
CSSOM allows scripts to access (i.e. read and usually also write) values by reading a serialized (computed or used) value with getComputedStyle() or getPropertyValue() and updating or by writing new values with setProperty() – or with their camel-cased and dashed attribute aliases; and also by deleting values with removeProperty(). Note that while CSS Declaration Block has a readonly flag, the CSS Declaration, which is not exposed as an object, has not and then would probably need one.

Protected (or private?) properties would mostly be used with properties that accept multiple values and might become shorthand properties in a later level. The protected properties would work as the anticipated longhands. The danger, of course, is that editors would then feel more compelled to simply turn those former protected properties into longhands instead of exploring alternative solutions, e.g. display-inside/-outside vs. display-model/-role, to avoid the introduction of (partial) aliases.

The concept could also be used by properties that are helpful or systematic to specify but should only be settable by the browser, never by authors and users, due to implementation details for semantics of the host document language, e.g. something like:

/* browser default stylesheet for HTML */
img[src][alt] {
  display-model: replaced;
  content-image: attr(src type(<url>));
  content-text: attr(alt);
  content-size: target-size(attr(src type(<url>)));
}
a[href] {
  content-link: attr(href type(<url>));
}
title {
  env-set: title content();
}
[id] {
  target-set: attr(id type(<ident>));
}

PS: Feature queries with @supports implicitly assume declarability. This would either need to be stated explicitly or could be changed to computability, so protected properties could be used therein.

[Loirooriol]

I don't see the point. Instead of adding these pseudo-longhands, why not just turn the property into a shorthand of actual longhands?

could also be used by properties that are helpful or systematic to specify but should only be settable by the browser

The browser can already use internal properties, adjust the computed value, etc. Again, I don't see this bringing much benefit.

[Crissov]

I deliberately phrased this as a question because I’m not sure it would really be helpful or useful in practice – and outweigh the costs of implementation and of potentially maintaining legacy aliases in the future.

For authors, all of this would only matter if they could act on the values of those properties, i.e. through the OM in scripts or with @supports, if() etc. in CSS. Some of them would closely map to selectors, so write-protection essentially avoids circular dependencies / contradictions as in hypothetical :link {content-link: none}.

In theory, browsers could expose those pseudo-internal properties from the second use case in special stylesheets to implement arbitrary document languages or at least XML dialects. This would probably require some other changes and allen's as well, though, e.g. URLs in attr().