New plugin for CKEditor: ImageToolbar

Recently I've been working in order to create for Uritec a new plugin for CKEditor, it was needed due to the way that the Style system works in CKEditor.

First the Styles dropdown shows the styles that can be applied to the current element as well as its container(s); look at the official demo and select the image, now click on the Styles selector and you'll see there "Object Styles", "Paragraph Styles" and "Character Styles", something that it's not too user friendly if they just want to modify the image. The normal user wants simple things.

The second main problem is that even if they focus just on the Object Styles, you (as page author/designer) can't restrict the way that the styles work between them, so if you want to use a class to apply a 1px gray border, and a different class to create a slight rotation and shadow, the user can't apply both at the same time (unless you apply inline styles that we all know it's bound to fail).

So the goal was to allow to apply groups of classes that can be mixed so you set one group of classes to define different types of borders and another one to apply color filters, etc... Also, let's keep in mind that the align center has been disabled in CKEditor for those who prefer to use the classic Image plugin although it's easily done using display:block and margin:* auto, so one obvious group is alignment.

Putting all those buttons to show up always in the toolbar was considered a bad idea because most of the time they won't be used, and providing instead a "contextual" toolbar that shows only when an image is selected  was considered the best option.

Taking all of that into consideration ImageToolbar was born, designed to work in both classic (framed) editor as well as new inline mode, and compatible with the normal Image plugin and the Enhanced Image plugin. You can play at its demo with some predefined styles, but you can define whatever you want as long as you're able to do it with CSS classes. Or if you feel lazy today, check the 1 min. demo on YouTube.

If you use the Enhanced Image plugin you should know already that the way to define your CSS file requires taking some extra care, we have added some notes about it in a small guide about styling images in CKEditor, and due to those widget wrappers and upcast/downcast you'll find that it's much more powerful when you configure ImageToolbar with the classic image as you aren't restricted by the "Enhanced image" limitations.

Lastly, remember that unlike other plugins that claim to be free but then require you a monthly payment, this is a one time payment that will give you any future update.


Deprecation plan of IE8 in SimpleUploads

Die IE8, Die.

Planned deprecation of support for IE8 in SimpleUploads

We're already in 2016, Microsoft has stated that old versions of IE are no longer supported, and since some time ago Windows XP is not supported either.

IE8 is too bad according to any current standard, too limited and lacks too many features, it has bad security track, it's time to put it to rest and everyone of us has to work towards that goal and obviously one thing that we can do is to claim that those old versions aren't supported in our products, so people can realize that they have to change their browser to another one that has all those missing features.

So by the end of February I'll publish a new version of SimpleUploads just to remove the little parts that tried to add some kind of support for IE8.

I'll remove right now any claim in its description about support for IE8 and I'll update shortly the demo with the new version without support for any browser that lacks the FormData feature.

If you have any concern about this change, please comment here or send me an email, but remember that you can keep using your current version as long as you want if you prefer to support IE8 instead of embracing the future.


Die XP: Another benefit of Let's Encrypt

The Let's Encrypt project is a great initiative to move towards a more secure web, removing the costs to apply a secure certificate to a site and providing an automated client to take care of renewals.

This means of course huge changes across the whole the web industry:

Other CA will be forced to drop the price of their equivalent certificates to a bare minimum or make them free also, just to try to keep on some people looking at them.

Hosting providers will have to allow everyone to use a one click install of a free SSL certificate or at least manually update their certificates unless they want their clients to move to a friendlier hosting that allows setting up SSL without paying huge fees.

Website owners now will be able to avoid one of the problems (money) to install a SSL and this will be specially important for small websites. Big companies have enough resources that the cost of a certificate is nothing to them, but for a small website it's clear that every Euro counts, so most of the people didn't think at all about paying just to say that their site now can be used with https.

Hopefully this will mean the end of self-signed certificates or expired certificates, so end users will be able to understand better the difference between a secure site and a non-secure one and so after a while people will reject "old" sites that aren't using SSL, forcing those sites to install one, pushing their hosting companies to allow install of free SSL.

The government spies will have a harder time trying to track what everyone does, and no, this won't be an improvement for terrorists because they are already able to use secure communications but in Paris it has been clear that they used normal non-secure methods.

But there's one more benefit: Most of those small sites that now are installing SSL en masse are using shared hosting, so they don't have a unique IP and that means that they rely on SNI to enable https and it turns out that no version of IE under windows XP (as well as old Android 2.x phones) don't support it, so those that still keep using the old IE8 will now face a new problem because they will have constant security warnings whenever they try to visit all these new https sites.
And this is a good thing!!!

That people keep on using that old IE. I mean, it's old, old, old. Full of bugs, full of problems, a pain for all of us that try to create modern websites if you have to keep supporting it, and now those users will feel a little of that pain (although I guess that they are already suffering from all of us that have left IE8 behind and no longer test it).

Time to ditch IE 8 and move to a modern browser.


Updated demo for SimpleUploads

I've uploaded right now an updated demo to show the latest features of SimpleUploads and its compatibility with CKEditor 4.5

This post is part of the release as it aims to document the latests additions introduced since the last post about it (full details are in the history.html file).
  • Removed support for CKEditor 3.6. It's not a lot of code, but currently there's no reason at all to keep using a version so old and I doubt that there is anyone interested, so less code and less things to test.
  • Workaround for the CKEditor 4.5.2 change that  prevents dropping files on a dialog
  • Added ability to handle both the classic response from the upload of the new JSON format
  • Cleaned up and unified coding style with EsLint
  • Improved API and integration with other plugins like ImageCrop.
  • If the Upload Image button is used, launch a file picker showing only the images on your computer
  • Other minor adjustments and fixing of all the reported issues.
I'll finish all the testing and then I'll send the new version to all the clients and then I'll move on to add a feature that has been on my mind for too long

I also have to review and publish the full documentation about all the configuration options, public methods and events related to the plugin (instead of keep adding it in the plugin.js file or several pages and blog posts) (this will mean probably that I'll add more changes because I'll find some detail that I don't like)

PS: The current release of MS Edge doesn't support dropping files, but that's a missing feature in the browser, the next version currently available as beta already fixes this issue. You don't have to do anything on your side when it's finally released.


Taking a break to breathe is good and healthy

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.


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:
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


A Tweet is not enough

This Monday I did read a new blog post in Surfin' Safari about a new feature that Apple is introducing to make it easy to use the current system font on web pages. For whatever reason I was a little fed up with so many vendor CSS prefixes so I sent a tweet about it, but obviously it's hard to express things correctly on a tweet specially as I'm not an English native speaker and I'm not able to abbreviate things like all of you do because I'm afraid that then it will be even harder to understand what I say.

So after fighting only a little to avoid the characters limit I sent:
The mess caused by vendor prefixes on the wild is not enough, so we have new -apple webkit.org/blog/3709/using-the-system-font-in-web-content/ @jonathandavis
I'm not gonna copy each following message and reply as you can try to read it there, but I would like to point out some parts, a better explanation and say thanks to everyone that contributed as I think that it has helped to talk about the problem caused by the current usage of vendor prefixes.

I'm nobody, I don't work on a big company, I haven't written any book, it takes me too long to write things because I have to try to find the correct words so excuse me if this post has mistakes or it's unreadable, I've tried my best.

What did caused me to send that tweet?
It's known since quite some time that the current usage of vendor prefixes is causing harm in the interoperability between web browsers. Quite a few years ago we had the first browser wars between IE and Netscape where each one tried to defeat the other introducing new features as fast as possible and we all know that IE6 was the winner, so we had so many websites that took advantage of those proprietary features and the "Best viewed with IE" or "You must use IE to view this site" messages that most of us hated with passion.

It took many years to fight and reverse that situation, engineers had to work too many hours finding out the way that things worked and reverse-engineering the specifications. We also keep the perpetual "Mozilla" and "like Gecko" in the User-Agent, but currently this is absolutely getting out of hand.

So going again to a browser monoculture is something that I don't want and anything that points in that direction makes me cringe.

Currently other browsers are trying hard to avoid those same mistakes, experimental features are available only in "Nightly", "beta", toggling a setting in about:flags, using a command line parameter, whatever, ... but the common goal of that approach is to not expose experimental features for broad usage to the public web but the people that want can try it out, give feedback and find out if it solves the problems as expected.

But Apple is not planning to do that, they pointed out that this isn't aimed only at betas (although a day later he replied that it's only in beta at the moment, obvious as there's no final release ATM).

And one part that I found really offensive was this tweet about my comment that Apple doesn't remove the prefixed version of anything that they introduce:
And we will always support them (unlike some vendors that remove things at will). So what is the issue?
with other comments that I found ... we'll I think that it's better to not say what I'm thinking:
You can’t just break sites or apps. Apple doesn’t roll like that. A number of properties changed from prefixed to unprefixed too.
 It is what any company should say that cares about developer and user experience. An API is a contract and guarantee.
Just load the Release notes of any Mac OSX version and search for Deprecated Frameworks and Removed Frameorks.

So it's clear that Apple is able to deprecate and remove APIs even if they were the greatest new innovation at the time, but the obvious difference is that they have full control of the OS (if you don't like what we do, here's the door out), but on the Web they are playing the Embrace, Extend, ... game.

Going back again to the starting point:

Why are vendor-prefixes bad?
I'm not the one stating that, please read carefully this great post by Karl Dubost, take a look at what Mozilla and Microsoft has been forced to do just to have a chance of people using their browsers, and then tell me if this message from @ryosukeniwa is right or wrong:
I don't think proprietary CSS features aren't that bad since they fallback nicely. DOM and JS API are different, ..
But as I said, I'm nobody, please read what Daniel Glazman has to say about the matter. I'm really honored thinking that all of these great people have spent some time reading about my humble tweet, but then I have found out the real reason why I despite vendor prefixes: The CSS working group asked all of us to stand against them for the Open Web and it seems that the message got deep into my head.

That's enough for this post, I have many other things to say because there were lots of tweets and I don't want to mix the things here.