Sites

Firefox 49 fixes sites designed with WebKit in mind, and more

Several recent articles on the Hacks blog explain why web developers should care about cross-browser compatibility and how great web developers achieve it. Web developers have a critical role in making the web work for everyone. And so do browser makers. As of today we’re introducing a number of compatibility features to the Gecko rendering engine, bringing us up to date with the WHATWG Compatibility Standard.

Some notable changes in this release include support for several -webkit- prefixes and WebKit-specific interfaces. These platform features are non-standard, vendor-specific, and quite prevalent.

Non-standard, incompatible CSS breaks websites for user agents designed around standards. When a browser that doesn’t support -webkit- prefixes (such as Firefox 48 and below) visits one of these sites, the web looks broken. This will be the case until those sites update their CSS. That’s why Firefox 49 includes the following changes to accommodate WebKit-specific content:

(in)Frequently Asked Questions (iFAQ):

Q. So, what does this mean for me?

A. As a user, improved compatibility with sites that were designed for WebKit browsers only, especially on mobile.
okcupid

As a developer, you might want to go back and add unprefixed equivalents to your -webkit-only CSS so we can remove these from the web platform one day in the future (theoretically). Pro Tip: Unprefixed properties always come last.

Q. Did you just break my site?

A. We hope not! But you can toggle this for testing with the following preference:

about:config?filter=layout.css.prefixes.webkit

If there’s a difference (for the worse!), please report bugs to bugzilla.mozilla.org and cc mitaylor@mozilla.com, or report them on webcompat.com.

Q. Should I only use -webkit- prefixes from now on?

A. No, that’s unnecessary and inadvisable. Keep using web standards and keep testing in multiple browsers. If you must use -webkit- prefixes (and there are fewer reasons to do so than ever before), make sure they’re above the unprefixed property in your CSS.

Full disclosure: Mike edits the Compatibility Standard, but there’s work to be done if you’d like to contribute!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

100 super useful web sites allowing one simple task each

I just came across this post on imgur showing lots of cool little helper sites. Sadly there were no links in the description, so using some Sublime Text Magic, I converted them.

Just to find out later that not only do imgur posters either post screenshots of links or unlinked links, no, all of this was once again stolen content.

The original list is maintained by Amit Agarwal so please go on to:

The 101 Most Useful Websites

Excellent work, Amit, shame people don’t respect it.

To make this not a total waste of blogpost, at least here is how I used Sublime Text to turn a list of non-links into a list of links using a bit of regular expression knowledge (go fullscreen).

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

A few questions and answers about “mobile web” and sites vs. apps

I just got asked to provide a few answers for a survey amongst “mobile web experts” and thought it’d be good to re-use those here. So here goes:

What is the difference between a web site and a web application?

There are a few differences. On a very basic level applications are catered for doing things whereas web sites are more catered for offering content for consumption. Web sites started as structured, interlinked academical documents. Later on we added multimedia content to make them much more engaging but all in all they are fixed in their state.
Applications are more dynamic. They allow for customisation of the interface and store the state of what happens so that when you get back to it you can go on from where you left off.

The use case of an app should always be to do something with it. This could be as simple as voting on a how much you like a kitten photo and go as far as editing video content live in your browser or on your device. Basic examples would be a webmail client as an application and a pure image gallery to click through as a web site.

Web sites are static whereas web applications have atomic updates and in of themselves have a very small footprint as most of the content gets loaded subsequently and changes every time you use it.

All in all it is a sliding scale though as for example an image gallery can easily become an application if it allows you to upload your own images or edit and remix the existing ones in your browser. That is one of the main benefits of web technology – it is very flexible and allows for quick and simple changes to the final product without being hindered by a complex compilation, packaging and deployment process.

What kind of features should a web site have to be qualified as a web application?

Again, there are many things to consider. One main thing is that an app does one thing and one thing well. It is there to help you do something.

Technically it should behave like the fat client apps of old: it should retain my state and settings, allow me to customise the interface to my needs and it needs to work offline. The latter is not a technical necessity in terms of definition but to me crucial usability. Seeing how flaky our connections are – I am writing this on a plane – our apps should make people as effective as possible and this means we shouldn’t be dependent on a connection. The interface should be usable whilst we are off the grid and sync as soon as we go online.

