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

Already on GitHub? Sign in to your account

Add ability to add classes to <html> #103

Closed
badslug opened this Issue Apr 27, 2012 · 19 comments

Comments

Projects
None yet

badslug commented Apr 27, 2012

It would be useful to be able to inject html before or modify the outermost element. Alternatively, just have a meteor setting/flag to specifically address conditional styling.

The desired result is to use IE conditional comments to add styles to the outer element for cleaner, cross browser styling. See:

http://paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/

This is a technique used in popular html frameworks like HTML5 Boilerplate, ZURB Foundation, etc.

Currently meteor does not allow us to access on affect the tag that is generated (at least that I've found so far) preventing this technique from supporting older IE browsers.

Contributor

dgreensp commented May 23, 2012

I see what you mean. However, we don't currently plan to have special support for IE conditional comments at the top level of the document.

badslug commented May 23, 2012

How about just a hook to override the default tag text with our own arbitrary text? That would let us generate/inject the appropriate code we need without making it specific to IE conditional comments?

Contributor

dgreensp commented May 23, 2012

The HTML that's sent down to the browser on page load comes from a template in app/lib/app.html.in. The right hook would probably be to specify a different template for that.

You could hack your meteor distribution in the mean time, or there might be another way to achieve what you want. For example, conditional comments in the around stylesheets or script tags.

badslug commented May 24, 2012

Thanks for the pointers. Are there general guidelines for how to make these hacks in a way that is "safe" or forward compatible with updates. My fear is that doing a hack of this kind will mean I will have to have a process for supporting meteor update. E.g. if I replace app/lib/app.html.in with a custom file, when I run meteor update I'm assuming that will get overwritten or will it? I have some developers that follow my meteor project and currently the workflow is simple: git pull, meteor update, meteor. I don't want the step after meteor update to be a long check list of file updates to support hacks if I can avoid it.

I hope this isn't being unreasonable. I really appreciate what meteor does already and I'm very eager to see frequent updates.

Contributor

TomWij commented May 24, 2012

If you change to an approach where you can fetch the last commits from git instead of updating meteor, you will retain your changes and will be warned of any "conflicts" if the same line has been changed by both you and Meteor.

Note that you might be able to do something like $('body').addClass('ie'); instead, when the document is ready $(document).ready(function() { ... add the classes ... }. See QuirksMode on how to detect the browser...

It would even be awesome if somewhere were to add a smart package for this kind of stuff, as well as Modernzr.

badslug commented May 24, 2012

Hi Tom, I was hoping to make our hacks less intrusive if possible and avoid maintaining a fork of meteor. Meteor is changing so quickly that maintaining a vendor branch seems a bit daunting.

Your suggestion for doing something dynamic with javascript using QuickrsMode and/or Modernizer is good validation for me. Because of this issue I've been looking at using javascript to adjust styles based on the browser - we had already been going down that road to support a non-javascript stylesheet (that basically hides everything and shows a "You must have javascript" message since our web app requires javascript). I think I'll pursue that route rather than trying to hack meteor itself. Although I still think there are valid use-cases for injecting code before and substituting for the tag.

I've also been thinking about switching to bootstrap since there is a smart package for it already.

I agree having a Modernzr smart package would be awesome. I've been putting off building any smart packages until the API is approved by meteor to use. The other smart package I've been really wanting (and would be more than willing to build once the API is ready) would be one for jquery mobile.

Anyway, thanks for the input.

Contributor

TomWij commented May 24, 2012

Meteor simply does not work in any way if you don't have JS, I believe that it shows an empty page but I've seen there is an unsupported.html as well. I think it would do the former though, for people that don't have Javascript (not much do, I think).

Yeah, you could add the classes to the body or html tag and still continue to use the approach you did before.

badslug commented May 25, 2012

Ya, meteor doesn't show anything without javascript enabled. I hadn't played with that yet. I guess at some point sooner than later I'll have to figure out how to override the blank page when javascript is disabled. We need to display some message there to explain they need javascript...

I would think that even meteor out of the box should display some sort of "You must have javascript enabled to use this web app" default rather than a completely blank page. Unsupported seems to be for older browsers rather than no javascript at all. I guess this is either something we wait for the meteor guys to address or fork, patch and submit a pull request. My laziness has made me put off any patching of meteor (hence this whole ticket and thread) - the meteor guys are covering ground so fast it seems that I just wait a week and they've patched a ton of the things that I would have tried to work on. On the other hand, they have kind of hit a lull in small patches as they work on the deeper security stuff right now... I must keep working on project and not get pulled into patching meteor...

its42 commented Sep 15, 2012

+1

zeopix commented Sep 25, 2013

+1

+1

Contributor

awatson1978 commented Dec 18, 2013

Here's a pattern I commonly use for adding classes to the <html> tags.

Meteor.startup(function(){
  if(Meteor.userId()){
    removeWallpaper();
  }else{
    setWallpaper();
  }
});
setWallpaper = function(){
  $('html').addClass('landscapeLogin');
};
removeWallpaper = function(){
  $('html').removeClass('landscapeLogin');
};

And if you're using the event-hooks package, you can extend the pattern with the following.

Meteor.startup(function(){
  Hooks.init();

  Hooks.onLoggedIn = function(){
    removeWallpaper();
  };
  Hooks.onLoggedOut = function(userId){
    setWallpaper();
  };
});

This issue can be resolved with application code.

Contributor

mquandalle commented Mar 21, 2014

Fixed in e077e13 !

Owner

glasser commented Mar 22, 2014

@mquandalle well, sort of. actually, this has existed (with an unofficial API which has changed a few times, currently WebApp.addHtmlAttributeHook) since 0.5.8. The commit you found is just a refactoring of which code implements it. (Whichever release this goes into (likely 0.8.1) will change the API a tiny bit again...)

@glasser glasser closed this Mar 22, 2014

kfatehi commented Jan 28, 2015

Hi so I wanted to add Modernizr and had to figure this out. I ended up with this code, which is working.

Meteor.startup(function() {
  WebApp.addHtmlAttributeHook(function() {
    return {
      class: "no-js"
    }
  })
});
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment