Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parse iframe[title] as structure #42

Open
gRegorLove opened this issue Sep 18, 2018 · 2 comments
Open

parse iframe[title] as structure #42

gRegorLove opened this issue Sep 18, 2018 · 2 comments

Comments

@gRegorLove
Copy link
Member

@tantek pointed out that #2 is making good progress and we might be able to extend this to parse text alternatives for other elements like iframe, audio, video, object, and maybe source.

This issue is specifically for iframe, since providing a text alternative in the title attribute is well-documented on MDN.

my meta point is that regardless of which of those HTML methods you used, if you put a u-photo (or u-featured etc.) on them, and get a URL as a "value", then ideally you would get the text alternative in the "alt", regardless of how each of those specific elements says to markup the text alternative. we seemingly have this figured out for img[alt] and iframe[title], but not the others
-- @tantek, https://chat.indieweb.org/microformats/2018-09-18#t1537233694363900

My understanding of the issue would result in this spec update, copied from #2 (comment):


Add a new section with title "parse an iframe element for src and title" with the steps:

  • if iframe[title]
    • return a new {} structure with
      • value: the src attribute of the iframe as a normalized absolute URL, following the containing document's language's rules for resolving relative URLs (e.g. in HTML, use the current URL context as determined by the page, and first <base> element, if any).
      • alt: the title attribute of the iframe
  • else
    • return the src attribute as a normalized absolute URL, following the containing document's language's rules for resolving relative URLs (e.g. in HTML, use the current URL context as determined by the page, and first <base> element, if any).

@jgarber623
Copy link
Member

jgarber623 commented May 12, 2020

A few quick questions on this one:

  1. Are there in-the-wild examples of anyone marking up an <iframe> with a root or property class name and a title attribute?
  2. If we add this title parsing change, would it make sense to more broadly apply it to any element with either a root or property class name and a title attribute?
<a href="https://sixtwothree.org" class="h-card" title="Welcome to my website!">Jason Garber</a>
{
  "type": ["h-card"],
  "properties": {
    "name": ["Jason Garber"],
    "url": [
      {
        "value": "https://sixtwothree.org",
        "title": "Welcome to my website!"
      }
    ]
  }
}

…an actual value-title pattern. 😂

Edit:

Thinking more about my suggest above, how would my suggestion interact with something like…

<div class="h-card">
  <span class="p-name">Jason Garber</span>
  <img src="https://assets.sixtwothree.org/jgarber.png" class="u-photo" alt="A photo of the author with wild eyes and mouth agape" title="My default avatar!">
</div>

Maybe as…

{
  "type": ["h-card"],
  "properties": {
    "name": ["Jason Garber"],
    "photo": [
      {
        "value": "https://assets.sixtwothree.org/jgarber.png",
        "alt": "A photo of the author with wild eyes and mouth agape",
        "title": "My default avatar!"
      }
    ]
  }
}

@jgarber623
Copy link
Member

☝️ I'm not sure I support my own suggestion in the second bullet point. The title attribute is global, very generic, and likely used to include all manner of unhelpful text in non-immediately-visible markup.

Whereas the title attribute on an <iframe> (or an <abbr> to use another example) has a stronger coupling between the attribute, its value, and the element.

So I just managed to talk myself out of bullet point two.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants