rrssb 2.0 outline

[dbox]

https://github.com/kni-labs/rrssb/tree/2.0

• [ ] New dev folder structure: #118
• [x] Ajax loading of inline svgs
• [x] New plugin style JS call w/ options
• [x] Total counts per #49
• [ ] Add .popup defaults - @connorwyatt
• [ ] Port resize functions from 1.x - @joshuatuscan / anyone else who can help
• [x] Style total counts - @dbox
• [ ] Simplified index with multiple examples - @dbox
• [ ] Tiny format fixes per #128 - @dbox @jsmoriss
• [x] Update readme with new installation instructions
• [ ] Separate repo for demo page - @dbox
• [ ] Kill jquery :skull: @AdamPS @adamschwartz
• [ ] Update bower.json /w proper ignores and dependencies
• [ ] Test - everybody!

Note: This is a full version update and will have breaking changes. 1.x.x will also still be available.

[connorwyatt]

By the way I've pushed my changes to my fork of rrssb and you can have a look if you like.

They dont resize yet because those functions arent in the file but I will add those in at some point

[connorwyatt]

https://github.com/connorwyatt/rrssb/tree/2.0

[connorwyatt]

There's no count yet either but that will be added

[AdamPS]

#103 ended with "I'll use the 2.0 thread from now on" so I'll pop a couple of questions / requests in here. Context is that I use Drupal and have recently become a co-maintainer of the associated module https://www.drupal.org/project/rrssb.

General requests:

• Consider the "deliver mechanism". Make it as easy as possible for downstream consumers to integrate changes. Currently the index.html is a manual integration into our PHP file. If you could deliver a PHP array that would be ideal (possibly you could use the PHP to make your index.html automatically). Taking the SVG out of index.html will be a big help in itself. The URLs in the PHP would ideally have placeholders such as [title] and [url].
• Allow extensibility by users of the library - in particular adding of new buttons. This is easy in 1.0, so just need not to lose it when moving to an SVG file or similar.
• Be ready for success and a large number of buttons. Basically take care of bloat from unused buttons. In 1.0 the CSS for every button is included in the delivery and this will gradually become significant bloat. It would be simpler if there were one CSS file without any button-specific directives. Then the button-specific CSS would ideally be delivered alongside the SVG and URL information collectively as "button data" (PHP?) from which an index.html sample can be generated. The Drupal module can take the button data in and generate appropriate files based on which buttons the user selects.
• Keep the library light-weight rather than getting bloated with many features - that's one of the key advantages that attracts people to it!

[AdamPS]

Specific question. I don't understand how you can both "use AJAX/CDN to get the SVG" and "avoid bloat of downloading unwanted buttons". Surely the client side script will fetch the full SVG from the CDN?

What I had expected was that the SVG would reside on the server, and the CMS (Drupal/Wordpress) could then see which buttons are configured and only pull in the appropriate parts of the SVG.

Simple hand-crafted sites would likely be happy with simply fetching the whole SVG so this is fine as a fallback behaviour.

[AdamPS]

Many thanks for all the hard work!

[connorwyatt]

To answer your final question first, each svg is downloaded separately and only if the button is present so they aren't all downloaded, reducing the bloat that would be required if all the svgs were included in the js script. On 21 May 2015 20:45, "AdamPS" [email protected] wrote:

Specific question. I don't understand how you can both "use AJAX/CDN to get the SVG" and "avoid bloat of downloading unwanted buttons". Surely the client side script will fetch the full SVG from the CDN?

What I had expected was that the SVG would reside on the server, and the CMS (Drupal/Wordpress) could then see which buttons are configured and only pull in the appropriate parts of the SVG.

Simple hand-crafted sites would likely be happy with simply fetching the whole SVG so this is fine as a fallback behaviour.

— Reply to this email directly or view it on GitHub https://github.com/kni-labs/rrssb/issues/113#issuecomment-104400213.

[connorwyatt]

