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

rrssb 2.0 outline #113

Open
5 of 14 tasks
dbox opened this issue May 21, 2015 · 100 comments
Open
5 of 14 tasks

rrssb 2.0 outline #113

dbox opened this issue May 21, 2015 · 100 comments
Labels
Milestone

Comments

@dbox
Copy link
Contributor

dbox commented May 21, 2015

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

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

@dbox dbox added the 2.0 label May 21, 2015
@connorwyatt
Copy link
Contributor

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
Copy link
Contributor

@connorwyatt
Copy link
Contributor

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

@AdamPS
Copy link
Contributor

AdamPS commented May 21, 2015

#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
Copy link
Contributor

AdamPS commented May 21, 2015

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
Copy link
Contributor

AdamPS commented May 21, 2015

Many thanks for all the hard work!

@connorwyatt
Copy link
Contributor

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
#113 (comment).

@connorwyatt
Copy link
Contributor

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 #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
#113 (comment).

@dbox
Copy link
Contributor Author

dbox commented May 21, 2015

"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
Copy link
Contributor

AdamPS commented May 21, 2015

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
Copy link
Contributor

AdamPS commented May 21, 2015

@dbox the plugin js call sounds good!

@AdamPS
Copy link
Contributor

AdamPS commented May 21, 2015

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
Copy link
Contributor

AdamPS commented May 21, 2015

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
Copy link
Contributor

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
#113 (comment).

@connorwyatt
Copy link
Contributor

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
#113 (comment).

@connorwyatt
Copy link
Contributor

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
Copy link

Marc-pi commented May 21, 2015

@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
Copy link
Contributor

AdamPS commented May 21, 2015

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
Copy link
Contributor

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
#113 (comment).

@dbox
Copy link
Contributor Author

dbox commented May 21, 2015

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

@connorwyatt
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Contributor

AdamPS commented May 22, 2015

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
Copy link
Contributor

AdamPS commented May 22, 2015

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
Copy link
Contributor

AdamPS commented May 22, 2015

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
Copy link
Contributor

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
Copy link
Contributor

AdamPS commented May 22, 2015

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
Copy link
Contributor

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
Copy link
Contributor

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

@dbox
Copy link
Contributor Author

dbox commented May 22, 2015

ah. perfect.

@connorwyatt
Copy link
Contributor

;)

On 22 May 2015, at 19:58, Daniel Box [email protected] wrote:

ah. perfect.


Reply to this email directly or view it on GitHub #113 (comment).

@connorwyatt
Copy link
Contributor

There you go, my github pages version has the K and M functionality now

@dbox
Copy link
Contributor Author

dbox commented May 27, 2015

@connorwyatt Did you want me to pull into 2.0 or do you want to get a little further first?

@connorwyatt
Copy link
Contributor

You can pull it in just let me check whether I need to push anything up.

I haven’t done anything with the sizing of the buttons yet so that is the next job that needs doing.

On 27 May 2015, at 18:34, Daniel Box [email protected] wrote:

@connorwyatt https://github.com/connorwyatt Did you want me to pull into 2.0 or do you want to get a little further first?


Reply to this email directly or view it on GitHub #113 (comment).

@bboerendans
Copy link

The thing why http://graph.facebook.com/?id=http://connorwyatt.github.io/rrssb/ and http://graph.facebook.com/?id=http://kurtnoble.com/labs/rrssb is giving the same count is that in both pages the meta property="og:url" have the same url :)

@dbox
Copy link
Contributor Author

dbox commented May 28, 2015

@bboerendans That's what we thought too but I put a page up with no og:url meta and it's still doing it:
http://dbox.us/rrssb2/

@connorwyatt
Copy link
Contributor

Yeah we checked that @bboerendans and it’s not that, I have no idea what to do with it but I’ll look into it.

No URL is hard coded into the js so I can’t see why it’s playing up

On 28 May 2015, at 13:26, Daniel Box [email protected] wrote:

@bboerendans https://github.com/bboerendans That's what we thought too but I put a page up with no og:url meta and it's still doing it:
http://dbox.us/rrssb2/ http://dbox.us/rrssb2/

Reply to this email directly or view it on GitHub #113 (comment).

@dbox
Copy link
Contributor Author

dbox commented May 28, 2015

I have an idea. Standby
On Thu, May 28, 2015 at 7:40 AM Connor Wyatt [email protected]
wrote:

Yeah we checked that @bboerendans and it’s not that, I have no idea what
to do with it but I’ll look into it.

No URL is hard coded into the js so I can’t see why it’s playing up

On 28 May 2015, at 13:26, Daniel Box [email protected] wrote:

