Hello everyone. I’m going repeat one of my replies from the previous page of the thread, because while I acknowledge your frustrations, it’s very important you be aware of the risk and inevitable maintenance burden you’re setting yourselves up for by injecting CSS into the widget.
I want to be clear that we will continue improving the widgets in a structured, maintainable manner. I sympathise if what’s there right now doesn’t fit your desires, and that you don’t want to go to the significant extra effort of using the API via your own server. But, the reason for adding customisation options the way we have—rather than encouraging direct and raw CSS access—is that they are features we can commit to, and maintain in future iterations.
———
Although it is possible to inject additional content into the frame, I would
strongly discourage it for a couple of reasons: Firstly, although the frames
are presently rendered on the same host context as your page, we also
don’t display any user-identifying information in the timeline. If we add
features in the future that depend on a Twitter user’s state, we have to
change the frame to load from a twitter.com subdomain instead, to protect
the user’s identity. In that scenario, your code injection will cease working and
you’ll run into a cross-domain communication error.
Similarly, we’re keen to embrace lighter-weight forms of sandboxing than
iframes. Once Web Components, or CSS 4’s reset:all or any other
options stabilise and gain browser support, we’ll be looking to use them
if page performance can be improved, and lighten the impact of our code.
———
The mark-up within the frame will change. Maybe an adjustment to Twitter’s design will move things around, or a new browser feature could be enabled with different semantic mark-up. Similarly, extending our current system of themes, colour, link and border customisations might need to be refactored to support CSP security features, or the CSS restructured to support more granular customisations.
Embedded timelines exist to make it very, very easy to drop your Twitter posts into pages. People talk about the 80:20 rule, which for the things we build I prefer to think of as more of a 95:5 rule. I want the overwhelming majority of people to get what they need from the tools we release as Twitter for Websites. But, the tools have to be stable, and maintainable, and indeed they do have to meet Twitter’s wider standards around display guidelines, and our opinion on what makes up a user identity.
We have a way to go to reach that 95%, but we have to be thoughtful about it: If we’re rash in dropping in new options, or opened a feature to allow injecting CSS, we’d be ensuring that the widgets will be expensive to maintain, and adding untold risk in ability to keep those features bug free. The API transition has been a long and very disruptive process. We do not want any level of disruption to be a regular occurrence when working with the Twitter platform, from the responses of REST methods to the behaviour of widget options.
CSS hacks are not something that we can support, and not something that we can give advice or forewarning about changes for. Your website is your website, and you’re free to run whatever code within it that the browser and the user permits, but the widgets are injected into frames because that creates a light sandbox. We can’t promise anything regarding the stability, behaviour and content within that sandbox if you decide to reach inside.
I appreciate your feature requests, your feedback, and again I want you to know that this is not on deaf ears and there’s plenty of work we plan to do.
If the widget really can’t work for you right now, then the API is always there for you to render anything for yourselves. There’re a lot of people on these forums who can help. But I hope that in time we can build out what you need.
Thanks,
Ben
