[c#] How to edit CSS style of a div using C# in .NET

I'm trying to grab a div's ID in the code behind (C#) and set some css on it. Can I grab it from the DOM or do I have to use some kind of control?

<div id="formSpinner">
    <img src="images/spinner.gif" />
    <p>Saving...</p>
</div>

Make sure that your div is set to runat="server", then simply reference it in the code-behind and set the "class" attribute.

<div runat="server" id="formSpinner">
   ...content...
</div>

Code-behind

formSpinner.Attributes["class"] = "class-name";

If all you want to do is conditionally show or hide a <div>, then you could declare it as an <asp:panel > (renders to html as a div tag) and set it's .Visible property.

Add runat to the element in the markup

<div id="formSpinner" runat="server">
    <img src="images/spinner.gif">
    <p>Saving...</p>
</div

Then you can get to the control's class attributes by using formSpinner.Attributes("class") It will only be a string, but you should be able to edit it.

Make sure that your div is set to runat="server", then simply reference it in the code-behind and set the "class" attribute.

<div runat="server" id="formSpinner">
   ...content...
</div>

Code-behind

formSpinner.Attributes["class"] = "class-name";

Add the runat="server" attribute to the tag, then you can reference it from the codebehind.

This question makes me nervous. It indicates that maybe you don't understand how using server-side code will impact you're page's DOM state.

Whenever you run server-side code the entire page is rebuilt from scratch. This has several implications:

• A form is submitted from the client to the web server. This is about the slowest action that a web browser can take, especially in ASP.Net where the form might be padded with extra fields (ie: ViewState). Doing it too often for trivial activities will make your app appear to be sluggish, even if everything else is nice and snappy.
• It adds load to your server, in terms of bandwidth (up and down stream) and CPU/memory. Everything involved in rebuilding your page will have to happen again. If there are dynamic controls on the page, don't forget to create them.
• Anything you've done to the DOM since the last request is lost, unless you remember to do it again for this request. Your page's DOM is reset.

If you can get away with it, you might want to push this down to javascript and avoid the postback. Perhaps use an XmlHttpRequest() call to trigger any server-side action you need.

Make sure that your div is set to runat="server", then simply reference it in the code-behind and set the "class" attribute.

<div runat="server" id="formSpinner">
   ...content...
</div>

Code-behind

formSpinner.Attributes["class"] = "class-name";

If you do not want to make your control runat server in case you need the ID or simply don't want to add it to the viewstate,

<div id="formSpinner" class="<%= _css %>">
</div>

in the back-end:

protected string _css = "modalBackground";

This question makes me nervous. It indicates that maybe you don't understand how using server-side code will impact you're page's DOM state.

Whenever you run server-side code the entire page is rebuilt from scratch. This has several implications:

• A form is submitted from the client to the web server. This is about the slowest action that a web browser can take, especially in ASP.Net where the form might be padded with extra fields (ie: ViewState). Doing it too often for trivial activities will make your app appear to be sluggish, even if everything else is nice and snappy.
• It adds load to your server, in terms of bandwidth (up and down stream) and CPU/memory. Everything involved in rebuilding your page will have to happen again. If there are dynamic controls on the page, don't forget to create them.
• Anything you've done to the DOM since the last request is lost, unless you remember to do it again for this request. Your page's DOM is reset.

If you can get away with it, you might want to push this down to javascript and avoid the postback. Perhaps use an XmlHttpRequest() call to trigger any server-side action you need.

Add runat to the element in the markup

<div id="formSpinner" runat="server">
    <img src="images/spinner.gif">
    <p>Saving...</p>
</div

Then you can get to the control's class attributes by using formSpinner.Attributes("class") It will only be a string, but you should be able to edit it.

If all you want to do is conditionally show or hide a <div>, then you could declare it as an <asp:panel > (renders to html as a div tag) and set it's .Visible property.

To expand on Peri's post & why we may not want to use viewstate the following code:

style="<%= _myCSS %>"

Protected _myCSS As String = "display: none"
Is the approach to look at if you're using AJAX, it allows for manipulating the display via asp.net back end code rather than jquery/jscript.

If all you want to do is conditionally show or hide a <div>, then you could declare it as an <asp:panel > (renders to html as a div tag) and set it's .Visible property.

Add runat to the element in the markup

<div id="formSpinner" runat="server">
    <img src="images/spinner.gif">
    <p>Saving...</p>
</div

Then you can get to the control's class attributes by using formSpinner.Attributes("class") It will only be a string, but you should be able to edit it.

How do you do this without runat="server"? For example, if you have a

<body runat="server" id="body1">

...and try to update it from within an Updatepanel it will never get updated.

However, if you keep it as an ordinary non-server HTML control you can. Here's the Jquery to update it:

$("#body1").addClass('modalBackground');

How do you do this in codebehind though?

Add the runat="server" attribute to the tag, then you can reference it from the codebehind.

Add runat to the element in the markup

<div id="formSpinner" runat="server">
    <img src="images/spinner.gif">
    <p>Saving...</p>
</div

Then you can get to the control's class attributes by using formSpinner.Attributes("class") It will only be a string, but you should be able to edit it.

How do you do this without runat="server"? For example, if you have a

<body runat="server" id="body1">

...and try to update it from within an Updatepanel it will never get updated.

However, if you keep it as an ordinary non-server HTML control you can. Here's the Jquery to update it:

$("#body1").addClass('modalBackground');

How do you do this in codebehind though?

If all you want to do is conditionally show or hide a <div>, then you could declare it as an <asp:panel > (renders to html as a div tag) and set it's .Visible property.

Add the runat="server" attribute to the tag, then you can reference it from the codebehind.

If you do not want to make your control runat server in case you need the ID or simply don't want to add it to the viewstate,

<div id="formSpinner" class="<%= _css %>">
</div>

in the back-end:

protected string _css = "modalBackground";

Add the runat="server" attribute to the tag, then you can reference it from the codebehind.

To expand on Peri's post & why we may not want to use viewstate the following code:

style="<%= _myCSS %>"

Protected _myCSS As String = "display: none"
Is the approach to look at if you're using AJAX, it allows for manipulating the display via asp.net back end code rather than jquery/jscript.

This question makes me nervous. It indicates that maybe you don't understand how using server-side code will impact you're page's DOM state.

Whenever you run server-side code the entire page is rebuilt from scratch. This has several implications:

• A form is submitted from the client to the web server. This is about the slowest action that a web browser can take, especially in ASP.Net where the form might be padded with extra fields (ie: ViewState). Doing it too often for trivial activities will make your app appear to be sluggish, even if everything else is nice and snappy.
• It adds load to your server, in terms of bandwidth (up and down stream) and CPU/memory. Everything involved in rebuilding your page will have to happen again. If there are dynamic controls on the page, don't forget to create them.
• Anything you've done to the DOM since the last request is lost, unless you remember to do it again for this request. Your page's DOM is reset.

If you can get away with it, you might want to push this down to javascript and avoid the postback. Perhaps use an XmlHttpRequest() call to trigger any server-side action you need.