Skip to content

[css-text] 'tab-size' de facto applies to inline boxes #5489

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.

Sign up for GitHub

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

Jump to bottom
Closed
Loirooriol opened this issue Sep 1, 2020 · 5 comments
Closed

[css-text] 'tab-size' de facto applies to inline boxes #5489

Loirooriol opened this issue Sep 1, 2020 · 5 comments
Assignees
@frivoal
Labels
Closed Accepted by CSSWG Resolution css-text-3 Current Work Tested Memory aid - issue has WPT tests Tracked in DoC

Comments

@Loirooriol
Copy link
Contributor

From https://drafts.csswg.org/css-text-3/#propdef-tab-size

Applies to: block containers

However, all Chromium, WebKit and Firefox also support it in inline boxes. Testcase

<!DOCTYPE html>
<div style="white-space: pre; tab-size: 100px; -moz-tab-size: 100px">
  A&#9;<span style="tab-size: 50px; -moz-tab-size: 50px">B&#9;C</span>
</div>

looks more or less like

A              B       C

So I guess the spec should be changed to reflect reality?
@Loirooriol Loirooriol added the css-text-3 Current Work label Sep 1, 2020
@frivoal
Copy link
Collaborator

frivoal commented Sep 2, 2020

Matching reality is good, so yes, we should change. But what is the behavior exactly? A tab character isn't a shift by a particular amount, it is a shit to a tab stop. I guess we just compute the potential tab stops independently for each preserved tab character?

If so, the following sentence

Tab stops occur at points that are multiples of the tab size from the block’s starting content edge.

just needs to be changed to

Tab stops occur at points that are multiples of the tab size from the starting content edge of the preserved tab's containing block’s.

I think that's what browsers do. An alternative model where tab stops of different sizes somehow stack up seems complicated and unnecessary.

@frivoal frivoal self-assigned this Sep 2, 2020
@frivoal frivoal added the Agenda+ label Sep 2, 2020
frivoal added a commit to frivoal/wpt that referenced this issue Sep 3, 2020
@frivoal
[css-text] Tests for support of tab-size on inline boxes
7ef5f1d 
See w3c/csswg-drafts#5489
@frivoal frivoal mentioned this issue Sep 3, 2020
Merged
@frivoal
Copy link
Collaborator

frivoal commented Sep 3, 2020

Made a couple of basic WPT tests backing this proposed resolution up: web-platform-tests/wpt#25373

They pass in Safari and Chrome, and would pass in Firefox if used the -moz- prefixed syntax instead of the unprefixed one, which Firefox does not yet support.

@fantasai
Copy link
Collaborator

fantasai commented Sep 9, 2020

The reason the spec defines it on the block container and not the inline is so that tab stops line up even when the font changes within the paragraph. It was very intentionally specced this way.

@Loirooriol
Copy link
Contributor Author

@fantasai What about saying that tab-size applies to inlines, but <number> values refer to the space character’s advance width of the block container?

This would still give authors more freedom to change the tab-size value in inlines, and would be closer to existing implementations, while still avoiding that pitfall when changing the font?

Though current implementations do break the alignment when the font changes. Testcase

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-text] 'tab-size' de facto applies to inline boxes, and agreed to the following:

  • RESOLVED: Change the spec to say tab size applies to inlines but when that happens the number values apply to advance width from block container
The full IRC log of that discussion <dael> Topic: [css-text] 'tab-size' de facto applies to inline boxes
<dael> github: https://github.com//issues/5489
<dael> florian: Currently applies to block but in impl applies to inline as well. Question is how? Stack or independant? From tests seems independent
<dael> florian: If you have a prserve-tab with a value of 7 you measure frmo edge and push to next independent of if other ones. All browsers seem to do this so would like to spec it
<astearns> ack fantasai
<Zakim> fantasai, you wanted to ask where to put this and to
<chris> sounds like we could standardize reality there
<chris> ok, fair enough
<dael> fantasai: Defined to apply to block so when font changes in paragraph tab stops line up. We knew at time impl didn't do that. I think it's not a question about line up with realitiy, there's a reason the spec is different. We can decide we can't do thing that is correct, but there's a reason why it was spec as different.
<dael> florian: I did not know that, thank you
<dael> oriol: I prop in issue that maybe could go in between current spec and current impl. Could say property applies to inlines and let authors change values in line boxes. If value spec is a number say it refers to advance size of space character of containing block.
<dael> oriol: In common cases keep good alignment but closer to current impl
<dael> fantasai: Works for me
<dael> astearns: And likely more web compat
<dael> florian: Works for me
<dael> astearns: Prop: Change the spec to say tab size applies to inlines but when that happens the number values apply to advance width from block container
<dael> astearns: That would change for all browsers?
<dael> oriol: Yeah, right now they use width of space of inline box.
<dael> florian: I will add a test for that
<dael> astearns: Objections?
<dael> RESOLVED: Change the spec to say tab size applies to inlines but when that happens the number values apply to advance width from block container
<dael> astearns: Thanks oriol for the solution

@mozilla-apprentice mozilla-apprentice mentioned this issue Sep 9, 2020
Closed
frivoal added a commit to web-platform-tests/wpt that referenced this issue Sep 10, 2020
@frivoal
[css-text] Tests for support of tab-size on inline boxes (#25373)
65ee37e 
See w3c/csswg-drafts#5489
@frivoal frivoal added Tested Memory aid - issue has WPT tests and removed Needs Review of Test Case(s) labels Sep 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@frivoal frivoal

Labels
Closed Accepted by CSSWG Resolution css-text-3 Current Work Tested Memory aid - issue has WPT tests Tracked in DoC
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@frivoal @fantasai @Loirooriol @css-meeting-bot