How is fixing a bug in standards support an "enhancement"?

This bug is 7 YEARS OLD.

How hard can it be to make "tab-size" an alias for "-moz-tab-size"?

It's blocked on bug 1308113, since we're not supposed to ship unprefixed if we don't match the spec. And the next step there is bug 1308113 comment 10.

I know that. But nobody's even assigned to that bug. It's been around for 8 years, and it's been idle for at least 2 years, with the last real activity being ME suggesting that it should be taken off of the back burner it's obviously on!

This bug will never get fixed at this rate.

Also, I was trying to make the point that this is NOT an "enhancement". This is a failure to support the spec. It should be marked as a "defect", not an "enhancement".

See my blog post on the age of bugs for why arguing on the basis that the bug has been open a long time isn't going to help. (Arguing on the basis of user or developer need, or the basis of what other browsers support, is much more relevant.)

(Arguing on the basis of user or developer need, or the basis of what other browsers support, is much more relevant.)

I did that two years ago, if you actually read the history on this bug. I mentioned that this is a problem for a site I use that displays source code that includes tabs. Explaining why, in real-world terms, this needs fixing, is clearly ineffectual in motivating anyone.

As for your blog post, I've read it before. I consider it a very facile argument that relies on a strawman to make its point. Specifically in this case, I'm not asking you to support MS Word documents. I'm looking for support for part of the current CSS spec, on the display of a fundamental Unicode/ASCII character, not some proprietary software, the publisher of which you know the average reader looks at with a sneer. You wrote up that argument 12 years ago and apparently you've been relying on it ever since to deflect reasonable criticisms. Well, I don't accept your argument as valid.

We're talking about handling simple tab characters, which have existed practically since the dawn of computers. This isn't new tech, it's not a new, complex layer on the web, it's just a single style setting that dictates the width of a single Unicode/ASCII character.

Fixing this bug would be as simple as putting in an alias for "tab-size" → "-moz-tab-size". However, apparently "policy" (whose? yours?) says that you can't do that, because "-moz-tab-size" doesn't work right in certain cases and it can't be "tab-size" until it does. But nobody's working on making "-moz-tab-size" work in all cases, because this bug is effectively shielding that bug from ever being in the spotlight by disguising it as a vendor-specific style.

A world in which we have a mostly-spec-supporting "tab-size" would be a lot better than a world in which we have no "tab-size" for another 8+ years while you continue to say, "it's not about how long the bug has been around!"

Just because it's in a spec doesn't mean it's important. There are lots of things that are in specs that we don't implement -- and there's more in specs than we can implement.

That said, the policy you're arguing against is in a spec.

Hi felice, setting aside arguments about standards and priorities for a moment, can you not use -moz-tab-size alongside tab-size in your stylesheet, if a simple alias will do the job in your case? If that's impractical as a work-around in the meantime, it would be good to know.

@David

Just because it's in a spec doesn't mean it's important. There are lots of things that are in specs that we don't implement.

"A" spec. Just some random spec. It's not like it's an important spec. Not, like, one of the spec that govern the entire web. Nah. Not necessarily important. How silly of me to assume it would be.

/s

The whole point of a web browser is that it conforms to a spec so that authors can create web content that users can view consistently. How can you have any pride in your work and still argue that a failure to support the spec doesn't warrant attention even after it's been failing for eight years?

It's not like I don't know who you are. Unless I'm mistaken or out-of-date (admittedly not unusual), you're the guy when it comes to making sure Firefox follows the CSS spec. Why devote this much energy to quashing someone's request that you, or someone you direct, do exactly that?

You're very clearly resisting the idea of getting this and the other associated bug fixed. I won't try to read your mind about why you would do that, but it's pretty clear that you don't want to fix it. So, given your attitude and your role in the project, it presently seems to me that this bug will never be fixed. You might as well mark it "Will not fix, David doesn't think supporting tab-size is important".

@Thomas
We're not clueless about vendor prefix versions. I've said as much. Of course we can work around it.

And hey, we all worked around IE for, what, 20 years? Wasn't that fun?

I'm not here in search of a workaround. I'm trying to find/trigger/elicit an actual solution. If you offered that idea in earnest, then I appreciate the thought, but that's not what I'm here for.

Sigh. I didn't realize the markup here would join my text to the quote immediately above it. My own text above starts inside the quote at "A".

