Embedded Timeline - More customization? (Specifically: CSS customization)

WebFireThemes · 2013-06-13T15:48:28.000Z

Hi ,

is there a way of removing the avatar ??
thanks in advance !

artificialideas · 2013-06-13T16:11:30.000Z

Just put a display:none; into the CSS (with the solution I told about, you can attach a CSS file that will affect the script’s ).

matt_carswell · 2013-06-13T17:23:59.000Z

the demo at http://kevinburke.github.io/customize-twitter-1.1/ doesn’t seem to be affected by any custom CSS

DA_Sticks · 2013-06-13T17:33:26.000Z

@elporfirio elporfirio

Your post ROCKS…we have a winner…fully styled by css

thanks a MILLION https://github.com/kevinburke/customize-twitter-1.1#tested-browsers

DA_Sticks · 2013-06-13T22:30:45.000Z

.

benward · 2013-06-14T01:41:00.000Z

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

EyesX · 2013-06-14T02:01:17.000Z

“I want to be clear that we will continue improving the widgets in a structured, maintainable manner.”

Oh really? Why didn’t you start that of BEFORE pulling the plug on the old API, that’s just ignoring your users…poorly done twitter…

philCheese · 2013-06-14T11:26:13.000Z

This is just terrible. I’m having to contact clients to tell them why they don’t have a Twitter feed at the moment - I can’t ‘integrate’ this new widget as the space I use for Twitter feeds is so limited and I have NO WAY of styling it.

I am absolutely dismayed that Twitter haven’t considered the impact that this will have on thousands and thousands of sites. As Mattias says above this is VERY poorly done, you have really dropped the ball here. What a headache.

kennylovesyou · 2013-06-14T11:39:03.000Z

Please give us a way to add in our own css styles.

supersanj1001 · 2013-06-14T15:48:29.000Z

Hi Ben Ward,
We have implemented the embedded Timeline on our home page but because of the css restrictions we can’t resolve an accessibility issue in Internet Explorer:

Bracknell Forest Borough Council

This is the website for Bracknell Forest Council. It includes all of our services, such as bins and recycling, council tax, benefits, libraries and schools.

In Firefox there is p-nickname and full-name appear on 2 lines. In IE, they appear on the same line and there is no gap between p-nickname and the tweet time. Using:
.tweet .header .u-url .p-nickname{display:block}
resolves the issue. I am reluctant to Artificial Ideas css solution after your comments.
Please advise.

ckbeav · 2013-06-14T16:28:51.000Z

Thanks for the information Ben. I’ve implemented the CSS hack on multiple sites this week and will monitor for changes. I look forward to seeing what Twitter comes up with.

ulearnuk · 2013-06-14T16:54:46.000Z

I would like to join others here in deploring the way this has been handled.
The new api has been launched too quickly: typically upgrades include new features + ALL PREVIOUS, your new version is retrograde.
Twitter needs to understand that they are ‘biting the hand that feeds’ here, independent developers are most probably responsible for exponential twitter growth. Countless business sites will be down, like a deck of cards. Nothing spreads quicker than bad news.
This should be a No1 priority for twitter to resolve.

benward · 2013-06-14T17:58:31.000Z

Hi Sanjeev,

The issue there (in IE8 and below only; IE9 and IE10 both render the link on a new line) is an unfortunate freak case of the old browser’s limited rendering and the exact length of your username butting up to the point of now wrapping.

Looking at your site, the easiest fix for this is actually in your own CSS: Change the left and right padding of #twitter P to 10px (or less) rather than 20px, then the widget will be a little wider within your bubble design, which spaces the text out.

I’m always keen to find ways to fix edge-cases like this one, but we chose not to use display: block for the screen-name wrapping, because it creates a different accessibility issue of a large, invisible click area adjacent timestamp is also clickable. It was very confusing in use, so we had to tolerate this edge case as a consequence. I hope the CSS above works as a solution for you.

Ben

BeckercOCIT · 2013-06-14T21:10:50.000Z

We are using sharepoint as a foundation and have twitter feeds with width requirements as well. Our primary feed used to fill a 748px area, however, I am now limited to the 520px.

The documentation says that it will adjust to the size of a div if contained in a div, this should be changed (the documentation but I would prefer the limitation) to as 'as long as it is 520 or less.

Glad to hear the 520px limit is on your radar and hope to have this resolved soon.

I wanted to leave the header with the follow us link, however, the iframe that contains the ‘Follow us’ does not behave as expected.

darthblade · 2013-06-15T02:03:24.000Z

Looks like Kevin’s solution will help, but… argh…
It’s the 2’nd or 3’rd time Twitter devs are making weird unnecessary changes, essentialy breaking the app and forcing users to write new hacks. And all of that effort just to display a couple of quotes on a page.

cyberleagle · 2013-06-15T14:20:50.000Z

I tried Embedded Timeline on my blog when my previous Twitter feed widget stopped working a week or so ago. However until we get the ability to change font sizes and eliminate or reduce the size of the logo I have had to rip the big ugly thing out. I now have a placeholder explaining why my nice Twitter feed is no longer there. Would love to be able to put it back. So please roll on the customisations.

NYSkiBlog · 2013-06-18T20:18:16.000Z

The people who have posted already in the comments are clearly talented developers. I’m just a guy with a website.

I would submit that a large percentage of websites are mastered by schmoe’s like me. The other ski bloggers I know are still wondering what happen to their twitter feed. When mine disappeared I went to their sites saw their feeds were gone too and realized it was nothing I did.

I know a (very) little html and actually figured out how to use the transparent mode myself and then wrapping the thing in a [div] to get the color I want.

But the fonts are wrong, I can’t add padding on the right (for some reason I can on the left) and the whole thing looks like a hack. I agree with the guy who said - don’t go backwards eliminating features when you got to the “next” version. Maybe rename the API version .9 instead of 1.1.

BTW I didn’t hear this from anyone else but the new widget really slows the load of my page. Just me?

michaellinder · 2013-06-17T01:05:41.000Z

It’s odd that Twitter, which has so conscientiously refined the visual appeal of its own apps, would arbitrarily trash the aesthetics of millions of blogs and sites. The anger and dismay expressed by developers and designers is more than justified — API 1.1 is a design crime. If it represents, as Ben Ward suggests, Twitter’s “opinion on what makes up a user identity,” it has a very low opinion of us all.

ulearnuk · 2013-06-17T09:45:19.000Z

We started the week logging in expecting to find fontsize&colour options added to API 1.1

no such luck!
This is poor response indeed, we have cancelled inclusion of a T-feed in a current design, the customization is too crude. Time to get proactive I’d say.

LaxmanRaoVL · 2013-06-17T10:16:18.000Z

<script>  
twttr.ready(function (twttr) {
window.twttr = (function (d,s,id) {
      var t, js, fjs = d.getElementsByTagName(s)[0];
      if (d.getElementById(id)) return; js=d.createElement(s);
      js.id=id;
      js.src="https://platform.twitter.com/widgets.js"; 
      fjs.parentNode.insertBefore(js, fjs);
      return window.twttr || (t = { _e: [], ready: function(f){ t._e.push(f) } });
    }(document, "script", "twitter-wjs"));

twttr.widgets.createTimeline(
      '346553456301076480',
      document.getElementById('timeline'),
      function (el) {
        console.log("Embedded a timeline.")
      },
      {
        width: '290',
        height: '440',
        related: 'wcngtindia2013,2013Agile',
      	chrome:'nofooter', 
      	count:'true',
      	screen_name:'AgileInBusiness',
      	hashtag:'#2013Agile',
      }

    );
});
</script>

Check this widget!!!