[Pro] Javascript for Search Field, Safari problems

You’re missing something fundamental here. If you apply the listener to the search field element itself, then the event will be observed on the item that is creating it. The only reason you would need to wrap that listener in another listener is if you were putting your JavaScript in the head of the page. In that case, you have to wrap the field’s listener in a listener on the document itself, so you know when the document has finished loading.

This pen illustrates adding the listener on the search field:

If you were going to put the JS code in the page head, rather than at the very bottom of the page in the Before /body position, then you would need to wrap the handler like this:

document.addEventListener('DOMContentLoaded', function(){
  document.getElementById('search').addEventListener('blur', function(){
    this.value = '';
  });
});

The outer one observes the page loading, and the inner one observes the form field blurring. It’s seriously easier to just move the code to the bottom of the page, though, and it means that you get a faster time to first paint on the screen.

You want to listen for these events as close to where they are emitted as possible. While the blur event will bubble out, and eventually reach the document, it’s just easier to listen directly from the input.

Walter

On Mar 1, 2017, at 8:07 PM, JDW email@hidden wrote:

This doesn’t work either…

//delete field contents and defocus when user clicks outside field
> function blurMe(evt){
>    if (evt){
>        document.getElementById("Field").value = '';
>    }
> }
> window.addEventListener("blur", blurMe, false);

James W.


dynamo mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk


dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

Hi Walter,

Thank you for the JS education! I confirmed your “wrapped” handler works great.

Per your suggestion about placement before , are you saying I should put all my “addEventListener” code snippets in that location? Right now, I have everything placed before , as follows:

//clear & unselect search field on page load
document.addEventListener("load",function(evt){
 var GF = document.getElementById("Field");
 //delete field contents and defocus on page load
 GF.value = "";
 GF.blur();
});

document.addEventListener('DOMContentLoaded', function(){
  document.getElementById('Field').addEventListener('blur', function(){
    this.value = '';
  });
});

//clear & reset search field on press of browser Back button
//(works in FF, Chrome & Safari, but not IE)
function pageShown(evt){
    var GF = document.getElementById("Field");
    if (evt.persisted){
        GF.value = "";
        GF.blur();
    }
}
window.addEventListener("pageshow", pageShown, false);

//prevents blue hover border from sticking in iOS Safari on browser BACK
function touchStart(evt){
    if (evt){
        document.getElementById("Field").style.border = "2px solid transparent";
    }
}
window.addEventListener("touchstart", touchStart, false);

//clear & reset search field on press of browser Back button in IE
function detectIE() {
    var ua = window.navigator.userAgent;
    var msie = ua.indexOf('MSIE '); //IE 10 & lower
    var trident = ua.indexOf('Trident/'); //IE 11
    var edge = ua.indexOf('Edge/');
    if (msie > 0 || trident > 0 || edge > 0) {
        document.getElementById("Field").value = "";
        document.getElementById("Field").blur();
    }
    return false; // browsers other than IE
}

dynamo mailing list
email@hidden
Update your subscriptions at:

