Clean up the CSS

[jessmartin]

We shouldn't force styling on application authors. And we should make it easy for them to style their applications however they please.

This isn't done yet. Here are a few other thoughts:

• Preface all CSS rules in index.css with vwf- to avoid potential name conflicts.
• Review the editor, overlays, and browser requirements warning to see if they need special styles since I took out a few global styles.
• Seek and destroy any further inline styles.
• Clean out the support/client/lib/images directory. Certainly some old stuff in there.
• Remove the black background and 20px padding from the default style.

[davideaster]

I would go even further. The page should be almost completely under the control of the application author. In addition to your points:

• Hide all scripts inside AMD modules (except for RequireJS).
• No content in body that the application didn't add explicitly through *application*.vwf.html or a configured driver.
• No default styles.
• Make messages and dialogs transient. Allow the application to trap them and provide a custom implementation without the system modifying the DOM.

[davideaster]

And along those lines, what do you think about putting the overlay content directly in the body, as opposed to putting an ID on the overlay div? The application content will then be at the top and can do whatever it needs.

Here's a possible implementation: 66c93c4.

I also think the #vwf-root div should go away. I don't really know a suitable replacement yet, but I think the application should tell the views where to render (at least indirectly) instead of having to work around a fixed element.

[jessmartin]

@davideaster I like the way you're thinking!

Hide all scripts inside AMD modules (except for RequireJS).

Heck yes. I think we're most of the way there already with the recent changes, right? I think this will clean things up quite a bit.

No content in body that the application didn't add explicitly through application.vwf.html or a configured driver.

That would be amazing. Drivers could be responsible for injecting things into the DOM as necessary. It would be cool if the "feature detection" feature of each drivers could insert the appropriate error messages into the browser in a standardized way and place (that could also be disabled) whenever their feature wasn't detected. I.e., three.js needs WebGL, etc.

No default styles.

Yes. With this PR, we're getting close to this, only styling the editor and such. We'll still have some css included, but it will all be .vwf-* rules. Hmm.. I wonder if some users will want to turn that off or override those styles as well, though.

Make messages and dialogs transient. Allow the application to trap them and provide a custom implementation without the system modifying the DOM.

Yes. I have no idea how to do this cleanly. I'm thinking the config file.

[jessmartin]

what do you think about putting the overlay content directly in the body, as opposed to putting an ID on the overlay div?

Excellent idea. I think that .unwrap() works beautifully. Then the user can have whatever styles they want at their top-level. Including a div or something that wraps everything, if they need it. Cool.

I think the application should tell the views where to render (at least indirectly) instead of having to work around a fixed element.

Interesting. Again, that could be a config option. I'm thinking something like this in application.config.vwf.yaml:

drivers:
  threejs:
    renderTo: #threeJSFrame

And then in application.vwf.html:

<div id="myApplication">
  <div id="threeJSFrame"></div>

  <div id="otherContent">
    <p>Some stuff</p>
  </div>
</div>

If threejs doesn't find that config option, it could the insert the #vwfRoot div into the body and render into that.

[eric79]

There are already some good changes on this branch. I suggest that we go ahead an merge what's here so we don't hold those changes hostage while we are waiting on the rest. To that end, I just added the remaining tasks as Redmine story #4332.

@scottnc27603 @davideaster what do you think? Would you mind reviewing?

[davideaster]

👍 in principle. But since it's a little old, are you comfortable that nothing new depends on the styles are being removed?

[eric79]

80% confident. I rebased on development about a month ago and did some testing, and found no problems. It wasn't exhaustive testing, but I'm relatively sure that they're not needed. I would say that we should go ahead and merge it, and any apps that don't like the results can add the styles back to their individual app (which is what we would like to see in the future).