[css-contain-1] in layout containment section, `display:contents`, `none`, and `table-cell` values should link to these value definitions

[dholbert]

In section 3.2. Layout Containment...
https://drafts.csswg.org/css-contain/#containment-layout
...the spec mentions three specific values for the display property, as follows:

If the element does not generate a principal box (as is the case with display: contents or display: none), or if the element is an internal table element other than display: table-cell, or...

Right now, the display: contents string is a link and it points at https://drafts.csswg.org/css-display-3/#propdef-display , and the other values aren't linkified at all.

I'd expect that:
(1) all three should be linkfiied
(2) they should point to their actual specific value definition, not to the property definition -- i.e. they should have these three targets
https://drafts.csswg.org/css-display-3/#valdef-display-contents
https://drafts.csswg.org/css-display-3/#valdef-display-none
https://drafts.csswg.org/css-display-3/#valdef-display-table-cell

[tabatkins]

Bikeshed handles ''prop: value'' by autolinking to the property. CSSWG also has the "suppress repeated links" feature turned on, so multiple links to the same thing in a single paragraph will be suppressed and only the first will remain, which is why the latter two aren't linkified. (In other words, they're linked in source, but suppressed in output.)

This is the generic way we handle this sort of prop:value inlining; I can change it to link as you desire, but it would be much more manual, and not consistent with how those sorts of snippets are linked anywhere else across our specs. Is it important for the understanding of this section that it link specifically to those values?

[frivoal]

Bikeshed handles ''prop: value'' by autolinking to the property.

I guess that's the part I would change, and make bikeshed link "prop: value" to the value instead. If you just meant the property, there's not need to specifiy the value, but when you mean the value, showing the property can be useful for context, but you're still talking about a particular value.

If that was changed, the rest would just fall out, since we'd no longer have 3 links going to the same place.

[dholbert]

Bikeshed handles ''prop: value'' by autolinking to the property.

Thanks for clarifying - I hadn't realized that this was the way it was supposed to work. This seems reasonable when the values are all defined right in the same section as the property -- but in this case, the value definitions are quite spread out, so it's less helpful. In particular, when I visit the current display:none link-target (https://drafts.csswg.org/css-display-3/#propdef-display ) in a maximized browser, I have to hit my PageDown key 6 times in order to arrive at the section where the none value is actually defined.

Is it important for the understanding of this section that it link specifically to those values?

Probably not; I mostly filed because it felt like a mis-link, since the value definition was so far away from where the link takes you. But if this is convention & not really a mistake, then I suppose this is fine as-is.

[tabatkins]

I guess that's the part I would change, and make bikeshed link "prop: value" to the value instead. If you just meant the property, there's not need to specifiy the value, but when you mean the value, showing the property can be useful for context, but you're still talking about a particular value.

Can't in general; the ''prop: val'' syntax is generally used for arbitrary CSS examples, and there's no guarantee of a reasonable mapping between the value and a value definition (that is, a machine-parsable mapping that doesn't involve Bikeshed needing a deep understanding of CSS syntax and grammars). Theoretically I could map simple examples, like display: none, but it would be weird that width: 10px would still just link to 'width', rather than its <length> value definition.

In particular, when I visit the current display:none link-target (drafts.csswg.org/css-display-3/#propdef-display ) in a maximized browser, I have to hit my PageDown key 6 times in order to arrive at the section where the none value is actually defined.

Yeah, that kinda sucks. I'll see about making the values in the propdef link to their definition.

[ewilligers]

For this particular example, I uploaded a PR that changes
''display: contents'' or ''display: none'' to
'display' values of ''display/contents'' or ''display/none''
This is similar to the approach taken in a number of other CSS specs.

It results in links to both the property and the values.

[tabatkins]

That works too, thanks. ^_^