To answer your previous questions, you could use php to insert the values by using php variables in the script tag in your HTML (not in a separate js file as php won't run on it).

You can add your own buttons too but you will need to make an svg, and then get the API URL for the social network. Then you can code it into the js like the others. The reason it isn't easier is because they all have different URL structures.

Finally, all the CSS is quite small because most of the styles apply to all buttons, only the colour of the button is different if my memory serves so you can't really reduce the size.

It will still be lightweight, just easier to use. On 21 May 2015 20:41, "AdamPS" [email protected] wrote:

#103 https://github.com/kni-labs/rrssb/issues/103 ended with "I'll use the 2.0 thread from now on" so I'll pop a couple of questions / requests in here. Context is that I use Drupal and have recently become a co-maintainer of the associated module https://www.drupal.org/project/rrssb.

General requests:

• Consider the "deliver mechanism". Make it as easy as possible for downstream consumers to integrate changes. Currently the index.html is a manual integration into our PHP file. If you could deliver a PHP array that would be ideal (possibly you could use the PHP to make your index.html automatically). Taking the SVG out of index.html will be a big help in itself. The URLs in the PHP would ideally have placeholders such as [title] and [url].
• Allow extensibility by users of the library - in particular adding of new buttons. This is easy in 1.0, so just need not to lose it when moving to an SVG file or similar.
• Be ready for success and a large number of buttons. Basically take care of bloat from unused buttons. In 1.0 the CSS for every button is included in the delivery and this will gradually become significant bloat. It would be simpler if there were one CSS file without any button-specific directives. Then the button-specific CSS would ideally be delivered alongside the SVG and URL information collectively as "button data" (PHP?) from which an index.html sample can be generated. The Drupal module can take the button data in and generate appropriate files based on which buttons the user selects.
• Keep the library light-weight rather than getting bloated with many features - that's one of the key advantages that attracts people to it!

— Reply to this email directly or view it on GitHub https://github.com/kni-labs/rrssb/issues/113#issuecomment-104399293.

[dbox]

"Consider the "deliver mechanism". Make it as easy as possible for downstream consumers to integrate changes. Currently the index.html is a manual integration into our PHP file. If you could deliver a PHP array that would be ideal (possibly you could use the PHP to make your index.html automatically). Taking the SVG out of index.html will be a big help in itself. The URLs in the PHP would ideally have placeholders such as [title] and [url]."

The new plugin js call will address this. PHP will not be used.

<body>

  <div class="rrssb-container></div>

  <script>

    var options = {
      socialNetworks: [ "facebook", "twitter", "linkedin", "email" ],
      showCount: true
    };

    $(".rrssb-container").rrssb( options );

  </script>

</body>

[AdamPS]

Well be careful with "each svg is downloaded separately" because I think it could impact the page load speed - each file to download adds an overhead: bytes sent to establish a new socket and also the socket transfers slowly when it starts up due to discovering the available speed.

Maybe better for the server to run the smarts and serve a single file containing the right icon set? Or at least allow this as an option? I.e. a config parameter that could be set to point to URL of an SVG container or similar.

[AdamPS]

@dbox the plugin js call sounds good!

[AdamPS]

Thanks again for listening. One more general consideration: what about the fallback if scripts aren't enabled? I think it ought to be at least some sort of list of buttons that are links and contain text. This is potentially important for:

• search engines and bots
• screen readers
• older/low-end devices
• bugs/compatibility problems meaning scripts don't load

I gather that kni-labs write high-end flashy websites, which is great. But I'm more into generating simple small websites fairly frequently. They don't have a lot of personal attention each so simple is good! Some of my clients have 8-year old devices themselves!

[AdamPS]

It looks to me as if the the CSS is currently close to 500 bytes per button - nearly 50% of the SVG size.

Some other well-established social share solutions have around 100 buttons.

[connorwyatt]

I agree with @dbox, no php will be used but you can use php to insert the social networks into the js options. That would be up to you though.

I'll look into the overhead of establishing multiple connections but without multiple connections it would need php or another server side script to do the job.

Remember that with the CSS the base styles are most of the file, the specific styles are only a tiny part, meaning that adding new social networks would add minimal code to the CSS. On 21 May 2015 21:29, "AdamPS" [email protected] wrote:

It looks to me as if the the CSS is currently close to 500 bytes per button - nearly 50% of the SVG size.

Some other well-established social share solutions have around 100 buttons.

— Reply to this email directly or view it on GitHub https://github.com/kni-labs/rrssb/issues/113#issuecomment-104412336.

[connorwyatt]

I don't personally work with kni labs but I do work with websites with a lot of js, and you'll be glad to know that seo is not a problem as google now runs js and indexes.

For older devices, a simpler solution might be your best bet (e.g. the idea you had in another thread about moderately responsive buttons).

I personally don't write code for old browsers, I just use a piece of code that let's older browser users know that their browser is out of date and that the site may not work properly. I'm not a big fan of supporting ie8 or below.

If you want to write a fallback for non js users then you could do that but that isn't something I would personally do. On 21 May 2015 21:23, "AdamPS" [email protected] wrote:

Thanks again for listening. One more general consideration: what about the fallback if scripts aren't enabled? I think it ought to be at least some sort of list of buttons that are links and contain text. This is potentially important for:

• search engines and bots
• screen readers
• older/low-end devices
• bugs/compatibility problems meaning scripts don't load

I gather that kni-labs write high-end flashy websites, which is great. But I'm more into generating simple small websites fairly frequently. They don't have a lot of personal attention each so simple is good! Some of my clients have 8-year old devices themselves!

— Reply to this email directly or view it on GitHub https://github.com/kni-labs/rrssb/issues/113#issuecomment-104411170.

[connorwyatt]

By the way with regards to the fallback, the rrssb container gets emptied before adding the buttons (in the 2.0 I'm writing) so you could add a fallback in there and if the script runs it will remove the fallback

[Marc-pi]

@AdamPS you have great library to manage compat : modernizr, respond, html5shiv etc... just use them. rrssb must work at state of art on stabilized techs.

yes, all serious search engines are reading now JS, google being at front of them

[AdamPS]

Thanks all for continuing to listen. I guess I'm a bit old fashioned on scripts - I'll bow to your wisdom.

Regarding the CSS size though please can you double-check? I just tested and my result was that 67% of the file was the specific parts. Presumably this number will increase over time as more buttons are added?

[connorwyatt]

Apologies, I haven't looked yet, I will now On 21 May 2015 22:30, "AdamPS" [email protected] wrote:

Thanks all for continuing to listen. I guess I'm a bit old fashioned on scripts - I'll bow to your wisdom.

Regarding the CSS size though please can you double-check? I just tested and my result was that 67% of the file was the specific parts. Presumably this number will increase over time as more buttons are added?

— Reply to this email directly or view it on GitHub https://github.com/kni-labs/rrssb/issues/113#issuecomment-104426002.

[dbox]

We may be able to rewrite the each loop to be a little more efficient.

[connorwyatt]

Just looked, I was thinking of the scss rather than the css. I'm not aware of a way round it though so it's going to have to stay like that. You could always remove rules you don't need

[connorwyatt]

@dbox I was just thinking that but I don't think you could unless you change some of the colours to be the same, eg Facebook and LinkedIn but I like the slightly different shades to be honest

[AdamPS]

It's possible that my aims are a little bit different from yours - but also I think I might be able to help you get the best of both worlds. Please let me know if I'm not helping, and I'll leave you in peace!

[AdamPS]

CSS: close to 500 bytes actually contains 3 bits of real information: normal color; hover color; tiny hover color. Why not have the js file store these three colours in a config array and then inject the CSS?

[AdamPS]

SVG files: I think there is a lot of evidence against fetching separate files: many articles; tools such as YSlow; feedback from users of the Drupal RRSSB module; the links I sent in my original issue - it seems like a step backwards from v1.0.

I expect it is faster to embed all the SVGs in the JS (like you say they are fairly compact).

But even better is to let the server-side code send only the data for the chosen buttons - I'll explain more in a mo...

[connorwyatt]

CSS injection isn't a bad idea, I'll test both methods of loading the SVG's and in the future I might look into writing a php version as you are right that server side includes would be a better bet, you'd still want the js though for the behaviour

[AdamPS]

HTML: so if I understand correctly, the base page will just be a placeholder which the JS populates with list items. (Maybe I'm old-fashioned to prefer my HTML in-line then the script to style more like Superfish etc). If you are going this way beware that users may currently be customising the HTML and so you might lose that flexibility.

In particular don't assume that URL for sharing is the current page URL or title is current page title. This breaks in a feed / if content is embedded / if the current URL isn't canonical etc.

Secondly, some of the sharing buttons require extra parameters. E.g. youtube can't really share a page so the Drupal module allows configuration of the user's channel. And pinterest needs an image to be supplied etc.

[connorwyatt]

Yes that is all being supplied, I've already written that in, check my 2.0 branch on my for of the project.

You can specify pinterest media, youtube link and github link

[connorwyatt]

And whilst I understand that some people prefer inline html, the jquery plugin call using .rrssb() means that you can set it up in seconds rather can copying html into your pages

[AdamPS]

Add you own buttons: you say it would be possible - so could you actually add a JS function for this? I think it would pass: URL (with placeholders); either SVG file URL or SVG string; 3 colors as above.

This seems particularly neat, because then in the Drupal module, we can take the JS, delete all the config specific buttons (you could even ship a minimised version) and then server side PHP could add exactly the set of buttons that are needed using the above function (and passing SVG text rather than URL).

So potentially best of both worlds? Use the larger script for a quick try out, it is entirely self-contained . Serious users that care about perf have the blazing fast lightweight version. Anyone using a CMS gets that without extra effort because the plug-in or module does the work.