ID:1811683
 
Not a bug
BYOND Version:507
Operating System:Windows 7 Pro 64-bit
Web Browser:Chrome 41.0.2272.89
Applies to:Webclient
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
507.1274

Descriptive Problem Summary:
Layout not working as expected and click events aren't firing in the WebClient. Just so much inconsistency across the board. Somewhat frustrating experience. Wish I could just use bootstrap and be done.

Screen shot showing from back to front:
- WebClient rendering. Notice elements are stacked vertically and ignore absolute positioning. Element overflows container. Click events don't work on tabs.

- Chrome rendering. Everything as expected and events firing as expected.

- WinClient rendering. Notice elements are stacked horizontally and green container is ignoring the specified width on the parent container (the body).

- IE 11 Emulating IE8 renders and behaves as expected.



Example Source
http://files.byondhome.com/PopLava/WebClient_Layout_src.zip

I'm confused by the terminology here. What are you referring to when you say "WebClient" and "WinClient"? Chrome generally should deliver the best rendering, but in theory other browsers should work, if that's what we're looking at here.

Nevermind, I misunderstood the OP. So from what I gather, you are writing the interface in DMF and it is showing differences in the webclient and DS runs (bug #1) AND neither is performing as expected (bug #2). And the "chrome" test is just outside html to show how it should work?

Also, I recommend you update to the latest 507 just to be on the same page.
Your correct on the understanding.

Installed latest. Same layout problem. Example source is linked at bottom in case you didn't see it.

Server up with example here:
http://www.byond.com/play/23.99.84.35:8802

off to bed.
Okay, I looked at the code and this isn't a .dmf problem at all. The interface in question is entirely browser-based and exists within a browser control.

Here's the problem: The CSS you're using says that the webclient, being in a modern browser, is rendering this correctly. It's the embedded IE in DS that's incorrect, and by quite a lot. By default that renders in IE7 compatibility mode, which is just the way the embedded browser works.

I don't think this is "fixable" in the webclient, because you're relying on broken positioning behavior. The standard says when position is set to absolute or relative and no left/right/top/bottom is set, the regular static position should be used--which, because the div is a display:block element, should be below the text. IE7 however is acting like the block should go where the text ended, as if it were an inline-block, even though that block would appear below the text with position:static (the default).

IMO, anyone designing an in-game browser interface should try to make it standards-compliant and only massage for IE7 as needed. Or even better, add this to your document's head section:

<meta http-equiv="X-UA-Compatible" content="IE=edge">

The meta tag actually does work in the embedded browser, if you're not in quirks mode. Your doc currently is in quirks mode, however, so I would suggest adding a <!DOCTYPE html> to the top.

The methods I tried that made DS's embedded IE render your content correctly (the way the webclient does) were:

1) Use the aforementioned meta tag.
2) Wrap the "Click on the tabs" text in a div. This forces old IE to use the correct static position instead of trying to pretend the absolute div is an inline-block.
3) Don't use position:absolute or position:relative for .Pane at all. This is obviously not a good general-case solution because it could impact the div's content, but it does position the div correctly.

My recommendation is to use the meta tag and doctype, and simply design around that. Then your doc should be as standards-compliant as modern IE gets, and the result should display the same in the webclient.

(BTW, your code base was helpful in uncovering a bug with meta refreshes. It caused an issue for me in IE.)
Lummox JR resolved issue (Not a bug)