Page on khronos.org looks weird Topic is solved

[SlayerM]

Hi there!

https://www.khronos.org/members/list - this page in PM27 (and PM26 too) looks weird. It is normal on Chrome-based browsers. It's a bug of browser or site itself?

[Moonraker]

looks perfectly fine to me in pm27.
Could you be more specific in what way it looks "weird".?

[SlayerM]

Here the screenshots:

[dark_moon]

Can confirm this.
Don't know if this is related, but i get that in error console:

Code: Select all

Warnung: getPreventDefault() sollte nicht mehr verwendet werden. Verwenden Sie stattdessen defaultPrevented.
Quelldatei: https://www.khronos.org/assets/tools/min/?g=js_main&1611a
Zeile: 2

[Moonchild]

This doesn't render correctly in any Mozilla-derived browser. Possibly because they are relying on a Chrome-quirk in the way absolutely-positioned children in relatively-positioned containers are rendered (which the spec isn't clear about, last time I checked) but it may also be related to something else.

I tested in Firefox nightly (bad), release (bad) and MSIE (good) so it seems to be a Mozilla platform bug. Filed bug #1321985, see what the people who are more expert in the layout corner of Mozilla have to say about it.

[Moonchild]

Okay, update. It has nothing to do with positive/relative positioning.

Pale Moon and Firefox do this as they should be doing it. Chrome, chromium derivatives and MSIE are NOT doing this according to the HTML spec while we do.

The images are lazy-loaded into img elements that have no "src" attribute initially, so they are treated as "nothing".

The spec text that supports our behavior:

Firstly, the spec says this sort of <img> "represents nothing":

If the src attribute is not set and either the alt attribute is set to the empty string or the alt attribute is not set at all, the element represents nothing.

Source: https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element

Later on, in the rendering section, it explains what that means for rendering:

If the element is an img element that represents nothing and the user agent does not expect this to change, the user agent is expected to treat the element as an empty inline element.

Source: https://html.spec.whatwg.org/multipage/rendering.html#images-3

So, we basically treat it as if it were an empty <span> (as the spec requires). Without intrinsic width and height, the images will "overlap" if they are not small enough to fit into normal line heights+padding.

[ron_1]

Off-topic:
And it's things like this which is why Chrome/Google is ruining the internet. I wish Google and Chrome would just go away.

[Moonchild]

If you want this to get some attention to be fixed in Chrome, then I suggest you star it:
https://bugs.chromium.org/p/chromium/is ... ?id=671871

It's a clear spec-compliance issue but I guess if less than 10 people star it, it'll just end up under the rug (and getting it fixed in Chrome is a first step for all these "but it works in Chrome" sites to do it properly).

---

FTR I reported this to khronos' webmaster as well and they made a quick fix to their site and "will review in more detail tomorrow"