Tantek Çelik

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

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

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

  3. Happy first day of spring!

    Time for some spring cleaning.
    * Delete apps you’re not using
    * Delete accounts you don’t need

    * https://boffosocko.com/2018/03/19/facebook-app-purge/
    * https://indieweb.org/delete_your_account

    See and use:
    * https://indieweb.org/appaccess

    Add yourself to:
    * https://indieweb.org/app-quits
    * https://indieweb.org/silo-quits

  4. There’s no such thing as free private #socialmedia.

    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


  5. Privacy Theater: Why Social Networks Only Pretend To Protect You:
    by @rohitkhare

    From *2009*.

    #ownyourdata on the #indieweb before #Facebook or #DeleteFacebook

  6. @overcaffeinated @RodBegbie @waferbaby #indieweb folks choose that which meets needs eg:
    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/

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


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

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

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

  11. [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).

    We need to update the Editor's draft source with a link to the viewable Editor's Draft, and then regenerate the Editor's draft Overview.html.

    Labels: css-color-3, Needs Edits

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

  13. 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'?

    cc: @kevinmarks @Zegnat @aaronpk @martymcguire

  14. Homebrew Website Club SF!

    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

    Topics for this week:

    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!

  15. CSSWG specs need usable test suite docs

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

    cc: @gsnedders @liamquin @atanassov @astearns

    Labels: wg-css, PR-blocker

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