#microformats 2018-09-17

2018-09-17 UTC
gemelen4 and queue-tip20 joined the channel
#
queue-tip20 Allah is ԁoіng
iLogic20, barpthewire, KartikPrabhu, aksnowman and ^Tempest joined the channel
#
^Tempest Allah іs ԁoing
[jgmac1106], vivus, barpthewire, [deeden] and justin-29 joined the channel
#
justin-29 Allɑh is doiᥒg
indy, jmac, [jgmac1106], [eddie], barpthewire, jackjamieson, mdo0, KartikPrabhu, Blaxar21, [kevinmarks], jackjami_ and jamesrichardson1 joined the channel
#
jamesrichardson1 Αllah is doiᥒg
#
@onasusweb Pourquoi les microformats sont importants pour la SEO #ecommerce #prestashop #seo #php #webdev #symfony #vuejs #css #javascript #git #woocommerce #opencart #magento https://www.onasus.com/pourquoi-les-microformats-sont-importants-pour-la-seo/?utm_source=ReviveOldPost&utm_medium=social&utm_campaign=ReviveOldPost (twitter.com/_/status/1041751091875139585)
[jgmac1106], jackjamieson, dougbeal|mb1, [eddie], boogy16, [christophe], tantek__, KartikPrabhu, tantek, echarlie, bronzehedwick3, tjsimmons7, AimHere11, boxrick17, Guest66878, josecapurro7 and [kevinmarks] joined the channel
#
tantek__ greetings microformatters
#
tantek__ what no +v Loqi?
gRegorLove joined the channel; gRegorLove left the channel
#
gRegorLove tantek, should have voice now
#
tantek__ trying again
#
tantek__ interesting
#
tantek__ we have made very good progress on https://github.com/microformats/microformats2-parsing/issues/2 - rough consensus on https://github.com/microformats/microformats2-parsing/issues/2#issuecomment-392608361 , an implementation, and yet I think we still need test cases for verification, plus worth discussion text alternative content in audio, video, etc.
#
Loqi [aaronpk] #2 image alt text is lost during parsing
#
tantek__ Like we could say, solving propagating img alt by itself is ok and we should adopt this proven solution (add test case, change spec)
#
tantek__ or we could continue iterating, specifically test what/how text alternatives are provided for <audio> <video> elements, and see if that can merit a similar solution, or if they need a completely different solution
#
gRegorLove Re: "need test cases for verification" do you mean more real-world tests? We have these constructed tests in mf2py https://github.com/microformats/mf2py/blob/cfb3ef5972c7a6065b39df04183d4d9e2ddd78d8/test/examples/experimental/img_with_alt.html
#
tantek__ here is another example to consider: iframe (which is in the mf2 parsing spec)
#
tantek__ specifically, should we treat "title" on an iframe as the text alternative per https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#Accessibility_concerns ?
#
gRegorLove And snarfed linked a real-world example with Bridgy publish http://jgregorymcverry.com/6851-2/
#
Loqi [Greg McVerry] My last step in the great Feed rebuilding. Adding all the blogs I curated on my following page https://jgregorymcverry.com/following  to https://aperture.pk3.io http://jgregorymcverry.com/wp-content/uploads/2018/09/Screen-Shot-2018-09-16-at-7.58.37-AM-300x184.png
#
tantek__ OR should we keep such "smarts" out of the parser and "merely" pass along the 'title' attribute in a similar structure (could be an orthogonal issue)
#
tantek__ the precedent for this is that we already have "smart" 'title' attribute handling for e.g. <abbr>
#
tantek__ so it would be reasonable to treat the 'title' attribute on iframe as it's "alt" property
#
tantek__ especially given the accessibility documentation https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#Accessibility_concerns
#
tantek__ not finding good docs on how to provide text alternatives for <audio> and <video> and <object>, I'm willing to postpone those for now
#
tantek__ the higher level challenge I'm trying to figure out is, is there a way to *consistently* provide text alternatives for URL based properties, regardless of what element they came from?
#
[kevinmarks] Aren't the text alternatives whatever is inside the tags?
#
gRegorLove +1 for splitting those into separate issue(s)
#
tantek__ gRegorlove - it makes it potentially harder (more work) for consuming code to consistently text alternatives across media types
#
tantek__ I am wondering if we can do a little bit more work up front (parsing spec, mf2 parsers) to make it easier for all mf2 consuming code to write more accessibility friendly support
#
tantek__ I feel like the potential win there is big enough to merit some up front thinking on our part
#
tantek__ because "easier for all mf2 consuming code to write more accessibility friendly support" = likely more mf2 consuming code that provides accessible content
#
tantek__ e.g. think of all the Microsub readers (especially those that have yet to be written)
#
tantek__ kevinmarks, the short answer to your question in the global case is "no".
#
tantek__ the more precise answer requires answering element by element because they (audio, video, iframe, object) treat "whatever is inside the tags" differently
#
tantek__ and in only *one* case (object) does a *subset* of what is inside the tags (ignoring any param elements) possibly constitute a text alternative
#
gRegorLove Not sure I follow exactly (attention is a bit distracted), but it sounds like different issues since the img alt one was about changing the parsed structure
#
tantek__ for audio and video, what is inside the tags is content to use in case the browser has no support for those tags at all, which is different from a "text alternative"
#
tantek__ gregorlove, yes now that we have figured out an improved parsed structure that works for img alt, the question is, can we *re-use* that *same* parsed structure for say iframe title, so that consuming code can be simpler for handling the "text alternative" for an img or iframe
#
tantek__ the (one specific incremental improvement) question
#
tantek__ (audio, video, object require more thinking)
#
gRegorLove Gotcha
#
tantek__ gregorlove I think you are right in that creating a separate issue (for those) could make it easier to iterate on their design / brainstorming asynchronously, with full knowledge of the accepted solution for img alt, in the hopes that we can re-use the same solution
#
tantek__ perhaps we can at least start with iframe title since that seems like it should map directly into the same "value" and "alt" properties solution in the JSON
#
tantek__ audio and video I'm not sure of the recommended way to provide a text alternative (short of a full transcript), so perhaps they need their own issue just to track the question
#
tantek__ object is more well defined in that regard, but more complex as well. *one* way of authoring an object with text alternative is to put the text inside, like <object>text alternative goes here</object>
#
tantek__ there is a rough example of that on my home page (view source on tantek.com and look for <object )
#
tantek__ but one can also do <object ...><img src=... alt="text alternative" /></object> in which case "text contents" of object would be ""
#
tantek__ and any depth of <object><object><span><object><img src=... alt="text alternative"/></object></span></object></object>
#
gRegorLove Agreed, looks like iframe[title] maps well to img alt
#
gRegorLove Speaking of iframe, should we consider iframe[title] when parsing a p- property? Not currently on http://microformats.org/wiki/mf2p#parsing_a_p-_property (and I don't know of examples)
#
tantek__ likely yes
#
tantek__ I don't know of any examples either, however given that this approach is prescribed by MDN for text alternative for accessibility, I am more willing to consider specifying it in the absense of specific examples
#
tantek__ it is also compatible with the general use of the 'title' attribute on elements so that makes it feel ok (not risky) to do