Category: edge

Posted on

A work-around for aspect-ratio percentage padding issues on flex items in older versions of Firefox and Edge

Whilst working on a recent project I needed to enforce a fixed ratio on some elements in the layout. In this case I used the ‘Aspect Ratio’ method which uses a ‘0’ height element with a percentage-based ‘padding-top’ value (More info about that in this CSS Tricks article).

The problem I ran into was that I was also using Flexbox for layout so each element was a Flex item, all of this was fine in Chrome and Safari and also in recent versions of Firefox and Microsoft Edge 17, 18 and in the upcoming 19.

But when testing in Edge 15 and 16 I found that the elements with the aspect ratio method applied to them were just completely invisible. Looking into it further I came across a Stackoverflow post and discovered that the issue was that in these versions of Edge they were supporting an earlier version of the Flexbox specification which meant that the percentage-based padding-top had no effect, basically rendering these elements with a ‘0’ height so they didn’t show up. It seems that the Flexbox specification was updated circa 2018 and basically brought it in line with the way Chrome and Safari have always behaved.

An alternative way of specifying the padding-top value is to use the ‘vw’ viewport-width units instead of percentages, whilst I found this did work to some extent it was harder to keep the ratios exactly how I wanted, but at least it was a way that would get these elements working in older version of Edge. Rather than having to completely redo my markup and CSS just to support these older browsers I wanted to see if there was a way to target only these earlier versions of Edge and use ‘vw’ units for Edge 15 & 16 but keep percentages for all other browsers.

As it happens I was also using “Variable Fonts” on this site which are only supported in Edge 17+, as such as I was already testing for Variable Font support by using ‘@supports (font-variation-settings: normal)’, so combining this with another parameter ‘(-ms-ime-align: auto)’ which allowed me to target Edge I came up with a workaround.

Here’s an example of how it would be used, in this case it is a 3-up layout so each element is 1/3rd of the page width so set at 33.33333% of the width and then a padding-top set to the same percentage. The first CSS block sets the main styles and the second block adds the ‘@supports’ check which overrides the first for matching Edge versions:

.aspect-block {
    padding: 0;
    position: relative;
    flex: 0 0 33.33333%;
    height: 0;
    overflow: hidden;
   padding-top: 33.33333%;
}

@supports (-ms-ime-align: auto) and (not (font-variation-settings: normal) ) {
    .aspect-block  {
        padding-top: 33.33333vw;
    }
}
Posted on

Adobe Edge Preview 5

I wrote a post "My thoughts on Adobe Edge" back in August last year which looked at Edge Preview 1 where I was mainly interested in seeing how the output of Edge compared with Flash in capability, size and efficiency.

Since then Adobe have been regularly updating the Preview releases for Edge and have just released Adobe Edge Preview 5, since the initial Preview 1 release – which was pretty bare bones in regard to functionality – they have added a lot of new functionality.

In particular two things I’m pleased to see in Preview 5 are "Publish to Web" which brings code minification and "Down-level Stage for non-HTML5 Browsers" which provides a way to set fallback content for non-HTML5 browsers:

  • Publish to Web — Optimize your content for deployment by specifying if jQuery should be packaged with the composition, or downloaded from a CDN to improve caching.Edge also transforms the _edge.js file, and minifies both the _edge.js and _edgeActions.js files, resulting in significantly smaller files.
  • Down-level Stage for non-HTML5 Browsers — Use the new down-level stage to design static (non-animated) compositions that are compatible with older non-HTML5 browsers such as Internet Explorer 8 and below.

It’s good to see the minification capabilities added as this definitely helps deal with the size issue that I highlighted in my Preview 1 post. I think there’s probably still a load of work to do in minimising file sizes as this is especially important for mobile devices.

I’m keen to see what new features are added in future Preview releases, one issue is in regard to responsive web layouts and how content created in Edge can possibly adapt to the dimensions of the device / browser window that it is viewed in, again for mobile access this is very important.

One other feature that would be very good is some way to reproduce the masking capabilities that is possible in Flash, in particular the ability to apply a non-square mask over some content. It is possible to clip content but this uses rectangular clipping by limiting the overflow of a containing div to be hidden. I can’t see how non-square cropping would be possible with the limitations of current CSS3 capabilities, I’d happily be proven wrong on this though.

Here’s a preview video published on Adobe TV which introduces the updated features in Beta 5:

Posted on

Rise of the Machines

As we move further into a post-Flash(1) web there’s a lot of excitement and hype about HTML5 and CSS3. These new technologies combined with the power of JavaScript frameworks like jQuery offer the potential to create much more dynamic, animated, interactive user experiences on the web.

Many tools are now being developed to make the creation of these experiences much easier (Edge, Sencha, Hype, MotionComposer, Animatable(2) etc). However, there’s a potential danger lurking under the surface with these apps and the many demos and samples showing off these new shiny features: Machine Generated Code.

Made in the image of Flash

