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.


Creating a responsive Div with proportional dimensions

When you create a responsive layout, you might need sometimes to embed an element (classic example: a YouTube iframe) in a way that it scales down for smaller screens, keeping the aspect ratio.

The way to do that is to wrap that element in a parent div, and control the dimensions of that Div:

<div class="responsive-wrapper">
</div >
In the CSS you can then use something like this:
.responsive-wrapper {

.responsive-wrapper iframe {
The trick is that the .responsive-wrapper is a 0 height div, and it has only a padding-bottom defined as a percentage so that means that its total height is really based on the width of its parent.


Ok, we all have seen that trick, but: what happens when want to limit the width of the embedded element?
If your page has enough width and the embedded element takes 100% width it might look too big, so you might want to limit its width to 800px for example.

Well, the solution is not really complex after thinking a little: just wrap everything in another div with max-width, that way the total width that .responsive-wrapper will be always limited to our maximum and the height (given by padding-bottom) won't grow as we resize the page.


Anyway, defining the padding as a percentage ( = desiredHeight * 100 /desiredWidth) doesn't look nice to me, I wanted to be able to use only defined widths and heights.

What I want is the intrinsic behavior that img has, so that we can define width and height as well as max-width, max-height.

There's a solution for this using vw units, that way the element will keep the aspect ratio, but it's gonna be messy again to keep a maximum width that works correctly in mobile: if you work only with the .responsive-wrapper and try to set max-width:800px you can add now max-height:300px for example, but if you have set width:100vw then the element will create an horizontal scroll as soon as you keep some margin on its sides.

So you still need to keep that extra wrapper div.

But there's another interesting solution, why don't we use an image to give us that ratio automatically? This idea is explained on StackOverflow by Elliot Richerson 

It's good to have different options and I find this one interesting, you just need to add an image with the aspect ratio that you want as the first element of .responsive-wrapper and with width:100%, height:auto and then you can apply the max-width/height to .responsive-wrapper itself.

Obviously this still forces us to add an extra element and now you have an extra http request to download that image, that you have to recreate for every aspect-ratio that you need.

And then I thought: Would it be possible to create such image on the fly?
At the moment I'm working with javascript (not only static html), so my crazy mind starts to think: I can use a data-url, and even I can try to find out what's the basic structure of a .gif and create a fake one with the dimensions that I want, then base64 encode it and use it as the src of the image.

Wait a minute man! that's too much work, we're in 2015, you can just create a canvas, set it to the desired size and get its content as data-url without the need to find out how to create a .gif or .png

But, but...
Yes, I can use a canvas instead!

so the new trick is to use a <canvas height="300" width="800"> and then in the CSS
.responsive-wrapper {

.responsive-wrapper iframe {

.responsive-wrapper canvas{

The nice part of this solution is that you can use whatever units you want, and the aspect ratio is defined in the HTML, so you can use this class with different elements and even add other media queries for whatever other effect you might need.




Testing DevTools, take 2

This is my second day testing Firefox Developer edition.

Almost right after start, I get a notice that there's an update ready, clicking it a dialog was shown stating that the update was ready to be applied. So I agreed and waited, this should be transparent and done without such dialog, specially when frequent updates are expected due to the usage of the alpha channel.

The prompt to save passwords has changed, I'm not sure if previously it showed the user name, but now it has a field with the masked password below it that it's absolutely useless, it can't be edited, it doesn't provide any info, Why are they wasting time and effort in things like this?

So I started working, the first changes were mostly server-side to send new data and modify some JS, then I added two breakpoints to check that it was working as expected, some adjustments, I browsed a little, took a quick look at the network tab, its layout is somewhat different like the Clear button at the bottom right instead of the top left like all the other tools so at first I thought that it wasn't available.

Then I went back to debugging, but now those two breakpoints no longer work. No matter if I remove and add them again, reload the page..., the script isn't stopped and so I can't use Firefox to debug javascript. After restarting Firefox and adding again the breakpoint at the same place this time worked, but my usual reaction at this point is just to switch to another browser and go back to Firefox only when everything works perfectly in other browsers and I have to review Firefox.

I want to check as I'm not sure the value of the document.ELEMENT_NODE constant so I type document.EL and as it's already shown in the autocomplete I press Enter and it uses only "document.EL" so it says that it's undefined, so I press Up arrow, Tab and it shows in light gray "<- again="" autocomplete="" br="" english="" exact="" i="" if="" in="" is="" m="" makes="" not="" pressing="" results="" sentence="" so="" spanish="" sure="" tab="" the="" this="" without="" work.="">In Firebug and IE the first Enter does the autocomplete and then pressing it again shows the result. Chrome behaves like Firefox on the first step but after pressing Up arrow no matter how many times you press Tab, the autocomplete doesn't work.

Back to CSS, trying to add or edit a pseudo-element like a::before it's not possible, the rest of the tools allow it; Chrome even shows them in the DOM tree.

Trying to do some basic testing with Mobile isn't even fair. IE11 has the very minimum, Firefox improves it a little, although not really too much and Chrome is hands down the absolute king. Several features really useful that makes it a non-sense try to use any other tool to start checking for mobile:
Touch emulation: the pointer turns into a fingertip and :hover no longer works. Absolutely a must.
Device list: instead of a list of sizes, it shows devices by their name, and it also adjust other things like the device pixel ratio, so it's easy to get a good view of how it will be viewed on such screens.
Rule with @media rules in the page, good to find the breaks and verify them.
Zoom control, nice.
Network emulation, so far I haven't used it too much, but it has obvious benefits without the need of using external tools to simulate throttling. I know that I'll use it because otherwise it's impossible to test how a remote server works with different conditions.

I've decided to test now the WebIDE to connect to my phone. Yesterday I did a quick test and I gave up. I saw "Chrome on Android" listed and I picked it but nothing happened, and today I realized that then I must go to the left and click on "Open application" and the open tabs are listed there and debugging starts.
So then I tried to debug Firefox as I already debugged Firefox on Android some time ago, and then I realized that it's not done automatically and I had to enable the remote debugging on it, this should be hinted more clearly, when an Android device is detected, create an entry linking to how to enable debugging of Firefox.

One "annoying" thing is that every time that I connect again to Firefox on Android it prompts me to accept the connection, with the only options as "Disable", "Cancel" and "Accept", but not a "Yes, always allow this device", Chrome doesn't do such things.

When connection to a device Chrome clearly shows the list of open tabs and allows to close, open a new one or change the url, as well as proxying the request to localhost, another must have to be able to test changes without having to upload to a server.


Firefox DevTools, a long way to go

This Monday I tweeted about the bad state  of JS debugging in the current releases of Firefox where both Firebug and DevTools are no longer useful because they ignore most of the breakpoints.

I got a reply from suggesting me to use the alpha version AKA as Firefox Dev edition, but I pointed him that it's known that it lacks behind all the other tools, so I would prefer to wait until the most obvious bugs are fixed (I linked some that are important for me).

Yesterday I got another reply suggesting me to give DevEdition another try, and so this evening I've started by opening a document where I've been writing down this experience of installing and trying to use the latest version. It's not from the point of view of a new user because I've tested it a little bit, but I might not be aware of awesome things just because the problems that I find force me to use other tools.

The first step is instaling the Firefox Dev edition, I picked the custom install and of course I rejected the option to install it as my default browser, that's a non-sense that when you install a new browser you're going to make it the default right from the start (yes I know that everyone does this since Netscape times).

After launching the first thing that I notice is that the UI lacks the rounded borders of the normal Firefox. I notice also how slow are the UI animations (it feels the same way in the normal Firefox, but I don't see them because I've added the Classic Theme Restorer and that way I don't have to use the hamburger menu). That's a problem with Firefox itself trying to create useless animations, not with the DevEdition.

Then I try to use it on a site and the obvious first stones appear in my path, the history, autocomplete, credentials, everything is empty so I have to type everything again. Not a big problem, but it will force me to waste my time. It should have prompted me to import such data from Firefox or to use Sync as this seems a sensible use-case. As it didn't offer me to use Sync I'm not sure if that would be a good idea or it's risky to use it with different versions at the same time.

So let's start testing it.

I add a new CSS property "max-wi" TAB, now I type 0 and press Arrow UP, it changes to 1 but it's unitless so it doesn't work. Firebug and Chrome correctly change from "0" to "1px", IE11 behaves like Firefox.

Now it's time to save the changes, I adjusted only one rule but when I try to use the context menu there's no "Copy rule" like Firebug or IE11, I have to manually select the text like in Chrome.

Extra Bonus points and the main reason that IE11 it's now mostly my prefered tool for CSS adjustment is its Changes pane that shows all the CSS changes made in the page. Certainly it's a little buggy sometimes and it could have several enhancements, but all the rest of developer tools lacks anything like this and it's precious to be sure to know all the adjustments made across different elements.
Chrome seems to have something related with the History pane, but honestly I haven't figured out how to make it work as I want.

One thing that DevTools doesn't seems to know is that "0" is "0", it's unitless so when I write "margin: 0 auto;" it's wrong to change it to "margin: 0px auto;". Firefox and Chrome respect my 0 and IE11 does it correctly for "margin: 0 auto;" but not for "height: 0;" (test by checking a property written in the stylesheet that way or modifying a property and switch to another element and back to the modified element)

Other clear sign that these tools aren't ready: Use the context menu and select "Add rule", change the selector or leave it as is, now Tab and you'll find that you're now nowhere, you have to click inside the rule to add a new property. All the other developer tools correctly place you ready to type your new property as that's the only logical thing to do after creating a rule. This breaks the workflow and makes me waste my time moving my hands from the keyboard to the mouse.

Bonus points go to Firebug because while editing a rule you have a super useful autocompleter based on the parent node names, ids and classes. No other tool has this.

Trying to work a little with javascript, put a breakpoint, check the DOM, reload the page. All the tools except Firefox DevTools correctly switch the selected pane to the script that has the breakpoint and DevTools just show that tab in green stating that execution is stopped and waiting for you to click.

Another day I will keep on testing and reporting the differences, but so far I haven't seen anything in Firefox that made me want to use it.