@bboerendans https://github.com/bboerendans That's what we thought
too but I put a page up with no og:url meta and it's still doing it:
http://dbox.us/rrssb2/ http://dbox.us/rrssb2/

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


Reply to this email directly or view it on GitHub
#113 (comment).

@dbox
Copy link
Contributor Author

dbox commented May 28, 2015

@connorwyatt. Thanks! If you could bring in the current resizing that would be best.

@dbox
Copy link
Contributor Author

dbox commented May 28, 2015

@bboerendans @connorwyatt. Haha. So we were all right about the og-title. When I originally uploaded it, it had the og-title, then I took it off. Evidently all it takes is seeing it once and it caches it, even if you remove.

http://www.dbox.us/rrssb/

@connorwyatt - I think it's safe to assume script is all good. :)

@connorwyatt
Copy link
Contributor

Cool, I would have been absolutely stumped otherwise.

Seems like a strangely permanent system though!

On 28 May 2015, at 15:04, Daniel Box [email protected] wrote:

@bboerendans https://github.com/bboerendans @connorwyatt https://github.com/connorwyatt. Haha. So we were all right about the og-title. When I originally uploaded it, it had the og-title, then I took it off. Evidently all it takes is seeing it once and it caches it, even if you remove.

http://www.dbox.us/rrssb/ http://www.dbox.us/rrssb/
@connorwyatt https://github.com/connorwyatt - I think it's safe to assume script is all good. :)


Reply to this email directly or view it on GitHub #113 (comment).

@dbox
Copy link
Contributor Author

dbox commented May 28, 2015

@dbox dbox added this to the 2.0 milestone Jun 4, 2015
@dbox
Copy link
Contributor Author

dbox commented Jun 19, 2015

@connorwyatt You still working on stuff?

@connorwyatt
Copy link
Contributor

Hi @dbox, at the minute I'm not as I've just started a new job, it's currently in a state where it loads the svgs using ajax and you can use it via jquery, it just doesn't resize.

Feel free to add in the resizing functions, the old ones should be fine, you would just need to change element names and classes. Otherwise I won't get round to it in the next month and it might be longer.

-------- Original message --------
From: Daniel Box [email protected]
Date:19/06/2015 16:17 (GMT+00:00)
To: kni-labs/rrssb [email protected]
Cc: Connor Wyatt [email protected]
Subject: Re: [rrssb] rrssb 2.0 outline (#113)

@connorwyatt You still working on stuff?


Reply to this email directly or view it on GitHub.

@adamschwartz
Copy link

Hey @dbox, I really dig what y’all have built. I’m wondering if in 2.0 you might consider dropping jQuery as a dependency?

If you wanted to still support $.fn.rrssb you could bring that in if jQuery is detected. That way the advantages of using it with jQuery could be maintained while still allowing it to be used by websites which don’t use jQuery.

I’d be happy to help out if this is something you’re interested in doing.

@AdamPS
Copy link
Contributor

AdamPS commented Jul 23, 2015

So is your long term plan to drop v1.0?

I entered the debate further up the thread from the perspective of the co-maintainer of the Drupal integration. I don't want to rerun the discussion again, but just a quick summary. I can see that the drop-in zero integration option is attractive to many people. But having the js generate the content is somewhat breaking the CMS model. With v1.0, the HTML in Drupal starts off as an array and gradually gets expanded to the final HTML, with dozens of opportunities for customisation via hooks, templates, translations etc. Some people are using these. Also I believe our users are attracted by the fact the V1 module doesn't download a separate file per image - it is much more lightweight than comparable Drupal modules. I know, you said V2.0 is super fast on a modern developer PC, but maybe it makes a difference over a slow broadband. Certainly there are plenty of articles that say a single file is better performance. I have a prototype roughly working with Drupal auto-generating a CSS file with SVGs as background images (hence better caching compared with inline SVG) although unfortunately can't do the micro format at the moment, so maybe I need to look at other ideas.

So net of all that is that I'm not sure how v2.0 would fit into the Drupal module. Do you think there is any way that the two approaches can live side-by-side in the same project? Clearly there is a fair overlap. Or if we aren't sure about v2.0 would you suggest that we fork and go our own way? I don't know what the original author of the Drupal module would say - maybe he would be more happy about the new V2.0 approach, but it's less good for my websites.

I can potentially help if we can find the side-by-side approach. Although I mostly do php/CSS, and don't know much javascript, so I might not have the skills you are looking for.

@dbox
Copy link
Contributor Author

dbox commented Jul 23, 2015

@adamschwartz Personally, I don't mind dropping it as I don't do the JS updates. Would need to run by @joshuatuscan and @connorwyatt. I guess I'd just need to see some data on what % of people use jquery and what the ramifications of removing it are.

@dbox
Copy link
Contributor Author

dbox commented Jul 23, 2015

@AdamPS 1.x will still be available, but I doubt we'll maintain it to the level that 2.0 will be. Definitely happy to have rrssb-drupal and rrssb-wp forks off the main repo, but I personally have zero interest in maintaining all the different versions. At a certain point, people like to build things differently, and that's okay!

@AdamPS
Copy link
Contributor

AdamPS commented Jul 24, 2015

@dbox Great, thanks it will help to have 1.0 around still. I can understand it would be less well maintained. Any updates to SVG files would perhaps be a really useful thing to transfer across and hopefully really easy to do as the files will stay in sync.

@adamschwartz
Copy link

@dbox I’m not sure why jQuery usage data would be necessary. Removing jQuery as a dependency would allow more people to use it, not fewer. That being said, the development time to remove it as a dependency (and continue to maintain it that way) is certainly real, but I’d be happy to help out there.

@joshuatuscan @connorwyatt thoughts?

@dbox
Copy link
Contributor Author

dbox commented Jul 24, 2015

I just meant if 99% of people are using it, then probably not worth the
refactor, but I'm game.

We just gotta port those resize functions over first.

On Fri, Jul 24, 2015 at 11:46 AM Adam Schwartz [email protected]
wrote:

@dbox https://github.com/dbox I’m not sure why jQuery usage data would
be necessary. Removing jQuery as a dependency would allow more people to
use it, not fewer. That being said, the development time to remove it as a
dependency (and continue to maintain it that way) is certainly real, but
I’d be happy to help out there.


Reply to this email directly or view it on GitHub
#113 (comment).

@adamschwartz
Copy link

Ahhh, I see, my mistake.

Yeah, as co-creator of YMNNJQ I may be just a tad biased ;), but when a library can do everything it wants without jQuery, I typically advocate it. And like I said, I’d be happy to help out as I see it being very beneficial here. IMHO, a typical blog wouldn’t need jQuery since it’s just displaying static posts. Things like comments can be handled by Disqus, and Social Sharing can be handled by RRSSB :). One thing that drew me to RRSSB from the beginning was how lightweight it was as compared many other similar tools out there. At the time I didn’t realize that jQuery was a dep though. With jQuery added in, RRSSB’s size is an order of magnitude larger. Anywho, sorry again for my earlier confusion.

