At a minimum, it should probably be embedded in a sandboxed iframe.
Just taking a screenshot, and linking to the tweet, seems like a more robust solution, that won't randomly stop working, and doesn't have the same privacy issues.
When I started blogging again, I wanted to render my Twitter feed on the homepage, as a sort of bitesize alternative to the regular content, but I too have a deep aversion to allowing external scripts on my websites. So I added some code to my Hugo theme that pulls the tweets from my profile via the Twitter API and renders them statically.
That of course still leaves open the matter of whether/how you're making sure to trigger a new build for every new tweet.
> That of course still leaves open the matter of whether/how you're making sure to trigger a new build for every new tweet.
Cron every five minutes.
It was pretty darn simple to get the text of a tweet, and just apply some styles to it. If one was motivated, making something to replace Twitter's version of embedding would not be very difficult.
Sure, but these problems were anticipated in the design of, certainly later, HTML specs. One example: the ALT text tag for images, which has been part of the spec since at least HTML4, originally published as a recommendation in 1997.
Every image on your website(s) should have ALT text to be screenreader friendly and, if it doesn't, that's on you: it doesn't make using images an inherently bad or accessibility-unfriendly idea.
Is it necessary for a quoted tweet to look exactly like it came from Twitter when the text and a link serves an identical purpose?
That said, if someone wants to delete a tweet or otherwise correct the record, are you prepared to issue a correction of your own when quoting a tweet? The internet is particularly unforgiving when it comes to this.
<object> or <portal> already exist. maybe they would work?
It was shipped behind a flag with an initial implementation vulnerable to a same origin policy bypass as well as local file disclosure. As far as I can tell the only reason it wasn't assigned a Moz standards position of "harmful" is because Google argued "it's actually still a work in progress!" (three years ago).
Refs:
- https://research.securitum.com/security-analysis-of-portal-e...
It's not clear what you're asking for. (E.g. do you want that snippet not to be sandboxed?)
> iframe is a full page.
An iframe loads whatever you give it. If you give it a URL to a "full page"/"whole page", then it loads that. If the URL leads to e.g. "a div" or "a table", then that will be loaded. That's under the control of the person who's putting stuff on the other end of the URL. To repeat, there is exactly one case where this doesn't hold up: when you want the loaded content to be inline and not block-level (e.g. "some text"—and if inline content is what you meant, then you should say that instead of just giving another vague response; again, though, even if that is what you want, how would that be relevant to the use case we're talking about here: embedding tweets?)
What you're proposing stands little chance of being implemented, given the security implications.
And have none accessibility.