Customisation and personalisation of the interface and interactivity to me make an application. This could just mean a game where I can change my character and get extras the more I play. A proper “web” application to me also should use the web whenever it can. For example I am very frustrated with playing a game on my phone and when I go to my tablet playing the same game my score and achievements aren’t synced although the device knows who I am. Why be online then?

A lot of badly designed web apps are just wrappers for content like a news feed. For example turning a blog into an app is a pointless exercise. It just adds the overhead of having to install the wrapper, update and uninstall it when I am fed up with the blog but doesn’t give me the “do something” part that defines an app.

If I don’t interact with it other than reading there is no point in making it an app. You lose a lot of the flexibility of the web when packaging HTML as native apps with the most important thing being opaque updates. An app that is hosted on the web can be patched and upgraded without the end user having to download megabytes of data. That is incredibly useful on slow or flaky connections. Instead of the whole app you only download the changes.

What is the difference between a mobile-friendly site and a mobile web app?

A mobile-friendly site is a web site that detects the capabilities of the device it is displayed on and doesn’t make assumptions about how big my screen is and that I have a mouse and keyboard or not. It runs in the browser of the device and is thus hindered by its limitations – which in the case of older Android devices are quite limited indeed. It caters to the mobile space in terms of display changes – single column display, larger fonts, larger buttons.

A mobile web app is an application built with web technologies running in an own, full-screen wrapper and not inside a browser. It takes advantage of all the things the current environment allows for. For example it stores content and itself locally instead of having to be online and requesting everything new every time you open it. It can access the special features of certain environments like swipe gestures, accelerometer for interaction or accessing the camera to get content in. Its purpose is for me to do things with it and not just visit it like I visit a web site.

What would you consider is the key feature that made HTML5 (as opposed to Flash and Java) the number 1 choice for developing mobile web apps?

Flexibility is the super power of HTML5. It is easy to make an HTML5 app adapt to a new environment and to make an interface that shows and hides content and functionality dependent on the capability of the device or environment. Both Java and Flash are not “web native”, meaning you need to initiate and execute an own code environment inside a browser before you see the results. This hinders interactivity of the containing document and the content of the Flash movie or Java Applet. Whilst both Java and Flash have incredibly good development tools and capabilities once they are available they are very demanding to the hardware they run on. That’s why iOS devices don’t have Flash. There is already a fully capable environment available – the browser – and executing another one inside it means using a lot of resources. On mobile devices this means shorter battery life and the device heating up quickly.

With HTML5 we have the opportunity to improve what mobile, web enabled devices already have to have – a browsing environment. These are available open source and for free (Firefox, Chromium and others) and developers can build apps without needing to sign up for one company and get their SDK to get started.

All environments have their uses and there are things that are better done in Flash than in HTML5. Betting on open technologies and browsers means though that you are very likely to be flexible enough to cater to the next environment around the corner. The web has always evolved and mutated around the needs of the market. That’s why multimedia in HTML5 is just another element of the document and not a black hole that can not interact with the rest of the browser or the document.

Where would you say the mobile web is heading? Do you see a future for the mobile web?

There is no mobile web. There is the web. Right now we start consuming it more and more on mobile devices. That is cool. And the web is totally ready for that as it is flexible enough to adapt.

If you use web standard technologies to build applications that expect a certain device, a fixed size of a screen, a special way of user interaction or expect a fast connection you are building a very limited and very quickly outdated piece of software.

Over the last years we should have learned that hardware is a commodity and susceptible to very sudden change. An amazing piece of hardware that is the hot new thing now can tomorrow be embarrassingly outdated.

When you build your web apps to only cater for that you try to be native code and that is a race you can not win. A lot of native apps are built to promote a new piece of hardware and to get people to upgrade. That is a very old technique of selling more products called in-built obsolescence.

Web apps should be beyond this. Our job is to give end users the best possible experience on the current devices but not make them a necessity. We did this mistake in the past which is why you see web applications that tell you that you need a “modern browser like Internet Explorer 6” and “at least 800×600 resolution”.

Native apps on high-end devices are doing really well right now, but I can foresee that people will get bored of having to buy a new phone every year just to get new functionality that is not that important when you consider the cost. The web will stay and always be the open alternative for those who want to consume and create on their own terms instead of being dependent on the success or goals of a certain company.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)