Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-pseudo][css-writing-modes] text-orientation and ::marker #9788

Open
frivoal opened this issue Jan 12, 2024 · 7 comments
Open

[css-pseudo][css-writing-modes] text-orientation and ::marker #9788

frivoal opened this issue Jan 12, 2024 · 7 comments
Assignees

Comments

@frivoal
Copy link
Collaborator

frivoal commented Jan 12, 2024

text-orientation should have an effect on ::marker, so that, for instance, you can have upright numerals in a numbered list's markers, and otherwise mixed orientation text.

ol {
  writing-mode: vertical-rl;
  text-orientation: mixed; /*the default*/
}
ol li::marker {
  text-orientation: upright;
}

Here's a test case: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=12266

Currently, all browsers fail it. I think that's a browser bug, as even though text-orientation isn't part of the set of properties that apply directly to the ::marker pseudo, it should inherit into the text inside the marker and apply there. Do we agree, or is there something somewhere in the spec that actually makes it the expected behavior?

@frivoal frivoal added css-pseudo-4 Current Work css-writing-modes-4 Current Work labels Jan 12, 2024
@Loirooriol
Copy link
Contributor

it should inherit into the text inside the marker and apply there

text-orientation is defined to apply to "all elements except table row groups, rows, column groups, and columns". Not to text.

Maybe that should change, but with the current specs, browsers seem compliant here.

@frivoal
Copy link
Collaborator Author

frivoal commented Jan 14, 2024

Fair point.

I guess text-orientation has two (families of) effects:

  • change how text is laid out
  • change text-related units

It seems logical for the second one to be anchored on actual elements. The first one would make more sense to me to apply to text, so a possible fix for this issue would be to change the Applies To line from "all elements except[…]" to "text, and all elements except […]".

From a compat point of view, that ought to be largely OK:

  • on ::marker their may be sites where starting to apply it would be a change, but most likely it would be a desired change (people wouldn't specifically style markers if they didn't want an effect on markers).
  • the on content of tables, it won't make a difference, because while table row groups, rows, column groups, and columns are excluded, table cells are not, and so we're already inheriting and applying it there, so there would not be a difference in behavior.

If we don't want to do that, I would argue that would ought to include it in the properties explicitly allowed on ::marker.

@Loirooriol
Copy link
Contributor

Loirooriol commented Jan 14, 2024

This is upright on Gecko, Blink and WebKit:

<div style="writing-mode: vertical-rl">
  <div style="display: contents; text-orientation: upright">AB</div>
</div>

So I guess it's implemented as applying to text indeed.

@Loirooriol
Copy link
Contributor

In fact since inline elements/boxes are not excluded, and it's inherited, then it needs to apply to text as per #5303 (comment).

@frivoal
Copy link
Collaborator Author

frivoal commented Jan 22, 2024

So, it would seem that this needs no normative spec correction. We'll need at least some tests, but should we add an informative statement? Maybe include one more bullet point in example 4 highlighting the conclusion reached in #5303 (comment) that “inheritable properties that apply to inlines also apply to text”.

@Loirooriol
Copy link
Contributor

I think #5761 missed text-orientation and it needs to be changed to also apply to text to obey the resolution from #5303.

@Theshrink

This comment was marked as duplicate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants