We want to find out more about how web developers use images.
It would really help if you could answer a few simple questions using our online survey. That should only take a few minutes.
We’ll collect responses for two weeks, then publish a summary of the results.
If you don’t have time for the survey, just reply to this post.
Thanks!
Fast search for the complete plays, poems and sonnets of Shakespeare (including locations and stage directions) using texts from the PlayShakespeare project.
Texts are downloaded automatically as you use them.
You can also manually download texts by clicking one of the Download all checkboxes.
Texts are removed when a checkbox is unchecked.
As well as search, you can use the app to open texts or citations:
You can also link to search results:
There are several options for filtering search results:
Click on a word in a text to search for that word.
Feedback welcome!
This app is open source.
The code and data used by the app is available on GitHub:
© 2005-2016 PlayShakespeare.com. Permission is granted to copy, distribute and/or modify this information under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation. Terms at playshakespeare.com/license.
Please note that this is not an official Google product.
Over the last two decades I’ve taught several Web Dev 101 courses.
To be honest, I don’t think any of those courses were much good.
In my experience students start out excited and ready to learn, but soon glaze over because the content and teaching are boring or baffling or both.
By way of apology to those I have baffled and bored over the last 20 years, I’ve put together 10 principles for explaining HTML, CSS and JavaScript to absolute beginners.
I think we can do a better job of teaching basic web skills.
I recently read a couple of articles that convinced me to try ESLint:
blog.lauritz.me/linting-javascript-in-2015
sitepoint.com/comparison-javascript-linting-tools
We went ahead and implemented ESLint for the WebRTC samples repo, and we’re really pleased with the results. JSHint and JSCS are both brilliant tools, but ESLint provides more functionality than both of them combined. It’s quick, too: checking the 23 WebRTC samples main.js files in a couple of seconds, for 30 customised rules (along with the defaults).
If you want to do the same yourself, here’s a quick how-to for making the move from JSHint and JSCS to ESLint.
1. Create an eslint branch for your repo.
2. Run npm install grunt-eslint --save-dev to install ESLint and add it to your package.json file. Remove JSHint and JSCS from package.json.
3. Create an ESLint .eslintrc config file (or adapt ours). Add rules, globals and other settings based on your existing JSHint and JSCS config. Note that rules marked ‘recommended’ in the ESLint documentation are run by default.
@slicknet pointed out that there’s a tool for this: github.com/brenolf/polyjuice.
4. Remove .jshintrc and .jscsrc files.
5. Replace JSHint and JSCS build tasks with ESLint — for example, in Gruntfile.js or gulpfile.js. Likewise for Git hooks and test scripts.
6. Install ESLint for your text editor and turn off JSHint and JSCS linting.
7. Remove or replace references to JSHint and JSCS in your JavaScript files, such as inline rule settings. The following ESLint declarations can be used instead:
... // eslint-disable-line new-cap/*eslint-disable */
…
/*eslint-enable */
Global declarations are the same:
/* global Fubar */
8. Run ESLint for your files and fix them as necessary. (This is much easier if you already have ESLint installed for your editor.) You can also run ESLint from the command line with the --fix parameter to automatically fix some errors, such as spaces in arrays or function definitions.
9. Test all the files that you changed.
10. Make a pull request for the eslint branch, get an LGTM and merge it.
That’s it!
.eslintrc config file for WebRTC samples repo
I built a prototype API and application for searching Google developer video transcripts and metadata:
1. I work for a search company.
2. More and more content online is video.
3. Video is inherently opaque to textual search.
How can we navigate and search media content? Not least the thousands of videos on Google Developers, Android Developers and Chrome Developers.
Thankfully Google has a secret weapon: a crack team of transcribers who produce highly accurate, timecoded captions for Google videos. (Not to be confused with the sometimes slightly surreal automated alternative.)
Some people prefer to access information by reading text rather than watching videos, so I also enabled access to downloadable transcripts:
The transcripts have Google Translate built in, so you can choose read them in a different language. Caption highlighting is synchronised with video playback — and you can tap or click on any part of a transcript to navigate through the video.
(Apologies if the translation is dodgy…)
I hope the app and API are useful. As ever, your feedback would be much appreciated.
With some minor tweaking you could use my app and API to build search for any YouTube channels that have manually captioned videos — just tweak the channels in the code.
A quick hat-tip to the world’s transcribers, captioners and reporters.
These unsung heroes have amazing, hard-won skills! If you’ve ever seen a captioner at work at a live event, you’ll understand what a complex and difficult job it is.
Why are captions important? Because they give more people better access to media: those of us with impaired hearing, or whose first language isn’t the language of the video we’re watching.
Likewise, respect is due to the archivists who catalogue video after broadcast — the art of ‘shotlisting’. Without shotlists, history is lost (and it’s hard to resell footage…) Where was that sequence of Donald Rumsfeld getting down with Saddam Hussein? Shotlisters work long days faithfully cataloguing and timecoding news stories, often at double speed, one package (or rush) after another. One of my ex-colleagues at ITN, Jude Cowan, wrote a brilliant and moving book of poetry on the subject.
Search for something:
simpl.info/s
Transcripts for two or more videos:
simpl.info/s/t?id=ngBy0H_q-GY,3i9WFgMuKHs
Link to a query:
simpl.info/s?q=breakpoint
Data and transcript for a video:
shearch.me/2UKPRbrw3Kk
Transcript only:
shearch.me/t/2UKPRbrw3Kk or
shearch.me/transcript/2UKPRbrw3Kk or
shearch.me/captions/2UKPRbrw3Kk
Multiple values — comma, semicolon or pipe delimiter, spaces OK:
shearch.me/2UKPRbrw3Kk,iZZdhTUP5qg
shearch.me/t/2UKPRbrw3Kk, iZZdhTUP5qg
Search any field for a query, spaces OK — can be a bit slow:
shearch.me?q=http 203
More shortcuts: c for captions, s for speaker — speakers are parsed from transcript:
shearch.me?c=svg&s=alex
Can specify ranges for commentCount, dislikeCount, favoriteCount, likeCount, viewCount:
shearch.me?speaker=Jake&viewCount>10000
You can use any of these values to specify order:
shearch.me?speaker=Jake&viewCount>10000&sort=viewCount
Add a hyphen for descending order:
shearch.me?speaker=Jake&viewCount>10000&sort=-viewCount
Show items with titles that include ‘Android’
shearch.me?title=Android or
shearch.me?t=Android
Items with speakers that include Reto and a title that includes Android:
shearch.me?title=Android&speakers=Reto
shearch.me?t=Android&s=Reto
Spaces are OK:
shearch.me?speakers=Reto Meier&title=Android
More complex stuff works too:
shearch.me?(title=Android Wear|description=Android Wear)&speakers=Reto
shearch.me?(title=Android Wear|description=Android Wear)&speakers=[Reto,Wayne]
shearch.me?title=”Android Wear”|title=WebRTC
shearch.me?(title=Android Wear|description=Android Wear)&speakers=Timothy
Fuzzy matching — with apologies to Wayne, whose name I generally misspell :):
shearch.me?speakers=pekarsky~
For dates, use ‘from’ and ‘to’, which can cope with anything Date can handle:
shearch.me?from=Feb // assumes text-only is a month this year
shearch.me?from=April 2014
shearch.me?from=2013-03-01&to=2013-05-01
shearch.me?from=2013&to=2014 // midnight, 1 January to midnight, 1 January
Get total for any quantity field — this query returns the total number of views for all videos:
shearch.me?count=views
Get total for any query and quantity field:
shearch.me?speakers=butcher&count=views
Get all individual values for any quantity field for all videos — returns an object keyed by amounts, values are number of occurrences for each amount:
shearch.me?countall=views
Get all individual values for any quantity field for any query:
shearch.me?speakers=reto&countall=views
Build a chart from results (views for videos that mention ‘Chrome’):
simpl.info/s/chart.html
Available from GitHub: github.com/GoogleChrome/dev-video-search.
Truth be told, it’s a bit of a dog’s dinner. I wrote most of the app and API on long flights and in the small hours under the influence of jet lag. E&OE! The JavaScript is a little… procedural, and I hereby pledge that I will mend my ways.
Issues and pull requests welcome.
There are three code directories:
app: the web client (as used at simpl.info/s). This will automatically choose the local Node middle layer (below) if run from localhost.
get: middle layer Node app to get data from the database. For testing, you can run this locally with the app running from localhost. I run the live version on Nodejitsu at shearch.me, for queries like this: shearch.me?captions=svg&speaker=alex (same as shearch.me?c=svg&s=alex).
put: Node app to get YouTube data and transcripts, massage the response and put it in a CouchDB database at cloudant.com.
$ npm install jitsu
$ jitsu login
$ jitsu deploy
$ 🙂
I used Cloudant, which has Lucene search built in (and is based on CouchDB, and is very easy to use). Firebase can now be used with Elasticsearch, but when I started that required extra installation.
I probably should have. In fact, an SQL database with Lucene for full text search might have been much more appropriate than CouchDB. (This kind of search is actually much easier with Firebase now.)
Good in some ways, and quick. In particular, the JSON/HTTP/REST styles feels fits well with Node/JavaScript development.
Problems came with full text search:
• Full text search is not built into CouchDB, though it can be added on with Lucene or other search engines.
• CouchDB searches return entire documents, with no ‘partial’ results. (In my case, a document represents all data for a video.) So, for example, if I want to return only captions that include ‘Android Wear’, I need to retrieve all the documents (in their entirety) that have captions that mention ‘Android Wear’ then filter.
• CouchDB search queries cannot be combined: for example, ‘get me all videos from 2013 with WebRTC in the title’. So, again, you have to add your own filter.
Around 250MB, but more like 150MB without transcripts: the transcript for each document is really just a convenience to make it quick and simple to retrieve human readable transcripts, and replicates the captions (with a few tweaks).
At present I’m updating the database manually to avoid code changes breaking it, but once the code settles down I’ll run automatic updates every (say) 30 minutes.
No big reason. Node.js has been around longer.
Last time I looked: 4312 videos, 3550 with transcripts.
With a bit of sneaky regexing these are parsed from transcripts.
NB: speaker names are not parsable for many captions, so speaker search results may not always be complete.
The primary use for the caption matches is within HTML markup. Returning JSON for each span might be neater and less verbose, but for most apps that would entail extra effort transforming to HTML. I could be persuaded otherwise.
This depends a lot on connectivity. From work, the app gets and inserts the video data and transcripts in under three minutes. From home, it takes about 10 minutes.
Indexing takes about 10 minutes.
I use JSCS and JSHint with grunt and githooks to force validation on commit.
Chrome JSON formatting extensions, pro.jsonlint.com and regex101.com were very useful.
Most developers look to JavaScript and image optimisation, server configuration, file minification and concatenation – even CSS tweaks.
Poor old HTML gets neglected, despite being the core language of the web.
HTML payloads are big and getting bigger. Pages on most top-100 sites require around 40k of HTML per page. Sites such as Amazon and Yahoo use thousands of lines of HTML per page. The youtube.com home page currently clocks in at a whopping 3.5K HTML elements.
Reducing HTML complexity and the number of elements in a page won’t improve parse time much – but well crafted HTML is a crucial foundation for building fast-loading pages and layouts that respond successfully to different viewport sizes.
In this article you’ll find out how to write clean, concise HTML that enables you to create content that loads fast and works well across a variety of devices. In the process, you’ll learn how to build sites and apps that are easier to debug and maintain.
| There is always more than one way to write code – especially HTML. Rather than begin every sentence in this article with ‘In general …’ we’ve gone ahead and prescribed what in our experience usually works best. That doesn’t mean that every suggestion is right every time. |
HTML is a markup language for adding structure and meaning to content.
HTML should not be used to style content. Don’t put text in heading tags to ‘make it bigger’ or use blockquotes just for indentation. Instead, use CSS to change the appearance and layout of elements.
| The default appearance of HTML elements is defined by a browser’s default stylesheet: Chrome, Firefox, Internet Explorer and Opera each have their own. For example, in Chrome the h1 element by default is rendered as 32px bold Times. |
Three general principles:
<!DOCTYPE html> <html> <head> <title>Recipes: pesto</title> </head> <body> <h1>Pesto</h1> <p>Pesto is good!</p> </body> </html>
<head> <title>My pesto recipe</title> <link rel="stylesheet" href="/css/global.css"> <link rel="stylesheet" href="css/local.css"> </head>
That way, browsers have CSS information ready before parsing HTML.
<body> ...<script src="/js/global.js"></script><script src="js/local.js"></script></body>
index.html:
<head> ... <script src="js/local.js"></script> </head> <body onload="init()"> ... <button onclick="handleFoo()">Foo</button> ... </body>This is much better:
index.html
<head> ... </head> <body> ... <button id="foo">Foo</button> ... <script src="js/local.js"></script> </body>js/local.js:
init(); var fooButton = document.querySelector('#foo'); fooButton.onclick = handleFoo();
A major reason for the success of the web is that browsers handle invalid HTML. There are even standardised rules for how browsers should render invalid code.
However, this is NOT a reason to be laissez-faire. Valid HTML is easier to debug and often smaller in file size, faster and less resource-hungry to parse and render. Invalid HTML can make successful responsive design difficult to implement.
Writing valid HTML is particular important when working with templates: what seems to work OK in an isolated chunk of code may go horribly wrong in combination with other content.
<div id="foobar">
...
</div><!-- foobar ends -->
For example, this will work:
<p>Pesto is good to eat... <p>...and pesto is easy to make.
But this is less likely to go wrong, since the end of each paragraph is made explicit:
<p>Pesto is good to eat...</p> <p>...and pesto is easy to make.</p>
<ul> <li>Basil <li>Pine nuts <li>Garlic </ul>
<!-- wrong: liable to cause layout grief --> <video src="foo.webm" /> <!-- better --> <video src="foo.webm"> <p>Video element not supported.</p> </video>
<link rel="stylesheet" href="css/local.css"> ...<script src="/js/global.js"></script>
Conversely, cut clutter by removing unnecessary code:
<video src="foo.webm">
The following example doesn’t work as expected, because the presence of an attribute forces a true value:
<video src="foo.webm" autoplay="false" controls="false">
This works:
<video src="foo.webm" autoplay="true" controls="true">
This is more readable:
<video src="foo.webm" autoplay controls>
<a href="//en.wikipedia.org/wiki/Tag_soup">Tag soup</a>
Consistent formatting makes HTML code easier to understand, optimise and debug.
<h2><a href="/contact">Contact</a><h2>
…whereas at first glance this just looks like a link:
<a href="/contact"><h2>Contact</h1></a>
<A HREF="/">Home</A>
Mixed case is EVEN worse:
<H2>Pesto</h2>
Semantic means ‘relating to meaning’.
HTML markup adds meaning to content: element and attribute names describe the role of content.
HTML5 introduced a number of new ‘semantic elements’ such as <header>, <footer> and <nav>.
Using the right element for the right content is good for accessibility and helps ensure your code is understandable:
<div>Name: <input type="text" id="name"></div>
is better expressed as this:
<div> <label for="name">Name:</label> <input type="text" id="name"> </div>
This has a bonus side effect: the for attribute means that clicking on the label automatically throws focus onto the input element. This is particularly useful for checkboxes and radio buttons.
To reiterate: HTML should be used to add meaning and structure to content, not for styling.
Coding for email is nothing like coding for the modern web.
We won’t go into the gruesome details here – suffice to say that best practice for HTML email coding resembles web development from the late 1990s: tables, shim GIFs, inconsistent and minimal CSS, patchy image and media support, little or no support for JavaScript, and lots of minor hacks. (For an unpleasant taster, take a look at MailChimp’s most basic template.)
More information here, here and here.
This article is about HTML, but here are some basic CSS tips:
<!-- verbose :( --> <ul> <li class="ingredient">Basil</li> <li class="ingredient">Pine nuts</li> <li class="ingredient">Garlic</li> </ul>
<!-- better :) --> <ul class="ingredients"> <li>Basil</li> <li>Pine nuts</li> <li>Garlic</li> </ul>
Consider the range of devices, contexts and input methods that will be used to interact with your HTML:
<h4>W3C Web Accessibility Initiative ARIA guidance</h4>
CSS:
h4 {
font-variant: small-caps;
}
Whatever you do, test!
Build HTML testing into your workflow, toolchain and deployment processes.
Test page load on a variety of devices, on large and small screens, in a variety of connectivity contexts. Try interacting with your page with a text-only browser such as Lynx, or with a screenreader such as ChromeVox. Use emulators such as Chrome Dev Tools device mode to monitor changes. Page Speed, Web Page Test and other tools can be integrated with your workflow to automate testing before or after deployment.
For more information about how to write high performance HTML, follow the links in HTML, CSS and JavaScript resources and check out the guidance on Web Fundamentals.
I’ll be publishing a monthly roundup of news about media tech.
Sign up at bit.ly/signupmedia.
Archive at medianews.me.
Media Newsletter
Watch my Google I/O video: Fundamentals of video on mobile:
Video with captions on Chrome for Android
New on HTML5 Rocks: a detailed look at building servers for WebRTC.
html5rocks.com/en/tutorials/webrtc/infrastructure
I’ve built a site to provide simplest possible examples of HTML, CSS and JavaScript:
Motivations:
Caveats:
I hope it’s useful – comments and suggestions much appreciated.
It’s now possible to use WebRTC – PeerConnection and MediaStream – in Internet Explorer with Chrome Frame.
Best of all, getUserMedia no longer requires a flag to work with the Chrome stable channel – so, if Chrome Frame is installed, getUserMedia just works!
I’ve recorded a screencast that shows how to install Chrome Frame and configure Chrome in order to use WebRTC in Internet Explorer:
First, an explanation of how Chrome Frame works.
Google Chrome Frame is an open source plug-in that seamlessly brings Google Chrome’s open web technologies and speedy JavaScript engine to Internet Explorer 6, 7, 8, or 9.
When web developers add the Chrome Frame meta element to their web page, Internet Explorer will use Chrome Frame to render the page.
There’s more information about Chrome Frame for developers at developers.google.com/chrome/chrome-frame.
To try out WebRTC with Chrome Frame today, you will need to use Chrome’s Dev Channel. In the future, the WebRTC APIs will be available in both Chrome and Chrome Frame’s stable channels, without requiring any flags or other user intervention.
Installation steps
1. Download Chrome’s Dev Channel browser from dev.chromium.org/getting-involved/dev-channel. (This does not work with Canary.)
2. Quit all of your browsers.
3. Install Chrome’s Dev Channel.
4. Start Internet Explorer and install Chrome Frame from google.com/chromeframe?quickenable=true.
5. To enable PeerConnection, you need to set a flag by using regedit to create the following entry in your registry (as ever, be careful when using regedit!):
[HKEY_CURRENT_USER\Software\Policies\Google\Chrome]
"AdditionalLaunchParameters"="--enable-peer-connection"
Just to reiterate: the WebRTC APIs will be ‘flagless’ in future versions of Chrome and won’t need this kind of intervention.
6. Re-start Internet Explorer.
One tip: you need 32-bit Internet Explorer to use Chrome Frame. It’s normal to have 32-bit Internet Explorer, even for 64-bit Windows, but you may want to check. Just look in All Programs for the version named Internet Explorer!
Once you’ve set up Chrome Frame in Internet Explorer, try out the getUserMedia demo at simpl.info/getusermedia or the WebRTC video chat application at apprtc.appspot.com.
If you want to know more about how to implement real-time communication in your web apps, take a look at the detailed introduction to WebRTC and getUserMedia at html5rocks.com: html5rocks.com/en/tutorials/webrtc/basics, html5rocks.com/en/tutorials/getusermedia/intro.
Let us know how it goes!
I’ve written a detailed introduction to WebRTC on HTML5 Rocks.
I’ve tried to explain some of the more difficult concepts – please let me know if anything is still mystifying!
Pavel Feldman taking feature requests live from the audience
The Google I/O session I did with Chrome Dev Tools tech lead Pavel Feldman is now on YouTube.
Lots of new features to help you develop and debug on mobile and desktop: frame mode, the Sources panel, the new timeline, Source Maps, Web Worker debugging – and much more.
It’s a fun session, especially when Pavel shows how he uses the Dev Tools to build the Dev Tools…
If you haven’t had a look at the HTML5 track element — check it out my tutorial on HTML5 Rocks.
The track element provides a simple, standardised way to add subtitles, captions, screen reader descriptions and chapters to video and audio.
Tracks can also be used for other kinds of timed metadata. The source data for each track element is a text file made up of a list of timed cues, and cues can include data in formats such as JSON or CSV. This can enable DOM manipulation and other behaviour synchronised with media playback — as well as deep linking and media navigation via text search.
Raspberry Pi desktop
We got a Raspberry Pi in the office today, and hooked it up to a keyboard and monitor.
Raspberry Pi board, roughly Arduino size
In case you haven’t heard of it, Raspberry Pi runs Linux on an ARM processor and has a target price of $25/£15 for a pre-configured system.
Works a treat!
Just want to get Chrome on it now :^).
I can’t believe the things I’ll eat when I’m on a plane.
Cute!
That's a lot of ingredients
I’ve built a Google Chrome extension called Hold It! that pauses video when it’s not visible.
For example, when you:
Video play resumes automatically when it becomes visible again.
Useful when viewing videos on multiple tab pages, or if you click a link to open a video in a new, hidden tab.
Works for YouTube, Vimeo and on any site that uses the HTML video element.
Caveats: does not work for YouTube advertisements, and does not work on bbc.co.uk and some other sites. If you have a solution, let me know!
You can get it (for free!) from the Google Chrome Webstore.
How to use the extension
After installing the extension, any playing video will be paused when you move to a different tab or minimise a window. If you click on a link to open a video in a new, hidden tab, the video will be paused until you move to the new tab.
How does it work?
This extension uses the Page Visibility API.
The API can be used to check when a web page is visible to the user or not.
If you minimise your browser window, or move to another tab, the API fires a webkitvisibilitychange event.
When a new page loads, the extension looks for videos on the page — including Flash video and HTML video elements. If the page is not visible, or becomes hidden, all playing videos on the page are paused. Play restarts (for videos that were playing) once they become visible again.
Contest per lo sviluppo di applicazioni per il Chrome Web Store italiano.
Avete tempo fino a lunedì 12 Settembre 2011.
I’ve built a Google Chrome extension called Page Speed Test that uses the Navigation Timing API.
You can get it (for free!) at the Chrome Web Store.
The extension displays a timeline of navigation and page load events for the current page, and a historical chart of page load timing data for all visits to the page.
It’s still a bit rough around the edges, so I’d really appreciate any feedback.
Navigation and page load timing charted for all visits to the current page
Timeline of navigation and page load events for the current visit to the current page
For web apps to be as good as native apps, they need better context (right click) menus.
Take a look at the screenshot above. This shows what happens when you click on a person in a Google+ circle: I’d like to move the person from the current circle to a different one.
A ‘proper’ context menu would be very useful in this case, but of course what I get is the usual generic browser menu with items that are irrelevant to the task I’m trying to accomplish.
I know that you can add items to context menus in Chrome apps, for example, or hack them in other ways, that there are security considerations (if people add deceptive menu items), that many (most?) users never use context menus, and so on.
BUT…
There must be a way.
Sam Dutton’s blog 