@AdamPS
Copy link
Contributor

AdamPS commented Jul 24, 2015

From the Drupal perspective, jQuery will very likely be loaded anyway. But there is a certain amount of hassle to get v10 that is required here - the default is lower.

@joshuatuscan
Copy link
Collaborator

I think it’s a good idea to abandon jQuery as a dependency. Originally it was for speed and banking on the fact that most people will have jQuery running on their site already, however, vanilla JS would be better and I’m for it.

Like Daniel said, just need to port the functions away from using it.

On Jul 24, 2015, at 10:40 AM, Adam Schwartz [email protected] wrote:

Ahhh, I see, my mistake.

Yeah, as co-creator of YMNNJQ http://youmightnotneedjquery.com/ I may be just a tad biased ;), but when a library can do everything it wants without jQuery, I typically advocate it. And like I said, I’d be happy to help out as I see it being very beneficial here. IMHO, a typical blog wouldn’t need jQuery since it’s just displaying static posts. Things like comments can be handled by Disqus, and Social Sharing can be handled by RRSSB :). One thing that drew me to RRSSB from the beginning was how lightweight it was as compared many other similar tools out there. At the time I didn’t realize that jQuery was a dep though. With jQuery added in, RRSSB’s size is an order of magnitude larger. Anywho, sorry again for my earlier confusion.


Reply to this email directly or view it on GitHub #113 (comment).

@adamschwartz
Copy link

@AdamPS a great example of why dep management on the web is so hard. 👍

@joshuatuscan awesome! Let me know if I can help at all.

@dbox
Copy link
Contributor Author

dbox commented Jul 24, 2015

Checklist at the top of this thread has been updated with some tasks:)

This one is the main priority right now:

Port resize functions from 1.x - @joshuatuscan / anyone else who can help

Not sure about @joshuatuscan's current availability, so if anyone else can dive in and help feel free!

@dbox
Copy link
Contributor Author

dbox commented Jul 24, 2015

Btw, 2.0 is DELIGHTFUL to work on thanks to all @connorwyatt's work on the gulp/browsersync setup.

@dbox
Copy link
Contributor Author

dbox commented Oct 5, 2015

Pinging to see availability on 2.0 work. @joshuatuscan you around at all? Anyone else want to dive in here? I'm currently slammed but would like to get 2.0 out the door if possible. I can help but can't take on the porting of resizing functionality.

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

No branches or pull requests

7 participants