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

Convert CSS2 to Bikeshed #5196

Merged
merged 38 commits into from Jul 1, 2020
Merged

Convert CSS2 to Bikeshed #5196

merged 38 commits into from Jul 1, 2020

Conversation

gsnedders
Copy link
Contributor

Fixes #2220.

While in total this is a big change, each of these commits individually is comparatively small and reviewable. The only exception is 82079cb, but the main change there is "just" concatenating all the *.src files, so should be easily reproducible.

This primarily marks up many (but not all) property value definitions as
being property values for their respective properties. The choice is
mostly those keywords that exist in other specs; this should be further
completed in due course.
This is in preparation for conversion to Bikeshed; both because the
forthcoming conversion relies on parse/serialize cycles (using html5lib,
which doesn't support preserving case) and because Bikeshed itself
relies on tags when they appear in BSMD being lowercase.
This is done for the same reason as the previous commit (both Bikeshed
conversion tooling does this, so this limits the diff in that single
commit making blame more workable, and because Bikeshed does not handle
tags split across multiple lines). Note that this doesn't deal with new
lines within attributes yet.
This is, similar to parent commits, prior to the Bikeshed conversion
to make more easily ignored from blame (plus also is easier to
review).

Most of this just gets rid of ambiguous ampersands and makes quoting
of elements consistent (the choice of quotes is done to minimize the
size of this diff).
Plus get rid of all the old source files (to git can correctly notice
the lines have moved) as well as the old build system and the committed
output.
This doesn't actually produce a particularly large diff, contrary to
what one might expect. This primarily just gets rid of head elements.

The algorithm used here is pretty simple:

 1. Start with cover.src, then for each chapter/appendix:
 2. Append the contents of the body element to the existing body
 3. If the style element in the head has content not yet seen, add it to
     the existing head.
These BSMD blocks were generated with a modified version of the old
propdef generator, but should be trivially correct.
The q0 anchors date back to the original 2011 publication of CSS 2.1 and
are all applied to the top-level headings within each page. As such,
they're essentially unused (because everywhere just links to the top of
the page). Additionally, the q0 anchors were removed when CSS 2.1 was
edited in place in 2016 (see
w3c#2551).
The old build system always took the first anchor within the header as
the header's anchor, but Bikeshed (very reasonably) expects the anchor
to be on the header itself. Note in many cases we also provide "legacy"
anchors as spans within the header; these are unchanged.
In plenty of places we have strong directly nested within dfn or dfn
directly nested within strong; in both cases this is unnecessary as the
goal here is purely presentational and the current TR stylesheet boldens
all dfns anyawy.
The old build system generated its index through specific markup rather
than using all dfns. In reality, most of the things marked up for the
index are actually generally useful dfns (this is unsurprising, given
the index contains things people might want to lookup!).
This is needed as moving the IDs got rid fo a number of spans, therefore
making new strong elements now adjacent.
There's no need for this.
Amusingly, some of the index instances are never actually defined.
The former produces quotes around the element in the BS output; the
latter enables CSS syntax highlighting. The latter seems like the
better behaviour.
This just adds lang-xml to pre elements with no lang-* class whose
contents can be parsed as XML, as it is unlikely for arbitrary content
to parse as XML (potentially some of this is intended to be HTML, but
highlighting it as if it is XML is unlikely to be harmful).
This, similar to the previous commit, adds lang-css when there is no
lang-* class already and the content parses as CSS without any parse
errors. As CSS is more permissive, the automated script added slightly
too much here and a little was manually reverted.
This happens to only be in img[alt]
The old built system added an ID to all imgs, so we should to.
The old CSS2 build system used [[FOO]] for a normative reference and
[[-FOO]] for a non-normative one. BSMD uses [[!FOO]] for a normative
reference and [[FOO] for a non-normative one.
This drops IDs for: index xrefs (x[n]), bits of generated content
(annoying-warning, minitoc, W3C-doctype), refs (ref-*), and the index
sections (index-[A]). Only the first might be referenced at all, and
unfortunately they are not unique across all pages unlike all other
anchors.
@gsnedders gsnedders added the CSS2 label Jun 11, 2020
@plinss
Copy link
Member

plinss commented Jun 11, 2020

I'm a bit concerned about concatenating all the files.

I accept that Bikeshed doesn't support multipage specs yet, but I expect it to eventually. And CSS2 is large enough that there's benefit to having both single page and multipage versions. It depends on how Bikeshed will handle multipage specs, whether it will be able to split a single source file to produce a multipage version or it will concatenate multiple sources itself to produce the single page version. And it's likely too soon to know which of those approaches it may require.

There's also author and reviewer pain in having a single large source file rather than a number of more manageable files.

I'm wondering if, in the meanwhile, it would be better to preserve the individual source files and have a singe additional file that's nothing but a set of includes.

cc @tabatkins for any insights into how Bikeshed may wind up supporting multipage specs.

@gsnedders
Copy link
Contributor Author

@plinss by way of comparison, the ten largest Overview.bs:

156K    css-color-4/Overview.bs
156K    selectors-4/Overview.bs
172K    css-values-4/Overview.bs
176K    css-tables-3/Overview.bs
228K    css-flexbox-1/Overview.bs
240K    css-grid-1/Overview.bs
256K    css-text-3/Overview.bs
260K    web-animations-1/Overview.bs
264K    css-fonts-4/Overview.bs
664K    css2/Overview.bs

@plinss
Copy link
Member

plinss commented Jun 11, 2020

@gsnedders good data, but if anything that tells me there are more specs that we should consider having multipage versions of when Bikeshed can handle it (and maybe multipage support should get bumped in priority).

To be clear, I'm perfectly fine with re-releasing CSS2 as only a single page spec until Bikeshed gets multipage support. I highly value the work you're doing here, and think the value in the Bikeshed conversion outweighs the pain of a large single page spec for those that read it (though it may violate the priority of constituencies in some regards, the improved cross-linking and consistent presentation offsets that).

I just want to be sure that when Bikeshed does support multipage, we're not in a situation where converting CSS2 back into a multipage spec is too much of a burden. If Bikeshed will be able to support auto-splitting a single input file, then this is mostly a non-issue (except for potential editor/reviewer pain of dealing with a large source file). Keeping the source files split just feels like keeping our options open. I accept that it could also cause editor pain if updates often need to span files, but I don't expect it to get updated much after the conversion.

All in all, please take this for what it is, a concern, not an objection.

@tabatkins
Copy link
Member

My intent is indeed that multipage output will be supported from a single source file; having each "page" be a separate file that you include in is possible (and probable!), but won't be necessary. So don't take that as a concern here.


That said, I do agree that keeping the chapters as separate files which are included together into the final document probably makes for an easier editting experience most of the time (unless you're doing find-and-replace across the whole thing, but even then, a good editor can do that across multiple files in a folder). And yeah, those very large specs should be split; I've thought about doing precisely that for Flexbox, Grid, Color, and Selectors, because they're very difficult to navigate currently.

On the other hand, I'm not the one doing this work, so if it would be a pain to reverse the combining, whatever. ^_^ However, I would at minimum ask for some big-text section separators (https://tabatkins.github.io/bikeshed/#big-text) so it can be reasonably navigated by editors with minimaps.

@gsnedders gsnedders merged commit b399d17 into w3c:master Jul 1, 2020
@gsnedders gsnedders deleted the css2-bs3 branch July 1, 2020 13:09
tidoust added a commit to tidoust/browser-specs that referenced this pull request Jul 3, 2020
The Editor's Draft of CSS2 was converted to Bikeshed recently:
w3c/csswg-drafts#5196

This means that the spec becomes single page for now (at least until Bikeshed
supports multipage specs).

This update drops `cover.html` as "common" filename, since it was only used
there, and adjusts tests to only expect multiple page from the published
CSS 2.1 version.

Note the published version of CSS 2.2 still has multiple pages, so the spec
still needs to retain the `multipage` flag in `specs.json`.
tidoust added a commit to w3c/browser-specs that referenced this pull request Jul 3, 2020
The Editor's Draft of CSS2 was converted to Bikeshed recently:
w3c/csswg-drafts#5196

This means that the spec becomes single page for now (at least until Bikeshed
supports multipage specs).

This update drops `cover.html` as "common" filename, since it was only used
there, and adjusts tests to only expect multiple page from the published
CSS 2.1 version.

Note the published version of CSS 2.2 still has multiple pages, so the spec
still needs to retain the `multipage` flag in `specs.json`.
domenic pushed a commit to whatwg/html that referenced this pull request Jul 6, 2020
The sub-pages of the spec now 404, as of
w3c/csswg-drafts#5196. This replaces all
links with the singlepage version.
mfreed7 pushed a commit to mfreed7/html that referenced this pull request Sep 11, 2020
The sub-pages of the spec now 404, as of
w3c/csswg-drafts#5196. This replaces all
links with the singlepage version.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Convert CSS2 to use Bikeshed
3 participants