If there's a case for using MVC for responsive websites, this is it:
I'm working on a site that is mostly ASP.NET WebForms, which is undergoing a redesign to use responsive markup. It is impractical to convert everything to MVC, so I have to make do with the existing controls.
On a particular form page, we have two combo-boxes on the same row; these have CSS classes appropriately set to specify the width at 48% of the parent element. The trouble is that since we're using the asp:DropDownList, the control is rendered with a style attribute having width:275px;, which overrides the width set in the CSS class.
In codebehind of the composite control containing these DropDownLists (particularly the RenderChildren method override), I've tried calling [control].Style.Clear(); prior to calling the base method. This has no effect; even adding:
[control].Style.Add(HtmlTextWriterStyle.Width, "inherit");
causes the element to be rendered as:
<select style="width:275px;width:inherit;" class="input-half first" id="longAndComplicated" name="longAndComplicated">
Note the two width declarations, when ideally there shouldn't be a style attribute in the first place.
I've had a poke in Reflector at the source, and couldn't find where this hard-coded width is being set; I gather that the style setters are being copied from somewhere further up the ASP.NET hierarchy.
As a lucky guess, I tried:
Setting Width to an empty string on the <asp:DropDownList> ("inherit" causes a Parse error)
Explicitly specifying Width="48%"
Setting EnableTheming="false"
None of these has had any positive effect, with the rendered style attribute still having width:275px;.
Where is this width magically being set from? How can I override this behaviour, ideally without having to create a derived class inheriting from System.Web.UI.WebControls.DropDownList?
Many thanks.
I have better Idea, fix the width and do not inherit the width, as that will inherit width from parent and over-ride the width element defined with width:275px; so that will be meaning less.
I have created a fiddle, works fine in chrome, the select tag has fixed width,
If sub element size will increase it will automatically grow.
Please check fiddle
If your question is referring to CSS class class="input-half first" then the style defined in element style is the one what is applied at last and will have high priority compare to class, better create new class, and assign it.
Hope, I have answered in right context as you have written many things with reference to ASP.net control, but I don't think that should be problem in majority cases.
Doh - I figured out what it was.
It turns out that the containing composite control defined properties along the lines of DropDown1Width and DropDown2Width. These 'cleverly' set the Width property of the underlying DropDownList controls, which were used during the DropDownList.Render() method.
Fortunately I don't have to go subclassing DropDownList, though in hindsight the lack of definitive web search results suggested the problem was likely to be somewhere in our own codebase.
I say "defined", as I have since removed these redundant properties (and their corresponding assignments in various ASPX files).
Related
Are there a css property that would change nothing?
I need this for testing purposes very often when writing scss just to see that I created a css selector correctly. For instance, I would be glad to have something like this foo: "helloworld1"; and later on I would be able to change the value of the foo and check the value in the developer tools to see that my selectors have indeed reached a correct element.
I thought about using the width: auto;, but sometimes the width is specified (e.g. width: 100px;).
Define your own properties using custom properties (aka CSS variables)
Custom properties are solely for use by authors and users; CSS will never give them a meaning beyond what is presented here.
Also
Custom properties are ordinary properties, so they can be declared on any element, are resolved with the normal inheritance and cascade rules, can be made conditional with #media and other conditional rules, can be used in HTML’s style attribute, can be read or set using the CSSOM, etc.
Instead defining:
<div id="my-custom-element-101"></div>
I wrote:
<my-custom-element-101></my-custom-element-101>
But didn't go further to extend HTMLElement and define it. This way I get some enhanced readability and don't need to do any further coding.
Is there any potential downside to this practice?
There's no absolute downside for that, as soon as you use valid custom element notation (i.e. a name with an hyphen "-").
In this case it's just an unknown custom element.
Of course if someone else decide to define a custom element with the same name you could get into some troubles but if you own the entire code of the page it can't happen.
Also note that, in your example, your tag <my-custom-element-101> is seen as an inline element, not a block.
I have a GWT code that creates a list (grid as result) and I set the style to a CSS class like
.test tr {
height: 26px;
}
now...if from code I need to obtain that "26px" when the render isn't completed or when the grid has no element? ho can I obtain that value? I know i can do
obj.getElement().getStyle().getProperty("height");
to obtain some style attribute but how can I obtain the sub-element tr related value?
As you've discovered, the element's style property only contains styles that are directly set on the element itself - it does not automatically pick up css that has applied to it, or css that has been applied to parent nodes and inherited to it, etc.
To do this, you need to get the 'computed' style of the element. This is a somewhat expensive operation so should be done carefully, and will not work in older versions of IE, so different code entirely must be written. Some libraries like GXT have a built-in feature to do this work for you (XElement.getComputedStyle(...)), if you are not using a library like that, you will need to write JSNI that can call into this api and ask for these details.
Check out http://caniuse.com/#feat=getcomputedstyle (IE8 and below do not have it, old Android Browser and Opera Mini apparently have issues), and https://developer.mozilla.org/en-US/docs/Web/API/Window.getComputedStyle for the details on the call. In your JSNI, remember to use $wnd to refer to the window object, something like this:
$wnd.getComputedStyle(element).getPropertyValue('height');
There is no need to get that value programmatically. I imagine that you have only one or two styles that define your tables, so you can always infer the row height from your style name. For example, if you have "standard" height set at 26px and have a "big-table" style setting it at 36px, you can simply:
int rowHeight = myTable.getStyleName().contains("big-table") ? 36 : 26;
Just got a new webpage with css for a fancy box popup from the design team;
And they don't know or don't care to look for existing classes and ids;
I need a working solution without any IFRAME
The problem is that there are already over 20.000 css lines in the main css file, and at some point something will get overwritten and the entire website will do a big BANG!
This new webpage has very common class and id names, and I am talking about almost 100 tags with css properties;
I want to know if there is a method to encapsulate this new css properties and the future ones;
And if there is a way to do this, how can it be done?
With this webpage I got lucky, I pasted the tags with content and just before this, I used the style type"text/css' tag; But i will not always be lucky;
Just because we get webpages with css code written by different people, it does not seam fair to me to create new css classes if some of the properties or names or ids intersect with each other.
I now have about 10 classes for the a tag and im most part, the properties are the same;
Use targeted rules and let the cascade take care of it for you. Put your popup in a wrapper with as detailed of a name as you like.
<div id="myPopupDivWithCommonIds">
<!-- rest of popup -->
</div>
And target your css rules to that div.
#myPopupDivWithCommonIds .error { color: bright-pink; }
#myPopupDivWithCommonIds #main { width: 93.21%; }
Etc. etc. This takes care of the css rules and prevents your new stuff from overflowing. You will have to take care to make sure none of the other rules trickle down; the best way for that is to judiciously overwrite any properties that are defined (what Pekka said). You could also go nuclear on it and include a custom 'reboot' or 'bootstrap' stylesheet and again re-target all of its rules to your new popup div (like you said, it's difficult for 20k lines of css; but including another file with the resets rules targeted to your div by appending the #id selector as above helps a little).
Oh, and that still doesn't address the problem of repeated ids technically being invalid markup and very likely to interfere with any JavaScript you're trying to run on that page.
If this sounds like a mess, well, it is. Your developers and designers have got it to that point and short of a serious refactoring, you're not going to get back to a clean solution. An iFrame may seem like a hack or impossible for your use case, but it really would clean up a lot of your correctly foreseen problems.
My understanding about CSS is that, generally if you set <div style="color: Red">, all content inside <div> will be affected. However if you put a html button inside, the color on the words on the button is not affected. I'm a bit disturbed by this exception. How do I give a reasonable explanation to it?
It's about users' expectations of the user interface.
Buttons (and other user interface widgets) prefer to look like their operating system counterparts. On Windows, users expect buttons to be grey with black text, so that's how browsers present them. It's intentional that you have to try quite hard to override that behaviour.
It's because it would be impractical for input elements to inherit style information from parent elements, this means whenever you style a form, you would have to create style rules for every type of input used in it, to make sure they don't turn out unexpected. you can however force inputs to inherit their parent's style with css:
input {
color: inherit;
}
That code will cause all input elements to inherit their parent's text color style.
The "cascading" part of "Cascading Style Sheets" (CSS) means that in general, you're right: a property set on an object will cascade down to objects below it.
However for some properties this doesn't make sense, so those properties are explicitly non-cascading (eg if you set a border on a div, you don't want all its children to have borders as well).
If we were dealing with raw XML in our DOM, that's where it would end. The colour would indeed cascade all the way down. However, we're dealing with HTML, and HTML has some pre-existing conditions, exceptions and overrides. For example, a <div> always defaults to display:block; whereas a <span> will default to display:inline;.
Buttons and input fields have a lot of defaults and overrides, which is why they show up as buttons and input fields without you having to do loads of styling on them. This is also why they override the cascading effect of certain CSS rules, including color.
You can override the override by specifying inherit for the overridden styles. So if you want you button to take the red colour you specified previously, you would do something like this:
.mybutton {
color:inherit;
}
You will want to look up the rules for inheritance in CSS; certain property values will cascade to certain descendant elements, and certain ones won't. In fact, one of the possible values for many CSS properties is inherit, which suggests that this value is not always the default.
The browser itself has default styles for input types, dependent on the OS it's running on. So for Windows, it will most likely be grey, for Apple OS' blue and round (fancy).
There are very easy ways to override this in CSS, I use it all the time in my websites, customising buttons and input fields to better match my site design with images and as mentioned before color values either inherited or changed.
Here is a nice article explaining the cascade and inheritance rules native to using CSS that might help you out.
:)
Buttons and some elements else come with their own style. This style is browser dependent. In different browsers the buttons can look a bit different.