Fix broken links to "layout viewport"

[tidoust]

The "layout viewport" term is now defined in CSS Viewport: https://drafts.csswg.org/css-viewport/#layout-viewport

This update fixes the link, leveraging ReSpec's cross-spec referencing capabilities to avoid hardcoding a URL that can evolve over time.

(Also using the opportunity to refresh the nearby link to "px")

[dandclark]

Suggested change

	, "css-viewport"
	, "cssom-view"

When this is css-viewport, the link currently resolves to https://www.w3.org/TR/css-viewport-1/#layout-viewport which doesn't actually have that definition. I think the issue is that the draft https://drafts.csswg.org/css-viewport/#layout-viewport defines the term so respec sees the linkage, but the published version https://www.w3.org/TR/css-viewport-1/ doesn't yet have it.

One option is to wait to land this PR until another version of css-viewport is published, at which point this link should be there. Another is to apply the suggestion to change it to cssom-view, which makes it resolve to published version of the spec this already links to (https://www.w3.org/TR/cssom-view-1/#layout-viewport), so we're at least not hardcoding the link anymore.

Or if there's a way to get respect to link to the draft version of css-viewport that'd work too, but I'm not sure if that can be done without hardcoding it.

I'm not sure which is better, maybe the editors of those specs have a recommendation? Or I'd be fine to just land a version of this now pointing to cssom-view-1 since the result is we still keep linking to the same spec for now, with a note to consider switching to cssom-view later if the published version of that spec ends up with a definition that's more applicable to what EditContext is doing with it.

[tidoust]

Oh, I had forgotten that ReSpec always targets the published version and assumes that any term defined in the Editor's Draft also exists in the published version, which isn't always the case. That's tracked in speced/respec#3246.

I don't think there's a way to tweak ReSpec to do something else for now and I don't have a fantastic solution to offer in the meantime. On top of the alternatives you suggest, you may also hardcode the link to the new fragment, but that defeats the point of getting rid of hardcoding. Sigh.