I use goog.html.sanitizer.HtmlSanitizer.Builder to create safe HTML that I then dynamically insert into a dialog. I wanted to have an input field that uses the Html 5 "placeholder" attribute.
I tried
.alsoAllowTagsPrivateDoNotAccessOrElse ([ "placeholder"])
and got an expected nasty compiler error!
I ended up adding the place holder attribute to the closure-library attribute white list javascript code. The call to alsoAllowTagsPrivateDoNotAccessOrElse was removed and all worked well.
I'm trying to bind the background-img: url('') property in a WinJS application.
I've got a view model property which is set to something dynamic like:
'images/' + myObject.name + '.jpg'
But I'm unsure how to use data-win-bind to set said property to the css property background-img: url(''); correctly.
My template is currently set like this:
<div class="item" data-win-bind="style.backgroundImage: backgroundImageUrl">
Where backgroundImageUrl is my view model property, but this does not seem to setting things correctly.
Any ideas as to how to bind to these properties?
Your data-win-bind syntax looks correct. So there could be two possibilities.
First, make sure you've called WinJS.Binding.processAll. That's necessary to set the binding context and set up the bindings described by data-win-bind attributes. Nothing happens without it.
Second, the value of the source's backgroundImageUrl must be a string in the form that CSS expects, that is, "url('')". It can't just be the relative path itself, like you would use with an img.src target.
To do this, either make the source's property in that form, or use a binding initializer/converter to add the url('') part automatically. For more on that, I suggest looking at Chapter 6 of my free ebook, Programming Windows Store Apps with HTML, CSS, and JavaScript, 2nd Edition, with the general data-binding discussion starting on page 299 and the initializer stuff starting on page 315.
I'm looking to get ideas on how to not change at all the code used to create css tabs (so that I can place it into an include file to avoid duplicating the code across all files that use it), but my current implementation doesn't allow this because I need to select the active tab using id="selectedTab".
The only implementation I found so far that solves this is the following one:
http://unraveled.com/publications/css_tabs/
It requires assigning a class to each tab and uses the body id to determine the active tab.
Is this the only way or is there any other alternatives?
My current code looks like this (the id=noajax" is used to avoid using ajax to load certain pages):
<div class="productTabsBlock2">
<a id="selectedTab" href="/link1" >OVERVIEW</a>
SCREENSHOTS
<a id="noajax" href="/link3" >SPEED TESTS</a>
<a href="/link4" >AWARDS</a>
</div>
EDIT: asp is available as server side and is already used on these pages.
If you're looking for a non-JS solution, then the body class/id provide the easiest way to do what you want.
If you have access to JS library, you can easily add "selected" class to any of the <a> element and modify its appearance.
Just in case you haven't notice, you can use more than one class definition in an element. For example, <a class="noajax selected" /> is valid and both CSS selectors .noajax and .selected will be applied to the element.
An include file for what? If it's a server side programming language like PHP, you can pass a parameter for the selected tab through various methods.
you could use jQuery to add the `selectedTab' id (or class) like so
$('.productTabsBlock2 a').mouseover(function () {
$(this).addClass('selectedTab');
});
What is a good approach to avoiding Selenium tests being broken when dealing with the changing "Name" and "Id" attributes of a control that is rendered on a ASP.NET page using a master page? I want to avoid changing my tests when ASP.NET renders the web page's controls with different DOM identifiers.
http://www.stevetrefethen.com/blog/AutomatedTestingOfASPNETWebApplicationsUsingSelenium.aspx
Selenium
solves this problem using XPATH and
providing the ability to locate
controls based on XPATH expressions,
alleviating the need to hard code HTML
tag structure into a test script. For
example, the ASP.NET runtime may
render ID attributes that look like:
id="ctl00_cphContents_gridMaint_DataGrid"
Finding this control using an XPATH
expression can be simplified to
something like this:
table[contains(#id, "gridMaint")]
In the event the nesting of the
DataGrid changes the script will
continue to function properly as long
as table's ID contains the text
"gridMaint".
Another option is to use CSS locators. They're normally less fragile than XPath. For example, to target a div with a class of .myDiv you can use the locator "css=.myDiv". If the specified element has other classes the CSS locator will still work, although the XPath equivalent would change from "//div[#class='myDiv']" to "//div[contains(#class, 'myDiv']". Also, CSS locators tend to be faster than XPath across browsers.
I am refactoring some CSS on a website. I have been working on, and noticed the absence of traditional HTML IDs in the code.
There is heavy use of CssClass='…', or sometimes just class='…', but I can't seem to find a way to say id='…' and not have it swapped out by the server.
Here is an example:
<span id='position_title' runat='server'>Manager</span>
When the response comes back from the server, I get:
<span id='$aspnet$crap$here$position_title'>Manager</span>
Any help here?
Use jQuery to select the element:
$("span[id$='position_title']")....
jQuery's flexible selectors, especially its 'begins with'/'ends with selectors' (the 'end with' selector is shown above, provide a great way around ASP.NET's dom id munge.
rp
The 'crap' placed in front of the id is related to the container(s) of the control and there is no way (as far as I know) to prevent this behavior, other than not putting it in any container.
If you need to refer to the id in script, you can use the ClientID of the control, like so:
<script type="text/javascript">
var theSpan = document.getElementById('<%= position_title.ClientID %>');
</script>
Most of the fixes suggested her are overkill for a very simple problem. Just have separate divs and spans that you target with CSS. Don't target the ASP.NET controls directly if you want to use IDs.
<span id="FooContainer">
<span runat="server" id="Foo" >
......
<span>
</span>
You can embed your CSS within the page, sprinkled with some server tags to overcome the problem. At runtime the code blocks will be replaced with the ASP.NET generated IDs.
For example:
[style type="text/css"]
#<%= AspNetId.ClientID %> {
... styles go here...
}
[/style]
[script type="text/javascript"]
document.getElementById("<%= AspNetId.ClientID %>");
[/script]
You could go a bit further and have some code files that generate CSS too, if you wanted to have your CSS contained within a separate file.
Also, I may be jumping the gun a bit here, but you could use the ASP.NET MVC stuff (not yet officially released as of this writing) which gets away from the Web Forms and gives you total control over the markup generated.
Ok, I guess the jury is out on this one.
#leddt, I already knew that the 'crap' was the containers surrounding it, but I thought maybe Microsoft would have left a backdoor to leave the ID alone. Regenerating CSS files on every use by including ClientIDs would be a horrible idea.
I'm either left with using classes everywhere, or some garbled looking IDs hardcoded in the css.
#Matt Dawdy: There are some great uses for IDs in CSS, primarily when you want to style an element that you know only appears once in either the website or a page, such as a logout button or masthead.
The best thing to do here is give it a unique class name.
You're likely going to have to remove the runat="server" from the span and then place a within the span so you can stylize the span and still have the dynamic internal content.
Not an elegant or easy solution (and it requires a recompile), but it works.
.Net will always replace your id values with some mangled (every so slightly predictable, but still don't count on it) value. Do you really NEED to have that id runat=server? If you don't put in runat=server, then it won't mangle it...
ADDED:
Like leddt said, you can reference the span (or any runat=server with an id) by using ClientID, but I don't think that works in CSS.
But I think that you have a larger problem if your CSS is using ID based selectors. You can't re-use an ID. You can't have multiple items on the same page with the same ID. .Net will complain about that.
So, with that in mind, is your job of refactoring the CSS getting to be a bit larger in scope?
I don't know of a way to stop .NET from mangling the ID, but I can think of a couple ways to work around it:
1 - Nest spans, one with runat="server", one without:
<style type="text/css">
#position_title { // Whatever
}
<span id="position_titleserver" runat="server"><span id="position_title">Manager</span></span>
2 - As Joel Coehoorn suggested, use a unique class name instead. Already using the class for something? Doesn't matter, you can use more than 1! This...
<style type="text/css">
.position_title { font-weight: bold; }
.foo { color: red; }
.bar { font-style: italic; }
</style>
<span id="thiswillbemangled" class="foo bar position_title" runat="server">Manager</span>
...will display this:
Manager
3 - Write a Javascript function to fix the IDs after the page loads
function fixIds()
{
var tagList = document.getElementsByTagName("*");
for(var i=0;i<tagList.length;i++)
{
if(tagList[i].id)
{
if(tagList[i].id.indexOf('$') > -1)
{
var tempArray = tagList[i].id.split("$");
tagList[i].id = tempArray[tempArray.length - 1];
}
}
}
}
If you're fearing classitus, try using an id on a parent or child selector that contains the element that you wish to style. This parent element should NOT have the runat server applied. Simply put, it's a good idea to plan your structural containers to not run code behind (ie. no runat), that way you can access major portions of your application/site using non-altered IDs. If it's too late to do so, add a wrapper div/span or use the class solution as mentioned.
Is there a particular reason that you want the controls to be runat="server"?
If so, I second the use of < asp : Literal > . . .
It should do the job for you as you will still be able to edit the data in code behind.
I usually make my own control that extends WebControl or HtmlGenericControl, and I override ClientID - returning the ID property instead of the generated ClientID. This will cause any transformation that .NET does to the ClientID because of naming containers to be reverted back to the original id that you specified in tag markup. This is great if you are using client side libraries like jQuery and need predictable unique ids, but tough if you rely on viewstate for anything server-side.
If you are accessing the span or whatever tag is giving you problems from the C# or VB code behind, then the runat="server" has to remain and you should use instead <span class="some_class" id="someID">. If you are not accessing the tag in the code behind, then remove the runat="server".