You can put all of your JS in the before /body position, and it will work better (all page elements are guaranteed loaded, so you don’t have to wait for the page to load – no more wrappers. Speaking of which, your first two listeners below are doing almost the same thing. You should pick one, and don’t put both of them there. Try deleting the first one – I doubt you will need it now. In fact, try cutting things away and see how little you can get away with. The border appearing on back can be removed with CSS:

#Field { outline: none }

Walter

On Mar 1, 2017, at 10:08 PM, JDW email@hidden wrote:

Hi Walter,

Thank you for the JS education! I confirmed your “wrapped” handler works great.

Per your suggestion about placement before , are you saying I should put all my “addEventListener” code snippets in that location? Right now, I have everything placed before , as follows:

//clear & unselect search field on page load
> document.addEventListener("load",function(evt){
> var GF = document.getElementById("Field");
> //delete field contents and defocus on page load
> GF.value = "";
> GF.blur();
> });
> 
> document.addEventListener('DOMContentLoaded', function(){
>  document.getElementById('Field').addEventListener('blur', function(){
>    this.value = '';
>  });
> });
> 
> //clear & reset search field on press of browser Back button
> //(works in FF, Chrome & Safari, but not IE)
> function pageShown(evt){
>    var GF = document.getElementById("Field");
>    if (evt.persisted){
>        GF.value = "";
>        GF.blur();
>    }
> }
> window.addEventListener("pageshow", pageShown, false);
> 
> //prevents blue hover border from sticking in iOS Safari on browser BACK
> function touchStart(evt){
>    if (evt){
>        document.getElementById("Field").style.border = "2px solid transparent";
>    }
> }
> window.addEventListener("touchstart", touchStart, false);
> 
> //clear & reset search field on press of browser Back button in IE
> function detectIE() {
>    var ua = window.navigator.userAgent;
>    var msie = ua.indexOf('MSIE '); //IE 10 & lower
>    var trident = ua.indexOf('Trident/'); //IE 11
>    var edge = ua.indexOf('Edge/');
>    if (msie > 0 || trident > 0 || edge > 0) {
>        document.getElementById("Field").value = "";
>        document.getElementById("Field").blur();
>    }
>    return false; // browsers other than IE
> }

dynamo mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk


dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

Walter,

The border just acts as a hover state to highlight the search field. I set that border in the CSS. The only reason I use JS to kill it is because when I view the search results page and then click the browser back button, the border displays and continues to display even if I am not hovering over the search field. My JS prevents that problem from happening.

By the way, I just now began testing IE and Edge. Without the “window.onload” of my original JS code, clicking the browser BACK button from the Search Results page will leave the search term inside the search field. But when I use “window.onload”, that problem goes away (the search field properly gets blanked). I tried putting the JS just before but the problem remains. Without “window.onload” search terms get stuck in the field when using modern IE or Edge. No other browser, not even Safari in iOS, needs “window.onload” – they clear the search term without it.

–James W.


dynamo mailing list
email@hidden
Update your subscriptions at:

This test page uses “window.onload” before and works great in any browser, including stupid IE11 and Edge (but of course, it conflicts with Freeway rollovers that put “onload” in the “body” tag):

https://kiramek.com/search-test2.html

This version eliminates “window.onload” and puts all the JS before , but IE11 and Edge retain the search-term inside the search field when you click the browser BACK button on the Search Results page:

https://kiramek.com/search-test3.html

To test the above pages, just click inside the search field and type “alarm” and then hit return.

–James W.

P.S. If you don’t have a Windoze computer, just download the free VM from MS here:

I tested with “MS Edge on Win10 Stable” on “VirtualBox.” I also tested on a real Win10 computer and saw it respond the same. The VM comes with Edge and IE11, by the way.


dynamo mailing list
email@hidden
Update your subscriptions at:

Here’s a screencast showing the problem (no sound):

James W.


dynamo mailing list
email@hidden
Update your subscriptions at:

Walter,

Separate but related question…

I agree with your sound reasoning about putting JS before instead of before , but why does your Protaculous2 action put a link to the large “prototype.js” file before ? Why not before instead? And why does Protaculous2 put “Additional JS Libraries” (which we type into the Actions palette) before ? Why not before ? Why does your Carousel2 action link to “scriptaculous.js” before ? Why does your ScriptyLightbox3 action link to “scripty_lightbox_3.js” before ? Is it a rule that all external scripts should be placed before ? Perhaps not in light of this…

Furthermore, I see a lot of Freeway-generated functions placed before too, including:

  1. FWShowHideLayer
  2. FWLoad
  3. FWRestore
  4. FWLSwap
  5. FWCallHit
  6. FWSlave
  7. FWFindLayer

I have “render blocking” in mind when I pondering these things, especially the external *.js files which Google’s PageSpeed Tools dislikes.

–James W.


dynamo mailing list
email@hidden
Update your subscriptions at:

The Actions were all written a large number of years ago, when the thinking (and what was considered valid) was different. The current thinking (and Yahoo speed evaluations prove this out) is that you should put as much of the JS below the HTML content as possible, particularly after CSS and fonts, because they do block the rendering of the page until they load.

The Protaculouses all use a dom:loaded listener to make them only fire their scripts once the page has entirely loaded, which is why they don’t fail to work. But it’s even faster to not listen for the event, and simply use the empirical fact that the rest of the HTML has been requested to trigger your scripts.

When you’re looking at the core Actions, remember that many of them were written in the very late 90s and early 'oughts. Times, and best practices, have changed.

Walter

On Mar 2, 2017, at 7:40 PM, JDW email@hidden wrote:

Walter,

Separate but related question…

I agree with your sound reasoning about putting JS before instead of before , but why does your Protaculous2 action put a link to the large “prototype.js” file before ? Why not before instead? And why does Protaculous2 put “Additional JS Libraries” (which we type into the Actions palette) before ? Why not before ? Why does your Carousel2 action link to “scriptaculous.js” before ? Why does your ScriptyLightbox3 action link to “scripty_lightbox_3.js” before ? Is it a rule that all external scripts should be placed before ? Perhaps not in light of this…

The best way to load external JavaScript - Human Who Codes

Furthermore, I see a lot of Freeway-generated functions placed before too, including:

  1. FWShowHideLayer
  2. FWLoad
  3. FWRestore
  4. FWLSwap
  5. FWCallHit
  6. FWSlave
  7. FWFindLayer

I have “render blocking” in mind when I pondering these things, especially the external *.js files which Google’s PageSpeed Tools dislikes.

–James W.


dynamo mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk


dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

Walter,

Thank you for the information about JS placement in light of how things have changed.

By the way, I was able to resolve the IE problem where the field wouldn’t get reset when the user clicks the BACK button from the Results page. While strange, my revised code works…

BEFORE (bad):

//clear & defocus search field after press of browser Back button on Results page
//(works in FF, Chrome & Safari, but not IE or Edge)
function pageShown(evt){
    if (evt.persisted){
        document.getElementById("Field").blur();
    } 
}
window.addEventListener("pageshow", pageShown, false);

AFTER (good):

//clear & defocus search field after press of browser Back button on Results page
//(works in FF, Chrome & Safari, but not IE or Edge)
function pageShown(evt){
    if (evt.persisted){
        document.getElementById("Field").blur();
    } else { document.getElementById("Field").value = ""; document.getElementById("Field").blur();}
}
window.addEventListener("pageshow", pageShown, false);

I tried it without the “if” statement at all, but that didn’t work. The addition of the “else” works. And I found that “blur();” needs to be in the “if” and both “blur();” and “value=‘’;” needs to be in the else. Confirmed in Edge(Win10), IE11(Win10), IE9(Visa), as well as Chrome and Firefox on Mac and Windows, as well as Safari, and iOS Safari, and FF on Android.

My code can now be placed before without need for “window.onload” and it JustWorks.

Thanks again, for all your advice.

Sincerely,

James W.


dynamo mailing list
email@hidden
Update your subscriptions at:

One last question for you, Walter…

In the past in another thread, you kindly gave me the following code for use inside “DOM Loaded Observer” in your Protaculous2 Action. It displays an overlay (splash screen of sorts) when the page is first loaded and then a cookie is set so the overlay won’t bother the same user again for a week.

//this cookie ensures the patent-splash displays only once a week
var message_box = $('legaleze').setStyle('z-index: 1000');
$$('body').first().insert(message_box.remove());
//cookie expires once a week, in seconds:
var jar = new CookieJar({expires: '604800'});
if(!jar.get('hide_message')){
  message_box.show().observe(
    'click',
    function(evt){
      jar.put('hide_message',true);
      this.hide();
    }
  );
};

I copied the content of the external cookiejar.js file, minified it, and dumped that just above the above code in “DOM Loaded Observer.” What I want to do now is eliminate the reliance on prototype.js (delete Protaculous2 entirely on that page). To do that, I need to rewrite the above script in regular JS. Since I am not well versed in JS, this is proving to be a challenge.

I thought I could just extract the relevant functions contained inside prototype.js, but my oh my are there many, and so many are all tied together. It would be a huge amount of code to do it that way.

Is there some online tool that can magically take prototype code and change it to regular JS? (Probably not, since I couldn’t find it.)

Thanks,

James W.


dynamo mailing list
email@hidden
Update your subscriptions at:

The entire point of Prototype is that it is optimized for developer speed primarily, and page speed secondarily. All those functions, all inter-related, is why you can write something in a terse one-liner and it will just work in every browser. The developers who invented it looked at JavaScript, and wanted it to be more like Ruby. And from Ruby comes the Principle of Least Surprise, meaning you can say $('item').remove(); or $$(‘items’ ).apply(‘highlight’);` and pretty well expect it to do what it says. Under the hood, all of that simplicity is paid for with an object-oriented kit of parts that take up thousands of lines of code, and plaster over the differences between browsers’ various interpretations of the standards.

The author of CookieJar was able to pack a lot of functionality and reliability into a very few lines of code because he had that base to stand on and that principle of programming to follow.

So rather than re-writing all of Prototype in order to get CookieJar, your best bet is to look for a “vanilla” version of what CookieJar does. I think if your goal is to write and read cookies from JavaScript, you’ll find something on MDN or Stack Overflow that can do that without too much drama. The document.cookie interface is built into JavaScript, and the only reason you would need a library function to access it is to translate the low-level interface into something you can call more simply. You’re not the only one using the cookie if you use Google Analytics or similar, so you have to dig “your” data out of an undifferentiated mass. That’s the bulk of the work that CookieJar does for you.

Walter

On Mar 3, 2017, at 3:47 AM, JDW email@hidden wrote:

One last question for you, Walter…

In the past in another thread, you kindly gave me the following code for use inside “DOM Loaded Observer” in your Protaculous2 Action. It displays an overlay (splash screen of sorts) when the page is first loaded and then a cookie is set so the overlay won’t bother the same user again for a week.

//this cookie ensures the patent-splash displays only once a week
> var message_box = $('legaleze').setStyle('z-index: 1000');
> $$('body').first().insert(message_box.remove());
> //cookie expires once a week, in seconds:
> var jar = new CookieJar({expires: '604800'});
> if(!jar.get('hide_message')){
>  message_box.show().observe(
>    'click',
>    function(evt){
>      jar.put('hide_message',true);
>      this.hide();
>    }
>  );
> };

I copied the content of the external cookiejar.js file, minified it, and dumped that just above the above code in “DOM Loaded Observer.” What I want to do now is eliminate the reliance on prototype.js (delete Protaculous2 entirely on that page). To do that, I need to rewrite the above script in regular JS. Since I am not well versed in JS, this is proving to be a challenge.

I thought I could just extract the relevant functions contained inside prototype.js, but my oh my are there many, and so many are all tied together. It would be a huge amount of code to do it that way.

Is there some online tool that can magically take prototype code and change it to regular JS? (Probably not, since I couldn’t find it.)

Thanks,

James W.


dynamo mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk


dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

Thank you for the advice, Walter. I understand the power of the prototype framework , but it seems most JS programmers are using the jQuery library instead. There are other, albeit less popular JS libraries as well. For simple needs, I am thinking I should avoid all of these libraries altogether and just write pure JavaScript.

James W.


dynamo mailing list
email@hidden
Update your subscriptions at:

I understand and agree with your direction here. My point about Prototype wasn’t to say that you should use it, but that you don’t need to replace it entirely in order to get what you want done. The CookieJar tool is really cool and nicely written, and could not be written as simply as it is without Prototype, but there’s nothing about the problem of reading and writing cookies that can’t be done with vanilla JS.

Walter

On Mar 3, 2017, at 9:10 PM, JDW email@hidden wrote:

Thank you for the advice, Walter. I understand the power of the prototype framework , but it seems most JS programmers are using the jQuery library instead. There are other, albeit less popular JS libraries as well. For simple needs, I am thinking I should avoid all of these libraries altogether and just write pure JavaScript.

James W.


dynamo mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk


dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

Please take me off this list, I don’t know how to get myself off of it.
Thanks

On Fri, Mar 3, 2017 at 6:41 PM Walter Lee Davis email@hidden wrote:

I understand and agree with your direction here. My point about Prototype
wasn’t to say that you should use it, but that you don’t need to replace it
entirely in order to get what you want done. The CookieJar tool is really
cool and nicely written, and could not be written as simply as it is
without Prototype, but there’s nothing about the problem of reading and
writing cookies that can’t be done with vanilla JS.

Walter

On Mar 3, 2017, at 9:10 PM, JDW email@hidden wrote:

Thank you for the advice, Walter. I understand the power of the
prototype framework , but it seems most JS programmers are using the jQuery
library instead. There are other, albeit less popular JS libraries as
well. For simple needs, I am thinking I should avoid all of these
libraries altogether and just write pure JavaScript.

James W.


dynamo mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk


dynamo mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk


Dianne Terwilliger
email@hidden


dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

At the bottom of every message you get is a link where you can manage that. Nobody else can help you with it. If you’ve forgotten your password, there is a recovery system where you can either get it or reset it (can’t recall, it was many years ago when I wrote it).

Walter

On Mar 3, 2017, at 9:49 PM, Dianne Terwilliger email@hidden wrote:

Please take me off this list, I don’t know how to get myself off of it.
Thanks

On Fri, Mar 3, 2017 at 6:41 PM Walter Lee Davis email@hidden wrote:

I understand and agree with your direction here. My point about Prototype
wasn’t to say that you should use it, but that you don’t need to replace it
entirely in order to get what you want done. The CookieJar tool is really
cool and nicely written, and could not be written as simply as it is
without Prototype, but there’s nothing about the problem of reading and
writing cookies that can’t be done with vanilla JS.

Walter

On Mar 3, 2017, at 9:10 PM, JDW email@hidden wrote:

Thank you for the advice, Walter. I understand the power of the
prototype framework , but it seems most JS programmers are using the jQuery
library instead. There are other, albeit less popular JS libraries as
well. For simple needs, I am thinking I should avoid all of these
libraries altogether and just write pure JavaScript.

James W.


dynamo mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk


dynamo mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk


Dianne Terwilliger
email@hidden


dynamo mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk


dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

Walter,

I finalized my CSS and JS for my cookie application. No Protaculous2/Prototype or jQuery external libraries required.

The cookie is used only to remember the last time a DIV overlay was displayed, and when the cookie expires (I set it to 30 days), then the overlay will display again and a new cookie will be set when the user clicks anywhere on-screen to close the overlay. By using the cookie, the overlay is not bothersome (not displayed on every page load) to repeat visitors.

For the sake of others who wish to do something similar, here’s the code…

Put this CSS in "before in Freeway’s HTML Markup dialog:

<style type="text/css">
/* DIV overlay is named "legaleze" */
#legaleze{
   display:none;
   top: 0;
   left: 0;
   right: 0;
   bottom:0;
   background-color: white;
   opacity: 0.9;
   filter: alpha(opacity=90);
}
/* Close box is named "box" */
#box:hover {
  background-color: red;
  cursor: pointer;
}
</style>

Put this JS in “before ” in Freeway’s HTML markup dialog:

<script type="text/javascript">
function setCookie(cname,cvalue,exdays) {
    var d = new Date();
    d.setTime(d.getTime() + (exdays*24*60*60*1000));
    document.cookie = cname + "=" + cvalue + ";" + "expires=" + d.toGMTString() + ";path=/";
}
function getCookie(cname) {
    var name = cname + "=";
    var ca = decodeURIComponent(document.cookie).split(';');
    for(var i = 0; i < ca.length; i++) {
        var c = ca[i];
        while (c.charAt(0) == ' ') {
            c = c.substring(1);
        }
        if (c.indexOf(name) == 0) {
            return c.substring(name.length, c.length);
        }
    }
    return "";
}
document.addEventListener('DOMContentLoaded', function(){
    var cook=getCookie("kiramek_patent_notice");
    if (cook === "Show every 30 days") { //do nothing
    } else { //close the overlay on click and set cookie
    document.getElementById("legaleze").style.display = 'block';
    document.getElementById('legaleze').onclick = function(){ 
        document.getElementById("legaleze").style.display = 'none'; 
        setCookie("kiramek_patent_notice", "Show every 30 days", 30);
        }
    }
});
</script

NOTE: Add the closing greater-than symbol to the end of /script above. I tried to add it, but it totally messes up the line breaks here on FreewayTalk when I do that, even though it’s situated within “[code]” tags.

–James Wages


dynamo mailing list
email@hidden
Update your subscriptions at:

This is great work, James. As far as the code tags go – they are really just a hack, I never spent any time on them besides getting them to parse the very few posts left over from the interregnum period when this mailing list was hosted on PHPBB. This list uses Markdown, not BBCode. To make a block script tag, either indent every line with one tab or four spaces, or make a “fenced” code block with four tildes in a row, on a line by itself, before and after the block of code. And if you really want your code to look great (color highlighting and everything) make a Gist or Pastie, and put the link to the resulting page all by itself on one line here.

Walter

On Mar 8, 2017, at 3:11 AM, JDW email@hidden wrote:

I tried to add it, but it totally messes up the line breaks here on FreewayTalk when I do that, even though it’s situated within “[code]” tags.


dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

Thank you for the Gist/Pastie suggestion, Walter. That code is indeed lovely to behold!

James W.


dynamo mailing list
email@hidden
Update your subscriptions at:

Walter, I created a Gist but when I paste the URL into this field here on FreewayTalk, the URL does not appear in the Preview! The only way I can get it to display is by putting it inside “code” tags like this:

https://gist.github.com/JDW1/2c2b619fb6bca99fdbfd43d4a4c49b2c#file-gistfile1-txt

I copied your Gist’s URL above and pasted it into my post here, but that URL too won’t display in Preview. How in the world did you insert it?

Furthermore, when I view my Gist on Gist Hub, it is not colored. What’s the trick to that?

Thanks,

James


dynamo mailing list
email@hidden
Update your subscriptions at:

The Gist (or Pastie) only appears in FreewayTalk after you publish the new post. That’s a long-standing bug that I never fixed while I had the chance, and now can’t fix because I no longer have access to the server.

In my usual use-case, I just paste the URL in Mail.app when I compose messages there, so I don’t see that distinction. The color syntax highlighting is dependent on you setting the correct file type, either by giving the Gist a fake filename when you create it, as I did, or by using the file type picker to choose the programming language. Both of those options are in the Gist interface, not the FreewayTalk one.

In the case of your example, which I just pasted into Gist, the fact that it had tags meant that it was HTML, so I ended my example’s “filename” with .html. That was all the clue that the formatter needed. I could also have stripped off the tags, and set it to .js, and that would have worked similarly.

Walter

On Mar 8, 2017, at 11:18 PM, JDW email@hidden wrote:

Walter, I created a Gist but when I paste the URL into this field here on FreewayTalk, the URL does not appear in the Preview! The only way I can get it to display is by putting it inside “code” tags like this:

https://gist.github.com/JDW1/2c2b619fb6bca99fdbfd43d4a4c49b2c#file-gistfile1-txt

I copied your Gist’s URL above and pasted it into my post here, but that URL too won’t display in Preview. How in the world did you insert it?

Furthermore, when I view my Gist on Gist Hub, it is not colored. What’s the trick to that?

Thanks,

James


dynamo mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk


dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options