https://igx.4sqi.net/img/general/width960/476_TYzkOJEMShKLKkTngHSR8yx-nBDIkfzw0bz3LKCI28Y.jpg https://igx.4sqi.net/img/general/original/476_TYzkOJEMShKLKkTngHSR8yx-nBDIkfzw0bz3LKCI28Y.jpg
Happy #Gregorian #May and Second New Sunday^1. Day 122, one third of the way through the year.
#LEGO #month #calendar #nofilter
^1 tantek.com/w/NewCalendar#fiveSunrevolutionsyncdays
Wong: “How’s your Sanskrit?”
Doctor Strange: “I’m fluent in Google translate.”
If only Google Translate supported #Sanskrit, nevermind ancient Vedic Sanskrit, in 2016 or now.
Would have used it in #YTT, Yoga Sutra studies.
#doctorstrange
attending The Ultimate Marvel Movie Marathon @DrafthouseSF, started 17:00 yesterday, 28 hours, 12 movies, 6 Infinity Stones, finishing with Avengers: Infinity War. Taking time to reflect and reset.
https://drafthouse.com/show/the-ultimate-marvel-movie-marathon
W3C Process Document for Busy People should start with how to make specs
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.
https://igx.4sqi.net/img/general/width960/476_lLhpShqSbu4mquo6F614oJGx6dgGxjTZYwsn_qClf04.jpg https://igx.4sqi.net/img/general/original/476_lLhpShqSbu4mquo6F614oJGx6dgGxjTZYwsn_qClf04.jpg
https://igx.4sqi.net/img/general/width960/476_daSiphPI15i7LfI7VbOP0LRQqY2KfIhzQrTiWhPJBMc.jpg https://igx.4sqi.net/img/general/original/476_daSiphPI15i7LfI7VbOP0LRQqY2KfIhzQrTiWhPJBMc.jpg
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.
3 weeks ago: tantek.com/2018/086/t1/back-to-track-tuesday-again
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.
Feedback and contributions welcome on https://indieweb.org/untag
Also reasonable to consider 'untag-of' support a potential future separate issue rather than as part of implementing 'tag-of' support.
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.
https://igx.4sqi.net/img/general/width960/476_shkvRlTzyLs9vBmxW_Ac1-JOZfVv69WwyGsuabMVfKQ.jpg https://igx.4sqi.net/img/general/original/476_shkvRlTzyLs9vBmxW_Ac1-JOZfVv69WwyGsuabMVfKQ.jpg
#TBT to running by #NPSF cheering 1.5 weeks ago near #RnRSF mile 12 and feeling great. 📷 Henry; thanks @avamrtnz @therunetarian @perrwa!
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).
#halfmarathon #fromwhereirun #run #optoutside #getoutside #SF #SanFrancisco #Marina #latergram #2018_098 #nofilter
^1 tantek.com/2014/033/t2/finished-first-halfmarathon-rain-cold-wind
^2 tantek.com/2017/315/t1/finished-tam-trail-run-half
tantek.com/2017/321/t2/last-saturday-racing-tam-half-marathon
^3 tantek.com/2018/098/t1/rock-n-roll-half-marathon-finished
Bridgy Publish to GitHub should preserve markup in plaintext as such
When using Bridgy Publish to POSSE a comment (or issue) to GitHub, it should preserve any visible plaintext markup from the source as visible plaintext markup on GitHub.
Example: http://tantek.com/2018/107/t3/ has a <data> [data] element example, while the POSSE copy seems to have lost the <data> (but it's still in the Markdown source if I click edit)
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.
Transfer complete. More details soon.
Another major Q1 challenge wrapped up (2ish weeks into Q2).
Now that I’m back from @W3C @CSSWG f2f and @TYPO_Labs #typolabs18 Berlin, need to catch-up on more Q1 things, while working on aforementioned details.
Additionally there is a compelling use-case for this proposal:
Permalink pages which do not link to themselves or otherwise display their own URL.
This proposal would enable the relatively (so to speak) minimal markup:
<data class="u-url" value=""></data>
To provide the u-url for the h-entry of such permalink pages, instead of having to provide an absolute URL in the value attribute.
Upon reconsideration, I retract my suggestion in https://github.com/microformats/microformats2-parsing/issues/10#issuecomment-331511675 that "this issue's resolution should depend on resolving #9 first", and commented on how to orthogonally resolve issue #9 (http://tantek.com/2018/107/t1).
As promised in https://github.com/microformats/microformats2-parsing/issues/10#issuecomment-331499024, I’ve added PROPOSED text inline in the u-* parsing section per the proposal of this issue: http://microformats.org/wiki/index.php?title=microformats2-parsing&diff=66782&oldid=66724.
I see github.com/aaronpk’s agreement with this proposal, and would like to see at least one, preferably 2-3, more parser developer(s) explicitly agreeing as well.
We also need to see this proposed change prototyped in at least one parser to make sure it is implementable (seems like it) and to see if there are any unintended consequences.
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.
17:30: Tea time — in celebration of
HTTP 418
18:30: IndieWeb demos and hack night!
Enjoy tea & biscuits, learn about the history of HTTP 418, and how it was saved from deprecation! As usual we’ll have demos of personal website breakthroughs. Create or update your personal web site!
Join a community with like-minded interests. Bring friends that want a personal site, or are interested in a healthy, independent web!
Three ~9hr days of @CSSWG meetings and we still had agenda items remaining:
https://wiki.csswg.org/planning/berlin-2018
Great working with everyone, and welcome first-timers @clagnut & @notwaldorf!
Want to help improve #CSS? Check open issues: https://github.com/w3c/csswg-drafts/issues/
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
The @CSSWG accepted my and @gsnedders proposed new workflow for editing & publishing updates to #CSS 2.x as efficiently as we can given current @W3C process: https://github.com/w3c/csswg-drafts/issues/2553
@gsnedders restored it in GitHub to its previously published state.
@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.
In short: the cost of switching CSS2 to use Bikeshed (and the likely fixes / changes needed to Bikeshed to handle producing a multipage spec like CSS2) is not worth the benefits.
@gsnedders has been able to create a branch of CSS2 (see https://github.com/w3c/csswg-drafts/pull/2544) that he can use to regenerate the existing CSS 2.1 REC with 2016 updates.
That is, at this point it is likely easier (less work) to incrementally maintain the tool setup that @gsnedders has setup to build CSS2, than it is to do the work to change CSS2 to use Bikeshed.
My understanding is that @plinss is also able to run the CSS2 build tools, and even do so automatically on the server whenever a commit is made to the /css2/ directory to rebuild the spec accordingly.
PROPOSED: Automate and incrementally maintain existing CSS2 build tools instead of converting to use Bikeshed.
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.
That being said, even if/when CSS2.x normatively references CSS3 Syntax for the grammar (see related issue https://github.com/w3c/csswg-drafts/issues/2224), I would prefer to subset that, excluding scientific notation from CSS2.x.
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.
Thanks!
Tantek
cc: @astearns @atanassov
@gsnedders this looks good. I spot checked the 550(!!!) files changed and the diffs I saw were consistent with what I would expect with reverting to 2011 CSS2.1 REC with 2016 updates.
[css2] Should we add scientific notation to CSS 2.1?
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.
cc: https://github.com/gsnedders
Related to issue #2224
Labels:
css2,
Agenda+ F2F
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.
^1 https://www.w3.org/TR/CSS21/
^2 https://www.w3.org/Style/css2-updates/REC-CSS2-20110607-errata.html
^3 https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+is%3Aopen+label%3ACSS2
Guten Abend Berlin Freunden! Ich bin in deiner Stadt.
Here for @CSSWG meetings this week. LMK if you’re around and let’s hang!
(no idea how to search Twitter for friends/followings in Berlin so I can @-mention them)
went to Rock 'n' Roll Half Marathon San Francisco and finished in 2:23:31. My 11th half.
Beautiful day for #RnRSanFrancisco. Thanks Perry, Krissi, Ava, Henry for coming out early to cheer at mile 2, more #NPSF at 12, and Holly & Tony during mile 13!
https://igx.4sqi.net/img/general/width960/476_s4ROAFegTT3rpXq-r_-4h78OAjOjBAwVKRsK-nAn4x0.jpg https://igx.4sqi.net/img/general/original/476_s4ROAFegTT3rpXq-r_-4h78OAjOjBAwVKRsK-nAn4x0.jpg
https://igx.4sqi.net/img/general/width960/476_-Bv4ybCBwjN21gj5dzAZ72I6H9cu10AjFGlWfFZhIuc.jpg https://igx.4sqi.net/img/general/original/476_-Bv4ybCBwjN21gj5dzAZ72I6H9cu10AjFGlWfFZhIuc.jpg
https://igx.4sqi.net/img/general/width960/476_ShIo7yhAKZz1rTOO6j76rho4dwwAaoFSZ0GwEtaNY4w.jpg https://igx.4sqi.net/img/general/original/476_ShIo7yhAKZz1rTOO6j76rho4dwwAaoFSZ0GwEtaNY4w.jpg
https://igx.4sqi.net/img/general/width960/476_rxDvhNhGp5nQNk1Hbg76CHF4Xt-FjWd3-mY-nCzL1-8.jpg https://igx.4sqi.net/img/general/original/476_rxDvhNhGp5nQNk1Hbg76CHF4Xt-FjWd3-mY-nCzL1-8.jpg
25km last Saturday at #SFRC. Longest trail run yet. Climbed through the fog, watched it flow over the hilltops.
#latergram #fromwhereirun #run #trail #trails #trailrun #optoutside #getoutside #Marin #Miwok #fog #clouds
https://igx.4sqi.net/img/general/width960/476_76IlonZSdkz0OTzKLGuObE3X-DC1PFin5jWGpUBwlaI.jpg https://igx.4sqi.net/img/general/original/476_76IlonZSdkz0OTzKLGuObE3X-DC1PFin5jWGpUBwlaI.jpg
#FBF four years ago: finished my second half marathon, first half that I ran with my dad. 📷 Katy Kunkle
#runner #runners #halfmarathon #rnrhalf #rnrsf #rnrsf2014 #2014_096
2017 taxes done & reviewed. e-file authorizations signed, returns filed, acceptances confirmed. Expecting auto-deposit refunds in ~2 weeks. Took me longer this year than last.
That’s one major Q1 challenge wrapped up (a week into Q2).
Previously: tantek.com/2018/093/t3/last-numbers-for-taxes
Last year: tantek.com/2017/073/t1/2016-taxes-done, tantek.com/2017/062/t1/finished-taxes-with-accountant
Yesterday evening I gave my accountant the last numbers & calculations he needed for 2017 taxes. More complicated this year, took longer than last.
Best time to update your tax prep system is when doing final prep for the previous tax year. #2018_092
Taught my first two yoga classes of the year, outside in the late afternoon sun. Pleasantly surprised to see a few familiar faces. Now that the Sunday Presidio Picnic is back, I’ll be teaching there again as well starting April 22nd. Stay tuned!
This year’s first quarter went by very quickly.
It’s been good overall, though definitely with a few unexpected challenges. Have made some good changes, with a few more still in progress (that I had hoped would have been completed by now). Reflecting & writing up what was signficant so far this year. Hope to get to writing up the same for 2017 as well.
@rolandturner great post. Insightful, agreed on "two fronts".
Re: reduce use of Facebook, some steps: https://indieweb.org/Facebook#How_to_wean_yourself_from
Here’s also a page to help reduce appaccess to FB login, more: https://indieweb.org/appaccess
Reply sent from my indieweb site
https://igx.4sqi.net/img/general/width960/476_K_fQdk4--gvGXKhqPGn7_We4p3RxxN-XsLtG64CJ6VY.jpg https://igx.4sqi.net/img/general/original/476_K_fQdk4--gvGXKhqPGn7_We4p3RxxN-XsLtG64CJ6VY.jpg
https://igx.4sqi.net/img/general/width960/476_779WFoSZRRbQEOFtFoxZKZ-AKA76OtEOVKBxtwBfwN0.jpg https://igx.4sqi.net/img/general/original/476_779WFoSZRRbQEOFtFoxZKZ-AKA76OtEOVKBxtwBfwN0.jpg
Vivid dawn #colors seemingly from morning #trailrunning endorphins, yet captured in a photo #takenonipodtouch, #nofilter.
#NPSF #novemberproject #optoutside #getoutside #wakeupthesun #fromwhereirun #run #trail #runner #trailrun #runners #trailrunners #vanillasky #cottoncandysky #iwokeuplikethis #hillsforbreakfast #twinpeaks #doublehumps #pano #panoramic #takenonipodtouch6
1. #Dawn from the North "Eureka" Peak, panoramic from the Twin Peaks parking lot down to the South "Noe" Peak
2. #Sunrise from the Twin Peaks parking lot, panoramic from Angel Island to Candlestick Point
https://igx.4sqi.net/img/general/width960/476_rj-VU9lPHrSYeymo5TkylF7xTB5SCZtobteX7NZt5LU.jpg https://igx.4sqi.net/img/general/original/476_rj-VU9lPHrSYeymo5TkylF7xTB5SCZtobteX7NZt5LU.jpg
https://igx.4sqi.net/img/general/width960/476_QZi6VYqmjzJ_bFfbJuXnO-4xKRsYsPmH0mjzXnu5Xlk.jpg https://igx.4sqi.net/img/general/original/476_QZi6VYqmjzJ_bFfbJuXnO-4xKRsYsPmH0mjzXnu5Xlk.jpg
https://igx.4sqi.net/img/general/width960/476_RxpDGPGVPtgJ06Taicotp2Jxe5_yw1oUkubY5zisBck.jpg https://igx.4sqi.net/img/general/original/476_RxpDGPGVPtgJ06Taicotp2Jxe5_yw1oUkubY5zisBck.jpg
https://igx.4sqi.net/img/general/width960/476_7-XfkUu4NUGAvvgCqMw0R1xrNn7BT9Yzs98QeOSo4WU.jpg https://igx.4sqi.net/img/general/original/476_7-XfkUu4NUGAvvgCqMw0R1xrNn7BT9Yzs98QeOSo4WU.jpg
#TBT to #running #SFRC last Saturday, so much green, and so many #flowers blooming. Now it feels like spring.
1. Succulent flowers blooming near Rodeo Lagoon
2. Wall of eucalyptus trees on Bobcat trail
3. Rodeo Beach, surfers, Pacific Ocean
4. Started from the bottom now we’re here - on Hill 88 with a view of that same beach
13.5 miles, 2200' climbed.
#spring #flower #bloom #rodeo #lagoon #beach #ocean #hill88 #Marin #Marinheadlands #trailrun #trail #trails #getoutside #optoutside #Saturday #2018_083 #fromwhereirun #getsomesun #latergram #nofilter
Thanks for the @Summer_Ash link @ArielWaldman:
http://www.syfy.com/syfywire/star-stuff-what-did-mercury-ever-do-to-you
Even if retrogrades do happen frequently, presumably co-retrogrades (just made that up) with Mercury happen less frequently. Or at least an evergreen topic for short videos whenever it makes "the news".
Dear @NASA, please post something scientific about Mercury and Jupiter being in #retrograde ← see hashtag for why 😂
Dear @ArielWaldman, please post a video about the same on your channel: http://arielwaldman.com/projects/youtube/
#science #scienceplease
Back to #NPSF Double PR Wednesday! (since 2017-10)
34:51 #earlygang @ ~5:30
34:21 #normalgang @ ~6:30 (17s slower than Oct)
6hr+ sleep. Some coffee before going to Alta Plaza. Tough two sessions, felt good for day after track. No music.
Previously:
2018-02: DNF. 1 lap then stopped because I felt horrible.
2018-01: N/A. Out of town for NPSF hell week PR Wednesday.
2017-12: DNF. http://tantek.com/2017/362/t1/npsf-pr-wednesday-interrupted
2017-11: 37:14 http://tantek.com/2017/333/t1/npsf-pr-slower-weeks-of-races
2017-10: 34:26 + 34:04 http://tantek.com/2017/298/t1/npsf-double-pr-wednesday-tied-last-month
Still a few minutes behind last May's 31:35, and my all time PR 30:08 in 2015. Need to keep showing up for NPSF double-gang.
https://igx.4sqi.net/img/general/width960/476_Kb56944S3WrLeJXtvD0keD9y2_EVKWWDmSTHIDicX5Q.jpg https://igx.4sqi.net/img/general/original/476_Kb56944S3WrLeJXtvD0keD9y2_EVKWWDmSTHIDicX5Q.jpg
https://igx.4sqi.net/img/general/width960/476_lqQvMtYzHBOcc_5Ms0UCpESjosDceQ_m8t2H0FKW-qg.jpg https://igx.4sqi.net/img/general/original/476_lqQvMtYzHBOcc_5Ms0UCpESjosDceQ_m8t2H0FKW-qg.jpg
https://igx.4sqi.net/img/general/width960/476_vPrGL-2DHb9ZwQDZeSfzKbrYlb8QldynQOefqgUFeQQ.jpg https://igx.4sqi.net/img/general/original/476_vPrGL-2DHb9ZwQDZeSfzKbrYlb8QldynQOefqgUFeQQ.jpg
Back to #Track #Tuesday. Again. Thanks to #accountabilibuddy @micheleperras. Again. 1st photo 📷 @butteronadonut. #nofilter
Workout: 1600 progressive, 3x400 + 200 rests, 1200 + 400 rests, 2x800 + 400 rests
I did: WU jog/run, 5x400 + ~90 second stretch rest, abs, CD jog/run
It was particularly fun pacing (and keeping up with!) coach Nick on my 2nd to last 400 (his last lap) for a 1:35 (just a few sec slower than my Kezar lap PR).
#NPSF #Kezar #runners #novemberproject #tracktuesday #runner
6 weeks ago: http://tantek.com/2018/044/t1/back-on-track-tuesday
The list of possible VCP assembled output syntaxes was intended to be comprehensive. Thus ordinal ISO dates should be normalized to YYYY-MM-DD. The spec should be explicit about this since it appears parsers disagree.
Assembled dates must be normalized YYYY-MM-DD, because parsed output consuming code likely expects that, either way, simpler for JSON consuming code.
Can we improve h-entry backcompat to handle common WordPress hentry streams?
h-entry Parser Compatbility specifies typical hAtom hentry properties and how to consume them as h-entry equivalents. This appears to be insufficient for some common WordPress themes. We should investigate examples of WordPress blogs with hAtom to see if we can do better with additional hentry backcompat parsing.
h-entry has two proposed additions so far that we should validate with examples in the wild (that would be result in better parsed results with those additions)
time.entry-date[datetime] - parse as dt-published
rel=author - parse as u-author
Examples welcome of common / plain / modern WordPress home pages that currently fail to produce good hentry backcompat parsing results.
cc: https://github.com/aaronpk
Labels:
help wanted,
question
hosting Homebrew Website Club SF tonight @MozSF!
RSVP http://tantek.com/2018/080/e1
Special guest @aaronpk will demo his #IndieWeb reader setup!
https://aaronparecki.com/2018/03/12/17/building-an-indieweb-reader built on #openweb standards #WebSub #Microsub #microformats2 #IndieAuth #MicroPub #Webmention #Webhooks
There’s no such thing as free private #socialmedia.
Either
you pay for hosting your private data
or someone else pays to access it
or someone buys whole site, changes ToS (as you agreed to let them), does with your private data as they wish
#indieweb
Privacy Theater: Why Social Networks Only Pretend To Protect You:
https://techcrunch.com/2009/12/27/privacy-theater/
by @rohitkhare
From *2009*.
#ownyourdata on the #indieweb before #Facebook or #DeleteFacebook
@overcaffeinated @RodBegbie @waferbaby #indieweb folks choose that which meets needs eg:
https://eli.li/entry.php?id=20180314144847
#IndieAuth
#Micropub
#Webmention
#RSS
#Microformats
and https://twitter.com/ChrisAldrich/status/961794239163068416.
My site #hfeed #Atom. Simple building blocks enable evolving a plurality of approaches, features, tools: https://indieweb.org/plurality
Drop by and chat some time! https://chat.indieweb.org/
It makes sense to special case the [a-z] microformats2 class name segment requirement to allow numbers in vendor prefixes, since there are existing vendor/product names with numbers, e.g. (made up examples with actual (past) vendor/product names)
h-6prime-rev
p-p3k-special
u-revision3-source
As I wrote in http://tantek.com/2018/079/t2 (https://github.com/microformats/microformats2-parsing/issues/30#issuecomment-374784404), the 'type' array must not convey any ordering semantics from the source (thus it must enforce an artificial order that does not convey anything, in addition to uniqueness per set requirements). All other uses of arrays in the parsed JSON output (children, property values, rel subarrays) already convey appropriate document order semantics.
Since HTML 'class' and 'rel' attributes are defined as unordered sets, we must preserve that semantic across any parsing transformations, in order to avoid introducing meaningless noise like artificial ordering which could accidentally cause a consuming application to erroneously infer and depend on such.
The parsing spec must require uniqueness in the 'type' array accordingly, and since JSON arrays do have a defined ordering (whether you want it or not), the best we can do is to define a canonical ordering that does not imply anything about the unordered source, such as alphabetical ordering of unique h-* classnames.
For 'rel' attributes, the spec http://microformats.org/wiki/microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats already says the right things for treating them as sets, and notably does preserve source order in the URL sub-arrays for each rel key, which is intentional.
Consecutive dashes were never intended in microformats2 class names, only as separators between [a-z] segments per original microformats naming principles: http://microformats.org/wiki/naming#Some_Details
I’ll make edits to capture this succinctly along with issues #27-30 (comments forthcoming), assuming no objections.
[css-color][css-color-3] Needs header link to Editor’s Draft
As is common convention in our modern specs, the header section needs a link to the CSS Color Level 3 Editor's draft (however that draft itself needs regenerating, it says "Editor's Draft 7 July 2014" currently).
https://github.com/kartikprabhu Yes this also changes backcompat for hCalendar, 'description' would be interpreted as 'p-content' for h-event.
https://github.com/gRegorLove yes try updating the consuming code to prefer 'content' over 'description' and see if everything still works. We may have to deprecate (rather than completely remove) 'p-description'. See how the consuming code update goes, and then see how much trouble it would be to update to publishing 'content' instead of 'description'.
Replace h-event 'description' with 'content' property
Splitting off from
issue 2: it appears most (nearly all?) currently published h-event posts are using "content" (adopted from h-entry) instead of "description" (from mf1 hCalendar).
Should we drop "p-description" and replace it with "e-content" in h-event? (before transitioning h-event from Draft to Specification)
Are there any h-event (mf2, not backcompat mf1) consuming applications that depend on 'descripton'?
Are there any h-event (mf2, not backcompat mf1) publishers that only publish 'description' and not 'content'?
Problem: while CSSWG drafts link to their test suites, it is far too hard to figure out how to review & report problems with existing tests, and how to contribute new tests. We need usable test suite documentation, and should consider at a minimum having our specs directly link to where to file test suite issues.
The WG wiki page on tests is horribly out of date, as are nearly all its subpages. And links to the "Web Platform Tests" site land you at pages so opaque that it is unclear if you’ll have to guess correctly and click 3 or 30 nested links to find out where to give feedback or contribute tests. I made some bandaid fixes to that WG wiki test page with a direct link to issues and also to Rachel Andrew's excellent post Christmas Gifts for Your Future Self: Testing the Web Platform, but that wiki page as a whole needs to be completely rethought and rewritten.
Since having valid (reviewed) tests for a feature is required for that feature to exit CR, and missing such tests (or being unsure of them) is often something that blocks CSSWG drafts from progressing, this issue should remain open here (perhaps as a meta issue) until sufficient solutions are found / deployed that demonstrate increased feedback and contributions to test suites for CSSSWG specifications. (When people wonder why aren’t more web developers contributing or giving feedback on CSS tests, the poor usability barriers of these docs alone are a likely sufficient explanation, and thus a good place to start fixing.)
This issue directly affects all current CSSWG drafts at CR or earlier stages that are being developed in this repo and which we want to eventually (preferably efficiently) advance to PR. Thus please leave this issue open here in this repo for the CSS Working Group to resolve (rather than say, attempting to lump it or transfer it into some broader "Web Platform Tests" issue). Some more background: issue 2378
Remote participating in the @W3CAB meeting in China meant staying up til ~26:30 (2:30am) the past two nights. On the bright side, I could still access Twitter & GitHub URLs as needed for discussions.
Now for a circadian reset. #openweb #2018_071 #2018_072
So grateful. This year I shared roughly this with a few friends:
Pursue things that bring you joy. Recognize those doing the same, keep them close.
And afterwards this came to mind:
These things are not the easy things: indulging appetites, consumption (drinking, eating, watching, listening). Do not mistake stimulants for joy. Background for foreground. Punctuation for words.
These things are the harder things, that require work, discipline, practice, persistence. Work that sometimes means pushing physical limits, sometimes enduring physical discomforts, or harder, facing internal discomforts, frustration, fear, self-doubt, plateaus, regressions, solitude. In those moments, in that discomfort, alone, your choices may bring self-knowledge.
That process, not its fruits, brings joy. Showing up, doing, moving, creating, making, sharing. Find those things that bring you joy, and those that persist in those practices. See them and let them see you.
Apparently there are plenty of dimmable, auto-shutoff LED desk lamps on amazon.com; don't need IoT or special bulbs. Just got a 5W model with adjusable color temp & 1h/2h auto-shutoff.
Thanks mom & dad! cc @uniondesign @malexander1219
I want a nice bedside lamp just bright enough (dimmable?) for reading that is easy to tap/switch off (auto-timeout would be nice), because I’d rather fall asleep reading a book than a backlit display. Anyone have such a lamp they really like?
going to Yoga Philosophy 40-Hr Workshop by Lauren Pisano @lovestoryyoga starting tomorrow morning for four days.
A year ago I was just days into #YTT @YogaFlowSF. Feels about time for another deep dive.
http://www.lovestoryyoga.com/events-calendar/yogaphilosophyimmersion
hosting Homebrew Website Club SF tonight @MozSF
https://indieweb.org/events/2018-03-07-homebrew-website-club
Starting writing hour with some work on in-stream reply-contexts.
https://indieweb.org/reply-context#Minimal_text_reply_contexts
Thanks. Submitted a minimal suggested improvement here:
https://github.com/w3c/csswg-w3ctestlib/pull/1
So at least folks looking to provide feedback on specific test files will have a chance of finding the place to do so.
https://github.com/martinthomson wrote:
> that covers more than just query()
In that case, shouldn’t we re-open https://bugzilla.mozilla.org/show_bug.cgi?id=1105827, and file new dependent bugs for what is not yet implemented / covered?
https://github.com/dbaron wrote:
> hesitating about the bug URLs, because I'm a little hesitant to drive traffic to bugs
Makes sense. Worth adding to this project readme/how-to officially? As in something like:
“The mozBugUrl field should only be filled in for "worth prototyping" or "important" standards, to avoid misdirecting higher-level discussion traffic to the bugs, which should be focused on implementation-specific discussions.”
t