I am quite new to ASP.NET. When creating new pages that already contain ASP.NET components the id attribute is generated in upper case, for other elements the id attribute is generated in lower case:
<asp:xxx ID="foo" ...>
vs.
<div id="blaa" ...>
I am wondering what the reason for that is. I would tend to use lower case in both cases - is that ok? Can someone please shade some light on this?
Many thanks!
When you use <asp:xxx the attribute names have to match the properties of control class xxx.
Microsoft naming convention is that 2 letter acronyms are upper case, so the property name is ID.
Any other property name longer than 2 letters will be CamelCase.
The server will parse the <asp:xxx tag, so the result HTML might look very different.
Alternatively <div is HTML and will be all lowercase. The server will just serve it up as it is in your page.
That is just the ASP.NET syntax of Visual Studio changing to be uppercase. When you look at the actual generated HTML it will be lowercase just like the rest of your HTML.
You can do either, but the "Auto Generated" stuff or auto corrected stuff will have ID.
Related
Can we tag a single html element with multiple "itemprop" properties? I'm working on something for micro data tagging.(schema.org)
<asp:HyperLink ID="hlnk10" itemprop="url" itemprop ="manufacturer" runat="server"> </asp:HyperLink>
The hyperlink Text contains both properties I want to tag
Is this possible as per schema.org standards?
Thanks in advance.
My reading of the specification leads me to the conclusion that you can
have just one itemprop attribute per element but it can have more than
one value.
"Every HTML element may have an itemprop attribute specified... The
itemprop attribute, if specified, must have a value that is an
unordered set of unique space-separated tokens that are
case-sensitive, representing the names of the name-value pairs that it
adds. The attribute's value must have at least one token."
http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#names:-the-itemprop-attribute
You might try the nu validator or a microdata parser to test your code
and make sure you're getting the output you expect.
So instead of <span itemprop="name" itemprop="description"> you would use <span itemprop="name description">
Google's Rich Snippet Testing Tool may not be able to handle multiple itemprop values, yet, though.
I don't know what that asp will generate, but I think you want output more like this:
<span itemprop="manufacturer">The Name</span>
In order to get access to the text content of the link you add an extra span. The value of an a element will always just be the value of its href attribute. Adding an extra span to get access to the text content of a link is a common pattern.
I want to add a bunch of classes to some text fields so i can get their values with jquery. This seems like standard practice when using jQuery and this post suggests it as the answer but how does this affect page loading? Won't it be trying to find all these classes? I have been told in the past to try minimise the amount of classes used on controls.
I have about 12 controls i'll want to add unique classes to to get their value. I am using asp.net so I can't use the id. I also can't use the ClientID as the controls are in a table (but only 1 set of controls will show at any one time).
e.g.
<asp:TextBox ID="txtValue1" runat="server" CssClass="value1" Text='value1' />
<asp:TextBox ID="txtValue2" runat="server" CssClass="value2" Text='value2' />
<asp:TextBox ID="txtValue3" runat="server" CssClass="value3" Text='value3' />
...
var value1 = $('.value1').val();
var value2 = $('.value2').val();
var value3 = $('.value3').val();
And none of the class names will exist in css.
Thanks
Edit:
I know this works but I was more curious about the affect it had on page loading. There was an answer (seems to be deleted now) that said something like the html parser ignores the classes. The css parser will only look at classes that are defined. So it sounds like it would be completely ignored and have no affect on page load. Is this right?
It is okay to use a CSS class that doesn't exist, but if they are unique you want to use id, not class.
You say you are using ASP.Net so you can't use the ID parameter, but you can. In JQuery you can get the controls using the below
var value1 = $('[ID$=yourID]').val();
For more info on JQuery Selectors check out: JQuery Selectors and Attribute Ends With Selector
The above selector basically finds the id ENDING in "yourID" so ignoring all the masterpages extra text at the start. You just have to make sure these are unique. e.g. don't have ids like "HSBC" and "SBC" as the above selector on "SBC" will find both.
I don't think it's a problem. The only times I've had problems with non-existant classes or ID's is one time I had an onclick reference an ID that didn't exist. This messed things up...Other than that I think classes are pretty harmless. I'd be interested to know though..
Any other thoughts??
Which version of asp.net are you using? In asp.net 4.0, you have the ability to use unmangled ids. It looks like the simplest solution would be to set ClientIDMode="Static" to all of your textboxes and then refer by id. Otherwise, sure, I've created classes that don't exist to refer to things.... all the time.
Edit: (in response to your comment about the effect page load).
I think your question about having extra classes in a div that are not currently used is not a bad question (at least in a theoretical sense), and I honestly don't know the precise answer. I do believe any effect is quite minuscule. If you consider best practices to write html, you generally write and structure the HTML, with it's classes, before you write the CSS. This means at the time you write the CSS, certainly some classes will not be used. Indeed, after styling the basic tags (body, h1, a, etc), you may find you never need to create selectors with those classes for some particular design. And yet for the next design, you might need those classes. I'm pretty sure the technology behind CSS was built with those kinds of scenarios in mind, and I bet millions if not billions of pages on the internet follow that exact scenario, especially if they use something like Modernizr, which adds classes to the html element of the page as a way of providing you classes you can select against considering the possible capabilities of the current browser. You may never need those classes, but they are there if you need them.
In my markup I am using HTML title attributes which I set by the Tooltip property of various ASP.NET controls like an asp:Label. The content of those titles come from a database and I use data binding syntax, for instance:
<asp:Label ID="PersonLabel" runat="server"
Text='<%# HttpUtility.HtmlEncode(Eval("PersonShortName")) %>'
ToolTip='<%# HttpUtility.HtmlEncode(Eval("PersonFullName")) %>' />
Now, tooltips seem to be displayed as plain text on Windows and in the browsers I have tested. So the HTML-encoding is not what I really want and I am inclined to remove the encoding.
Can this be dangerous in any way if the database fields may contain script tags for example? My question is basically: Is it always guaranteed that HTML-title attributes are displayed as plain text? Are they always displayed as tooltips at all, or is it possible that some browsers (or OSs) display them in another way and allow and render HTML content in the title attributes?
Edit:
Looking at some of the answers it seems I didn't phrase my question well, so here are some additions:
If I have in the code snippet above a PersonShortName of "PM" in my database and as the PersonFullName a name with non-ASCII characters in it like Umlauts in "Peter Müller" the browser displays in the tooltip Peter Müller when I apply HttpUtility.HtmlEncode like in the code example - which is ugly.
I've also tested a simple HTML fragment like:
<span title="<script>alert('Evil script')</script>" >Hello</span>
The script in the title attribute didn't run in a browser with enabled Javascript (tested with Firefox), instead it was displayed in the tooltip as plain text. Therefore my guess was that title attributes are always rendered as plain text.
But as Felipe Alsacreations answered below there exist "rich tooltip plugins" which may render the title attribute as HTML. So in this case encoding is a good thing. But how can I know that?
Perhaps HttpUtility.HtmlEncode isn't the right solution and I have to filter only HTML tags but not encode simple special characters to make sure that the plain text is displayed correctly and to protect "rich HTML tooltips" at the same time. But it looks like a costly work - only for a simple tooltip.
Always sanitize output to the browser.
If a value like "><script>blabla</script> is inserted as a value for your fields, a user can essentially take over your entire site. It will probably make a mess when it comes to validation and correct code, but the script will still be run.
So to answer your question: No, it is not guaranteed that HTML-title attributes are displayed as plain text if the user knows what he/she is doing.
Beside security reasons:
Title attributes should always be plain text but certain JS plugins misuse them to display 'rich' tooltips (i.e. HTML code with bold text, emphasis, links and so on).
As for browsers and AFAIK they are displayed as plain text and tooltips, never displayed to those who use tabbed navigation (keyboard) and scren readers give to their users (blind and partially sighted people) many options, like reading the longest between link title and its text or always title or never ...
Surprisingly, still, no right answer in 5 years. The answer is: yes, you need to encode the title attribute, but not everything that is encoded in the innerText of the element.
The proper way to do it in asp.net if you do your own markup is:
string markup = string.Format("<div class='myClass' title='{0}'>{1}</div>",
System.Web.HttpUtility.HtmlAttributeEncode(myText),
System.Web.HttpUtility.HtmlEncode(myText));
The above will set both innerText and title of the div to myText, which is customary for elements that may contain long text but are constrained in width (as I believe the question implies).
The ToolTip property of a ASP.NET control will auto encode the value on output/rendering.
This means it is safe to set the tooltip to plain text as the page will sanitize the text on rendering.
Label1.ToolTip = "Some encoded text < Tag >"
Renders HTML output as:
<span title="Some encoded text < Tag >"></span>
If you need to use text that is already encoded, you can set the title attribute instead. The title attribute will not be automatically encoded on rendering:
Label1.Attributes("title") = "Some encoded text < Tag >"
Renders HTML output as:
<span title="Some encoded text < Tag >"></span>
Another point:
Who cares how the title attribute is rendered by a browser, when it is the presence of malicious strings in the source code that could present an issue?
It doesn't matter how it is displayed, the question is: how does it appear in the source code?
(As already stated, if you're pumping strings to the client, do something to sanitize those strings.)
I think there may be some confusion going on with this thread.
Firstly <asp:Label> is an ASP.NET Web Control. The Text and ToolTip attributes are "abstractions" of the inline content and 'title' attributes of an HTML tag respectively.
For these particular two properties Microsoft will perform the HTML Encoding for you automatically so if you set ToolTip="H&S<" then the <span> tag will be rendered as <span title="H&S<"...>. The same goes for the Text property.
NOTE: Not all properties perform automatic encoding (HTML or InnerContent properties for example)
If however you are generating HTML tags directly (Response.Write("<span...") for example) then you MUST http encode the text content and tooltip attributes content if:
Those values originate from a user / external unsanitised source or
If there is a possibility that the content may contain characters that should be escaped (& < > etc.)
Usually this means that it is safe to to:
Hardcoded content with no http characters:
Response.Write("<span title='Book Reference'>The art of zen</span>"); // SAFE
Hardcoded content with http characters that you manualle encode:
Response.Write("<span title='Book & Reference'>The art & zen</span>"); // SAFE
Dynamically sourced content:
Response.Write("<span title='"+sTitle+"'>"+sText+"</span>"); // UNSAFE
Response.Write("<span title='"+HttpUtility.HtmlEncode(sTitle)+"'>" +HttpUtility.HtmlEncode(sText)+"</span>"); // SAFE
I have an ASP.NET MVC application and I'm using CKEditor for text entry. I have turned off input validation so the HTML created from CKEditor can be passed into the controller action. I am then showing the entered HTML on a web page.
I only have certain buttons on CKEditor enabled, but obviously someone could send whatever text they want down. I want to be able to show the HTML on the page after the user has entered it. How can I validate the input, but still be able to show the few things that are enabled in the editor?
So basically I want to sanitize everything except for a few key things like bold, italics, lists and links. This needs to be done server side.
How about AntiXSS?
See my full answer here from similar question:
I have found that replacing the angel
brackets with encoded angel brackets
solves most problems
You could create a "whitelist" of sorts for the html tags you'd like to allow. You could start by HTML encoding the whole thing. Then, replace a series of "allowed" sequences, such as:
"<strong>" and "</strong>" back to "<strong>" and "</strong>"
"<em>" and "</em>" back to "<em>" and "</em>"
"<li>" and "</li>" back to ... etc. etc.
For things like the A tag, you could resort to a regular expression (since you'd want the href attribute to be allowed too). You would still want to be careful about XSS; someone else already recommended AntiXSS.
Sample Regexp to replace the A tags:
<a href="([^"]+)">
Then replace as
<a href="$1">
Good luck!
I am confused. I need to name my iframe in order to use the name as the target in my menu's hypelinks. According to my Visual Web Developer Express the name attribute is considered outdated and a new construct is required. My question is what attrbute code do I utilize to name my iframe. Thank you
According to my Visual Web Developer Express the name attribute is considered outdated and a new construct is required.
Then Visual Web Developer Express is wrong. For the purposes of anchors and scripting/styling hooks, 'name' is to be replaced by 'id', but for the purpose of identifying link targets (such as frames), it is not. See http://www.w3.org/TR/REC-html40/present/frames.html#adef-target , http://www.w3.org/TR/REC-html40/present/frames.html#adef-name-IFRAME .
This usage is not deprecated in HTML terms, but it's a bit of a code smell. Targeting a link to an iframe is generally considered a bad thing as it breaks many normal navigational expectations. There are uses for it, but be wary.
Ignore the warning. Believe the DOCTYPE specification. The name attribute is just fine. In fact, HTTP posts via embedded HTML forms pass data using the name attribute as the key.
<input id="txtName" name="name" />
To get at the textbox value in your Page_Load, you would use Request.Form("name"), and not Request.Form("txtName")
When in doubt about attributes and such, run your rendered HTML through the W3 validator to validate it against the DOCTYPE.
Typically, you would use the "id" attribute as a replacement. This is not always "optimal". I have noticed that this does not always work for named anchors, for instance.