#microformats 2019-11-13

2019-11-13 UTC
[chrisaldrich], KartikPrabhu, [jgmac1106], [snarfed], [KevinMarks], [bradleyallen], matschafferDisco, jacky, [LewisCowles], jeremycherfas_, asymptotically, tiupyu, [fluffy], M2colorDiscord[m, [Rose], [tonz] and [tantek] joined the channel; mblaney and M7022[m] left the channel
#
[tantek] that would be good!
[Yulia], jeremycherfas, tiupyu, [manton], poofDiscord[m], KartikPrabhu, gRegorLove, bitwinery, [schmarty] and [tonz] joined the channel
#
[tonz] A friend posted this in response to me posting about travel. https://ruk.ca/content/marking-blog-posts-carbon-emissions-data He suggests adding data to implicit statements like “today I went to Brussels” to indicate e.g. mode of travel or a value for the connected emissions. Anyone here who added data like that? Or other types of data, in a similar way as additional information layer to statements. I mean it’s not markup to help machines re
#
[tonz] it is adding data that isn’t explicit in the text itself, more a sublayer.
#
Loqi [Peter Rukavina] Marking up blog posts with carbon emissions data
[tantek], [tonz] and GWG joined the channel
#
[tantek] [tonz] I'm interested in citations for the methods of computation of carbon per method of travel, both for methods in general (train, car, bike, walking) and specific (TGV, Prius specific model, hybrid Trek commuter bike, walking with Nike shoes of a specific model)
#
[tantek] similarly for airlines / aircraft / distances / legs
#
[tantek] I have a feeling the variance is high enough that any general thing like "air travel is x kg carbon / mile" etc. is widely inaccurate
[dougbeal] joined the channel
#
[tantek] especially trains electric vs diesel etc. similarly busses. and different city subways are likely wildly different in energy consumption / carbon emissions. nevermind different (newer vs older) lines in one city e.g. London Jubilee vs Circle
#
[tantek] all of that IMO is *much* more important to discuss, figure out, and cite, than the "marking up" step
#
[tantek] sigh, also on a technical level please don't use data-* attributes for this
#
[tantek] adactio already debunked this like last week or so
#
[tantek] and took Google to task for attempting to propose data-* attributes for a bunch of new nonsense
[chrisaldrich] joined the channel
#
[tonz] I tried out http://www.ecopassenger.org/ just now as my friend linked to it in the posting above. For trains it allows one to indicate the energy production mix involved. Standard it seemed to use the production mix for the countries involved, but for my trainride I could indicate the ‘railroad production’ mix which is interesting, and correctly concluded that Dutch trains all run on renewable production.
#
[tantek] wow bin/query.exe
#
[tantek] ok this seems like a reasonable attempt at accuracy and thoroughness: http://ecopassenger.hafas.de/bin/help.exe/en?L=vs_uic&tpl=methodology
#
[tantek] only challenge is how they will keep it up to date, since it's based on a static snapshot
#
[tantek] that is already three years old now: http://ecopassenger.hafas.de/hafas-res/download/Ecopassenger_Methodology_Data.pdf
#
[tantek] so like anything in microformats, content first, markup later (if ever)
#
[tantek] better to just start publishing the information in clear text first, and start documenting examples of that on the/a wiki
#
[tantek] only by collecting such examples IRL might there develop enough understanding to start figuring out appropriate markup to express it, and frankly, to see if anyone has shown any interest in building consuming/parsing tools. if no even interest in the latter, then it makes no sense to go design/burden people with markup
#
[tantek] e.g. reason 1 is good: " documenting the climate impact of travel could be helpful in understanding more" <-- but only requires content, no markup
#
[tonz] do you have the link to adactio’s posting somewhere handy? otherwise I’ll search
#
[tantek] and reason 2 has been shown to be false by experience
#
[tantek] this kind of reasoning: "could prove a useful data surface, and could spur the development of browser-based tools" is what lots of people (myself included) used as justification for developing and using LOTS of microformats back in the mid-2000s, and only a tiny fraction of those were every actually realized, for all the effort that went into inventing things marking things up.
#
[tantek] all the "could ..." stuff is too aspirational and insufficient reasoning for markup
#
[tantek] so we don't do that any more. instead we wait for actual builders of such things to show *active interest* in the/a community, and then discuss *their* specific use-case, not the imagined aspirational "could do (insert magical results here)"
#
[tantek] adactio's postings debunking the Google proposal to use data-* attributes for information / annotation start here: https://adactio.com/notes/16037
#
[tantek] you may need to view the Twitter copies to see full threading
#
[tantek] threading is hard
#
[tantek] Also, JS devs have a bad habit of jumping to (ab)using data-* attributes instead of the proper HTML, so it's always a good idea to pushback on any use / proposal for using data-* attributes http://simplyaccessible.com/article/data-attributes/
#
[tonz] thanks
#
[tantek] no worries!
[tantek], [benatwork], [jgmac1106], [schmarty], [grantcodes], jeremycherfas, [LewisCowles], mblaney and [bradleyallen] joined the channel; gray00Discord[m] left the channel