You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Instantly share code, notes, and snippets.
Scott Jehl
scottjehl
Creator of Lightning-Fast Web Performance course. Author of Responsible Responsive Design (A Book Apart). Alum of @catchpoint / WebPageTest, @filamentgroup
Template meta tag pattern for template-based decisions
I've been finding this little meta[name='tmpl'] pattern useful lately when making template-based decisions in JS, such as when loading a particular file or set of files that are needed only on a particular page of a site.
First, in the HTML of a particular template, like say, a search result page:
One feature that would be extremely helpful when building with HTML5 appcache would be to request that an HTML document that references an offline cache always fetches content from the server (per ordinary caching header rules) when the network connection is available, and only "offline" when the server cannot be reached.
An example use case would be simple HTML document that refreshes regularly, yet should be available to browse offline, should the connection drop upon refreshing the page.
Here's a use case we had when building an app on BostonGlobe.com: Our app's homepage began as a simple list of a user's bookmarked links to articles, which were available to any device (JS or no JS). That list of articles would change constantly as a user bookmarked and removed bookmarks throughout the site. In modern browsers, that same list page would be enhanced into an application in which all of the bookmarked artic
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Could IMG@srcset be used sensibly in existing browsers?
Some early thoughts on img@srcset in the real world
Many agree that the newly proposed srcset attribute is much less syntactically intuitive than the widely appreciated picture element. I hope that the WHATWG and W3C review all of the efforts that the web dev community have put into the picture element proposal in their own community group and go back on this recent addition.
Syntax aside... if srcset was here to stay regardless of what we want, is there any way we could make it work in existing browsers without introducing unnecessary overhead or potentially buggy markup? At a glance, it looks shaky to me.
The main problem is request overhead, and attempting to work around that.
Given the following markup, existing browsers will prefetch/fetch the image referenced in the src attribute, and JavaScript can not prevent that request from going out. This means larger screen devices will request an unnecessary image for every imgset on a page - not good.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jQuery Mobile FixedToolbar Polyfill for non-fixed-positioning-supporting browsers (like iOS4)
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters