Tantek Çelik

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

💬 👏
  1. 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

  2. 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

  3. 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.

  4. 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

  5. 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
    ^3 tantek.com/2018/098/t1/rock-n-roll-half-marathon-finished

  6. 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

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

  8. 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.

  9. 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.

  10. 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.

  11. 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!

  12. 👍

  13. 👍

  14. 👍

  15. 👍

  16. 👍

  17. 👍

  18. 👍

  19. 👍

  20. 👍

  21. 👍

  22. 👍

  23. 👍

  24. 👍

  25. 👍

  26. 👍

  27. 👍

  28. 👍

  29. 👍

  30. Three ~9hr days of @CSSWG meetings and we still had agenda items remaining:
    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/

  31. 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

  32. 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.

  33. @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.

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

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

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

  37. 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.

  38. @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.



    cc: @astearns @atanassov

  39. @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.

  40. [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: @gsnedders
    Related to issue #2224
    Labels: css2, Agenda+ F2F

  41. Was just told by @cssrossen that I’m the last remaining (in name) editor^1 of #CSS 2.1 @CSSWG, or “Last of the Mohicans” as he put it (not sure how I feel about the comparison). In practice, @fantasai has been editing 2.1. And @gsnedders volunteered too. I think Rossen just wants to assign 2.1 errata^2 issues^3 to me^4.

    ^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
    ^4 http://www.w3.org/Style/CSS/Tracker/actions/871

  42. 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)