Tantek Çelik

Inventor, writer, teacher, runner, coder, more.

💬 👏
  1. Ran #BayToBreakers 2018 Bonus 15k in 1:46:11! Slower pace than last year, but longer distance.

    ~3.5 min slower than the Hot Chocolate 15k: http://tantek.com/2018/007/t2/finished-hot-chocolate-15k

    Last year: http://tantek.com/2017/142/t1/beautiful-day-people-baytobreakers

    on
  2. The @W3CAB is now actively tracking @W3C Process issues in public @GitHub https://github.com/w3c/w3process/issues e.g. we recorded a consensus today: https://github.com/w3c/w3process/issues/190#issuecomment-389439047
    This is a new level of #OpenAB transparency, working in the open in real time (when we can)

    on
  3. 👍 to a comment on issue 190 of GitHub project “w3process”

    on
  4. 👍 to a comment on issue 190 of GitHub project “w3process”

    on
  5. 👍 to issue 190 of GitHub project “w3process”

    on
  6. 👍 to a comment on issue 60 of GitHub project “w3process”

    on
  7. 👍 to a comment on issue 60 of GitHub project “w3process”

    on
  8. 👍 to a comment on issue 60 of GitHub project “w3process”

    on
  9. 👍 to a comment on issue 60 of GitHub project “w3process”

    on
  10. 👍 to a comment on issue 60 of GitHub project “w3process”

    on
  11. 👍 to a comment on issue 60 of GitHub project “w3process”

    on
  12. 👍 to a comment on issue 60 of GitHub project “w3process”

    on
  13. 👍 to a comment on issue 60 of GitHub project “w3process”

    on
  14. 👍 to a comment on issue 60 of GitHub project “w3process”

    on
  15. 👍 to a comment on issue 60 of GitHub project “w3process”

    on
  16. 👍 to a comment on issue 60 of GitHub project “w3process”

    on
  17. ↪ In reply to tantek.com’s post #W3CAC and one more overview:
    @tidoust on @W3C Strategy https://www.w3.org/2018/Talks/ac-slides/intro/strategy-2018.pdf

    on
  18. #W3CAC two more great overviews:
    @koalie on @W3C Marketing & Communications https://www.w3.org/2018/Talks/cm-ac2018-marcomm/
    @torgo on @W3C Technical Architecture Group (TAG) @W3CTAG  http://slides.com/torgo/tag-update-acberlin-05-2018

    on
  19. In #Berlin 🇩🇪 @W3C Advisory Committee meeting (#W3CAC) as a member of @W3CAB, sitting next to @torgo, listening to @jeff_jaffe’s intro, and @plhw3org’s projects update: https://www.w3.org/2018/Talks/ac-slides/project-intro/ (more links inside)

    on
  20. ICYMI: @Mozilla Manifesto addendum on inclusivity, civil discourse, dignity, individual expression, critical thinking, reasoned argument, shared knowledge, verifiable facts, diverse communities, common good:
    https://blog.mozilla.org/blog/2018/03/29/mozilla-marks-20th-anniversary-commitment-better-human-experiences-online/ by @MitchellBaker

    on
  21. Define "Grace Period" and "can reasonably assume are still a part of the web platform", W3C REC? CR? WPT tests with 2+ browser interop?

    The Confluence Metrics graphs are quite interesting! It would be great if the "Grace Period" could be better defined, in particular, how do you qualify the start of a grace period?

    Is it when the defining standard reaches a certain level of document maturity? E.g. W3C Recommmendation or at least Candidate Recommendation?

    Or given the qualification "can reasonably assume are still a part of the web platform", is it based on there existing some number of Web Platform Tests for the API, and 2+ browsers passing them (in the same way)?

    Either way it would be great to have a (at least somewhat) measurable / objective criteria, especially since the graphs make it look like the data is quite precise.

    Thank you for providing such a great resource!

    on
  22. ↪ In reply to a comment on issue 56 of GitHub project “wg-effectiveness” I should have said prioritized for rather than tailored to.

    I agree with your stated goal and scope of "make the process doc easier to understand for all W3C stakeholders". The current content certainly helps with that goal, and I am hoping that re-ordering the content as I am suggesting would help even more.

    I stand by the title suggestion: W3C Process Document for Busy People should start with how to make specs

    I believe this will serve all W3C stakeholders as you described, and here is why (additional thinking compared to initial issue description).

    (I wrote a version of this shortly after this morning’s meeting in IRC, and will repeat here to help move this forward.)

    The very name of "Process Doc for Busy People" implies that *time* (or lack of it - being busy) is the prime priority (saving time in particular) and design center of the document.

    Thus beyond *who* it is for, if we recognize that some things in the process happen far more often (and thus require referring to the process more frequently) than others, we can take that prime priority of saving time, and implement it by ordering process section by frequency of use, thus saving more people more time more often, since they will take less time to find their more frequent uses.

    E.g. iterating on specs happens more often than AC votes on transitioning specs happens more often than AC votes on WG (re)charters happens more often than votes on TAG/AB elections, happens more often than host agreement(s) being iterated, happens more often than change of Director. (illustrative, not exhaustive list)

    This is roughly similar to (though not the same as) the order I initially listed, yet this updated thinking is based on more objective criteria.

    Thank you for the invitation to raise a PR.

    If this line of thinking (ordering sections by frequency of use, most to least) sounds appealing, I can work on a new explicit section list order accordingly, and presuming that has consensus, can work on a pull request for it, all while maintaining the narrative style so the whole document still flows well.

    on
  23. 👍 to a comment on issue 42 of GitHub project “wg-effectiveness”

    on
  24. 👍 to issue 2588 of GitHub project “csswg-drafts”

    on
  25. a 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

    on
  26. Homebrew Website Club SF — Special 502 Bad Gateway Edition!

    When: Where: Mozilla San Francisco Host: Tantek Çelik

    17:30: Optional writing hour and quiet socializing
    18:30: IndieWeb demos and hack night!

    Homebrew Website Club retro 1980s-style logo

    What is HTTP 502 and what does a “Bad Gateway” really mean? Why do web servers return it, or do they? Does anyone really want a bad gateway?

    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!

    Any questions? Ask in #indieweb Slack or IRC

    More information: IndieWeb Wiki Event Page

    RSVP: on the Facebook event or post an indie RSVP on your own site in response to this indie event!

    on
  27. Wong: “How’s your Sanskrit?”
    Doctor Strange: “I’m fluent in Google translate.”

    If only Google Translate supported #Sanskrit, nevermind Vedic classical Sanskrit, in 2016 or now.

    Would have used it in #YTT, Yoga Sutra studies.

    #doctorstrange

    on
  28. RSVP yes to: a Facebook event 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

    on
  29. 👍 to issue 2589 of GitHub project “csswg-drafts”

    on
  30. 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.

    Modest proposal: start with W3C Recommenation (Technical Report) Flow: The "Recommendation Track" — that diagram is key and perhaps the most referenced thing (second perhaps is the Modifying a W3C Recommendation diagram and section). Include all the material up through just before Communication.

    Everything else, e.g. W3C Groups, TAG, AC, AB, Leadership section should all follow from there.

    Label(s): Process

    on
  31. a jpg. a 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

    on
  32. ↪ In reply to tantek.com’s post 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.

    on
  33. Enhancement: Bridgy Publish to GitHub should POSSE tag-of posts to add labels to issues

    Problem: Currently you have to use GitHub’s web UI to add (and remove) labels from issues.

    The indieweb has nascent 'tag-reply' post type using 'u-tag-of' markup. See this minimal set of markup inside an h-entry.

    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.

    Label(s): publish

    on
  34. a 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

    on
  35. 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.

    Label(s): publish

    on
  36. 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.

    on
  37. ↪ In reply to issue 10 of GitHub project “microformats2-parsing” 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.

    on
  38. ↪ In reply to issue 10 of GitHub project “microformats2-parsing” 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.

    on
  39. ↪ In reply to issue 9 of GitHub project “microformats2-parsing” 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.

    on
  40. Homebrew Website Club SF — Special 418 Tea Time Edition!

    When: Where: Mozilla San Francisco Host: Tantek Çelik

    17:30: Tea time — in celebration of HTTP 418
    18:30: IndieWeb demos and hack night!

    Homebrew Website Club retro 1980s-style logo

    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!

    Any questions? Ask in #indieweb Slack or IRC

    More information: IndieWeb Wiki Event Page

    RSVP: post an indie RSVP on your own site in response to this indie event!

    on
  41. 👍 to a comment on issue 175 of GitHub project “dom”

    on
  42. 👍 to a comment on issue 175 of GitHub project “dom”

    on