Wrong render of dota2.com on mako RTM #11

[Riccardo Padovani]

Some page of dota2.com is rendered bad on mako RTM#11, but I'm not able to reproduce the same thing on desktop.

Depending on the page, the entire page is cut on the left (like http://www.dota2.com/shiftingsnows), or background images are moved to the left (like http://blog.dota2.com)

I think (but I'm not sure) it's about div with left property that is a child of a div with a negative marginLeft. In fact, I'm able to reproduce it on this real simple page: http://people.ubuntu.com/~rpadovani/touch/oxide/oxide.html
The first text is cut off on the left on mako, while on every other browser I tried (chromium on desktop, android browser on phone) render it right

[Olivier Tilloy (osomon)]

It looks to me like those pages are fundamentally badly designed, as they assume a minimum viewport width, and when the viewport is narrower, they render poorly. I can easily evidence it by browsing to http://www.dota2.com/shiftingsnows on my nexus 7: in portrait mode, the entire page content is shifted to the left as you describe, but in landscape mode, it looks ok.

[Chris Coulson (chrisccoulson)]

I'm not sure what you expected to happen when you have a div that is relative positioned with "left: 50%" and a left margin of -800px on a screen that is about 341px wide. By my calculation, that puts the left edge of it at about -630px. With the div containing an absolute positioned element with "left: 400px", that puts the start of the text at about -230px - well off the left edge of the screen.

I tested this in Firefox and Chrome in responsive design mode with the screen resolution from mako (569x341 DIPs), and I get exactly the same result. This isn't an Oxide bug at all

[Riccardo Padovani (rpadovani)]

Sorry, but I don't agree with you.
Accordingly to the reference[0] the left property, when expressed as percentage, is referring to containing block's width.

Both in my example and in dota website the block has a width of 1600px, expressed explicitally.

So we have "left" and "margin-left" that removes one with the other, and we remain with only left: 400px of the child.

And this is what I have on all browsers, also with responsive design mode, but Ubuntu Browser on Mako.

I agree with you that the pages are badly designed, but as user if a website works well on Android with Chrome (tested on Galaxy S2, Galaxy S4 and Moto G) and with Stock Browser (tested on Galaxy S4), I expect it works well also on Ubuntu.

I don't change status of the bug because I'm not involved in the project, but please take another look at this

[0]: http://www.w3.org/TR/CSS2/visuren.html#propdef-left

[Riccardo Padovani (rpadovani)]

Also Windows Phone with Internet Explorer renders as expected (see screenshot).
Other screenshots from others devices will follow.

[Chris Coulson (chrisccoulson)]

Yes, "left: 50%" on a relative element will place it in the middle of the containing block. But in this case, the containing block is the document element and the width of the document element is the width of the visible viewport minus the width of the vertical scrollbar if there is one (in this case, 341px). Testing this in responsive design mode in Firefox and Chrome shows the same layout issue as Oxide, as expected - note, don't turn on mobile emulation - just set the size manually. More on this.....

The reason this works in other mobile browsers is because they set a minimum viewport width (in Chrome for Android's case, it's 980px). We should probably do the same in Oxide on mobile form factors to fix this.

(That doesn't change the fact that setting a margin in pixels will scale poorly on different form factors)

[Chris Coulson (chrisccoulson)]

Ok, http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/revision/899 seems to fix it

[Chris Coulson (chrisccoulson)]

Hrmmm, that broke everything else on mobile quite badly. http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/revision/900 fixes it up, but there is still an edge case where the layout will break (dynamically adding or removing the viewport meta element). I'm not sure how to fix that without carrying a blink patch to turn on the Android bits that deal with this