The data tree (in some makeshift looking markup pseudocode):

BODY {
    DIV (id = main) (byondclass = child) (skinparams = [left = map, right = output, splitter = 50]) {
        DIV (id = map) (byondclass = map) {}
        DIV (id = output) (byondclass = output) {}
    }
    DIV (id = input) (byondclass = input) {}
}

ID:
used in CSS and JS to identify an element in the DOM (Data Object Model), or data tree.

byondclass:
Used by BYOND to identify which element is used for skin controls, in the example above:
child = A child control
map = A map control
output = an output control
input = an input control

skinparams:
Used by BYOND to specify the skin control's parameters. These are pretty much identical to how Skin Controls were used. In the example for the child control:
left:map; = control's left pane is ID "map"
right:output; = control's right pane is ID "output"
splitter:50; = the child splits vertically at 50%.

a DIV tag in HTML is generally used as a container for other tags, and is usually used for organization. You can use other tags besides DIV, but it's best suited to use these because of their flexibility.

The BODY tag is necessary to show any content in am HTML webpage. It specifies the data in a webpage itself.

Hang on. the MAP tag is not the same as what is used in this example. A map tag is used as an image with clickable areas. id=map is pretty much saying "the element's ID is the string 'map'." the ID can be anything you'd want it to be. CSS and JS use it to identify the tag when trying to manipulate it.

some sample javascript:


Also, to answer your question about skinparams, it's used to specify any variables that would normally be used in winset() and winget() calls in normal DM. See the Skin Reference on what variables you can change using skinparams.

First a minor correction: There was an error in the skin reference at the time you posted, so the colons in skinparams should actually be = instead.

Now the full answer. The webclient itself handles interpreting this info. Here's the process that happens:

First, when you log into the webclient, you're connecting to the host machine which serves up a dummy HTML page. That downloads the webclient.dart.js file which is compiled from the webclient's Dart source, and then once a proper connection is established the server sends all the control and prompt types it uses along with either a default skin, a translated skin, or a .dms skin you've defined (preferring the latter).

The webclient then will load all of those control prototypes so they can be used, and it will build the skin. The skin goes through an interpreter that looks for divs--they must be divs--with a byondclass attribute. That attribute maps them to a specific known control prototype. If a control type is found, a new control is created and attached to that div. Its skinparams info is used to do an initial winset().

The interpreter I mentioned is just a piece of the webclient that analyzes HTML code. The webclient is a JavaScript program that runs in the browser, from inside a frame that points to the game server.

I'm not sure what clarification you're asking for about the winset() there. Like I said, when a new control is created, its skinparams info (if any) is used to do a winset(), so that the control has all the properties you want it to.

The web-client is a combination of javascript, and HTML5.

Lummox Jr. confused me I think... Anyone care to clarify my questioning. Thanks.

Bump

Ok let me try another approach, appreciate your honesty though. In another post you mentioned this:

The meat of the client is in a .js file that gets delivered, which is compiled from Dart. The .dms files are controls and prompts.

The client responds to certain events, like output messages, and calls the appropriate routine such as byond.skin.output()--which is setup by the compiled Dart code--and that by default will look for the right control and call the control's output() function.

If you write a custom control with a custom output() function, you can send output there just like you would to an output control or grid. (In fact we don't have a grid yet, but this setup will allow for one to be created.)

The meat of the client is in a .js file that gets delivered, which is compiled from Dart. What do you mean delivered?

Thanks. Just to be sure.
Check my definition of special web page.
Special web page is what would contain something like skinparams = "left:map;" correct?


Summary: User, connect's to web client page by sending request. Web client page sees the request and responds with a NEW page know as a special web page. The special web page runs a script that downloads webclient.dart.js

The script of the special web page downloads webclient.dart.js and right after tells web client page to load web.client.dart.js and right after tells web client page to request controls and skins from the hosted server.

The hosted server hears and responds to the web client page telling it what resources it needs and right after the web client page downloads them from the hosted server.

Once its download is complete, web client page displays the logging in interface.

Lastly web client page initialized downloaded resources per DM's hierarchy flow- world New(), client New() mob New() ect.

Anything off in what I said?

Side note: Not sure how busy you are. Visuals on this workflow would be amazing.
Side note: skinparams = "left:map left, here means http://www.w3schools.com/cssref/pr_pos_left.asp or does it mean http://www.w3schools.com/jsref/prop_style_left.asp

Sir Quizalot wrote:

I guess what I'm really having trouble understanding is how the sever knows what to send back. What is packaged in a dmb that makes it so it can be reached to with html when the dmb is being hosted on a computer.

skinparams = "left:map" for example isn't normal Javascript? Am I wrong?

skinparams="left:map" isn't JavaScript; it's an HTML attribute. Although in this case it's also wrong; it should be skinparmas="left=map". I could have sworn I fixed that in the webclient docs, but I see the wrong thing is still there. Very strange, but I'll fix it soon.

So as for how the server knows what to send and what parts are packaged in the .dmb:

The .dmb does not necessarily contain anything relevant to the webclient. The webclient will attempt to use any controls or skins you compile in via .dms files, and will also try to translate a .dmf skin (if you don't have a .dms skin, which takes precedence). But none of those are required.

All of the built-in controls and code for the webclient come from the web dir on the server, which is located in your BYOND installation directory. I.e., in your installation you should see bin/dreamseeker.exe, and so on; there's also a web dir that contains a bunch of .dms files, defaultSkin.dms, and some JavaScript files including webclient.dart.js--which is the webclient itself.

The very first thing the server (DD) does when someone connects is respond with an HTML page that includes some JavaScript files--among which are webclient.dart.js. Once that loads, it establishes contact with the server and the server starts to do all of the pre-login stuff, like delivering the translated or built-in skin (if relevant) and any .dms controls found in the web dir. Any .dms info compiled into the game is also sent.

But yeah errors still exist in documentation. Would be helpful to see the edit instead. Thanks.