[css-align] how to position a baseline-sharing group containing items with different fallback alignment
Nobody has claimed this yet.
- Dominant language
- Bikeshed
- Stars
- 4.9k
- Forks
- 816
- PR merge metrics
- PR metrics pending
Description
The spec text on how to position a baseline-sharing group seems confusing to me. I'll illustrate with an example:
<div style="display: grid; grid: 50px 50px / 200px;">
<div style="writing-mode: vertical-lr; justify-self: baseline;">1<br>2</div>
<div style="writing-mode: vertical-rl; justify-self: last baseline;">1<br>2</div>
</div>
§9.2 says (in the last bullet) that "opposite block flow direction and opposite baseline alignment preference" share the same baseline group, so the two items above are in the same group.
§9.3 says "Position the aligned baseline-sharing group within the alignment container according to the fallback alignment associated with the specified baseline alignment preference.".
The problem is that "baseline alignment preference" is associated with an item, not a group. In this case the two items have different fallback alignment, so the spec isn't clear how the group should be aligned.
It seems like the spec text in §9.3 assumes that all items in a group have the same specified alignment value, and thus the same fallback value.
I'm guessing that since the relevant baselines are on the same side visavi the container that the group should use start alignment in this case, but the spec could be clearer on this.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by comparing the example with CSS Align §9.2 and §9.3, focusing on how a baseline-sharing group is positioned when its items have different fallback alignment. Trace the meaning of the baseline alignment preference for each item and determine what the specification currently defines. Done means resolving the ambiguity and clarifying the relevant specification text.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- css
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100