Themes are control based and not html based – and as a result themes allow you to reuse almost any control property.
1)
a) Are there any control properties which affect the visual appearance of the control, but can’t be expressed through CSS?
b) If there are such properties, then I assume these properties are translated into Html and not CSS?! But that doesn’t make much sense, since CSS is far more capable of describing the visual appearance of a control!
c) Anyways, could you name me some of these properties?
2) I thought themes should be ( just like CSS ) all about presentation ( ie visual aspects of a Html document ), but that doesn’t seem to be the case, since controls also have many properties that don’t define the visual appearance of the rendered control?! In other words, I don’t see much usefulness for themes also specifying non-visually related control properties. Or am I missing something?
Thanx
Themes is an attempt at trying to replace CSS for redistributable controls. The main point of themes is that you have a more strongly typed syntax and a pre-built "skinning" framework.
In my opinion, Themes are a failure, for exactly the reasons you are describing - properties don't cover a wide enough range of DOM attributes to be more than marginally useful in specifying custom rendering for webcontrols. The additional coding needed to get obscure properties in negates the usefulness of themes the first time you need to code one. Additionally, having to learn an entirely new property syntax in order to abstract away CSS is counter-productive, since non-ASP.Net websites will never use it - in other words, it's just not standard.
Every webforms project I've worked on that started with Themes ended up dropping them for embedded CSS web resources.
To answer your questions:
a) Are there any control properties which affect the visual
appearance of the control, but can’t
be expressed through CSS?
I suppose it depends what you mean by "visual appearance". Adding an extra column to a grid, for example, certainly changes its appearance, but can't be done in CSS.
b) If there are such properties, then
I assume these properties are
translated into Html and not CSS?! But
that doesn’t make much sense, since
CSS is far more capable of describing
the visual appearance of a control!
Since a web page is basically HTML + CSS + Script, it makes sense that if the visual change isn't done with CSS, that it's probably HTML.
c) Anyways, could you name me some of
these properties?
How about the "Text" property on a <asp:Label>?
Themes are not "all about presentation."
Themes are simply a collection of CSS files, JavaScript files, images and skin files that work together. A Theme might contain a single CSS file, and have nothing at all to do with controls.
Skin files, though, are control-oriented. Skin files let you set property defaults for your controls. Most properties are default-able, not just the ones that control appearance. For example, if you're using GridViews in your application, skin files allow you to establish a standard appearance, rather than having to repeat the same property assignments every time the control is used.
StyleSheetThemes allow you to override those defaults on the page. Regular Themes take precedence over properties you assign on the page.
Also, collecting property defaults for your controls in a single place (the skin) makes them easier to manage, similar to what CSS classes do for HTML.
Related
Trying to figure out exactly what the limitations are, if any, in the Sitecore CMS Rich Text Editor fields when not using pre-loaded styles or modifying the Telerik RadEditor control. Basically want to know how far we can go using on page custom styles with the style tag. Will we run into any conflicts with existing pre-loaded CSS?
When committing style tags or inline styles to any RTE, it can be done, but don't do it. For one, if other editors are not aware of it, they can over write those styles with one change. Also style tags in the body of a web page will violate accessibility standards (depending on if your company needs to be 501 compliant). Also if your designer's classes are overridden, on the page it can be a nightmare to fix and maintain.
Recommendation: Typically I would make all CSS options for a rendering as rendering parameters, but if you really need embedded CSS, I would make a new text field on the template of the page/content, and have the developer pull that CSS correctly into the layout.
Here's a link, it's a bit dated but it does a good job explaining rendering parameters, which is the path I highly recommend:
https://sitecoretricks.wordpress.com/2018/03/31/understanding-the-rendering-parameters/
Like the title says.. why ?
I know why its required on the normal ASP.NET controls, there are numerous questions on SO about that.
But since you can only define .NET controls (no normal HTML markup) in the skin files, why is the runat="server" still required for every control in the skin file?
It has nothing to do with styles or themes.
Is there any reason why I still need ot add it to all controls in my skin files? Does anyone know what happens with it 'behind the scenes'?
Again, you have to understand how server side languages work.
All ASP.NET tags are transformed to browser-understandable HTML (a browser has no notion of what an <asp:button> is, for instance) by a server side pre-processor before the page is rendered. This means that all controls/modules/anything served by ASP.NET that's not just HTML needs to have these attributes.
I venture that the pre-processor was written originally to know what it needed to operate on based on the presence of that attribute. Otherwise it would have to process every tag even if it did nothing. It could've been written to just look for the namespace, but that would require extra processing.
A skin file is a special ASP.NET concept, for tags defined within the framework. Hence, it makes sense that these tags have to have the "runat=server". MS could've written a special rule into their pre-processor such as "if it's a skin file, assume it's all ASP tags"...but such rules really don't scale. Plus they're bad documentation.
As a web developer, you should understand which of your tags are actually HTML and which are convenience tags provided by the framework. The "runat=server" attribute makes that delineation explicit.
You can add runat="server" to plain HTML tags such as <input> but generally there's little reason to and it's a bad practice.
For portability moving forward, you may want to consider moving away from skin files and leveraging CSS. Attributes are very verbose for setting styles, which makes the end rendered pages larger (taking longer to load, providing poor user experience) and un-semantic.
Is it possible to change the default template of each ASP.NET server control? In WPF and Silverlight, each control is supposed to be lookless, so the developer can provide a user-defined control template to change how the control looks. If, for example, I want to use an outer and inner square/rectangle other than an outer and inner circle in a RadioButton, how do I accomplish that?
Don't have much experience with ASP but we used to work with Prado a lot (a PHP framework that behaves much like ASP .NET).
I would say the easiest thing to do is assign a CSS class to the component, which you should be able to do to any ASP .NET component and then simply use CSS to style the component.
At the end of the day, its all spat out to the browser as HTML anyway, so there's no real reason why you couldn't style it using CSS.
I recommend you don't use the standard CSS classes, unless you want all instances of a particular component to the look the same for your application.
We write a lot of Ajax apps and this is what we do.
ASP.NET has support for Themes and Skins. You can use a combination of skins and CSS (packaged up into a theme for convenience) to apply some styles to your controls. However, different browsers on different operating systems may render various controls slightly differently (for example take a look at how radio buttons are rendered). I'm not sure how much control you'll have over that behavior.
Since Themes in ASP.NET are used to style elements of your site, I was just wondering why would you use Themes rather than CSS, or is it common practice to use both? If so, when would you opt for one versus the other and why?
Just seems to me like Themes are kind of unnecessary, so I am just looking on clarification if there really is a good reason to use them, or it's just a part of the framework as an alternative(unnecessary) step to styling your site.
Imagine you have a site that, for whatever reason, uses dozens of asp:Calendar controls.
To style them with CSS alone, you'll have to set loads of properties on each one: DayStyle and TitleStyle and NextPrevStyle and on and on...
Using a theme will allow you to set all of those properties just once, and have it apply to every asp:Calendar on the site. The theme would contain the same CSS, but also the declaration of how to apply that CSS to server controls, which is something you can't easily do otherwise.
Of course, as Brian Hasden already said, you'll probably need some "global" CSS that lives outside of the theme (particularly if your site has multiple themes).
Themes have the benefit of being tightly integrated into the whole .NET environment so that things get themed without needing to specify their styles. It happen automagically like lots of other things in .NET. Based on that I can see the appeal for some people.
That being said, I personally never use the whole themes deal because I feel like it requires you to maintain two different sets of styles. One that's part of the theme and then others that are inevitably needed outside of the whole theming deal.
Maybe I'm just a control freak or dislike themes due to bad usage on previous projects.
When developing a web user control, I'm styling everything with CSS. Whenever I look at the control in the designer, none of the CSS is rendered, or course, because I'm not looking at it in the context of the page where my link element is declared to my CSS file. Plus, Visual Studio will include a warning:
The class or CssClass value is not defined.
for every class attribute I use.
I can get the designer to render the CSS if I include a link element in the control itself, but then I have duplicate link elements scattered throughout my pages.
Is there any way to get the designer to play nice with my CSS in a web control without injecting duplicate link elements everywhere?
Sadly at the moment, I think that's the best you're going to get as seen here.
The only good news I can see is this Connect Issue which is "Closed - Postponed", so they may well be thinking about it.
The issue you've got is that you can make a control display very differently depending on the CSS rules applied with the styles - so one style sheet or a combination of parent tags could make (for example) labels appear above their form elements, and another beside them - which would you want to display when you are viewing the User control out of the page context?