{"id":30843,"date":"2017-06-18T03:01:43","date_gmt":"2017-06-17T17:01:43","guid":{"rendered":"http:\/\/www.rjmprogramming.com.au\/ITblog\/?p=30843"},"modified":"2017-06-18T09:16:12","modified_gmt":"2017-06-17T23:16:12","slug":"youtube-embedded-video-in-iframe-api-regex-tutorial","status":"publish","type":"post","link":"https:\/\/www.rjmprogramming.com.au\/ITblog\/youtube-embedded-video-in-iframe-api-regex-tutorial\/","title":{"rendered":"YouTube Embedded Video in Iframe API RegEx Tutorial"},"content":{"rendered":"
\"YouTube<\/a>

YouTube Embedded Video in Iframe API RegEx Tutorial<\/p><\/div>\n

We’ve said many’s a time it’s good to revisit code and its workings. A break from it makes you forget to be optimistic, and be more realistic. So it was the other day with our YouTube<\/a> video via its Embedded Iframe API<\/a> karaoke_youtube_api.htm<\/a> interfacing web application, changed in this way<\/a> today. In fact, way back to its earliest times … and they can be the most optimistic, after all … this web application has contained the “weakness” in logical thinking, that is there, as of now, less so<\/i>. How can we only say “less so<\/i>“? It is a matter of probabilities, for us, and a lot of other design systems. Design systems should try not to complicate. We are participating with this “spirit of design” with our web application<\/a> having the one “region” of user interaction only, when they first enter the workings of it. We like it pared down this way, but in the process of allowing the user to be flexible, or not, by having that one HTML input type=text element, accept either a …<\/p>\n

    \n
  1. eleven character YouTube video ID … or …<\/li>\n
  2. anything else non-blank means search the YouTube “database” for what you have entered as a search of their video titles<\/li>\n<\/ol>\n

    … but in so doing, allowing advanced users some latitude, or more nervous users a narrow focus (a combination we tend to want to promote) we were …<\/p>\n