This article suggests it is:
https://msdn.microsoft.com/en-us/library/x3k2ssx2(v=vs.100).aspx
Is this correct or are there limitations documented somewhere?
Yes it is cross browser compatible. The first section of the same link gives you the answer:
Different browsers, and different versions of the same browser,
support different features. ASP.NET server controls will automatically
determine the browser that has requested the page and render the
appropriate markup for that browser. However, some control features
cannot be rendered on older browsers, so it is a good idea to look
at the output of your pages on as many browser types as you can to
make sure that the pages are presented to all browsers the way you
want them to be.
So as stated above you need to check in as many browsers as you can to check if any of the control is breaking in any browser. I don't think you can get any such list documented anywhere but information reported by different people as to what is breaking for them on which browser.
Related
Having a very annoying problem where custom user controls do not appear at all in my ASP.NET project when using IE8 and IIS6.
It works on all other browsers except IE8 when using ISS6.
When using exact same project on IE8 with ISS7, it works on all browsers including IE8.
Has anyone got any suggestions?
Is the content encapsulated in a certain tag, or included in a unique way (other language, etc.)?
I'm guessing there is a mime type or other configuration change between the two server instances, rather than it being a version conflict.
Why other browsers don't see the problem kind of hints away from that, but without additional details its hard to help more.
Frames/ Framesets has been deprecated.
Iframes are not recomended for various reasons.
Ajax is not always an option since one of the providers may not support it.
So how does one converge & display multiple html content from two different sources in a Asp.Net 4.0 or higher page as per modern HTML standard ?
Should i focus completely on ajax/partial page related development or continue using Iframe as a stop gap measure hoping they dont deprecate it too in the near future ?
well there was a time when even facebook was on iframe, now its all about partial responses. But iframes are not going anywhere soon ,we still get many of our client requirement specific to iframes and if it suits your need to achieve compatibility why are you confusing yourself with alternates.
besides that html5 has added some new spices to iframe so its clear that this thing is not going in bin.
so in the end , i would suggest:
1. Go for ajax/partial/jquery if you want your application to be both interactive & user friendly.
2. If compatibility is a big issue then go straight to iframes.
Regards
So HTML 5 has been widely publicised as expected to be ready in 2022. This is a long time to wait, and the test for that readiness is that "at least two browsers to completely pass [HTML 5 test suites]"
Obviously for browsers to pass this test they have to start implementing usable HTML 5 features before that. The list of new HTML5 features supported is looking thin at the moment. But there are a couple of significant changes to existing elements such as allowing A tags to surround block level that could be very useful now.
There are sites that are using HTML 5 now, so what are the factors that will make you start, or keep you from, building sites with an HTML 5 doctype?
Myself, I'm toying with HTML5 in a couple of personal sites, but will wait a while for work sites until things like a reliable validator appear.
It helps to divide this question into several parts.
1) When should one start using the HTML5 doctype?
The HTML5 doctype causes browsers to render pages in Full Standards mode. Unless you're currently using a strict doctype, pages may display differently. So you'll need to weigh up the amount of rework required if you're converting a existing site, and you'll need to understand the difference in rendering behaviour. Secondly, the doctype will cause the w3c validator to select HTML5 as the default language to validate against. Given that HTML5 is still in draft, this means aiming at a moving target. Is validity important to you? Some features that are valid in HTML4 are not currently valid in HTML5. Should you change your markup now to remove those features, given that HTML5 may change to make those features valid again? Provided you're comfortable with this, you can start using the HTML5 doctype now.
On the other hand, on it's own, what are you gaining? If you want browsers to render in Full Standards mode, you can use a strict doctype from HTML 4.01 or XHTML 1.x. Do you need HTML5 validation given that it will pass things that may not at present be handled consistently across browsers? Be aware that any HTML5 feature that currently works in browsers, works regardless of whether you use the HTML5 doctype or not.
2) When should one start using features that are currently interoperably implemented in the major browsers, but standardised for the first time in HTML5?
You can use these now, but try to make sure that your pages are properly accessible. Canvas, for example, does not provide good support for non-sighted users.
3) When should one start using features that are current implemented in some browsers, and will be standardised by HTML5?
This depends on your target users and delivery schedules. Will your users be using a browser that supports these features by the time your site goes live? What happens if they don't? Does the page fall back gracefully? Do you care if some users can't use your site?
4) When should one start using features of HTML5 that are not implemented at all yet?
Why would you want to do that? It might be reasonable for training purposes or investigating fall back behaviour, but HTML5 is still in draft form, and it's quite possible that some features will never be implemented, or will be implemented in a totally different way to that currently described, so you could waste a lot of effort.
Summarising, what matters is not so much what's in the HTML5 draft, as what is practically usable today. The draft describes a range of features, some of which have been in browsers for years, some which are new but have support or good fall back behaviour, and some which are not currently and may never be usable.
For me, I'll be holding off until I need an HTML5 feature, and I know that that feature is implemented in a consistent and stable way across the major browsers. That will probably happen some time during HTML5's Last Call phase, or possibly during the Candidate Recommendation phase.
Already have started using it for personal and client work.
For validation I use Henri Sivonen's excellent http://validator.nu/
When IE supports it. I work in the corporate world, and IE is required.
I use the doctype now! (for some projects at least)
As for the features, things like <canvas> and <video> are cool and useful now because there are often ways to make the content available for users whose browsers don't support HTML5 yet.
Semantic page structure tags like <sidebar> and the lot don't seem very urgent to me. I'll let those sit for another year or two.
simple question really (can hazard a guess but just need to make sure),
Just need a Yes/No answer as can't seem to claify anywhere.
Reason? Web pages for phones, where javascript support is "sketchy" among all mobile browsers, so doing away with anything javascript altogether and was wondering if there are any alternatives.
(Also before someone tells me off, I am of course implementing server-side validation by default, better if possible to validate stuff right away on the client as phone text entry isn't particulaly fun to go through multiple times. Also webpage is asp.net 2.0 & c# should that affect anything)
No, there is not.
I mean, obviously, the more involved answer is "Yes, of course, there are other types of client-side scripting systems (Flash/Silverlight/ActiveX/etc) that can do it", but in the context of your question (phones) then the answer is No.
I do suggest, however, that you may be surprised at what phones run JavaScript. Keep it basic, and keep it such that it fails gracefully (i.e. no harm comes to the functionality of the app with JS disabled) and you'll probably be surprised at the compatibility.
HTML itself allows for a very little bit of validation (the maxlength of the input forms, which is not much, as a validation).
Which means you need "more", to do real/useful validation on the client side...
, if you want something that works in almost every browser, that's accessible, that doesn't annoy the user, ...
As a sidenote : don't ever forget server-side validation !
(Yes, you said it in your question -- but it's never said too many times ^^ )
Yes — but only in an even more limited range of browsers than those which support (and have enabled) JS.
e.g. You could use client side VBScript.
No , there is nothing except for javascript for client side for client side validation for the time being.
But it seems that HTML5 has some interesting tags thet will help. http://dev.w3.org/html5/spec/forms.html
It is possible to validate HTML forms without JavaScript now. Have a look at How to validate HTML5 forms without JavaScript
Not really. HTML itself only allows to limit the maximum length of a text box, which is some sort of "validation" (by restriction).
But then again - very many mobile browsers DO run JavaScript, even "Opera Mini" does support basic (or not that basic?) things of JS. Mobile Opera has full JS support, IE - too.
There is a nice list of who-can-do-it on QuirksMode.org (here: http://www.quirksmode.org/m/table.html)
One thing I'd suggest looking at is the Mobile Device Browser File - you state that you're using ASP.NET 2.0, so provided that your server's up to date (i.e. it has .NET Framework 2.0 SP2 installed), you should be able to use it.
This will help your site determine which browser is viewing your site, what it supports in terms of controls, etc, and help you respond appropriately to the requests.
I.e. if you know in advance that the browser doesn't support JavaScript, you can remove the client side validation altogether and not send all the extra markup to the browser, making their experience of the site even cleaner.
Basically, no.
If your market includes browsers that support the new HTML5 input types, there's some very basic things you can do there: http://diveintohtml5.ep.io/forms.html
Beyond that though, Javascript is really the only real client-side option.
(It could also be done in VBScript, but only in Internet Explorer)
We're developing this ASP.NET web app with multiple users on different browsers. One of the users complains that the pages look funny, and after looking at the screen shot he sent, it looks like the css is not applied. According to the bug report, the user is using IE7 (but I suspect it could be IE8).
I develop in Firefox, and using the web developer toolbar, when I choose CSS --> Disable Styles --> Linked Style Sheets, I manager to recreate a page that looks a lot like the reported one.
I sent a message in return that told him to check the options under Internet Options --> General --> Accessibility, and make sure all the check-boxes where un-chekced. The reply was that they were, but that the page still looked funny.
So, the strange thing is that this app is used by hundreds of users, but I have only gotten complaints from this one user. Does anyone have any idea of what could cause the CSS to not be applied? Could it be my code, or is it some local setting in the client browser or system?
Sometimes there's no substitute for actually walking over to the user and looking at his/her setup. Difficult if they're in a different location, but not impossible; use a remote access tool like Copilot.
If I had to guess in order of likelihood:
They've disabled/overridden application-supplied stylesheets (enough ugly backgrounds and anyone might do this)
They have a caching issue
Could be a very mundane file-related issue - e.g. the version you're looking at references a file that's visible to you, but not to the user. They may even be blocking that file via browser settings, purposefully or not. Have you asked them to request the stylesheet file directly and report back what they 'see'?
Other than that, could be issues relating to the markup used (e.g. bad 'type' attribute) - is your markup validating?
Also, it's obvious, but have you validated your stylesheet? Is this person the only IE7 user?
There's a few things to check.
Firstly, check their anti-virus / security / firewall / etc. That can randomly block all sorts of things.
Secondly, there's a registry setting somewhere to disable CSS, but that'd do it for all websites.
Also, check to see if they've got a load of IE add-ons and toolbars installed. Some of them add crap to the user-agent string and it that gets too long I seem to remember IE will truncate it. This can confuse the adaptive rendering "feature" on .net 1.1 sites.
Oh, and make sure you've validated your CSS :)