Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clean up the CSS #151

Open
wants to merge 4 commits into
base: development
Choose a base branch
from
Open

Clean up the CSS #151

wants to merge 4 commits into from

Conversation

jessmartin
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

@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
Copy link
Member Author

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.

This should allow application authors to style their application's
containing <div> in whatever way is convenient for them.
@eric79
Copy link
Member

eric79 commented Feb 23, 2015

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
Copy link
Member

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

@eric79
Copy link
Member

eric79 commented Feb 24, 2015

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants