tantek.com

t

  1. Good times this morning guest co-leading the Monday morning #NPSF workout with pal Dena in the Santa suit here: https://www.instagram.com/p/BrxxqAdB4-v/

    Previously: 2017-149 @Nov_Project_SF https://november-project.com/buck-plz/

    on

  2. @abritinthebay there are a couple of open source Javascript #microformats2 parsers:
    http://microformats.org/wiki/microformats2#Javascript

    Try them out and definitely file any issues you find, and/or join us in discussion: http://microformats.org/wiki/discuss

    on

  3. #microformats2 parsing spec updated: http://microformats.org/wiki/index.php?title=microformats2-parsing&diff=66956&oldid=66955
    * u- parsing should always do relative URL resolution per https://github.com/microformats/microformats2-parsing/issues/10
    Implemented in current versions of parsers:
    * phpmf2
    * mf2py
    * microformats go

    on

  4. Resolution: proposal accepted.

    No objections in above discussion, and positive opinions (đź‘Ť) from several implementors on the proposal.

    Proposal implementations in mf2py and microformats go parsers is sufficient to demonstrate implementability and interoperability (with updated tests cases), all as noted/linked in issue thread.

    Editing specification accordingly.

    on

  5. #microformats2 parsing spec updated: http://microformats.org/wiki/index.php?title=microformats2-parsing&diff=66955&oldid=66898&rcid=103842
    * implied photo property restricted similar to implied url property per https://github.com/microformats/microformats2-parsing/issues/21
    Implementations:
    * mf2py (current version)
    * phpmf2 patch pending: https://github.com/microformats/php-mf2/pull/210

    on

  6. Resolution: proposal accepted.

    No objections in above discussion, and positive opinions (đź‘Ť) from three implementors on the proposal.

    Proposal implementation in mf2py per https://github.com/microformats/mf2py/issues/135 is sufficient to demonstrate implementability.

    Editing specification accordingly.

    on

  7. This is a misintepretation of the backcompat portion of the spec.

    Everything in the compat rules means “look for”.

    In this case, “author - including compat root vcard in the absence of h-card” means to look for an “author” class name, *including* looking for a “vcard” class name on the same element, only if there is no “h-card” class name on the same element.

    Thus yes, according to the spec, the code snippet:

    <span class="author">Tom Morris</span>

    Inside an hentry as noted above must be treated like:

    <span class="p-author">Tom Morris</span>

    And thus in the parsed JSON it becomes a simple "author": ["Tom Morris"] as noted as a “preferable result”.

    If you can suggest wording that would help clarify this in the spec, I would be happy to make an editorial change to make this more explicitly clear (as well as similar for h-event location).

    on