whatwg / meta Goto Github PK

Giving more folks write access will empower them to add labels, assign issues, and create and update branches. That seems like a good thing as we're all here to make the web better and any mistakes are easily corrected.

We don't necessarily want everyone to have access to the couple administrative repositories however so a way to manage this would be to have a large contributor team that has write access to each repository. We'd then add most folks to this team.

Before we do that we need to ensure that the master branches are protected, as mistakes are more costly for those and other than through pull requests nobody should be meddling with those anyway.

• forums.whatwg.org: redirect to https://github.com/whatwg/, or maybe the IRC wiki page?
• svn.whatwg.org: redirect to https://github.com/whatwg/, and stop running a SVN server there?
• help.whatwg.org: redirect to https://html.spec.whatwg.org/dev/ ?

Harder:

• images.whatwg.org: I am sure people link to this, but it seems also quite old. I wonder who still links to it and whether we can come up with redirects for it without breaking lots of things.

Currently https://html.spec.whatwg.org/ has a certificate of sni.dreamhost.com, and thus is blocked by Web browsers.
Looks like html.spec.whatwg.org is resolved to a dreamhost IP address by DNS, while others (at least spec.whatwg.org, fetch.spec.whatwg.org, and dom.spec.whatwg.org) are resolved to a DigitalOcean IP address.

Most standards (HTML Standard excluded) have a branch-snapshots/ directory. This hosts a copy of the standard reflecting the last commit in a PR. If the branch name used in the PR gets reused, the copy gets overridden. If the branch name is not local, it doesn't get created.

PR Preview has similar functionality, though I believe no overriding takes place and non-local branch names do not matter.

It would be nice if we could reconcile the two. I don't think we need to keep distinct solutions.

cc @tobie @domenic @foolip

We need to sort out how to host PR Preview resources. Currently they use Amazon S3. We could continue to use that or create some kind of space where the PR Preview tool can upload resources to (just HTML or also other resources found in the repository?).

Since these resources can come from untrusted sources we should consider not hosting them on whatwg.org. Perhaps "preview.whatwg.org" is sufficient though I'm a little wary of that still due to cookies.

cc @tobie @domenic @foolip

Twitter has made everyone's icons a circle, and this looks pretty bad for a few of our spec accounts:

• https://twitter.com/storagestandard
• https://twitter.com/compatstandard
• https://twitter.com/fullscreenapi
• https://twitter.com/mimesniff

What should we do?

Unfortunately the new Twitter UI does not allow you to "zoom out" when uploading a photo; we'd need to actually produce new resources with the extra whitespace on the sides.

An ideal setup would be a single machine-readable (JSON) document listing:

• Workstreams
  • Name
  • Scope
  • Short, "database" name (used by participate.whatwg.org code)
  • Editor
    • Name
    • Email address
  • Living standards. Per living standard:
    • Authors (usually a superset of workstream editor; used for bibliographies and attribution, not decision-making power)
    • Short all-caps name for cross-references
    • Full citable title that includes "Standard" at the end
    • Description (currently seen on spec.whatwg.org)
• Non-workstream things people might cite
  • See BOOKS, DOMPARSING, FIGURES, JAVASCRIPT, LOADER in https://resources.whatwg.org/biblio.json

Right now this data is scattered across:

• spec.whatwg.org as HTML
• idea.whatwg.org as HTML
• whatwg/sg's Workstreams.md
• participate.whatwg.org config.json
• https://resources.whatwg.org/biblio.json

The new resource would live in whatwg/sg since the SG controls scope changes/the creation of new workstreams/etc.

From this new machine-readable data source, we would then

• Generate spec.whatwg.org
• Generate idea.whatwg.org
• Generate whatwg.org/workstreams
• Generate https://resources.whatwg.org/biblio.json
• Update participate.whatwg.org code to consult this canonical resource
• Update labels.py to consult this canonical resource

Here is my vision:

Group: WHATWG
Title: Streams Standard
H1: Streams
Shortname: streams
Text Macro: TWITTER streamsstandard
Abstract: ...

I would like this to generate the following additional metadata:

