Content suggestion: Remove <length-percentage> and similar pages

[foolip]

What is the new suggestion?

Remove https://developer.mozilla.org/en-US/docs/Web/CSS/length-percentage and similar pages.

Why is it important or useful?

mdn/browser-compat-data#14971 is a PR to remove it in BCD, because support data is just the union of two other features. If we remove it from BCD, either the MDN page should be removed, or it includes the two compat tables for <length> and <percentage>.

Other supporting information

My weak opinion is that exposing these spec abstractions to readers is a bit weird, but that argument also applies to <length> and <percentage>. Perhaps they're useful to avoid spelling out all the allowed values for each property.

[wbamberg]

that argument also applies to and . Perhaps they're useful to avoid spelling out all the allowed values for each property.

Yes, <length> has value that <length-percentage> doesn't. All <length-percentage> can say really is that it "represents a value that can be either a <length> or a <percentage>" and we can just as easily, and probably more usefully, say that in the places we want to refer to it. But <length> can and does say a lot about allowed units and their meanings, and we really don't want to duplicate all that.

So as a pragmatic matter I think deleting <length-percentage> would be OK and deleting <length> would not.

More generally, BCD for data types is a bit weird. You can't do anything with a data type on its own, so what does "support" mean? Take for instance <flex>. We say it's supported since Chrome 29. The page refers to its use in grid-template-rows. But you can't use <flex> there in Chrome 29 of course, because you can't use grid-template-rows in Chrome 29. So what does it mean, to a developer, to say that a CSS data type is supported?

So sometimes I feel like CSS data types should not have BCD at all.

[foolip]

that argument also applies to and . Perhaps they're useful to avoid spelling out all the allowed values for each property.

Yes, <length> has value that <length-percentage> doesn't. All <length-percentage> can say really is that it "represents a value that can be either a or a " and we can just as easily, and probably more usefully, say that in the places we want to refer to it. But <length> can and does say a lot about allowed units and their meanings, and we really don't want to duplicate all that.

So as a pragmatic matter I think deleting <length-percentage> would be OK and deleting <length> would not.

That sounds good to me.

More generally, BCD for data types is a bit weird. You can't do anything with a data type on its own, so what does "support" mean? Take for instance <flex>. We say it's supported since Chrome 29. The page refers to its use in grid-template-rows. But you can't use <flex> there in Chrome 29 of course, because you can't use grid-template-rows in Chrome 29. So what does it mean, to a developer, to say that a CSS data type is supported?

So sometimes I feel like CSS data types should not have BCD at all.

Sometimes, perhaps. But do you agree that <length> is important to keep since it's the place that holds support for the ic unit? Is the distinction that <length> has subfeatures, but <flex> does not?

[wbamberg]

More generally, BCD for data types is a bit weird. You can't do anything with a data type on its own, so what does "support" mean? Take for instance <flex>. We say it's supported since Chrome 29. The page refers to its use in grid-template-rows. But you can't use <flex> there in Chrome 29 of course, because you can't use grid-template-rows in Chrome 29. So what does it mean, to a developer, to say that a CSS data type is supported?
So sometimes I feel like CSS data types should not have BCD at all.

Sometimes, perhaps. But do you agree that <length> is important to keep since it's the place that holds support for the ic unit? Is the distinction that <length> has subfeatures, but <flex> does not?

Well... this is outside the scope of your original issue, which I agree with. And I don't think we will resolve this wider issue now, and we have bigger things to deal with.

But it's not really about subfeatures. When we provide BCD we are saying to a developer "you can use this thing". But you can't use a data type on its own, it's just a value for properties, which are the things you use.

Consider https://developer.mozilla.org/en-US/docs/Web/CSS/basic-shape#browser_compatibility, the compat for <basic-shape>. It has subfeatures, and lists some browser versions. It's a data type that can be used, the page says, as a value for the clip-path, shape-outside, and offset-path properties. But all these properties have different BCD stories - and have to document themselves when particular values of <basic-shape> can be used. So how could the BCD for <basic-shape> possibly tell developers anything useful about when they can use the value?

It's rather like the way we do/do not provide BCD for dictionaries.

I don't have a good solution to this really, and there are types like <length> which are so widely used that it would be very awkward to duplicate the story for every property that uses it. So perhaps what we do now is the best pragmatic option. But I just had to mention it.

[foolip]

I agree that the <bla> entries don't mean anything by themselves and it's a bug that we have to fill in data for it in BCD. I guess that's out of scope of this issue though, the <length> and <percentage> entries will remain.

At this point, are PRs to remove BCD tables from pages like https://developer.mozilla.org/en-US/docs/Web/CSS/length-percentage welcome?

[teoli2003]

We discussed this today and we think there are a lot of open points to discuss about it:

• How does this affect links from css formal sections-
• Should we keep these content pages without bcd info on them?
• @estelle. More than the pages, how do we document types nowadays: not all are documented in the same way; what are the categories?

Let's convert this into a discussion.

[teoli2003]

@ruth: I converted this from an issue, but the discussion is now under mdn/content/discussions rather than the org-wise place. This may explain why new discussions appear below mdn/content. Maybe some configuration options should be updated to prevent this?

[estelle]

I am creating data types as I update CSS module landing pages. Some data types get their own page. Others, notably data types that are a finite number of keywords used only by a single property ( or a longhand property and an associated shorthand property), have the data type defined in the long-hand property page.

For example, CSS Counter Styles module introduces three data types (

). These are defined in the @counter-style at-rule, the at-rules symbols descriptor, and the symbols() function, respectively. The CSS generated content module includes <image>, which has it's own page,. That module also introduces a data type called <content-replacement>. This data type is just an <image>. I included the new term so if someone reads the spec then searches for that data type, they'll find the term. In this case, neither a separate page nor even a definition was needed. rather, the term exists with the content "(see )".

Basically, it's important that anything defined in the specification is included on MDN, so users know "this exists and it means that" or "this exists, but is not implemented" etc.