As a place for bringing together interested and concerned parties about browser engine diversity and standards, this repo would be useful for considering web standards in general beyond W3C, and the impact upon them by the participation (or lack thereof) of one or more browser engine implementations. How different orgs (IETF, WHATWG, TC39, etc.) approach these challenges and questions may help provide common approaches worth considering.
While the origin of this repo is from a W3C TPAC session, it was clear from the broad and diverse participation in that session that this is an area that goes beyond W3C, and thus we should consider expanding the README accordingly, noting browser engine diversity issues and opportunities across multiple standards organizations, and leave the W3C-specific parts as part of the origin (but not any restriction in scope) of this repo. If this general approach is non-controversial, I can make pull requests to update the README accordingly for specifics.
↳ In reply to @dens’s tweet@dens I remember 2009, when our worst complaints about #socialmedia were too many failwhales.
Congrats on Marsbot for AirPods! Could you allow sign-in with @Foursquare (OAuth) instead of a phone number for those of us without one or avoiding SIMjacking?
High level feedback on Canvas Formatted Text: Please harmonize this work with the
CSS Houdini effort.
In addition you may want to take a look at some of the prior work in:
SVG2 Chapter 11: Text.
Similar to
The Google WebID privacy threat model document,
the IndieAuth specification should have a brief non-normative
“Privacy Threat Model” or “Privacy Considerations” section, perhaps right after the
Security Considerations section, or alternatively as a separate document which the spec links to.
↳ In reply to issue 60 of GitHub project “w3process”This is not an “editorial mistake” from the perspective of those that carefully reviewed the Process document with the voting changes and in particular interpreted the only logical way that the election could be implemented given the text of the document (literally STV per seat for the number of seats in an election), and only approved the process accordingly. Several AC reps would have filed formal objections to the process had this been dropped before the Process went to review, and before that, in the AB.
The Process also doesn’t say, implement whatever voting experiments were run, so the excuses that have been made to justify running the subsequent elections as they have been run (“but the experiments!”) also hold no justification in the Process document.
Both of those are deemed objectionable enough to not remove this text from the Process and yes that leaves us at an impasse that the AB must take-up to resolve, especially towards a future where we may/will be relying even more on elected bodies to resolve conflicts rather than a BDFL “Director”.
As illustrated by the
2020-10-02 draft newsletter,
the Top Edited Wiki Pages includes User: pages which are more personal projects or bot updates and don't really add significant information to the This Week newsletter. User: pages should be omitted from the Top Edited Wiki Pages section.
The current
h-entry change control process
does not specify how to update the definition of a proposed feature, which means it falls back to being as strict as updating a stable feature which is more strict that desired for proposals. This issue is for considering a proposal for updating the definition of a proposed feature, as discussed during the
recent Microformats Issue Resolution pop-up.
Proposal: the definition of a proposed feature may be updated to be more consistent with one or more real world public web sites publishing and or consuming the feature, by citing URLs for those examples in an edit summary. New proposed property or value definitions may also be added for consideration per the existing requirements for adding a proposed feature. If you’re not sure whether to update an existing definition or add a new definition, try to work with the proposer(s) of an existing definition to come to a consensus to update it. Lacking consensus, add a new definition for consideration, retaining any previous definition(s).
This proposal also adds a convergence requirement for moving a feature from proposed to draft. If there are multiple definitions for a proposed feature, an issue must be opened to discuss how to converge the definitions by consensus agreement among those with real world public web sites publishing and or implementations consuming the feature.
This is a rough first draft, feel free to propose alternatives, simplifications, editorial suggestions.
Runair is awesome! Would be great to give an explicit open source license like CC0 (preferred), or BSD, MIT, Apache etc. of your preference and mention it in README.md.
For example, the IndieWeb newBase60py library uses CC0: https://github.com/indieweb/newBase60py and you could copy this LICENSE file in its entirety https://github.com/indieweb/newBase60py/blob/master/LICENSE
@slightlylate sorry for your and all of our collective loss. Saw him at #W3CTPAC 2019. He was kind & welcoming to new folks @W3C (@CSSWG etc.); appreciated his contributions & conversations 💔
This issue is not the place to make pitches for use-cases.
While we (Mozilla) are definitely sympathetic to use-cases that help users, a better place to capture those is either on your own blog with blog posts, or perhaps as pull-requests to add them to the respective Explainer, e.g. in this case:
Better yet both, so you can fully express the use-cases yourself and then cite them with a brief summary in the Explainer.
On the specific medical use-cases provided, if anything these are great examples both in terms of greater potential harm to users, and more vulnerable infrastructure due to systemic IT process issues. Those are both good reasons to expose fewer potentially risky features, not more.
↳ In reply to @slbedard’s tweet@slbedard or a Shazam for #birdsong, showing both which bird(s) and map of where heard, with optional contribution of location, naturally with @SwarmApp checkin integration for the obvious birds & bees mashup, and Twitter to tweet your #twitching 🐦🎶
On GitHub, project team members are able to add labels to your issues on a project. If your issue is a POSSE copy of an original post on your site, Bridgy should backfeed these as "tag-of" responses to the original post. cc: @dshanske
This is similar to
issue #776
which is the same backfeed feature request but for Flickr.
This is also the “labeled” specific subfeature of
issue #833
which documents many more backfeed for GitHub requests.
And similar to
this comment on #811
(original post)
requesting Bridgy Publish untag-of support,
it’s worth considering Bridgy Backfeed untag-of support
(the “unlabeled” specific subfeature of #833),
so when someone removes a label from your issue, your original issue post is notified. However, the
brainstorming of how to markup untagging
is still ongoing, and thus may need to wait for more discussion before implementing.
There has been some past brainstorming about possible MIME types for the JSON resulting from a compliant microformats2 parsing implementation:
microformats2-mime-type.
It seems one in particular, application/mf2+json, has seen some adoption in the wild: https://indieweb.org/application/mf2+json.
Should we specify an explicit MIME type for the parsed JSON result of an mf2 parser? And if so, should we adopt application/mf2+json or some other alternative?
This feature is both a useful declarative presentational feature for web developers and one that formerly had a non-standard -moz prefixed value (-moz-hidden-unscrollable). Thus we should consider giving it an explicit status of "important".
* 17k+ #Berlin anti-mask/anti-vax protesters gathered without masks (#COVID19 surge coming) * "Day X" preppers infiltrate German state institutions (@kbennhold), like a real-life MCU Hydra * Ware State Prison riot * Murder Hornet trapped, <2 mo. to find their nest
Hey guys (yes, literally), and anyone in a position of power (management, leads) at Google, or any tech company, or any company, please read this thread by @EmilyKager:
2wks "virtual" @W3C F2Fs: Prev: MTW 06:00-09:30 @W3CAB, first as a returning AB member This: MT1-5p ThF7-11a @CSSWG Long Zoom/gMeet hrs, missed in-person time & break chats. Though I could reference 30yo typography books for ::first-letter issues, like The Elements of Typographic Style, and How to Spec Type.
We reject traditional "fast growth" capitalist narratives, and instead humbly encourage slow sustainable growth across numerous projects that interoperate with each other.
Longevity & dependability directly benefit the people participating, instead of shortterm excitement which typically only benefits investors (sometimes "serial" entrepreneurs).
Would love to chat more about these topics: https://chat.indieweb.org/ (There’s a Slack link there too to use Slack to join).
@solarpunk_girl still reflecting on https://twitter.com/solarpunk_girl/status/1261196542519672834, how to design modern multi-generational housing? E.g. with care-sharing & support as primary goals, and COVID persisting: create quarantine split levels/sections with separate BRs/BA. Healthy half could provide food etc. for those in quarantine. Would work both for traveler / suspected exposure quarantine (like many countries requiring 14 days), and confirmed cases recuperating. If there were both (suspected and confirmed cases), they would need to be split apart as well, both sections accessible for care-providing without intersecting the other. We need new architectures of local sustainable support for a post-pandemic world.
A month ago @moral_imagining, @solarpunk_girl asked us to write a #MoralImaginations continuation to The Impossible Train story.
* * *
Since the train stopped, we’ve seen so many odd, shocking, and inspiring things.
People outside their train cars protesting to be let back on to enjoy their window views and demanding their familiar entitlements served by others.
Tensions outside the train bringing rise to new & familiar tragedies, now more visible to all.
A pair of humans board a shiny new train to the sky, launch, and arrive at the sky station to much applause.
People from different train cars, witnessing tragedy on tragedy, declaring enough, band together in solidarity, confronting and witnessing more tragedies.
Reports arrive that despite the apparent stoppage, the train is still moving, slowly, and the upcoming cliff, still crumbling away.
Per DAS charter feedback:
Mozilla has significant concerns about the inclusion of the
Network Information API in the charter (as a specification to potentially
adopt from the WICG) — Mozilla's public position is that this API is
"harmful" to the Web as the information that it provides is unreliable and,
at the same time, open to privacy abuses. As we have
stated publicly,
we believe it is "better that sites use methods that dynamically adapt to
available bandwidth, as that is more accurate and likely to be applicable
in the moment". Or, alternatively, use newer declarative solutions, such as
"lazy loading" images and alike.
Per DAS charter feedback:
Where we already have an existing Web APIs, e.g., Orientation Sensor,
we would prefer the working group cease work on
those items and instead focus on evolving the existing specifications.
Per DAS charter feedback:
Where we already have an existing Web APIs, e.g., Geolocation Sensor,
we would prefer the working group cease work on
those items and instead focus on evolving the existing specifications.
As is
evident with the Geolocation API,
implementers have continued to
make significant privacy and security enhancements to existing APIs, and
those enhancements have made their way back to the W3C. As such, we feel
it's unnecessary to have duplicate specifications.
Per DAS charter feedback:
The Fold Angle specification should be
incubated in the WICG before it becomes a working group deliverable. For
Fold Angle, we'd also like to see closer collaboration and input from the
CSS WG on the design.
Having said that, we would be comfortable with having WICG incubated specs
being explicitly listed as charter work items that the working group could
adopt at a future date. However, we'd like to see them listed in a manner
similar to the
Web Apps WG Charter's section on WICG Specs (i.e.,
separated out of the main deliverables list for the working group).
Per DAS charter feedback:
We believe it would be prudent for the System WakeLock API to go through
the WICG process until it gets implementation commitment from at least a
second browser vendor.
Having said that, we would be comfortable with having WICG incubated specs
being explicitly listed as charter as work items the working group could
adopt at a future date. However, we'd like to see them listed in a manner
similar to the
Web Apps WG Charter's section on WICG Specs (i.e.,
separated out of the main deliverables list for the working group).
Per DAS charter feedback:
On the the grounds of privacy, and given a lack of implementer support, we
would like the Devices and Sensors Working Group to cease work on the Ambient light sensor API and see it published as a Working Group Note instead.
Per DAS charter feedback:
On the the grounds of privacy, and given a lack of implementer support, we
would like the Devices and Sensors Working Group to cease work on the Proximity sensor API and see it published as a Working Group Note instead.
Per DAS charter feedback:
On the the grounds of privacy, and given a lack of implementer support, we
would like the Devices and Sensors Working Group to cease work on the Battery API and see it published as a Working Group Note instead.
A week ago Saturday morning co-organizer
Chris Aldrich opened
IndieWebCamp West
and introduced the keynote speakers. After their inspiring talks he asked me to say a few words about changes we’re making in the IndieWeb community around organizing. This is an edited version of those words, rewritten for clarity and context. — Tantek
That was a change we deliberately made last year, announced at last year’s summit. It was well received, but it’s only one minor change.
Those of us that have organized and have been organizing our all-volunteer IndieWebCamps and other IndieWeb events have been thinking a lot about the events of the past few months, especially in the United States. We met the day before IndieWebCamp West and discussed our roles in the IndieWeb community and what can we do to to examine the structural barriers and systemic racism and or sexism that exists even in our own community. We have been asking, what can we do to explicitly dismantle those?
We have done a bunch of things. Rather, we as a community have improved things organically, in a distributed way, sharing with each other, rather than any explicit top-down directives. Some improvements are smaller, such as renaming things like whitelist & blacklist to allowlist & blocklist (though we had documented
blocklist since 2016, allowlist since this past January, and only added whitelist/blacklist as redirects afterwards).
Many of these changes have been part of larger quieter waves already happening in the technology and specifically open source and standards communities for quite some time. Waves of changes that are now much more glaringly obviously important to many more people than before. Choosing and changing terms to reinforce our intentions, not legacy systemic white supremacy.
Part of our role & responsibility as organizers (as anyone who has any power or authority, implied or explicit, in any organization or community), is to work to dismantle any aspect or institution or anything that contributes to white supremacy or to patriarchy, even in our own volunteer-based community.
We’re not going to get everything right. We’re going to make mistakes. An important part of the process is acknowledging when that happens, making corrections, and moving forward; keep listening and keep learning.
The most recent change we’ve made has to do with Organizers Meetups that we have been doing for several years, usually a half day logistics & community issues meeting the day before an IndieWebCamp. Or Organizers Summits a half day before our annual IndieWeb Summits; in 2019 that’s when we made that aforementioned update to our Code of Conduct to prioritize marginalized people’s safety.
Typically we have asked people to have some experience with organizing in order to participate in organizers meetups. Since the community actively helps anyone who wants to put in the work to become an organizer, and provides instructions, guidelines, and tips for successfully doing so, this seemed like a reasonable requirement. It also kept organizers meetups very focused on both pragmatic logistics, and dedicated time for continuous community improvement, learning from other events and our own IndieWebCamps, and improving future IndieWebCamps accordingly.
However, we must acknowledge that our community, like a lot of online, open communities, volunteer communities, unfortunately reflects a very privileged demographic. If you look at the photos from Homebrew Website Clubs, they’re mostly white individuals, mostly male, mostly apparently cis. Mostly white cis males. This does not represent the users of the Web. For that matter, it does not represent the demographics of the society we're in.
One of our ideals, I believe, is to better reflect in the IndieWeb community, both the demographic of everyone that uses the Web, and ideally, everyone in society.
While we don't expect to solve all the problems of the Web (or society) by ourselves, we believe we can take steps towards dismantling white supremacy and patriarchy where we encounter them.
One step we are taking, effective immediately, is making all of our organizers meetups forward-looking for those who want to organize a Homebrew Website Club or IndieWebCamp. We still suggest people have experience organizing. We also explicitly recognize that any kind of requirement of experience may serve to reinforce existing systemic biases that we have no interest in reinforcing.
We have
updated our Organizers page with a new statement of who should participate, our recognition of broader systemic inequalities, and an explicit:
… welcome to Organizers Meetups all individuals who identify as BIPOC, non-male, non-cis, or any marginalized identity, independent of any organizing experience.
This is one step. As organizers, we’re all open to listening, learning, and doing more work. That's something that we encourage everyone to adopt. We think this is an important aspect of maintaining a healthy community and frankly, just being the positive force that that we want the IndieWeb to be on the Web and hopefully for society as a whole.
If folks have questions, I or any other organizers are happy to answer them, either
in chat or privately, however anyone feels comfortable discussing these changes.
Currently meetable supports tag browsing pages like: https://events.indieweb.org/tag/hwc
However if you trim the last segment, you get a 404: https://events.indieweb.org/tag/ or https://events.indieweb.org/tag
Meetable should instead redirect those to: https://events.indieweb.org/tags
Additionally, Meetable should consider redirecting https://events.indieweb.org/tags/ with the trailing slash to https://events.indieweb.org/tags without the trailing slash instead of serving duplicate content at those two URLs.
GitHub pull requests accept reacji just like comments, issues, etc. But currently Bridgy seems to not recognize reacji in reply to a pull request review permalink like:
↳ In reply to Tantek’s note1776-07-04 Declaration of Ind. "life, liberty" [for white men only]^1. Via @aclu^2 1863-01-01 Emancipation Proclamation 1865-06-19 EP & Civil War end announced to TX enslaved 1865-12-06 13th amend
Why celebrate July 4 more than #Juneteenth when rights were declared for all, not only white men?
When I was last on the Advisory Board (AB), I asked W3C Management (W3M) to provide a report on diversity of W3C, and in 2018 gender & geographic barcharts over time were provided for the AB, TAG, and W3M:
For example, what percentage of the AB, TAG, and W3M are white?
As far as I know, these W3C leadership groups lack even a single Black individual.
How many (if any) are in the Advisory Committee as a whole?
If W3C truly represents the interests of world-wide web standards, it’s long past time to ask these and other uncomfortable questions about who holds positions of authority & power @W3C. We must have the courage to ask them, and keep asking them, and actively work to dismantle systemic biases.
↳ In reply to @solarpunk_girl’s tweet@solarpunk_girl really like this! Need to replace & move beyond violent metaphors for common activities. Working on a longer post on this.
↳ In reply to @solarpunk_girl’s tweet@solarpunk_girl yes! Gardening & farming are ripe with metaphors for #NewNarratives. Also considering sourcing from cooking, baking, and toolmaking. New story arcs for the #NewPossible. #DontGoBackToNormal
🌃🌳 March 28th, SF distancing day twelve. Spent the day inside (except to move my car) until leaving 10 minutes to midnight for a night run.
Started tracking at Frederick & Ashbury, an empty intersection, lights out except the corner 2nd floor apartment(1). Empty to the East as well, up to the dark trees of Buena Vista Park, outlined by a gray sky above(2). Continued onward to spell NO FEAR on the streets (https://tantek.com/t55q1).
There was so much fear As we started sheltering we felt safer and yet more lonely Venturing outside, it was so quiet Fewer cars, fewer machines making noises Even in the city, we heard nature’s sounds from the crows to the parrots We closed streets to cars, welcoming runners, hikers, bicyclists Without cars, without their noise & pollution, more animals wandered near us. Coyotes, birds, rabbits, squirrels Even red tailed hawks swooped near the ground, showing off the bright tops of their tailfeathers Strangers started to greet strangers, as they passed each other at a distance, Maybe a smile, a nod, a wave, a hello, perhaps a brief exchange of greetings, well wishes, introductions to pets Slowly, our sense of fear transformed into a sense of solidarity
First
published on 2014-05-12,
the newsletter started as a fully-automatically generated weekly summary of activity on the IndieWeb’s community wiki: a list of edited and new pages, followed by the full content of the new pages, and then the recent edit histories of pages changed that week.
Since then the Newsletter has grown to include photos from recent events, the list of upcoming events, recent posts about the IndieWeb syndicated to the IndieNews aggregator, new community members (and their User pages), and a greatly simplified design of new & changed pages.
Meetable events allow uploading images, both a banner for the event itself,
and photos of the event afterwards. There should be a setup feature to explicitly pick and set one or more required licenses for image uploads.
At a minimum, Meetable should allow choosing a Creative Commons license like Flickr does
(radio buttons), perhaps defaulting to a CC-BY-NC license like the Wikimedia upload default, to encourage compatibility with the broader Wikimedia commons,
so images uploaded to default Meetable installations can also be published to Wikimedia,
and to allow Wikimedia images to be used for Meetable event banners.
Maybe allow multi-licensing as well, e.g. picking more than one license (checkboxes),
so uploads are required to be multi-licensed.
Additionally, consider allowing a user to enter one or more license URLs,
so those setting up their own Meetable can choose other licenses beyond
a predefined set of Creative Commons licenses.
Yesterday I ran 2.23mi(1) in memory of #AhmaudArbery, who would have turned 26. He was shot on 2/23 for jogging while black. The video is horrifying. #BlackLivesMatter because how is this still happening in 2020. #IRunWithMaud
This weekend #RunWithMaud in solidarity. If you’re in SF, you can start at Haight & Ashbury, run up Ashbury until it merges with Clayton, turn up Twin Peaks Boulevard, and turn around a bit after the first major turn, before the hairpin turn(2,3), running back down to Haight & Ashbury to complete 2.23 miles.
↳ In reply to issue 6103 of GitHub project “browser-compat-data”From a strict interpretation, in the W3C at least, a specification must be at least a publicly published Working Draft (WD) by an active Working Group (WG) to be on an official "standards track", and thus that should be our condition for explicitly labeling a technology in a W3C document as "standards track".
At a minimum a specification must be accepted into a WG’s charter, and not just as a NOTE, in order to qualify to be standards track. However it’s not actually on that track (and citable as such) per se until the WG has agreed to publish it publicly as a WD.
By at least a WD, I’m explicitly saying yes it can also obviously be a Candidate Recommendation (CR), Proposed Recommendation (PR), or Recommendation (REC, or edited, or amended). If it’s an Obsolete Recommendation we should use the "Obsolete" label.
If it’s only in an Editor’s Draft or a WD (before a CR), that would be reasonable to label as "Experimental", as anything that’s not yet in a CR can "Expect behavior to change in the future."
If a document is for example only developed in a Community Group (CG) such as WICG, it is not standards track (CGs cannot make standards), and thus we should explicitly label any technologies there as "Non-standard", until such document makes its way into a WG and the WG publishes it as a WD, therefore publicly signaling that the WG has agreed to advance it onto the standards track.
For IETF and other orgs, I’ll let others chime in about what state a document must be in to transition between "non-standard" and "experimental" and "standards track", or "obsolete".
“The indie web” was a name given to the collective us that used and still uses our domains for our actively independent web presence, a practice Blogger FTP helped enable for many years, for many people. Our sites worked (were at least viewable) without requiring (truly independent of) another web site or service being actively up & running.
Blogger FTP was a nice-to-have, even if/when it was down, your site and permalinks were still browsable, and you could still manually FTP and edit your site, your blog, on whatever generic web hosting service you were using. You could migrate your blog by FTPing your static storage files from one web host to another. Without any database export/import/(re)configuration.
Subsequently of course https://indiewebcamp.com/ was founded, eventually (and currently) https://indieweb.org/, recognizing a pre-existing practice by naming it and giving it a community focus. A community to discover & find each other, to actively collaborate, building on each other’s ideas & building blocks, evolving our sites, innovating the practical peer-to-peer web with a plurality of approaches, designs, interoperable implementations, and sustainable solutions.
🏙🌳 March 27th, SF distancing day eleven. Midday run/walk up to Corona Heights for another clear view of downtowns, San Francisco and Oakland(1). Later that afternoon a trip to Cole Hardware, limited to 15 store customers at a time(2). Inside, purchase limits on bleach, soap, paper towels, and gloves(3).
👥📰 March 26th, SF distancing day ten. Longer line to get into Haight Street Market(1). The newspapers reported on the $2 trillion stimulus(2,3). The New York Times in particular noted that states have begun discouraging visitors from other states, or requiring them to stay in quarantine, e.g. for 14 days.
