I am fairly new to web development, so forgive me if this is obvious. I have created a site, that is looking good on Chrome and Mozilla, but it appears I can not get the IE version to scroll at the same rate/height that my other versions are. Although I declare the height to be 6000 pixels, I am only able to scroll down to 1700ish, I have it outputting in the console if you wish to see it.
Take a look:
http://nick-barth.com/lindylongcon/
If you happen to notice any of my innumerable mistakes, feel free to mention them!
Thank you,
Nick Barth
As we talked about in the comments, there are major differences between IE version releases. IE6 through 8 are considered legacy browsers, while IE9 and greater are more inline with standard newer web technologies (css3 support only entered with IE10 for example).
When you said that it looked the same using different version I immediatly suspected it had something to do with quirks mode. quirks mode is a technique which allows support for older browsers. And it is the default mode for IE if you are not using <!DOCTYPE html>. By adding that to the top of your page you are saying to IE 'use standards mode' (and check out that link I mentioned for details about different types of DOCTYPE's and what they mean).
It also greatly explains why you were seeing such a specific problem with the css attribute of the width: 100%, to quote the wiki article (emphasis mine):
One prominent difference between quirks and standards modes is the
handling of the CSS Internet Explorer box model bug. Before version 6,
Internet Explorer used an algorithm for determining the width of an
element's box which conflicted with the algorithm detailed in the CSS
specification, and due to Internet Explorer's popularity many pages
were created which relied upon this non-standard algorithm. As of
version 6, Internet Explorer uses the CSS specification's algorithm
when rendering in standards mode and uses the previous, non-standard
algorithm when rendering in quirks mode.
Today, with a less than 5 percent usage of legacy browsers (which also support the newer width algorithm because it was introduced with the now extremely old IE6), you probably wouldn't need to use quirks mode ever, but it helps to know why adding the doctype is important (rather than doing it blindly).
Related
We are told to use progressive enhancement when building websites that will use modern features if available but still work if not.
However, I find it hard to test the fallback cases. Of course there should be some tests with some older browsers, but it is hard to target non-support of specific features. It is also nicer to use recent developer tools that are not available in legacy browsers.
Example: I use a flexbox layout with a float-based fallback. I would like to debug the fallback in chrome, but flexbox is already available there. I could also use IE 8 which does not support flexbox, but it also does not support many other features and the developer tools are not as nice to work with.
Is there something like "reverse polyfills" that remove support instead of adding it? What other solutions are available?
Safari has a "feature" which preloads pages while you are typing in the url.
Now for most users this is indeed a feature, speeding up page loads. But for web developers it can cause trouble - especially when it automatically loads scripts (such as importers or background scripts) that you have used earlier but have no intention of running currently.
This happens under Safari 8.x but it is possible that this was also the case on older versions.
Also, note that this feature is distinct from "DNS prefetch" which is the only related explanation I have come across - I have disabled DNS prefetch and that did not solve this issue...
The answer is much simpler than I thought. :)
I want to make a little painting program. So i am going over if it's even possible. As with all good painting programs it needs to have pressure sensitivity. And i don't think i have ever come across anyway to get pressure sensitivity of mouse/tablet. Is there a workaround.
The thing i have come closest to is touch event that is supposed to have pressure property.
This question has been asked before but that was like in 2009. I am hoping that there would be something available this time.
Chrome apps are also an option.
As far as I know only Firefox support this through a proprietary property on the event object:
var pressure = event.mozPressure;
which keeps a value between 0.0 and 1.0.
Wacom has a plugin that can be installed to give browsers an API to read these sort of values from but I guess it only works with their own tablets.
Hello from the future world of 2022!
There is a PointerEvent API that appears to be supported by major browsers, and pressure can be read out from the PointerEvent.pressure property.
tldraw is an example of a project using this API.
Notes on operating system support for this:
macOS
I can confirm pressure-sensitivity with tldraw's drawing tool works for me on macOS, with either Chrome or Firefox, and a cheap Wacom tablet. Safari did not.
Linux
Chrome on Linux works out of the box; I used the Flatpak version. Your mileage may vary with the .deb or Snap package.
For Firefox, you may need to do this or this to get pressure-sensitivity working. There seems to be a regression with Xinput 2 support being tracked by bug #1207700, so maybe this will be fixed some day.
Windows
I don't imagine you'll have any problems on Windows, but I'm unable to test.
If you were interested in creating a web-based paint program in 2022, you might have a look at Pressure.js, which claims to support both pressure input and "3D Touch" present on some Apple devices in a single library. I have no first-hand experience with this library, though, so I can't back up those claims.
It's true this comes 9 years too late for your project. Sorry about that. But this question ranks high in search results for "pressure sensitivity javascript api," so perhaps it can still be useful to someone.
For our project we need .NET WebBrowser control that supports automatic Windows authentication (like IE does). We have reviewed a number of options, but still can't select proper one:
1) Standard WebBrowser control based on IE. Quite fast, but it just has enormous memory leaks. On our rich-script page each opening of new page leaks about 7Mb of memory. There are a lot of discussions around it, but no solution.
2) Awesomium WebBrowser control (awesomium.com). It looked as really good option and in documentation was stated that it supported automatic windows authentication, so we were going to buy it. But automatic windows authentication just doesn't work. Support simply ignores all questions about it (although answers other ones quite quickly). That was one of the worst support of paid components that I have seen.
3) GeckoFx - it works quite well, but it is too slow (even IE control in 2-3 times faster).
4) Webkit.Net - it is very fast and it would have been good choice, but it doesn't support automatic windows authentication at all.
Are there any other choices that we can consider? Both free/paid components work for us.
have you tried a version of geckofx that uses a newer firefox? eg. https://bitbucket.org/geckofx/geckofx-9.0/downloads
As background, I currently develop for a university, and we have problems with departments demanding "web 2.0 content" and accessibility requirements.
How do really big sites that are JavaScript based deal with 508 Compliance? Some sites degrade, and others require enabling JavaScript. How much impact does one decision have versus the other?
Also, in a realistic sense, how much development time should be devoted the accessible versions of sites versus the "main" versions?
I'm a blind developer and find it possible to use many Web 2.0 sites - this is most certainly possible.
Firstly, I strongly advise against making a separae accessible site, regardless of how many people advise you to do this. This is bad practice and will end up being more work, even if it initialy seems simpler.
Next, try to use progressive enhancement (particularly if this is a new site). Code the site without any Javascript; it's not just accessibility which benefits. Then, in your OnLoad() go through and attach Click events to the anchor tags; this way if you have Javascript you'll see the Ajax version, otherwise you will have a full page refresh and see another HTML page.
Luckily, there is a new standard, WAI-Aria (www.w3.org/WAI/intro/aria.php) which makes this much simpler. You attach attributes to HTML tags to identify the semantics of an Ajax control, for example. The only problem with Aria is that it only works with newer screen readers and web browsers. The university may well require the site be accessible to people running older software.
I'm a screen reader user and often use Javascript enabled sites. Javascript is not an accessibility issue, the way it is used can be. For example if the site uses javascript that requires the use of a mouse and doesn't have keyboard alternatives it will not be 508 compliant. An example of a site that uses Javascript and is accessible is stackoverflow.com. The only feature that isn't accessible is the ability to determine if you have accepted an answer to a question. I would take a look at the links in Annie's answer. All the blind college students I know use a fairly modern browser with Javascript enabled, Lynx is no longer popular in the blind community. If you want to try using a screen reader a good open source one for windows can be found at
http://www.nvda-project.org/
and it works well with firefox. If you want to try using the web with out Javascript install the Noscript addin.
Sites don't have to disable JavaScript to be accessible. Many sites use ARIA roles to work better with screen readers. There's a giant list of articles on accessible AJAX applications here. You could try something like AxsJAX.