There's lot of truth on the post by @ppk "Stop pushing the web forward", and it has lots of replies, some very insightful and others that don't follow the reasoning. This is my take on it and you can bet that it will be closer to the clueless ones.
Browsers are adding new features, are constantly trying to find out what's missing and fill those gaps. That's great! we don't really want a whole full stop because we're always wishing than something works better, it's faster, it's doable...
But the current problem is that there are just too many new experiments, while old problems remain ignored and unfixed. You find a post stating that something is coming to the alpha version of a browser, that they plan to work on new features for the next release, but we're not able to correctly use the previously released features because it fails in some situations or it's implemented only in one browser and so it can't be used on the public web.
We need that those gaps are solved, we need to be sure that the existing problems are fixed before even more features are added.
For example pasting images into web pages:
Firefox pastes the data as base64, but it won't work on an input. But if you save it as a file in your computer, then you can Copy&Paste it and no other browser allows that.
IE11 won't paste any image unless you're using a contentEditable element, and in that case it even embeds the images included in a MS Word document, this isn't possible in any other browser.
Chrome allows nicely to paste a screenshot into an input, as explained above the other browsers don't allow this.
So a "basic" feature that users would enjoy across so many sites but that it isn't available in full form in all the browsers, don't you think that this is a good example of something that should be fixed before adding something absolutely new?
We'll always need better developer tools, tools that allow us to look at the pages and get more information, options to show warnings when something is wrong or we are using deprecated APIs. Don't get me wrong, the current tools are a million times better than what we had a few years ago but they still can be better: I'm in love with the CSS changes pane in IE11, there's no match for the mobile options in Chrome, I enjoy the UI from Firebug. And surely you can tell many things that you miss and wished that they worked better. All of this without new APIs.
So taking the time to review the bug trackers and clean them up doesn't mean that the web stops, it means that we remove the problems that we have and we can have a better solid future instead of lots of APIs that we can't rely on due to the number of bugs.
2015/08/02
On the font side of -apple-system
In my previous post I talked about the usage of vendor prefixes in CSS due to the introduction from Apple of the new -apple-system value for the font-family property.
I tried not to talk about the property itself and focus only on the issue of adding more vendor prefixed elements to the open web and today I want to expand that with my point of view about the value itself: -apple-system.
The theory upon which this new value is introduced is to help designers match the underlaying OS, and so we're supposed to treat it in a way similar to listing all the default OS fonts:
I know very little about fonts, but among those little things that I know is that each font has different metrics, so using such a mix of fonts will be a guarantee that the final result will be a disaster as soon as the user loads the page in an OS different than the one where the page has been designed, the carefully designed UI won't fit correctly because some elements will be bigger/smaller than expected, the font-weight won't give the correct feel, etc... using a fallback font is a kind of "last resort" and when you do that you try to suggest alternatives that would fit properly but you don't have that kind of guarantee when you use fonts designed from different OS.
Furthermore, someone that wants their page to match the system font won't stop just there and they will try to match the rest of the page as much as possible to the target OS and then we end up with only one targetted OS because obviously there's no kind of fallback to say: If you're on El Capitan use these icons, if you're on Android use this set, for Windows users, use this one, etc...
Even the same set of icons won't fit different versions of the same OS, the same way that they state that it would be incorrect using San Francisco in the previous versions of Mac OS X because that's not the native OS font. Whenever any OS changes their designers update the rules about drop shadows, colors, gradients, rounding of elements.... some times in a radical way, sometimes adjusting and improving the experience, but everyone is able to tell if any app is following the current OS or it has been designed for a previous one.
In the same way, a web designed to look & feel like a native app will look horrible (kinda like Safari 1.0 did on Windows) in any other OS, taking away the portability and abstraction that the web brought us.
Using this for embedded apps is absolutely OK, there's no doubt about where such apps will run so it's just natural that they try to match the OS, but the moment that anyone uses this on web apps and the public web it's a kick to the groin of freedom, the ability to load any page with any browser in any OS.
To see what this is about, load the video from Apple with IE11 for best results: https://developer.apple.com/videos/wwdc/2015/?id=804
I tried not to talk about the property itself and focus only on the issue of adding more vendor prefixed elements to the open web and today I want to expand that with my point of view about the value itself: -apple-system.
The theory upon which this new value is introduced is to help designers match the underlaying OS, and so we're supposed to treat it in a way similar to listing all the default OS fonts:
font-family: system, “Roboto”, -apple-system, “Segoe UI”, sans-serif;Except that no designer worth their job would ever do that.
I know very little about fonts, but among those little things that I know is that each font has different metrics, so using such a mix of fonts will be a guarantee that the final result will be a disaster as soon as the user loads the page in an OS different than the one where the page has been designed, the carefully designed UI won't fit correctly because some elements will be bigger/smaller than expected, the font-weight won't give the correct feel, etc... using a fallback font is a kind of "last resort" and when you do that you try to suggest alternatives that would fit properly but you don't have that kind of guarantee when you use fonts designed from different OS.
Furthermore, someone that wants their page to match the system font won't stop just there and they will try to match the rest of the page as much as possible to the target OS and then we end up with only one targetted OS because obviously there's no kind of fallback to say: If you're on El Capitan use these icons, if you're on Android use this set, for Windows users, use this one, etc...
Even the same set of icons won't fit different versions of the same OS, the same way that they state that it would be incorrect using San Francisco in the previous versions of Mac OS X because that's not the native OS font. Whenever any OS changes their designers update the rules about drop shadows, colors, gradients, rounding of elements.... some times in a radical way, sometimes adjusting and improving the experience, but everyone is able to tell if any app is following the current OS or it has been designed for a previous one.
In the same way, a web designed to look & feel like a native app will look horrible (kinda like Safari 1.0 did on Windows) in any other OS, taking away the portability and abstraction that the web brought us.
Using this for embedded apps is absolutely OK, there's no doubt about where such apps will run so it's just natural that they try to match the OS, but the moment that anyone uses this on web apps and the public web it's a kick to the groin of freedom, the ability to load any page with any browser in any OS.
To see what this is about, load the video from Apple with IE11 for best results: https://developer.apple.com/videos/wwdc/2015/?id=804
Subscribe to:
Posts (Atom)