[css-text] can tab-size be zero?

[kojiishi]

The tab-size property defines:

Negative values are not allowed.

Is zero intentionally allowed?

[inoas]

I think it should allow any value, even negative ones. Basically anything text-indent does.

[upsuper]

Is zero intentionally allowed?

I guess not, otherwise Phase II of the White Space Processing Rule should handle that explicitly because there is no multiple of zero other than zero.

But I guess allowing zero is probably fine. It can explicitly state that, if tab-size is zero, then make tab invisible.

I think it should allow any value, even negative ones. Basically anything text-indent does.

You may need to specify what would happen in that case explicitly. The current rule would make negative ones just behave like their absolute value I believe.

[frivoal]

I think we should exclude 0 and negative values. I mean, sure, if we allow them people are bound to eventually find creative ways to use them and then we'll be stuck in supporting them, regardless of how little sense it makes. But this is not supported by use cases, so I think we should keep it simple.

[upsuper]

Excluding zero is not simple. As tab-size accepts <length>, dropping zero would make valid values an open range, which, according to Tab, violates CSS's rule of limited ranges.

Oh, by the way, what 0 actually means in tab-size? Should it be parsed as integer zero or 0px? They may be effectively the same for layout, but can be obversable via the computed value from getComputedStyle().

[kojiishi]

@upsuper could you explain a bit more why

Negative values are not allowed.

is ok whlie

Only positive values are allowed.

is not?

I'm not very motivated to spend time to discuss how zero should work when there's no author benefits, and to make it to work, but you're right that it's not well-defined today and if we were to allow, we need to define it.

[upsuper]

See the second point of this email from @tabatkins.

[kojiishi]

Oh thanks, I see, I would then prefer:

The spec should instead define a minimum perspective and clamp values to that.

this route than to be creative for how zero should work here.

I hope it's not too controversial for the minimum 1 for integer. Not sure about length but I'm fine with any values such as 1px. WDYT?

[upsuper]

That suggestion is purely for perspective because perspective(0) would lead to infinite matrix parameter. It is not the case here.

It seems to me using the following text to replace step 2 of 4.1.3. Phase II: Trimming and Positioning should work:

If the tab size is zero, tabs are not rendered, otherwise, each tab is rendered as a horizontal shift...

This should at least give people an intuitive result if not that useful.

[kojiishi]

I'm ok with it, but I'm afraid special casing for non-useful staff purely adds burden to us, to ensure selection works good, editing works good, etc.

While I agree that it's one possible solution, I have mild preference to define the minimum.

[therealglazou]

After Rossen's request during today's confcall, I am perfectly fine with 0 being allowed for tab-size and I even think it's a nice feature to have in browser-based editors.

[kojiishi]

Oh I wasn't aware this was on agenda, sorry to miss the call.

I'm fine too if this was defined and all impls agree. Blink does implement it as zero-width character today but didn't find the spec defines it and we have no tests for it.

@upsuper:

Oh, by the way, what 0 actually means in tab-size? Should it be parsed as integer zero or 0px?

From a small test, it looks like Gecko/WebKit/Blink interpret 0 as integer zero rather than 0px. Trident/Edge doesn't seem to implement yet (caniuse).

[upsuper]

That probably makes sense, but I guess css-values may want to say something for this.