Goal: Process Document for Busy People should be tailored to key busy people: technical editors and contributors. They most often need to know how to make progress on a spec. This doc should start there and describe how everything else is in service of it.
tl;dr start with the actual work product of the W3C, specifications, then go meta one step at a time, section by section. Rough outline:
Making specs to improve the web is why we are here (how are they made? and updated? flow charts)
WGs are in service of making specs within a particular area (Charter scope) that are ready (incubation - link Rec Track Readiness)
The TAG is in service of making sure specs make sense across WGs.
IGs/CGs are in service of incubating proposals towards specs, either to hand-off when ready to an existing WG, or to motivate a new WG. Members can also submit things in service of incubating proposals.
Anyone can help start a CG, the W3C Team drives creating IGs, WGs
The AC is in service of prioritizing (voting) which WGs and IGs should be created or continue to exist and worth spending W3C resources on. Also voting for the TAG.
The AB is in service of the making/updating the process of all the above as efficient and consensus based as possible. The AB is also elected by the AC.
Appendix: Other random FYI W3C stuff that doesn't directly impact how specs are made, or the groups that support that: e.g. Communications, Workshops, Liasons.
Ran #Yasso fast yesterday at #track #Tuesday that I started to glow apparently, group photo 📷 @butteronadonut. Shout out #accountabilibuddy@micheleperras. #NPSF #Kezar #runners #novemberproject #tracktuesday #runner #nofilter
Workout: 6-8x(800 Yasso, 400 rest as long as the 800) I did: WU 400, 5x(800 Yasso, 400 rest + stretches), 400, abs, CD
Ran just a little under my usual pace, but at 44°F! Happy with 4:42 4:30 4:12 4:17 4:07 800s and still being able to breathe (without a buff) at that temperature. At least it wasn’t raining or windy.
There is also the counterpart: 'untag-of' posts (https://indieweb.org/untag) which are more of a brainstorm at this point, but I figured worth pointing out as a future enhancement, in case that helps generalize the code for 'tag-of' support.
Problem: currently you have to use Github’s web UI to remove a label from an issue.
If you could post an 'untag-of' response to a GitHub issue, and Bridgy Publish recognized that, it could call the GitHub API to (attempt to) remove the respective label from that issue.
The current brainstormed markup is similar to that for a 'tag-of' post, but with class name 'untag-of' instead.
I realize it would be even more helpful to have a real-live tag-of post permalink to refer to (preferably to a GitHub issue), so I will work on that next. I’m hoping this is enough to at least get started though.
It would be great if Bridgy Publish could 1. recognize that tag-of post to a GitHub issue, 2. add the respective label to the issue.
Beautiful weather at #RnRSanFrancisco, much nicer than Monday’s #BostonMarathon. I haven’t seen weather like what they had since the Kaiser SF Half Marathon of 2014, my first half^1.
Also this was probably the second happiest I have been near mile 12 of a half marathon (happiest was I think during the Mt. Tam Trail Half last November^2). Slower than expected^3, yet maybe happier was the right trade-off, having not really trained for this particular road/distance race (been training for longer distances on trails).
Note that the preceding paragraph also has visible plaintext markup - "data" tag, escaped in the original: tantek.com/2018/107/b1 thus it should also be escaped and displayed in the copy of this issue on GitHub.
HTML2text should (maybe?) handle this, or if not, Bridgy Publish could escape any visible '<' (less than), '>' (greater than), and '&' (ampersand) characters from the source before publishing to GitHub.
Can you provide an actual markup example that demonstrates the question?
For absolute URL values, the parser should just pass the value through, no processing or validation required.
For relative URL values, presumably "document's language's rules for resolving relative URLs" already handles making sure the base URL is valid.
Thus resolving a relative URL value could at most require URL escaping, which we could consider adding. However I’d rather first see an actual example markup that demonstrates how you could pass an "invalid [relative] URL" to the mf2 parser before adding another processing requirement (URL escaping) to the spec. Otherwise I'd prefer to close this issue with no changes needed.
Since #CSS 2.1 has been stable for years, and we now have a plan for rapid editorial & substantial edits and publishing, the @CSSWG agreed to name these bugfix revisions CSS 2.2 nth edition, incrementing n every periodic REC: https://github.com/w3c/csswg-drafts/issues/2008
@tabatkins I agree with that generally as an objective, that is:
Normatively state in CSS 2.1 that the grammar is defined by CSS 3 Syntax, with the key exception that we explicitly exclude any requirement to support scientific notation to maintain the fact that we are not adding any new features to CSS 2.x.
We should note any such exception like that in such a way to not discourage implementations from implementing all of CSS 3 Syntax, that is, something like:
For the purposes of this inclusion by reference, the scientific notation feature is excluded from CSS 2.1 in order to not add any new features to CSS 2.1. Implementations may (and are encouraged to) implement the full CSS 3 Syntax specification, and we expect any new or modern implementations to do so.
All this being said, assuming we can agree on this path forward for resolving this issue, I would like this issue to not be a CR blocker, so we can make incremental progress on CSS 2.x.
I can see reasons for using either "CSS 2.1 nth edition" or "CSS 2.2 (nth edition)" moving forward. In either case we should use "++nth edition" for subsequent updates rather than incrementing the decimal. Here is what I could come up with and or saw or heard mentioned by others:
Arguments for CSS 2.1 nth edition moving forward: * no new features, so no need to increment the decimal * past decision(s) that CSS 2.1 would be the last version of CSS2. * avoid version number inflation
Arguments for CSS 2.2 nth edition moving forward: * CSS 2.1 has been a stable (unchanging) document for many years, "2nd edition" does not accurately reflect the extent of likely editorial and substantive edits necessary to incorporate years of accumulated errata and issues * "CSS 2.2" explicitly sends a signal to browser implementers and detail-oriented web developers that it has (will have) major bug fixes since CSS 2.1 that everyone else has read and referenced (in books etc.) * Regular updates is a new mode. Since the proposed CSS 2.x editing & publishing workflow (see https://github.com/w3c/csswg-drafts/issues/2553) will be publishing regular updates with changes, it makes sense to provide a new decimal version number to signal this change in expected maintenance as well * A CSS 2.2 WD has been published, and will forever exist. It would now look weird (possibly be confusing) to have the "latest" CSS 2.x be 2.1, a perceived step backwards from the 2.2 WD * A single decimal increment over the course of 10+ years is reasonable and provides no danger immediate or subsequent of version number inflation
Based on these reasons, I have some preference for now (continuing) moving forward with CSS 2.2 on the condition that our proposed seasonal/regular iterations use "nth edition" rather than incrementing the decimal.
I also agree that "Just changing the publication date, without updating the spec name, doesn't seem enough to me".
I would be open to incrementing the decimal in the distant future if we make major changes such as replacing whole chapters with normative references to CSS 3 modules, or perhaps obsoleting a whole chapter in deference to one or more CSS module(s) (e.g. perhaps colors.html with css-color-3 and css-backgrounds-3).
PROPOSED: Use CSS 2.2 for the next REC track revision of CSS 2.1, and then append "2nd edition", "3rd edition" etc. for subsequent Edited Recommendations.
There are likely 100x (if not more) links to CSS2.x fragment links from before 2016 than after, and thus it makes a lot more sense to restore the 2011 REC fragment anchors to keep more fragment links working on the web, especially those that were referencing /TR/CSS2/somepage.html#somefragment or /TR/CSS21/somepage.html#somefragment which redirect to the latest version.
PROPOSED: Restore fragment identifiers in CSS2.x to those in the CSS2.1 REC published in 2011.
I would prefer to NOT add scientific notation to CSS2.x because technically it’s adding a feature (and we resolved long ago no new features in CSS2.x), but I can live with it assuming this is the result of some past resolution and will be harder to undo than "keep".
I am also opposed to adding scientific notation to CSS2.x if it requires adding more normative text as opposed to getting it as a side-effect from an external normative reference e.g. to CSS3 Syntax.
PROPOSED: Do not add scientific notation to CSS2.x, or if it is present then explicitly remove it, or if (when) included by a broader normative reference (e.g. to CSS3 Syntax grammar) then explicitly exempt it from inclusion of said normative reference.
@gsnedders@fantasai and I worked on this effort to restart CSS2.x editing & publishing with a formal but efficient workflow during the current (Berlin) CSSWG meeting and we’re pretty sure we can make this work (@gsnedders helping with the restart, build system, and testing, and initially @fantasai and myself as editors), and it's the most efficient we can do this given goals and current W3C process / patent policy constraints.
This is intended to supersede all decisions/resolutions at the past Seattle f2f where the WG last discussed CSS2.x workflow.
Please take a look at the gist and thumbs-up, or add questions / comments / suggested improvements accordingly. Assuming the WG approves this proposed workflow I’d like to document it in a README in the css2 directory https://github.com/w3c/csswg-drafts/tree/master/css2 so its easily discoverable and we can tweak/iterate as needed while actively using it.
Should we explicitly add scientific notation to the CSS 2.1 grammar?
We have a default policy of no new features in CSS 2.1 errata, so shall we continue with that, or, shall we make an exception for scientific notation for numbers for re-use by SVG?
This addition would either need to be made explicitly, or indirectly by normatively referencing the CSS3 Syntax Module (which is believed to more accurately reflect implementations) as an update to the CSS 2.1 Grammar.
Was just told by @cssrossen that I’m the last remaining (in name) editor^1 of #CSS 2.1 @CSSWG, or “Last of the Mohicans” as he put it (not sure how I feel about the comparison). In practice, @fantasai has been editing 2.1. And @gsnedders volunteered too. I think Rossen just wants to assign 2.1 errata^2 issues^3 to me^4.