You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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().
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.
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.
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.
Activity
inoas commentedon Sep 11, 2016
I think it should allow any value, even negative ones. Basically anything text-indent does.
upsuper commentedon Sep 11, 2016
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-sizeis zero, then make tab invisible.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 commentedon Sep 12, 2016
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 commentedon Sep 12, 2016
Excluding zero is not simple. As
tab-sizeaccepts<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
0actually means intab-size? Should it be parsed as integer zero or0px? They may be effectively the same for layout, but can be obversable via the computed value fromgetComputedStyle().kojiishi commentedon Sep 12, 2016
@upsuper could you explain a bit more why
is ok whlie
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 commentedon Sep 12, 2016
See the second point of this email from @tabatkins.
kojiishi commentedon Sep 12, 2016
Oh thanks, I see, I would then prefer:
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 commentedon Sep 12, 2016
That suggestion is purely for
perspectivebecauseperspective(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:
This should at least give people an intuitive result if not that useful.
kojiishi commentedon Sep 12, 2016
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 commentedon Sep 14, 2016
After Rossen's request during today's confcall, I am perfectly fine with 0 being allowed for
tab-sizeand I even think it's a nice feature to have in browser-based editors.kojiishi commentedon Sep 15, 2016
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:
From a small test, it looks like Gecko/WebKit/Blink interpret
0as integer zero rather than0px. Trident/Edge doesn't seem to implement yet (caniuse).upsuper commentedon Sep 15, 2016
That probably makes sense, but I guess css-values may want to say something for this.
[css-text] Clarify handling of zero-width tabs per Xidorn's suggestion.