(In reply to David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-8 from comment #19)

That said, the policy you're arguing against is in a spec.

I just noticed something. Immediately below the policy you're saying disallows removing the prefix in this case is an exception to the policy that seems to apply to cases similar to the one we're discussing:

(from: https://www.w3.org/TR/CSS/#CR-exceptions)

§ 4. Safe to Release pre-CR Exceptions

The following features have been explicitly and proactively cleared by the CSS Working Group for broad release prior to the spec reaching Candidate Recommendation:

• The flow-relative equivalents of the sizing properties ('width', 'height', etc.), the border properties, the margin and padding properties. See explanation and specification.

The explanation—which you wrote—lists inline-size as one of the excepted properties, and that's actually a rather similar case in my opinion. In fact, I would say that tab-size is conceptually a subset of inline-size, just applied to one specific character element.

At any rate, the spirit of the exception certainly indicates to me that W3C is not excessively concerned with minor flaws in whitespace/padding, on the assumption that browser developers will endeavor to fix those flaws in due time and users will benefit from having otherwise-workable properties in the meantime.

In my limited survey of the web as a whole (yes, I say that with some humor), I find that tab characters are pretty much used only to indent either source code or paragraphs. Other uses, such as tab-separated tables, are usually not intended for formatting, only delimiting fields.

That being said, neither of those primary use cases is currently flawed under -moz-tab-size, as the lack of preceding characters in an indentation means the width calculation is straightforward regardless of font. Furthermore, in cases where source code contains intra-line tab characters, pretty much all will employ fixed-width fonts, because otherwise tabs would not provide reliable spacing and formatting would be unpredictable.

Thus, removing the prefix would allow virtually all practical uses of tabs on the web to work properly with the existing implementation, while the more esoteric fail cases with proportional and unusual international characters/fonts (as I recall from the other bug) are also addressed and fixed over however many months or years.

So, again, I call for an alias to be created for tab-size → -moz-tab-size. I think this is entirely reasonable and not at odds with the policy you've linked.

I was also surprised this is not implemented. FF is the only browser which does not support this CSS rule AFAIK.

If that's impractical as a work-around in the meantime, it would be good to know.

Well, it is possible to work around it. However, I use responsive tab width, based on browser width, so it basically makes the CSS cumbersome. I worked around it using var but it's still kind of messy.

@media (min-width: 40em) {
	html {
		--tab-size: 4;
	}
}

@media (min-width: 80em) {
	html {
		--tab-size: 4;
	}
}

pre {
	/* -moz-tab-size is still required by Firefox */
	--tab-size: 2;
	tab-size: var(--tab-size);
	-moz-tab-size: var(--tab-size);
}

Now I have to replicate this to all the sites where I do this kind of responsive design. Sure, it's possible to do it. Am I happy that I have to make a FF specific fix? Not so much, it's unexpected and a time sink.

or the basis of what other browsers support, is much more relevant.

Every other (modern) browser supports tab-size.

Actually, it looks like Firefox's implementation of tab-size is still failing a couple of reftests (though note the reftests themselves have to be modified to account for the prefix issue):

https://github.com/web-platform-tests/wpt/blob/master/css/css-text/tab-size/tab-size-integer-004.html
https://github.com/web-platform-tests/wpt/blob/master/css/css-text/tab-size/tab-size-spacing-001.html

It looks like it has something to do with making sure it's calculated based on the block container or something? That first test (that was added about two months ago) is weird because if you replace the four spaces with four zeroes sans letter-spacing, you see they're in a smaller font than the one the tab is in, and if you put four reference zeroes in the same font as the tab without letter spacing, the two do align.

I'm not sure what the goal of the spec is here. It seems like they're implying tab-size should ignore font, but that makes no sense because both spaces and zeroes will be different sizes in different fonts. Is this what bug 1308113 is trying to address, or is this a new issue caused by a recent spec decision? Sorry if I'm pointing out something very obvious here, I'm just curious because the whole situation seems to be dancing around a very bizarre technicality in the spec.

felice, I flag your comment to the bugzilla admin as your comments aren't following our code of conduit: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

I am also restricting access to this bug to people who have editbugs permissions.

I'm proposing to "steal" this bug from Mats, as I have a patch for the behavior issue in bug 1308113 that has been blocking progress here; with that addressed, I think we can resolve this as well.

This results in lots of new WPT test passes.

There were also a couple of WPT tests that turned out to be broken;
tab-size-inline-001 and -002 had errors in their reference files such
that they'd never pass anywhere. So those are fixed here.

Depends on D117331

https://hg.mozilla.org/mozilla-central/rev/c32a18de589c

PRs pending to add to release notes and update BCD.