Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[meta] Creating an author-focused entry point summarizing the state of CSS #4752

Open
AmeliaBR opened this issue Feb 6, 2020 · 4 comments
Open
Labels

Comments

@AmeliaBR
Copy link
Contributor

@AmeliaBR AmeliaBR commented Feb 6, 2020

As requested by folks on the call, I'm starting a new issue to explore the tangent I started in #4715 (which is about publishing a new Snapshot) — can we make such a thing that is more useful for authors?

Specific aspects of a summary publication that have been brought up:

  • a single-source quick guide to CSS properties (etc.) that's more than an index where you need to click through for any details

  • information about both spec stability and implementation status, again as a quick guide for authors

  • obvious milestones / names to refer to new CSS & get people excited about the features that are now available

This doesn't need to happen in the Snapshot note. It doesn't even need to happen in a traditional W3C Technical Report format. When I mentioned the snapshots on CSS-Tricks as the closest thing the working group has to an overarching “CSS4”, Chris Coyier's response was:

If it were me, I’d hire a content strategist and a designer, and get them going on a microsite or landing page that delivers with crystal clarity what “CSS2019” is. I could get behind that. The snapshot landing page as-is is too dry.

Maybe it would be better to start from something like the working group website's “current work” page, which is also a great resource/overview that isn't well known. Or work with MDN folks to build something on their platform.

@frivoal

This comment has been minimized.

Copy link
Collaborator

@frivoal frivoal commented Feb 6, 2020

I am skeptical of doing this. I guess it depends on how we'd be doing it, as I do see some value in the marketing aspect of having an author focused definition of what CSS4 or CSS2020 is, but to be useful to authors, it would have to track the state of implementations, and caniuse.com or MDN are much better at doing this than we are.

@rachelandrew

This comment has been minimized.

Copy link
Contributor

@rachelandrew rachelandrew commented Feb 6, 2020

@fantasai and I are currently working on a new CSS Working Group site, one of the aims of that is to give authors information in terms of where to go to find out this kind of stuff.

I am not convinced we should be doing more than that, unless we have a very good way to maintain the data automatically it is going to be a lot of overhead to keep up to date, and we all already have plenty to do. I think we would be better placed in making sure that the data on MDN is up to date and referring folk over to that, rather than creating another place for people to keep track of.

@SelenIT

This comment has been minimized.

Copy link
Collaborator

@SelenIT SelenIT commented Feb 7, 2020

To me, making the CSS snapshot more useful/valuable for authors seems a great idea, for the following reasons:

  • The latest snapshot has the short and memorable URL (w3.org/TR/CSS), suggesting that this must be the latest "CSS in general" specification (similarly with w3.org/TR/HTML being the latest HTML spec, currently redirecting to Living Standard, w3.org/TR/SVG being the latest SVG spec, currently SVG2, and so on);
  • Many beginners seem to have problems with the concept of independently progressing spec modules;
  • People often get into confusion trying to find the "single source of truth" for some particular aspect of CSS (e.g., which one of two same-status modules with exactly the same publication date – css-cascade-3 and css-cascade-4 – should be considered "the true one");
  • People often ask for some clear way to tell the modern stuff apart from both "too old" and "too new" (e.g. when deciding where to send bug reports – to browser vendors or to spec editors);
  • The spec statuses alone are not always informative enough. E.g., having the spec that already was in CR and has been implemented in all browsers with no prefixes/flags for years (like CSS-multicol-1) in the same WD status as some early stage proposal often lead people to the false conclusion that they both are equally "new and experimental";
  • Calling everything after CSS2 "just CSS", as some suggest, doesn't address these issues and seems to broad to be useful;
  • The concept of the yearly updated snapshot of the language standard incorporating all the features considered "ready" to date (where "ready" doesn't necessarily mean "is supported by all browsers"!) is already familiar to most web authors from the EcmaScript standard (ES2015, ES2016, and so on).

At first glance, the CSS Snapshot (even "as is") seems to address these issues well. It provides clear criteria for comparing the "readiness" of same-status specs (if the spec is in the Official Definition of CSS, it must be ready), it explicitly excludes outdated parts of the spec (CSS2.1) that are replaced with newer modules, and it explains the reason why some separate features can be considered "ready enough" despite the specs they belong to are not ready yet (the "Safe to Release pre-CR Exceptions" section).

Tracking the implementation status doesn't seem a hard problem to me. Adding a dropdown caniuse widget (like here) would be enough, IMHO. Also, I believe that it could be useful to indicate in the "Notes" column on the "Current work" page which Snapshot was that spec added to (or, at least, to mark there the specs that are part of the latest snapshot) – it should make it much easier to grasp the current state of the CSS evolution.

@AmeliaBR

This comment has been minimized.

Copy link
Contributor Author

@AmeliaBR AmeliaBR commented Feb 12, 2020

Cross-referencing to #4770, which is specifically about the marketing benefits of the “CSS4” name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.