ASP.NET's Inline CSS

Will ASP.NET ever generate CSS the correct way...in a seperate .css file? Or am I simply unaware that it currently does if I ask it to?

I am not really sure what you mean. ASP.NET has the CssClass attribute that gets translated to class ='foo'.

If you use selectors those will work anyway. Only thing you cannot use is # selector. Usually skins give you enough power to do the same thing.

odujosh wrote:



I am not really sure what you mean. ASP.NET has the CssClass attribute that gets translated to class ='foo'.

If you use selectors those will work anyway. Only thing you cannot use is # selector. Usually skins give you enough power to do the same thing.

I'm talking about

MyObject.Style.Add("font-weight","bold")

Bah, nevermind, what the heck was I thinking? Hehe. Sorry, I spoke during the morning-time in a cold office without coffee...excuse my A.M.-Ignorance

odujosh wrote:

Only thing you cannot use is # selector. Usually skins give you enough power to do the same thing.

There's a workaround. Make ASP.NET handle the *.css extension then rig up your own stylesheet generator using control's ClientID attributes.

Alternativly! Petition The Guth to give us a ClientIDOverride property on INamingContainer.

W3bbo wrote:

Alternativly! Petition The Guth to give us a ClientIDOverride property on INamingContainer.

THAT is what I would love to see. No more of this ctl00_ContentPlaceHolder1_MyID crap...or whatever it says.

Nah, I wouldn't like to see that.. it's managed for a reason.. the form name might be important for certain bizarre interop. But within asp.net I don't think its at all important.

ID linked css classes aren't a requirement and the argument shouldn't be about inlining, but more that asp.net controls sometimes force their own inline style tags.. aka 'css UNfriendly controls'.

Generating css in its own class for you automatically.. not entirely sure it would achieve much..

The only way it could, would be by remembering 'signatures' of given classes, and reassigning them.. giving you the potential to optimize..

Otherwise, these linked in sheets could only be generated per page, and wouldn't gain any 'pluses'.

Personally I'd like a brother to the asp.net page system, based around xml and xslt.

You can create your own controladapters to let asp.net render fashionable xhtml or your own html style for your specific controls.

public class LoginAdapter : WebControlAdapter

{

protected override void Render(HtmlTextWriter writer)

{

writer.AddAttribute(HtmlTextWriterAttribute.Type, "checkbox");

writer.AddAttribute(HtmlTextWriterAttribute.Name, uniqueId + "$" + controlName);

writer.AddAttribute(HtmlTextWriterAttribute.Id, uniqueId + "_" + controlName);

writer.RenderBeginTag(HtmlTextWriterTag.Input);

writer.RenderEndTag();

.....
writer.AddAttribute(HtmlTextWriterAttribute.For, uniqueId + "_" + controlName);

writer.RenderBeginTag(HtmlTextWriterTag.Label);

writer.WriteEncodedText(labelText);

writer.RenderEndTag();

..... you probaly get the idea
}

}

etc. etc. Attach them to controls within the app_browsers folder and gone is that nastly html. Works pretty good with your own set of css files.

While you can read out the attributes here, I am unaware if you are able to write them on the fly to WebResources.axd and if it would make sense to do this each time a control is loaded. It's probaly better to keep them seperated in a css file.

You are actually complaining that the tool that does work for you doesn't do it the way you want.  Maybe you should stop using the WYSIWYG part and Visual Studio and actually just code it.

This was my big problem with VS.NET and how "easy" they made it to code things.  It speeds up my development considerably, but I still do a lot of hand coding.

I see more people yelling about ASP.NET's naming conventions for controls without ever thinking that maybe, I dunno, it's there to protect you from yourself (and from me too actually).

It prevents any controls from having identical ID's.

You can grab and set client side ID's into JS/CSS vars if you need to. I used to be really, really anal about the HTML that was outputted by my web apps. So, I wouldnt like a naming convention "cp_blah_blah_blah_whatever" either.


BUT ...

The payout for using .NET is undeniable. And when the rubber meets the road, your users want a site that works and fast. Even the technically inclined ones don't care about how human-readable your client-side ID's are.

JohnnyAwesome wrote:

It prevents any controls from having identical ID's.

But it also makes the IDs unpredictable.

If your page moves controls around differently when the page is generated, the element's id="" attribute will not be constant, so you can't use any external client scripts (those loaded with <script src="" />) or per-element ID styles.

The workaround, of course, is to use a wrapper element of some kind that's static XHTML, but this isn't always possible (especially with WebControls).

W3bbo wrote:



JohnnyAwesome wrote: It prevents any controls from having identical ID's.

But it also makes the IDs unpredictable.

If your page moves controls around differently when the page is generated, the element's id="" attribute will not be constant, so you can't use any external client scripts (those loaded with <script src="" />) or per-element ID styles.

The workaround, of course, is to use a wrapper element of some kind that's static XHTML, but this isn't always possible (especially with WebControls).

I've never had dynamically generated controls where it varies which container they're in. I suppose it can happen though.

My usual approach with scripts that need to use objects with ASP.NET-generated IDs is to have a global variable _prefix that sets the prefix for the controls (since I mainly run into this problem with master pages, all controls almost always have the same prefix).

Worst case scenario you can generate an inline script that sets variables that tell your external script the control names, e.g.:

<script type="text/javascript">
_myTextBoxId = "<%= MyTextBox.ClientID %>";
</script>

That's kinda what I do too, I mean prefixes are going to be 9 times out of 10 the same every time.