Repository: whatwg/streams
Status: LS
Boilerplate: omit conformance, omit feedback-header
No Editor: true
Logo: https://resources.whatwg.org/logo-streams.svg
!Participate: <a href="https://github.com/whatwg/streams">GitHub whatwg/streams</a> (<a href="https://github.com/whatwg/streams/issues/new">new issue</a>, <a href="https://github.com/whatwg/streams/issues">open issues</a>)
!Participate: <a href="https://wiki.whatwg.org/wiki/IRC">IRC: #whatwg on Freenode</a>
!Commits: <a href="https://github.com/whatwg/streams/commits">GitHub whatwg/streams/commits</a>
!Commits: [SNAPSHOT-LINK]
!Commits: <a href="https://twitter.com/streamsstandard">@streamsstandard</a>
!Tests: <a href="https://github.com/w3c/web-platform-tests/tree/master/streams">web-platform-tests streams/</a> (<a href="https://github.com/w3c/web-platform-tests/labels/streams">ongoing work</a>)

Almost all of this is inferred from the shortname.

Is that possible, @tabatkins? By editing defaults.include? The shortname substitution and the macro interaction I'm particularly unsure about.

Continuing discussion from whatwg/infra#156 (comment)

At one extreme, every time we reference a concept or algorithm from another specification, the end of that paragraph should contain a [SPECNAME] reference. I think that's what @annevk is claiming has been the style.

If so, we're not at all consistent about it, especially within algorithm steps. A bunch of places call algorithms or use concepts from other specs without adding a [specname] at the end of the line. E.g. https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send step 4, or https://html.spec.whatwg.org/multipage/webappapis.html#runtime-script-errors step 5, or everywhere that throws a TypeError without referencing ES.

At the other extreme these [SPECNAME] things should not generally be used unless you are mentioning the spec by name. E.g. https://html.spec.whatwg.org/multipage/webappapis.html#integration-with-the-javascript-module-system intro paragraph. The reference is implicit if you are cross-linking correctly.

The latter seems to be what we do more often, in my experience.

In particular an older commit on master might take a longer time building and by the time it finishes, overwrite the newer commit that was already copied to the server. This happened with Fetch today (the ABNF change is no longer represented until I land another commit).

Steps to reproduce the problem: Pass valid SSML as first argument SpeechSynthesisUtterance

What is the expected behavior?
SSML to be parsed

What went wrong?
SSML is not parsed

Chromium/Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=795371

Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1425523

Specifications: https://w3c.github.io/speech-api/speechapi.html#utterance-attributes, https://www.w3.org/TR/speech-synthesis11/

Related: whatwg/html#3294

Let's get this implemented in browsers in an open source (FOSS, FLOSS) manner.

[I didn't see any more specific way to report technical issues with the blog, so I'm reporting this here.]

It's still there; it shows up just fine on https://blog.whatwg.org/2016/08. It's even still said to have the URL https://blog.whatwg.org/javascript that's linked to from e.g. https://github.com/whatwg/javascript. There's just one problem: that URL no longer actually works :-(.

According to Google, this is actually a very new problem: they still have the page cached as it appeared on Dec 4, 2017 19:29:36 GMT.

@mnot has extended an invite to the @whatwg/sg or other members of the WHATWG community who might want to attend the IETF meeting in London in March 2018, or any other upcoming meetings. This could be a good opportunity for cross-pollination between the two communities, and I wanted to share it more widely.

The way I'd like to use teams:

• Anyone can join any team they desire. To join just let someone know or file an issue against whatwg/meta.
• Everyone tries to ensure the appropriate teams are pinged on relevant issues/pull requests
• Teams have no formal authority, though it's fine to add them as contributors to repositories for ease of collaboration. For all repositories we care about protecting master primarily. The bar for write access to other branches is much much lower.
• Teams have no responsibility either. If you ping a team and get no feedback, moving things forward responsibly is still on you.
• Creating new teams should be easy via filing an issue against whatwg/meta. Review should take some care it's not too much of a niche or overlap with existing teams.

I was thinking we'd put this in a Markdown to point folks to or maybe add it to the FAQ? Should we have a GitHub-specific FAQ?

As discussed in #4 that might result in less overall traffic, though this somewhat depends on whether the HTML Standard is involved or not.

#4 (comment) has a way of doing this from the command line.

Doesn't make much sense to have them indexed.

Excluding HTML, since it is a special duckling, all specs should ideally:

• Be on Bikeshed
• Not check their source files into the repo, but auto-deploy via Travis
• Deploy commit snapshots
• Include file-issue.js, commit-snapshot-shortcut-key.js, and dfn.js. (Or, instead of dfn.js, we should use Bikeshed's generated definition panels.)

If all of these become true we can start making some nice assumptions, e.g. we can move some script elements into our Bikeshed boilerplate.

What's missing?

• Fullscreen, Notifications, Mimesniff, Storage, Quirks
  • Still check in build output
  • Missing commit snapshots and commit-snapshot-shortcut-key.js
• XHR
  • Still checks in build output
  • Missing commit snapshots and commit-snapshot-shortcut-key.js
  • Still on Anolis; see whatwg/xhr#97
• Compat
  • Still checks in build output
  • Missing commit snapshots and commit-snapshot-shortcut-key.js
  • dfn.js is in the footer, confusingly
• Console
  • Missing commit snapshots and commit-snapshot-shortcut-key.js (but does not check in build output)
  • Missing dfn.js
  • Both being fixed; see whatwg/console#83
• Streams
  • Is using Bikeshed's definition generator instead of dfn.js (fixed in whatwg/streams@421e621)
• HTML differences from HTML4
  • Uses Anolis whatwg/html-differences#2
  • No Travis goodness either

Currently we ignore validation of the server we are copying resources into. I don't see an immediate attack, but we should set the correct example. It will also help us if it starts mattering at some point.

PRs created thus far:

• whatwg/url#202
• whatwg/dom#397

One thing that would be nice if we could deduplicate this known_hosts resource somehow. Or maybe add the information into .travis.yml. Getting quite a few boilerplate resources making the repositories look harder to work with than they are.

When I run travis lint .travis.yml on e.g., URL's or DOM's resource, I get this:

[x] value for env section is empty, dropping
[x] value for addons section is empty, dropping
[x] in env section: value for global section is empty, dropping
[x] in env.global section: unexpected pair
[x] in addons section: unexpected key apt, dropping

This might explain why @sideshowbarker had to define the Java version in the script invocation. If the global is also not used, I guess the ENCRYPTION_LABEL thing we commit everywhere is useless too?

With the groundwork in #6 landed, we now need to make sure all standards start using it. We also need to further tweak the script for that to happy completely, since a couple standards have additional requirements.

These are left:

• URL (needs extra resources for master)
• XMLHttpRequest (needs extra resources everywhere)
• Encoding (needs extra resources everywhere)
• Streams (needs emu-algify step)
• Console (needs extra resources everywhere)
• Compatibility (needs extra resources everywhere)

(There's also Books, Figures, Loader, and HTML Differences.)

Can't we make it git fetch $1 $2:$1-$2 to fetch less data? Should we also automatically set upstream for this remote branch to make pushing afterward easier?

I am using jQuery validation for validating an e-mail address.
And I saw they reference the regex from this url: https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address

The following JavaScript- and Perl-compatible regular expression is an implementation of the above definition.
/^[a-zA-Z0-9.!#$%&'+/=?^_`{|}~-]+@a-zA-Z0-9?(?:.a-zA-Z0-9?)$/

I tested this regex and it seems to be incorrect. Since it also matches bla@bla in this situation.
Also the 61 should be 62? Since the DNS allows 63 characters?

Perhaps you could use this one: http://emailregex.com/
/^(([^<>()\[\]\\.,;:\s@"]+(.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@(([[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}])|(([a-zA-Z-0-9]+.)+[a-zA-Z]{2,}))$/

I talked with @chrisdavidmills about notifying MDN about changes to standards. The easiest way to do this would be with a label that MDN can track (at least until MDN moves to GitHub at which point we could consider filing an issue there or have it filed automatically).

Suggestion: mdn-relevant. The expectation here is that MDN would take care of tracking whether they have documentation for it or not.

If we change this, and I think we should given the conflict with GitHub teams, it needs to be changed in whatwg/meta and whatwg/html. Anwhere else?

(We could also go for MAINTAINERS.md potentially, given that it's not always the editor that merges.)

It seems we updated HTML, but, e.g., https://github.com/whatwg/dom and https://github.com/whatwg/streams still refer to the Erlang wiki and generally don't seem to point to the guidelines here.

Fixing #64 first would be good though.

GitHub apparently helps new folks find the "good first issue" label. Should we attempt to switch from "good first bug"? That might have some repercussions for existing links, but given native support, maybe it's worth it?

We should also document whatever we end up doing in LABELS.md.

cc @sideshowbarker @zcorpan @foolip @domenic

Browser support for SVG favicons is patchy. Favicons are useful in distinguishing tabs for people who keep many open. It would be nice to have PNG fallbacks for WHATWG specs for those of us whose browsers don't support them.

https://github.com/whatwg/html currently has both and it seems to make editing a little easier. It also makes it clear most code is HTML and not Shell. And setting diff=html makes diffs a little bit easier to read due to including headings in the context (reportedly, haven't seen it happen much).

Some context in the following IRC discussions with @annevk

• http://logs.glob.uno/?c=freenode%23whatwg&s=14%20Jan%202017&e=14%20Jan%202017#c1017037
• http://logs.glob.uno/?c=freenode%23whatwg&s=19%20Jan%202017&e=19%20Jan%202017#c1017668

A few problems we have with hosting through Dreamhost:

• Their IPv6 setup for *.whatwg.org continues to be seriously broken—though Dreamhost claims there actually is no problem. But despite their claims I am certain they have a chronic consistent problem that causes IPv6 connections to appear like they’re basically being tarpitted. So on every machine from which I need to get to *.whatwg.org I have to edit the /etc/hosts file to force the 75.119.197.251 IPv4 address to be used instead.
  Among other things I need to do that for all places where I run an instance of the HTML checker, because the checker needs to fetch content from wiki.whatwg.org at start time.
• We recently had a more acute problem—with no workaround—when Dreamhost broke TLS certificate validation for *.html.org resources for at least a full day. It’s not clear how they broke it nor how they fixed it but @annevk says they claimed there actually was no problem.
• Today @annevk noted that “DreamHost's SSH instructions are basically "trust the network"… They move the server and there's no place to find the new public key securely”
• https://lists.whatwg.org/pipermail/whatwg-whatwg.org continues to be broken and apparently unfixable as long as we continue hosting at Dreamhost

The above is not even an exhaustive list—but I hope it’s enough evidence to make clear it’s time we seriously consider a move to hosting at DigitalOcean or some other provider that gives us control over the environment and ability to prevent problems like the above and fix them when needed.

Negatives to the 100 char wrap:

• You have to remember to do it.
• You need to do it manually or get a tool for your editor.
• A one-word change can turn into a diff of many lines.
• Makes it difficult to search for a term if the term is newline split in places.

I guess it's a benefit if your text editor / diff viewer doesn't support wrapping, but is that still a valid reason?

We don't manually wrap lines on the service worker spec, and the diffs look pretty good in split mode w3c/ServiceWorker@65cf285?diff=split.

We seem to be mis-aligned with header capitalization.
I didn't quite know what the "right" answer is (if there is even one).

FWIW found a nice "rule-of-thumb" guide that is fairly long in the tooth (but then again so is linguistics).

Noticed @annevk recently went with the "all capital words in header" approach. IIRC there is something about headers being like sentences. For certain I do recall them being without periods.

Example

https://github.com/whatwg/meta/blame/master/GITHUB-TEAMS.md#L1

May seem like a nit now but better to address a match than a forest fire. I would have fixed this up myself but not for me to solely decide without feedback. Please let me know and I'll submit a patch for us ASAP.

🙏

I wonder if it's really useful to have commit snapshots for PRs. It seems that latest branch snapshot would be sufficient.

There's two concerns:

• Making /commit-snapshots/ reflect master would make it easier to go through. It would reflect linear history just like our Git usage.
• Amount of space used on the server.

forbidding indexing by robots.txt is 1/2 a solution. using rel="canonical" to provide a suggestion to SEs is the other 1/2: it will prevent indexing of the snapshot and inform the SE what they should index. it also aligns with industry standard practice, see the wikipedia example at: http://ws-dl.blogspot.com/2017/08/2017-08-07-relcanonical-does-not-mean.html

Specs to add service worker to:

Special:

• HTML

Easy:

• Infra
• DOM
• Fullscreen
• Notifications
• Fetch
• MIME Sniffing
• XMLHttpRequest
• Storage
• Quirks Mode

Need to start using the deploy script first (#11):

• URL
• Encoding
• Compatibility
• Console
• Streams (has one, but it's a one-off created for streams)

The best path here might be to fix #11, then add the service worker registration to the Bikeshed template, instead of doing individual PRs like whatwg/dom#476

Original post follows:

I did this for streams with some success in whatwg/streams#637. Some thoughts:

• Maybe we should work to implement the more complicated strategy discussed at whatwg/streams#637 (comment) before rolling this out everywhere?
• Is there any way to deduplicate the code? Given that it has to be hosted on the same origin, it seems unlikely. Hmm, I guess importScripts works cross-origin? So then we'd just reduce the actual in-spec code to something like self.toCache = ... or maybe we could even get rid of that by inferring the logo filename from the origin.

This is a consequence of #9.

Related to #202, it's a bit annoying for every repo's commit history to contain a bunch of meta commits every time we want to update the deploy process. And, code duplication in general is bad.

Ideally we'd use the .travis.yml to set config variables:

• DEPLOY_USER
• TITLE
• SHORTNAME (=> current LS_URL, COMMIT_URL_BASE, BRANCH_URL_BASE, SERVER, WEB_ROOT)
• INPUT_FILE (or, just standardize on a single filename, e.g. index.bs or specshortname.bs... would lose a lot of Git history though, so probably not worth it)
• FILES_GLOB (to allow copying extra files, like images or encoding stuff)
• EMU_ALGIFY (boolean used by streams and console to run through emu-algify)

I guess SHORTNAME could be inferred from some git commands to get the current repository and INPUT_FILE could be inferred to be the only .bs file in the repo.

We could then I guess have a simple one- or two-liner in Travis that curls down the deploy script from whatwg/meta and runs it.

I might try prototyping this early next week; feel free to start without me though (a good first pass would probably leave out FILES_GLOB and EMU_ALGIFY)

• checker.html5.org is more up to date than html5.validator.nu;
• onlinewebcheck.com was discontinued.

Since we use this all over now (including HTML diffs), we should make it more obvious how to close it. Perhaps just render an [X] in the top? Or "click here to close"?

Here are some things it would be nice to have Travis verify for us, for all the Bikeshed-using specs:

• Line length, I guess ignoring inside <pre> blocks---any other exceptions?
• No trailing whitespace

Please add more ideas!

I want horizontal and vertical splitters in HTML. Also be able to make a side of an element a splitter similar to how borders are changed, means each element might have 4 predefined splitters. When I change its size other elements, if possible, around it fill the freed space. This is how I want it to be.

I want a vertical line in HTML !

Because in CI we use the Bikeshed web service, which I don't believe provides any way of seeing warnings, it's easy to commit spec changes that induce warnings without ever noticing.

Similar issues occur when someone wants to use make remote.

I'm not sure what the best solution is for this. /cc @tabatkins. Maybe what we need is a mode for the web service that will fail if there are any warnings? But hmm, we want to intentionally ignore the security/privacy warnings. Not sure...

I've been loving the branch snapshots for reviewing changes on URL. @tobie already did this for Web IDL, basically, although the URL pattern was different. @tobie would you mind outlining how that works? E.g. is the source code available, and what does it run on, etc.?

We currently have the following teams established:

• a11y
• canvas
• components
• html-parser
• i18n
• loader
• media
• modules

Am curious where a briefing of each team
(particularly components, a11y, media, and modules) would reside.
To be clear only curious about the last three.
I'm explicitly requesting (and assuming web) components,
only because i've been following the spec maturity for a few years now.
Even still i'm not 100% certain this is the "components" i'm assuming.

If so...This would be an honor and a privilege 🙏
how can I be down? :-)

Lastly when does a group get "christened" and which ones are on the horizon. Sheer curiosity.

Thanks in Advance!

Over in whatwg/dom a PR by @snuggs made me realize we should really have central commit title/message rules.

They should probably consist of the first three paragraphs of https://github.com/whatwg/meta/blob/master/TEAM.md#handling-pull-requests.

Should we just host those in a Markdown file in this repository and link to it from all over? Perhaps updating https://github.com/whatwg/meta/blob/master/CONTRIBUTING.md would be best?

It's just supposed to be a redirect, but it has HTTPS errors. This breaks older links that people have.

Given things like whatwg/url#249 that might be nice. It would also give us consistent spelling practices across standards.

@zcorpan something you might be interested in?

• Update license statements to use CC BY.
  • Figure out translation guidance and communicate it with translators: whatwg/sg#40.
  • Figure out guidance for associated resources: whatwg/sg#48.
  • Update Bikeshed template: #23.
  • Update all standards to make use of the new template and change their LICENSE resource as well.
    • compat
    • console
    • dom
    • encoding
    • fetch
    • fullscreen
    • html
    • infra
    • mimesniff
    • notifications
    • quirks
    • storage
    • streams
    • url
    • xhr
• Make @whatbot look at incoming PRs to ensure folks have signed the participation agreement.

@xfq you may wish to follow this given your interest on IRC.

http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org does not work for people because of HSTS.

Possible fixes:

• DreamHost adds Let's Encrypt to their mailing list service
• We move the mailing list to our own server
• We configure the mailing list to not suggest that URL anywhere. This was changed for the footer when we switched to https but the broken URL still exists in the List-Subscribe header as well as in Digest emails.

HTML has a pretty good set of labels. We've copied some of them to other specs but not all. It might be nice to do so, and document them. (Although, the topic: labels should be per-spec, I think... although certain topics like custom elements cross specs.)

https://www.google.com.sg/search?q=github+label+sync shows that there are lots of tools to help with this.

It seems there might be some GitHub integration benefits to this? It shows up under https://github.com/whatwg/meta/community at least.