Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDevelopment and...Development and...Building ExtensionsBuilding ExtensionsSkinsSkinsSkinning enhancement 1 - Classes to address all instances of a moduleSkinning enhancement 1 - Classes to address all instances of a module
Previous
 
Next
New Post
9/9/2008 8:01 AM
 

Im talking about the real world

Lets asume that you are a skindeveloper. Selling skin to a market.... A new browser come to market, lets call it IE 8. As a good skindeveloper you make a new release of your skin handling some isssues regarding the new browser, maybee you will handle the 120 DPI or something. You release the new skin to market.

All customers get the new skin and install it. Whops...the skin.css is overwritten.

You cant assume that you have controll over every intallation. Im talking about how to make DNN better for the ecosystem.

Jan

 
New Post
9/9/2008 2:36 PM
 

I may be missing something Jan, but why not use portal.css in this situation?

 
New Post
9/9/2008 3:00 PM
 

Dave I use portal.css in those case I am sure the value will not effect other parts of the installation. Thats not possible in all cases

The reason of new feature to make portal.css optional is also an argument.

This post is about Skinning enhancement not how we do it today by adding .css here and there ...... The reson for having module.css per portal is obvious.

Today an admin have access to skin.css portal.css container.css but NOT module.css.

 

 
New Post
9/9/2008 5:13 PM
 

Jan, so you are talking about a skin you sell and the customer / admin makes changes to it..

Yes then they have a problem if they reinstall the new skin version and used an @import in skin.css.

IMO it's good an admin cannot access module.css BTW since this would be a problem if you upgrade the module.

I agree with Dave you should use portal.css in this case.

I don't see how a module.css per portal would be anything different from portal.css. (inheritance wise, since this only depends on the classes you use not which file the CSS is in)

Also the enhancement I'm suggesting here will make it easier to address specific modules, without influencing other parts of the module.

So I do understand what your trying to say, but IMO it's already covered by portal.css (you can add an @import there too if you want to separate the modules CSS)

 

 
New Post
9/9/2008 6:14 PM
 

No I am not talking about a skin I sell. I am talking about a skin anybody sell. And I am not talking about any admin making changes in the skin they buy from a vendor.

IM talking about customers who have a skin, install a module with a module.css that they dont feel fit to there skin in some point. The customer have no skill so contact the host (superuser) or maybee a skinner nearby and ask for a change. As the module is used by alot of portals changing the module.css is not an option. So ok the skinner could change the portal.css... Yes its an option. But as I tryed to say it could have inpact on other areas in the portal and adds yet another http request on each page load(DNN-8098). Furthermore the skinner have to find out what is included in module.css to solve the issue for the customer.

The skinner have no access to module.css from file manager.

Portal.css (if loaded DNN-8098) loads for every page module.css loads for those page that have module.css

So what I try to say is: To enhance DNN skinning it would bee good to have the module.css or better Modulename.css located uder the portal folder eg module.css per portal.

Yes.. if a new release of the module installs it will need actions but that could bee solved too (as portal.css)

I agree that good that admin cant change module.css in DNN today but im not talking about today im talking about enhancements.

Yes I support your intial enhancement too.

Jan

 
Previous
 
Next
HomeHomeDevelopment and...Development and...Building ExtensionsBuilding ExtensionsSkinsSkinsSkinning enhancement 1 - Classes to address all instances of a moduleSkinning enhancement 1 - Classes to address all instances of a module


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out