Can we fix it?

Last month we were shown a new HTML UI from one of our embedded partners. When displayed in Flow, it showed a button with text incorrectly displayed over an icon. We've known for a while we had a few problems with buttons as many of them were the wrong size, or their content wrapped too soon. This gave us a good reason to investigate them all.

It turns out, the contents of Flow’s buttons were laid out as if everything were a flex item, not quite following the spec. Since flex items can not float, any button with a float inside would render incorrectly.

Buttons are used far more often than I’d expected and pleasingly, with this fixed, many sites looked far better. The Guardian and eBay now render their down arrows in the correct place without strange wrapping, and The WorldWideWeb Rebuild now renders its missing title bar icons.

As this button fix showed major layout improvements on many of the websites we have blogged screenshots of, it seemed a shame to not fix the remaining layout bugs.

After the buttons were fixed, all the alignment and sizing layout bugs at the top of YouTube had gone away. It has a problem with search results, but the only remaining problem with the rendering was a few centimetres of whitespace below the video, above the title. YouTube’s stylesheet is enormous and it at first appeared to be a CSS variable or a flex bug. After a lot of test-case trimming, it turned out to be that we hadn’t yet implemented percentages inside CSS calc() when applied to padding properties, in this case, padding-top: calc(9/16*100%). Helpfully, that code had been written a while back but hadn’t then been tested enough to commit.

Outlook demonstrated the most bugs in Flow but some were trivial fixes once we understood the problem. The horizontal alignment of each email subject was down to incorrectly subtracting the padding twice from the flex-basis size. The PDF icons had an enlarged grey background because of a problem with box-sizing: box-border when calculating the intrinsic sizes. Both took far longer to figure out what the problem was, than to fix it.

The magnifying glass in the search icon was too low, which turned out to be another flex bug (‘the main size of a fully inflexible item with a definite flex basis is, by definition, definite’). We also didn’t support placeholder text on input elements which needed shadow trees to be mostly implemented. After that, we found the 'Search' text was in the wrong colour which was due to Outlook's CSS not using ::placeholder, only the various vendor prefixes.

Finally, Twitter has a redesigned page since we last took a screenshot so it’s hard to know if the original alignment issues on there have been fixed or not. The new page had some problems that we had to fix. The search box in the top right was missing (actually off the right edge of the window) and each tweet’s date was vertically aligned incorrectly. The search box was off the side because it is absolutely positioned and positioned in relation to an incorrectly calculated static position. The incorrect date alignment was because the baseline code was skipping the baselines of flex containers.


If you’d like to automatically receive our posts by email please join our mailing list.

Design Trends

At Ekioh we’re regularly looking ahead to see what browser features are set to become popular. As part of this, I’ve recently spent some time reading the future design predictions from a number of web designers and design houses. As you might suspect there are some wacky ideas being peddled, but on the whole, most designers seem to be agreeing on a few concepts and techniques that look set to shape the way websites and product user interfaces will evolve over the next few years.

Isn’t it nice when things just… work?

Back in 2003, Honda released Cog. It was an amazing advert. I even ordered the free DVD – there was no YouTube back then. If you haven’t seen it, it’s worth watching – it has no CGI and no smoke and mirrors. It, apparently, took 606 takes.

Flow browser passes the Acid tests

The three Acid tests have a long history; they really started the push for browser compatibility that is now driven by the Web Platform Tests project. Having finished Flow’s support for full Google Mail, Acid3 seemed like another interesting target.

Getting Fired up during lockdown

Because of lockdown we’re all working from home at the moment so my access to hardware is somewhat limited. On a whim, I decided to try Flow on my Amazon FireTV Stick and was a little surprised to find it wouldn’t run. I grabbed some logs and asked colleagues what they thought the problem might be. They were able to quickly spot what the issue was and they gave me a build to test within a few hours. Armed with a working version I thought I’d see how Flow compares with the other browser options that are available.

Is the wider appeal of HTML being eroded?

For a while now, people have been expressing concern about Chrome’s dominance creating a browser monoculture. With Microsoft’s recent switch to Chrome, the choice of rendering engine was effectively reduced to Blink (Chrome), WebKit (Safari) or Gecko (Firefox). Whilst there are a large number of browsers for desktop and mobile users out there, almost all are based on Blink/Chromium.

As well as displaying web content, HTML browsers are used in a wide variety of products for application and user interface rendering. The potential effect of one company dominating the implementation of the standards is that they are biased towards web page rendering, their largest use case. Focusing solely on web content could limit the wider appeal of HTML.

MotionMark test results: Jan 2020

It's been a long time since we last posted MotionMark scores. I thought it would make sense to re-run them with the latest versions of all browsers.

All tests were run on a MacBook Pro (15-inch, 2018), with a 2.9GHz 6-Core Intel Core i9. I disabled mail and Time Machine to minimise interruptions. Unlike our previous, more thorough, analysis, I only ran each test three times. That averaged the results but, since I wanted screenshots, I chose the test run with the highest score in each case.