Any serious web developer would not consider the HTML code rendered by tools like Apple’s iWeb to be clean or optimal but rather to be bloated and messy. With the rise of ‘HTML5’ and the previously mentioned apps it seems that some normally standards-aware developers are being swept along with the buzz, happy that you can now do all these cool animations that are ‘standards based’. But if you take a look underneath the surface and examine the code being output then there are causes for concern — a high or total dependency on JavaScript to generate HTML content, bloated ‘divvy’ code and no consideration for fallback content or graceful degradation.

The content created might be made using web standards like HTML5, CSS3 and SVG but in reality it fails in exactly the same way that Flash does — poor / non-existant semantic structure and a lack of accessibility(3).

Web apps

Another form of Machine Generated Code that is manifesting on the web is within many popular web apps. Take a look at the code under the hood of Google+ and you’ll see something like this:

Is that code any better than the code that is generated by iWeb? It’s possibly worse. How can a company like Google who has incredibly talented developers end up with code like that? Well, in Google’s case it was written using a templating system that uses Closure, these templates are converted by java on the server into HTML(4). Nothing inherently wrong with that process but the end result is HTML that is machine-friendly but is not really intended to be easily readable by humans.

So it seems that with the ‘rise of the machines’ demonstrated by tools like Edge, Sencha and Hype along with development frameworks like those used by Google that there is a loss of focus on the best practices of clean code, graceful degradation, progressive enhancement, accessibility. Instead the focus is on easy generation of code and content, with Edge and Sencha giving a visual WYSIWYG-ish interface with which to create it, and Google’s Closure / Java dev process enabling code-savvy devs to write in a non-web native language and have this automatically generated or compiled into the final HTML and JavaScript.

(Of course a counter-argument is that clean semantic HTML code doesn’t apply to web apps as they are ‘more complex’ than ‘regular’ websites! That’s something for further discussion).

Change begins at home

So, is there a solution to this? Well, the first solution is to consider these issues yourself. If you’re evaluating tools like Edge, Sencha or evaluating development frameworks then pay close attention to the code they create. If it seems to be falling short then take the time to give feedback to the companies behind them. In the case of Adobe’s Edge tool which is currently an early preview release on Adobe Labs then there is an opportunity to give feedback on the app and influence it at an early stage of development. Don’t just whine about it on Twitter but take the time to give feedback and clearly explain what you think is wrong and how it can be improved.

Muse

Talking of people whining on Twitter, I wrote this article and had it all pretty much ready to publish when Adobe released another product on Adobe Labs, Muse. Although the main focus of this article is on the more interactive, dynamic flash-esque content creation applications that have been appearing I couldn’t really post this article without briefly mentioning Muse (I did mention iWeb and talk about Google+ after all, both of which obviously don’t fit that category of app).

Muse definitely renders Machine Generated Code as it’s sole aim is to enable visual designers to “Design and publish HTML websites without writing code”. I have to admit that the first thing I did when viewing the Muse website (which is itself built with Muse) was to view source, and sadly I was disappointed with what I saw there – lots of nested divs, generally bloated looking content, and despite purportedly being ‘HTML5’ there were no HTML5 structural tags to be seen.

Many WYSIWYG apps have come and gone and have never managed to produce good clean code without requiring the user to intervene and clean up code, this doesn’t mean it’s impossible to create such an app, but it’s definitely a big challenge. As with Adobe Edge I’d recommend taking time to give good, reasoned feedback about what you consider is wrong with the output it produces, don’t just complain about it on Twitter.

Christian Heilmann wrote an interesting article called “Getting rusty – we need new best practices for a different development world” which I think gives an interesting pragmatic perspective on the debate about Machine Generated Code and why we rightly consider clean, semantic code desirable as opposed to that produced by apps like iWeb, Edge, Hype, Muse etc. His final couple of paragraphs sum up the thoughts and feelings that inspired me to write this post:

“Using web standards means first and foremost one thing: delivering a clean, professional job. You don’t write clean markup for the browser, you don’t write it for the end users. You write it for the person who takes over the job from you. Much like you should use good grammar in a CV and not write it in crayon you can not expect to get the respect from people maintaining your code when you leave a mess that “works”.

And this is what we need to try to make new developers understand. It is about pride in delivering a clean job. Not about using the newest technology and chasing the shiny. For ourselves we have to understand that the only one who really cared about our beloved standards and separation of concerns is us – as we think maintainability and not quick deployment and continuous iteration of code. The web is not code – the web is a medium where we use a mix of technologies fit for the purpose on hand to deliver a great experience for the end users.”

Footnotes:

  • 1: By post-Flash I mean as the only way to do interactive animated content on the web.
  • 2: Animatable looks to be one of the most promising apps being developed as the team behind it have kept the whole concept of falling back to non-animated content as core to the way the app works, basing it on actual HTML content rather than just created through JavaScript.
  • 3: I acknowledge that it is possible with recent versions of the Flash player to make Flash content that is more accessible, but generally Flash’s integration with Screen readers like Jaws etc is not great, and you have to specifically apply settings to the Flash content to help it be accessible.
  • 4: This information about Google+ development and other interesting info from this thread.
