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 :)
Related
I'm doing css for a website. I send the html and css to a guy, he puts it into ASP.net. The problem is that the transfer didn't end well for my code and it needs some fixing. The problem is that when I look at it in Chrome, or Firefox, or IE8, I get three completely different renderings. I spent a good amount of time trying to fix a drop-down menu that is supposed to appear while hovering over a link. The one he had in place from ASP.net worked in IE, kinda worked in Firefox, and was completely broken in Chrome (I haven't tested Safari or Opera.) Just getting it to look basically the same in firefox and chrome was a struggle. The html source is showing me two completely different pages as well.
Does anyone have experience with this? I know nothing of ASP.net, and it seems like the guy is modifying my layout with a wsyiwyg (I found tables used in random places, which I did not put there.) Faced with this, what is my best option? Is this fixable, or am I in over my head?
Many times WYSIWYG programs don't generate code that results in reliable, consistent renderings. However, there are a few things you can do to check your site's consistency.
You can use a program like Adobe BrowserLab (there's a free trial right now) to automatically render your page in multiple browsers side by side
You can use the w3 Validator to make sure that your code is standards compliant. If your code isn't standards compliant, then you will likely have issues across browsers.
Note that you can force asp.net to generate XHTML Transitional- or Strict-compliant code (if that's the standard you choose to implement) via the web.config file. Use the directive
<xhtmlConformance mode="Transitional"/>
if you want to enable this behavior.
Was your code rendering fine in those browsers before you sent it off to the .NET guy? If so, the programmer is doing something to muck up your work. ASP .NET won't change the way your code renders... it's simply the Windows equivalent of PHP (simply put).
I would suggest (if you haven't already) testing your code before hand-off to verify proper rendering. Take some screenshots, and if after sending your code to this developer things break, you can point out that it was working until he started messing with your markup. If that ends up being the case, at least you know it wasn't you. If it was, then we have more work to do. :)
Can you provide any samples?
The html source is showing me two completely different pages as well.
That sounds like your asp.net guy is doing something wrong there. You can use asp.net to do browser-dependant rendering, but it sounds more like his job is to just make the site render what you gave him, and it's usually better to get your html and css right to begin with.
Is it OK if everything looking OK but HTML and CSS are not valid , for CMS Admin/control panel?
Should we only consider Web-standards for site, not necessary for site-management tools?
for example
:http://example.com/wp-admin
:http://example.com/admin/
Well, the point of standards compliance is to make everything work correctly for every user. Even though admin areas are only accessible to a few select users per site, if you are building a CMS you have to consider that many, many people might use your script which would add additional users who will be needing to access those admin panels. It's best to make everything standards compliant, that's why they create them. If an admin can't get the admin panel working properly, they'll ditch the script.
I agree it may not be worthwhile to to make everything valid. As long as you've done your testing and it working then it's probably not worth the time to make everything valid.
Some validation errors matter, some don't. The spec is a bit ridiculous in its requirements in places. What is important is that all open tags are closed and they are nested correctly as if this is not done there can be many subtle errors both now and in the future. As for non-encoded entities, using rel's and targets when you shouldn't - it doesn't matter so much.
Since you (usually) can control the access to the admin area (rather than normally having every single device and platform access it) it certainly matters less. The time would probably be better spent adding more features and fixing real bugs rather than aiming for 100% compliance. Don't tell any standards advocates I said that though. :)
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Is it worth it to code different functionality for users with javascript disabled?
I've just learned in this question that an ASP.NET webforms application will have issues to run properly in a browser with disabled Javascript (unless I don't use certain controls and features).
So this is a kind of a follow-up question. For my current web application which will only have a small number of users I can postulate to enable Javascript.
But how to deal with this question in general? As I can see (with my rather small knowledge about web development until now) Javascript is all around, especially the more a web site is "dynamic" or "RIA" like.
Is it worth at all to take care about the few users during web app development who disable Javascript in their browsers?
Are they really "few"? (I actually have no clue, I just don't know anyone who has Javascript disabled.)
I'm a bit inclined to tell them: "If you want a nice interactive page, don't disable Javascript." or "You cannot enter this website without Javascript. Go away!" Because I don't want to double code and development time for some mavericks (if they are mavericks). Does it indeed add a lot more time to get a website working with Javascript and without Javascript as well?
For what reason does someone disable Javascript at all in his/her browser? Well, I've heard: "Security!" How unsecure is Javascript actually? And does that mean in the end that millions of pages are unsecure and almost every website I am using is a risk for me? Are there other reasons except security?
Are there any branches or environments where it is usual or even mandatory to disable Javascript for security (or other) reasons? (For instance I have security services, offices in defense ministries or a bank in mind.)
Are there any trends in development to see to add more Javascript to web sites, thus making it more and more necessary to let Javascript enabled in the browser? Or is there rather a counter motion?
Thank you for some feedback in advance!
Whether or not to care about users who turn off javascript should be done on a case by case basis. If you believe that it is ok to turn away users that do not have it enabled then that is a decision that you can make and is made by many apps.
Keep in mind that it is not necessarily a conscious decision to have javascript disabled or at a limited capacity. Screen readers, for example have a very stripped version of javascript and a site that uses it throughout will often be inaccessible. Depending on the website, this may actually be illegal.
If a website is properly constructed with progressive enhancement from the beginning, then creating versions that work without javascript should not be too much additional work. Therein lies one of the major issues with webforms - it is difficult to gain control over markup and javascript tends to be very tightly coupled.
My personal view is the number of people who completely disable javascript to the extent that .net web sites stop functioning is very small - For some government sites I have been responsible for, I don't recall getting any complaints from "non-javascript" users.
My concern would be more about making sure your site was xhtml compliant, with valid markup (which earlier versions of Visual Studio did not generate), valid css, and intelligent use of javascript.
Having a disclaimer somewhere on your site - that is accessible to those few with javascript disabled telling people that javascript is required for the site to function correctly would be a good thing.
Depends on your audience. For one thing, if the site is completely nonfunctional without JavaScript, accessibility (e.g. to those who must use a screen reader) may be an issue, so if you expect any blind users, you might need to consider that.
In most situations, I'd say, you're probably fine just using <noscript> tags to drop in a quick disclaimer along the lines of "JavaScript is required to use this web site."
While I have no solid numbers -- and I presume I'm in the distinct minority -- I, and many of the more savvy users I know, disable JavaScript by default (a la NoScript). I enable it on websites on a case by case basis. Most novice users (I'm ignoring the 25% in the upper/middle of experience) don't even know what "JavaScript" means.
As a developer I see the cost/benefit of supporting JS-less users
as boiling down to one question:
Do your users need the site more, or do you need your users more?
One of my current projects makes heavy use of JavaScript and Flash and does not function at all without it. But as it's installed at the employer's site and the visitors are the employees using it for their job, that requirement is completely reasonable.
However, if I were working on a revenue-generating site where losing users meant losing money, I'd seriously think about crafting the site to work w/o JS -- albeit less quickly with more page reloads. (Perhaps by asking advice here.)
As a random thought -- you could probably devise a special method to determine how many of your current users do and don't have JS enabled.
I have a web application where I would like to allow end users to customise the look of the web site by uploading their own css file.
Are there any security issues with this? I can't see anything obvious but thought I'd ask in case there was anything I'd missed.
Javascript can be executed in CSS, you have to make sure that you are using some filtering.
I have also seen incidents where someone has covered the entire page on a microsoft controlled site with a transparent pixel, linking to a malicious site. Clicking anywhere triggered the attackers site to appear.
This could however be safe if the user only sees his or her own CSS, and they would have no way of someone else viewing what they have done. Otherwise some sort of whitelist or markdown would work.
Short answer: no it isn't. HTC in IE and XBL in Mozilla are both potential attack vectors. A hack of this nature was used to steal 30,000 MySpace passwords a while back.
Source: Simon Willison, Web Security Horror Stories
I wouldn't do it because CSS can show an image that could exploit some OS vulnerability in example.
Regards.
Depending on your server and configurations, it may be possible to run server-side code from a CSS file (though, this isn't default behavior on servers I know).
Short answer: no. First bad things that come to mind are MSIE expressions.
If these CSS files are available to all site users, and not just the person who uploaded, then there's a possible XSRF vector - you could include links to offsite resources in the CSS which perform "undesirable" effects to the user requesting them.
You may get customer support overhead if a user with his custom CSS screws the screen to that extent that he won't find the controls to reset it back. In which case you as admin will need to do it manually.
For that case a possible solution. Arrange for a specific Url to reset the style. Something like:
http://mysite.com/users/234234/reset
And advice to the user when he's about to modify the style to remember this Url and just follow it if things have gone out of control. When hit, the custom styles will be deactivated.
There are probably thousands of applications out there like 'Google Web Accelerator' and all kinds of popup blockers. Then theres header blocking personal firewalls, full site blockers, and paranoid cookie monsters.
Fortunately Web Accelerator is now defunct (I suggest you read the above article - its actually quite funny what issues it caused) but there are so many other plugins and third party apps out there that its impossible to test them all with your app until its out in the wild.
What I'm looking for is advice on the most important things to remember when writing a web-app (whatever technology) with respect to ensuring the user's environment isnt going to break it. Kind of like a checklist.
Whats the craziest thing you've experienced?
PS. I may have linked to net-nanny above, but I'm not trying to make a porn site
The best advice I can give is to program defensively. For example, don't assume that all of your scripts may be loaded. I've seen cases where AdBlocker Plus will block 1/10 scripts that are included in a page just because it has the word "ad" in the name or path. While you can work around this by renaming the file, it's still good to check that a particular object exists before using it.
The weirdest thing I've seen wasn't so much a browser plugin but a firewall/proxy configuration at a user's workplace. They were using a squid proxy that was trying to remove ads by replacing any image HTTP request that it thought was an ad with a single pixel GIF image. Unfortunately it did this for non-GIF images too so when our iPhone application was expecting a PNG image and got a GIF, it would crash.
Internet Explorer 6. :)
No, but seriously. Firefox plugins like noscript and greasemonkey for one, though those are likely to be a very small minority.
Sometimes the user's environment means a screen reader (or even a braille interface like this). If your layout is in any way critical to the content being delivered as intended, you've got a problem right there.
Web pages break, fact of life; the closer you have been coding and designing up against standards, the less your fault it is.
Something I have checked in the past is loading some of the more popular toolbars that people tend to install (Google, Yahoo, MSN, etc) and seeing how that affects the users experience.
To a certain extent it is difficult to preempt which of the products you mentioned will be used by your users since there are so many. I would say your best bet is to test for the most frequent products that your user base may employ and roll with the punches for the rest. If you have the time to test other possible scenarios, by all means do.
Also, making it easy for your users to report possible issues also helps lessen the time it takes to get a fix in place should it be something you can work around.