Csswg-drafts: What defines the various fields in the property definition blocks?

[bzbarsky]

This is sort of crosscutting across all CSS specs that define properties.

Say I am looking at https://drafts.csswg.org/css-logical-props/#logical-dimension-properties and I see it says "Media: visual". What does that actually mean? What other values could there be? Where is this defined? I see no link in this draft to a definition of the "Media" thing. Of course it also doesn't explain what "Inherited" means (or where it's defined), what "Initial" means, what "Canonical order" means, etc, etc.

Ideally all of those labels would be links to the relevant specs that define them. At the very least, links to such specs should be _somewhere_ like the "Document conventions" section or something. It's possible they're in the "Normative References" section; certainly the one for "initial" is (it's https://www.w3.org/TR/css-cascade-3/). But I checked the obvious things like "Media Queries" and "Media Queries Level 4" and "CSS 2.1", and none of them really define what the "Media" thing means in a property description, nor what a "visual" value means.

@dbaron @tabatkins @fantasai

[astearns]

I assume they should link here https://www.w3.org/TR/CSS22/media.html

[bzbarsky]

Ah, yes, that has the definition. And it's in the normative references. Just not very easy to find that it's the relevant thing.

[fantasai]

Tagging onto the snapshot for now... agreed that it needs to be easier to figure out.

[tabatkins]

Yeah, either snapshot or a "CSS spec conventions" spec would be helpful here. Happy to make all of them linkify.

[dbaron]

I think we had a WG resolution at one point that they should all link somewhere, and all be links -- although different ones would be linking to different specs (e.g., syntax, cascade, values, transitions or whatever defines animation types, cssom, etc.). Or at least discussed it.

A bunch of these things were actually defined in section 1.4.2 of CSS Level 2. I'd once copied that text into old drafts of syntax, but I guess it got taken out.

[xfq]

Value / Initial / Applies to / Inherited / Percentages / Media / Computed value are defined in CSS 2.1 § 1.4.2.

Animation type is defined in Web Animations § 4.3.

[bzbarsky]

@xfq Great, but the point is that this information should be in the _spec_, not in a random github issue.

[birtles]

I plan to make Animation type link to Web Animations once we have moved the definitions of those animation types to CSS Values and Units (so we can link to the values too).

[xfq]

@bzbarsky Do you mean something like this: https://xfq.github.io/specs/css-conventions/

[bzbarsky]

@xfq that would be one option, if all those bits in the various specs then linked to it. But they could also directly link to the definitions of the relevant terms. I don't really care as long as the information is findable by following the links.

[xfq]

This issue was partly resolved by tabatkins/bikeshed#617, although "Applies to" (except the "all elements" case), "Media", and "Canonical order" are still not autolinked.

[svgeesus]

@tabatkins suggestions for autolinking media?

[xfq]

@svgeesus I think Media can link to https://www.w3.org/TR/CSS2/media.html#media-groups

[xfq]

Media was removed per https://logs.csswg.org/irc.w3.org/css/2018-07-03/#e1045220

[frivoal]

With the recent edit @fantasai made to clean up some of the lines in propdef tables, I think we're almost there.
As far as I can tell, the only missing bits now are:

• Canonical order: This should probably link to something in CSSOM
• Applies to: his should probably link to something in css-cascade (maybe under https://drafts.csswg.org/css-cascade/#computed, since it already talks about it a bit)

So, I don't think this should be tied to the snapshot anymore. If we all agree, I'd like to open the 2 points above as separate issues, and retire this one.

[svgeesus]

So, I don't think this should be tied to the snapshot anymore. If we all agree, I'd like to open the 2 points above as separate issues, and retire this one.

I think that makes sense. It means that Snapshot 2018 can (like previous snapshots) be just a Note, not a WD that gets republished as a Note a year later ...

[frivoal]

It means that Snapshot 2018 can (like previous snapshots) be just a Note

Yes.

While we're on publication, I'm still not 100% clear why we publish each year's snapshot as a new document with a new shortname, rather than republishing in place and just using dated URLs / Previous Version links to get to the previous ones.

[svgeesus]

While we're on publication, I'm still not 100% clear why we publish each year's snapshot as a new document with a new shortname, rather than republishing in place and just using dated URLs / Previous Version links to get to the previous ones.

I don't either, except that it generates a small amount of interest and forward momentum.

So are we there yet can snapshot-2018 be published now?

[frivoal]

So are we there yet can snapshot-2018 be published now?

From my point of view, yes. But I agenda+ed to make sure the group is fine with resolving this issue elsewhere than in the snapshot.

While we're on publication, I'm still not 100% clear why we publish each year's snapshot as a new document with a new shortname, rather than republishing in place and just using dated URLs / Previous Version links to get to the previous ones.

I don't either, except that it generates a small amount of interest and forward momentum.

Can bikeshed echidna update notes? If it can't right now, can it be made to do so (cc: @tabatkins). If not, publication's got to be manual anywway, so I don't care strongly (although I do think it's a little odd). If it can, I would much rather switch to updating using the same shortname, so that we can publish with much less of a fuss than now.

[tabatkins]

Bikeshed can do whatever Echidna is allowed to do; I don't know if it can do Notes right now.

[xfq]

Echidna can handle WG Note updates. I published a Motion Sensors Explainer update with Echidna before.

[frivoal]

Alright. In that case, I think we should switch the snaptshots to all use the same shortname instead of having a new shortname every year. That seems easier for everybody.

[svgeesus]

Checked with PLH, all using same shortname is fine. So given that, should the shortname be CSS or should it be snapshot (and have /TR/CSS redirect to that as it currently does).

This also fixes the issue that each snapshot should be obsoleted, and the shortname does not let you find out when a new snapshot is released. There are a bunch of old dated snapshots with no info that they are not current.

[tabatkins]

I like "CSS"!

[plinss]

Personally I prefer the dated shortnames, we do have the /TR/CSS alias in place so people are free to use an undated URL as they see fit.

If nothing else, it shames us into keeping the snapshot up to date...

[frivoal]

If nothing else, it shames us into keeping the snapshot up to date...

Actually, I think it's the other way around. The friction of making a new note being higher than updating an old one, we hold off publishing over trivial inconsequential stuff cause there's always something more fun to do than worry about publication stuff.

— Should we update the snapshot?
— Resolved: Update the snapshot.
— bikeshed echidna

Seems much more likely to keep us up to date.

[plinss]

If making a new note has so much friction, then the process needs to be fixed. If only we knew someone on the AB...

[frivoal]

If making a new note has so much friction, then the process needs to be fixed. If only we knew someone on the AB...

The main problem is not one of process, but of tooling. Making a new note is a manual process, updating one is automated (by echidna).

And the problem isn't "so much friction". It's some vs none.

Also, I think there's some psychological friction as well. If you're updating a document, it feels OK to publish as soon as it's better than the previous one. If you're making a new one, it feels like it need not just to be better, but good on its own merits, which easily leads to postponing and procrastinating.

Finally, regardless of process or tooling, it just is the same document, updated. I simply don't get why we have to invent a new way of doing dated drafts by changing the shortname (and then having to wonder what to do about marking the old drafts superseded), while the regular way of publishing on TR handles that just fine.

[tabatkins]

Agree on all counts. Insofar as previous snapshots are worthwhile at all, the dated publication suffices just fine for that. I'd much rather maintain a single up-to-date document rather than a succession of them.