I've just started an internship with a company whose main product is an ASP.NET web forms. My related experience so far has been with Java and front end web development. My current task is to make their site responsive and more accessible for various users.Currently I'm struggling to make sense of how each HTML page is generated. All of the user controls are programmatically generated from code behind .ascx.cs files and there is no markup in any of the .ascx files themselves.I was wondering if this is standard practice? And are there any tools I can use to get a clearer picture of what each part generates?
ASP.NET user control best practices, programmatically or markup?
c#;asp.net;webforms
***EditedI am editing here because I did not really answer you question: ASP.NET was created around 14 years ago, when AJAX and DOM manipulation where in their infancy. The idea was to create controls and drag and drop them on a form. The controls would be part of a tree under the web form.  Anyway, At that time, ASP.NET fit the bill for 90% of projects, it had never been easier to create a web app then it had become with ASP.NET. Now it is 2015, and things have changed drastically over the years, namely, AJAX is everywhere.One of the issues with ASP.NET is that it generates unique IDs for each control based on where the control fit in its page's control hierarchy. It also saves a pages encrypted ViewState, the state of all its controls, in a separate form field. So if you change the DOM drastically, when the pages tries to restore it's view state, it will error out, because the page is no longer the same state as it was when the view state was captured.  For example a generated id of somepage_control_othercontrol could be used by the asp.net page to find a control that is nested within its page and and restore its current view state, without having to do it manually. So, to sum it up, the best practice at the time was to reuse nested controls and there xml representations in the markup, for example, <asp:TextBox />. If you want to use ASP.NET how it was designed to be used, use nested User Controls and Server Controls and try not to mess with the DOM too much. If you are going do a lot of DOM manipulations via javascript, don't mind pulling post parameters into variables manually, don't care whether a control automatically repopulates with it's last value after a post, want to determine your own input control names, then you can use straight HTML aspx file with no server controls and turn off ViewState on your page, but for most pages you will doing a lot more work that the framework would normally do for you.***End EditI have not done non MVC asp.net development now for several years, but the best way that I know of to understand how User Controls are generated is to understand the Page Execution and Control Execution Lifecycles and the events that render them.See https://msdn.microsoft.com/en-us/library/ms178472.aspxhttps://msdn.microsoft.com/en-us/library/aa719775(v=vs.71).aspxhttps://msdn.microsoft.com/en-us/library/ms178472(v=vs.85).aspxhttp://www.codeproject.com/Articles/457647/Understanding-ASP-NET-Application-and-Page-Life-CyPreInit All the Dynamic Controls, Master pages, Profiles and themes should be set in this event.Init    This should be used to set the initial value of the Control properties.InitComplete    This should be used to have custom ViewState data. This is the first place where ViewState has been loaded and can be changed.Preload This can be used to set the properties of the controls.Load    All the Database connections and Data Binding can be performed here. Before this event finishes up all the validations will be done. Once the event is finished, the events for all the controls will execute before calling the next event in this list.LoadComplete    This event can be used for activities on controls that require them to be fully loaded.sPreRender   This is the last page where the visual properties of the controls can be changed before getting them displayed on the page.PreRenderComplete   This will be called when the page is ready and no changes in visual elements can be made. All data binding are done at this point.SaveStateComplete   View State has been saved and from this point onwards changes in ViewState will not be preserved i.e. ViewState has been saved for the page already.Unload  The Page processing is done now. This is the last event that will be called.Essentially you need know exactly where you can do a certain types of tasks within the page and control life cycles. Once you understand this, you just need to subscribe to the right event for the task and write the code that's require in the event handler.Here is a complete list of all the events as the happen in order across all scopesPage    ProcessRequestPage    ProcessRequestMainPage    DeterminePostBackModeAdapter DeterminePostBackModePage    LoadScrollPositionPage    OnPreInitPage    ApplyMasterPagePostBack    ApplyMasterPageRecursiveControl InitRecursiveControl ResolveAdapterControl ApplySkinPage    ApplyControlSkinPostBack    ApplyControlSkinPage    OnInitCompletePostBack    LoadAllStatePostBack    LoadPageStateFromPersistenceMediumPagePersister   LoadControl LoadControlStateInternalControl LoadControlStateAdapter LoadAdapterControlStateControl LoadViewStateRecursiveControl LoadViewStateAdapter LoadAdapterViewStatePostBack    ProcessPostDataPage    OnPreLoadControl LoadRecursiveControl OnLoadAdapter OnLoadPostBack    ProcessPostDataPostBack    RaiseChangeEventsPostBack    RaisePostBackEventsPage    OnLoadCompleteControl PreRenderRecursiveInternalControl EnsureChildControlsControl ResolveAdapterControl CreateChildControlsAdapter CreateChildControlsControl OnPreRenderAdapter OnPreRenderControl SaveViewStatePage    SavePageStateToPersistenceMediumPagePersister   SavePage    OnSaveStateCompleteControl RenderControlControl RenderControlInternalControl RenderAdapter BeginRenderAdapter RenderAdapter EndRenderControl RenderChildren