The scores for the various browsers were:

Flow (5.8.0): 1087.51, 1196.89, 964.05

 

Safari (13.0.4): 755.13, 756.02, 734.09

Chrome (79.0.3945.130): 268.70, 287.16, 286.46

Firefox (72.0.2): 83.27, 110.63, 85.52

Firefox (72.0.2 with WebRender): 226.53, 284.43, 272.61

On every embedded device we have tried, Flow also comes top, but macOS is the only platform where Safari, Chrome and Firefox are available.

 

Ordering from Amazon the using Flow Browser

Being a big fan of online shopping, I’ve been keen to see when Flow could successfully complete a transaction on amazon.co.uk. It’s fair to say that online shopping is not a target use case for Flow, so I wasn’t going to get any engineering time dedicated to this; instead I was relying upon the product’s ongoing development to do the job for me.

Devblog: Fixed point vs floating point

I had an interesting problem with one of the sites I tried loading a while ago. weibo.com was using jQuery (version 1.7.2) which tries to detect browser features, and decided Flow was actually Internet Explorer. It later tried to use IE-specific filters rather than CSS opacity, so no fades worked. I tracked this down to jQuery’s startup code setting opacity to 0.55 and then getting it back out again. Since we converted 0.55 into 16.16 fixed point too early, it was retrieving it as 0.549988. That wasn’t equal to 0.55, and so jQuery decided Flow didn’t support opacity and therefore must be Internet Explorer.

Smooth animations with CSS will-change

In user interfaces it is very common to apply animation effects in response to user input. Some of the most common effects involving fading, sliding or zooming UI components in or out to redirect the user’s focus. In HTML/CSS this is typically achieved by modifying the opacity and transform CSS properties, by using CSS transitions, CSS animations or Javascript. What you may not realise is that setting these properties can have unexpected effects on the rendering order, and even the layout of HTML elements.

How can UIs keep up with higher resolution video?

If you buy a new TV today, the chances are it is 4K. It’s quite strange that the UIs on these TVs are still rendered at 1080p and upscaled, but that’s the reality. It means that any text and graphics in the video stream, such as football scores, are visually sharper and clearer than the TV’s own menus and app UIs.

How we test a browser

Browser testing has come a long way in the last 15 years. Back then I worked for a small embedded browser company with a test team that manually checked websites. This was tedious, and inefficient as there are only so many sites a person can visit in a day.

When I joined Ekioh, I was pleased to see they had taken a more modern approach from the start. There was a genuine passion for product stability and a strong desire to avoid the embarrassment of regression bugs.

More detail on the MotionMark test results

Ekioh’s multithreaded HTML browser is rapidly making a name for itself as being the fastest browser available. Whilst Blink based browsers like Chrome currently dominate the market, they might not be the best choice for application and middleware rendering. As the MotionMark benchmark confirms, Flow’s performance is streets ahead of the competition.

Devblog: Filling vector paths on the GPU

Since starting work on Flow, our focus for the rendering engine has been on HTML/CSS. The number of basic shapes and painting styles used in HTML/CSS is quite small, which has allowed us to create a highly specialised engine using the GPU for all painting tasks. We’ve also supported elements in Flow for a while, but until recently all canvas rendering was performed on the CPU.

Does a multithreaded browser use more power?

Recently I was discussing Flow, our multithreaded browser, with a friend of mine who questioned whether a browser using all the cores would be beneficial in battery operated products like their new smart watch. This prompted me to do some research and the results were surprisingly in favour of our multithreaded approach.

Devblog: Rendering HTML/CSS on the GPU

When rendering web pages most browsers use a general purpose graphics library to do all their drawing. For example Chrome uses the Skia graphics library. This makes sense for cross platform browsers since they can use a single drawing API and leave the implementation details to the graphics library. The graphics library can try to optimise the drawing operations using some platform specific 2D hardware acceleration, or using a 3D library such as OpenGL/DirectX to take advantage of the GPU. If there is no hardware acceleration available the graphics library can do all the drawing in software using the CPU.

Devblog: Google Mail in a clean room browser

Google Mail (Basic HTML) screenshot

Flow only recently added limited HTML form support and that lets us log into Google. We hadn’t concentrated on forms as they’re barely, if ever, used in TV UIs and there was plenty of other stuff to get on with. Pleasingly, Google Mail (Basic HTML version) rendered very well the first time we were able to log in. Full Google Mail doesn’t work yet, but it makes sense to start with the basic mode first.

Devblog: From SVG browser to HTML browser

In 2006 we started writing a clean room SVG browser, primarily targeting set-top boxes. Back then, user interfaces were written in native code (usually ugly and inflexible) or HTML (very slow). We emphasised how it was equivalent to a web browser but, rather than an HTML parser with CSS box model layout, we parsed SVG markup. SVG takes negligible time to lay out and uses CSS sparsely, so we massively outperformed HTML browsers on equivalent UIs.