[css-logical][selectors] Should flow-relative border colors be allowed in :visited?

[Loirooriol]

According to 4a4b81c, "the 'border-color' sub-properties" are allowed in :visited. This seems to refer to border-top-color, border-right-color, border-bottom-color and border-left-color.

But what about the flow-relative border-block-start-color, border-block-end-color, border-inline-start-color and border-inline-end-color?

They are basically the same, so I guess they should also be allowed, but since this kind of things are delicate due to privacy concerns, I want a confirmation.

[upsuper]

The related text doesn't seem to be in the spec now?

[Loirooriol]

According to #2263 (comment),

The commit (that I accidentally pushed earlier; it's still visible from the #2105 PR) specifies in step 2 that you compute styles, then in step 3 you record the styles; the implication is that you're recording computed styles

And from https://drafts.csswg.org/css-logical/#box,

the flow-relative and physical properties share computed values

So it seems flow-relative border colors should work in :visited.

[Loirooriol]

Then the question is whether the writing mode should be ignored in :visited or if it should affect the logical-to-physical mapping, e.g.

a {
  border: 20px solid red;
  writing-mode: horizontal-tb;
}
a:visited {
  border-block-start-color: green;
  writing-mode: vertical-lr;
}

Should border-block-start-color be resolved according to horizontal-tb or vertical-lr? For consistency with #2263, I'm more inclined towards the latter.

[emilio]

Variables are a whole different step from value computation.

Saying that writing-mode and direction applies to :visited, but only in a half-assed way (for custom-property mapping, but not for layout or anything else) seems somewhat inconsistent.

Note that there's still another case we should define which is how should it resolve for a:link { different-writing-mode }.

What I've implemented in Gecko uses the unvisited writing mode unconditionally for custom-property mapping (that is, :link has effect in the :visited style), which is somewhat inconsistent, but was the only reasonable way to implement without adding a lot of extra complexity.

Also, I think it's a much easier behavior to implement at least for WebKit and Blink as well.

[emilio]

Note also that per the spec as proposed these properties should be useless (i.e., always be resolved with the default writing-mode / direction). I think nobody would want that behavior, and matching the writing-mode that gets used on layout (the unvisited one) makes sense.

[Loirooriol]

Also, I think it's a much easier behavior to implement at least for WebKit and Blink as well.

Yes, that's how my patch for Blink behaves (but it was rolled out due to an unrelated problem)

[fantasai]

Yes, they apply. I don't see any reason why they wouldn't. +1 to @emilio’s comment. Transferring issue to selectors-4 for clarification on how :visited interacts with writing-mode if needed, this isn't an issue with logical properties.