The Place for Styles in HTML and XAML
I got a question from the community.
When working on a Windows app, how do you get a complete list of the style properties that apply to any given HTML element?
The short answer is you don’t. And that’s not a Windows thing, it’s an HTML/CSS thing.
With a language like XAML/C#, you have properties that apply to certain elements because of the way everything works behind the scenes. It’s all strong typed and inherited, so when you start typing the name of a property, Visual Studio is able to look into the typing system and see which properties apply and suggest them via Intellisense. But with HTML/CSS, the CSS properties don’t belong to certain elements. Instead any property can be applied to any element and it’s up to the browser (hopefully adhering to the standards) to implement what happens. Some are obviously ignored. It doesn’t make any sense, for instance, to set the font of an image, so the image element will simply ignore it. This is not really a big problem in my experience. You come to realize which properties have which effect on which element at the same time that you learn what the properties are and what they do. And they’re mostly intuitive. But we can thank the openness and democratic nature of HTML/CSS for the matter.
The best way to get a complete list of CSS in my opinion is to bookmark aka.ms/iedevcenter and then visit that and click on CSS under the Develop section.
And the second part of the question was...
Why is it never a good idea to inline style properties when using HTML/CSS. After all, in XAML, we often write the properties right there in the declaration of each element.
The fact is that in both HTML and XAML, you can choose to add your styles inline (that is, within the element in the HTML page), or at the page level (in a <style> tag in HTML or in a page resource in XAML), or elsewhere (in a separate style sheet). And in both languages, it’s advisable to define your properties as abstractly as possible. Some people say “never use inline styles” (in fact, I wouldn’t be surprised if you’ve heard me say that), but actually, inline styling may have it’s place. It’s just too easy to create bad architecture once you start inlining things, so you should start on the other side… with styles elsewhere. Then if there’s a style that truly only applies to a single page, it should be defined on that page. Then if there’s a style that truly needs to overwrite what the page has determined for it, then you can define it inline.
Hope that helps.