Posted on

My thoughts on Adobe Edge

Today Adobe published on their Adobe Labs website a public preview of a new application called Edge, which is described in their own words as:

"Adobe® Edge Preview is a new web motion and interaction design tool that allows designers to bring animated content to websites, using web standards like HTML5, JavaScript, and CSS3."

Having previously done a little comparison between the output contents and file size of their previously released Wallaby ‘Flash to HTML5’ conversion tool and that of Flash itself then I thought it would be good to do the same thing for Edge. However, the problem at the moment is – being only the first preview release – Edge has a fairly limited featureset with animation methods such as rotation, location (X / Y axis movement), opacity, scaling and skewing. Essentially some of the basic animation tools that you’d find in Flash. The problem with trying to do a comparison along the lines of the Wallaby test that I did is that I used a shape-tweened animation for that test, something which just isn’t possible at this time within the capabilities of Edge.

So, in lieu of being able to do a really exact comparison I have instead made a simple animation using one of the original SVG source graphics that I used for my Wallaby test. The main outcome of doing this test is just to see what the output of Edge is like – how many files does it create, how big is each file individually and in total. If you haven’t read the previous Wallaby post prior to this then in a nutshell the Flash output was far more efficient in both number of files and file size. Again it has to be said that a shape-tween animation is probably the most complex type of animation you could aim to do in this context, so I did set the bar fairly high there. But as tools like Edge and Wallaby are an attempt to try and bring Flash-esque timeline based animation creation to the world of HTML5/CSS/JS/SVG then it’s fair to expect that beyond some simple x/y movement and rotation that shape-tweening is something that people – especially those from a Flash background – will want to create.

‘Edge Case’ sample: Rotating an SVG in Adobe Edge

So, here’s the simple animation I created in Edge. I imported an SVG file which I had used for the Wallaby test and applied a simple 360 degree rotation to it, a lot simpler than the Wallaby test but I thought it was worthwhile bringing in an SVG file to see what Edge did with it.


View Edge’s Output in new Window
Download the Edge Assets as a Zip

Adobe Edge’s ouput HTML, CSS, JS etc

Here are all the files that Edge created for this example:

  • edge-case.html: 1kb
  • edge_includes/jquery-1.4.2.min.js: 72kb
  • edge_includes/jquery.easing.1.3.js: 8kb
  • edge_includes/edge.0.1.1.min.js: 32kb
  • edge_includes/edge.symbol.0.1.1.min.js: 29kb
  • edge-case_edge.js: 5kb
  • edge-case_edge.css: 1kb
  • images/noun_project_182.svg: 1kb

Total: 149kb

So, to get that basic rotation animation of an SVG file we get almost a 150kb payload in order to make that work. I haven’t bothered creating a Flash (or video) version of this animation as I think it’s fairly clear that it would be possible to get a smaller file size using Flash to create it. Edge and tools like it have obviously got their work cut out here, especially with the huge use of mobile devices then file sizes and number of separate files in a site (i.e. minimising server calls etc) is an important issue.

We’ve definitely got to cut Edge some slack though here, as small as Flash files can be it’s important to remember that the entire runtime for Flash is a plugin whereas as HTML / CSS / JS etc is supported by the browser’s native features, Also the JS files used by Edge are providing a kind of runtime in the form of some Javascript functions which gets added to every animation that you create with it. Presumably this could be alleviated by having this file be published only once and then referenced, or better yet by being hosted by Google’s CDN and referenced that way along with jQuery which Edge also includes with each animation.

Adobe Edge: Just a tool for Flash-ers or true HTML based creation?

It’s hard to say at this point how these tools will be used, a big area will surely be a replacement for Flash-based interactive / animated advertising, again file size is very important here as Flash banner ads often have a maxmimum payload for ad networks of about 40kb, so Edge is not competitive here.

I think my biggest concern about these tools is that they simply become a swap-in replacement for Flash and that people start to use them purely from a visual perspective and not considering the structure and semantic meaning which underlies all HTML pages. It is *HTML*5 after all, even though that term is often used as a buzzword to include JavaScript effects, technologies such as Canvas, SVG etc. It is extremely important to remember that semantic meaning is at the core of HTML. As such animations created with tools like Edge should keep that at heart and include a workflow that encourages this fact, not just enabling ways to make things move around the screen etc. So I’ll be interested to see how things progress with Edge.

Despite that concern it is still great to see tools like Edge and Sencha Animator being released, the uptake of complex JavaScript based interaction and animation is certainly hindered most by the lack of capable IDE’s to make the process quicker to do. Hand coding jQuery animation and interaction is fine but a good IDE would enable you to keep on top of the code being used but also make it much quicker and efficient to develop using these technologies.

Anyway, that’s my thoughts having played around with Edge, I’ll have to go catch up with some reading online and see what other people are saying, feel free to comment with your own thoughts!