I'm having trouble finding older revisions of the HTML5 specification. I keep finding resources such as WHATWG's version, or HTML5 differences from HTML4 and my google-fu is failing me.
Is there a repo where I can browse different versions of the HTML5 spec, and (more importantly) compare different versions?
It depends on how far back you want to go, but for looking at earlier versions a couple of options spring to mind.
The latest version of the spec has a list of links to some previous drafts at the very start.
The other option is the Wayback Machine, but it seems it stopped indexing the pages mid-2011.
Don't know how you'd go about comparing them though. You might be better looking at the diff tracker although that's tracking changes on the WHATWG version.
Related
I would like to use immutable.js, and see that v4.0.0 is at rc.12. That version string seems to indicate that v4.0.0 is not yet released. Is that because there is a problem with v4.0.0, and we should use 3.8.2, which is three years old? Is there a good fork that publishes v4.0.0 (or higher), so I can depend on it without raising questions about depending upon pre-release packages?
Last autumn a new group of devs have started work to finish 4.0 at the immutable-js-oss repo. It's not clear yet whether (or when) we can merge it back into the main repo (otherwise it will be released as a new package).
There are only a few things left to do for a final 4.0 release, 99% of the issues are already finished. If you are curious, have a look at the issues of the 4.0 milestone. The changes are mostly for compatibility with version 3.x and a few cases for handling very special data (e.g when passing nodejs objects to isolated sub-processes).
Our electron app uses RC12 since 2019, before it was on RC9 for a year. So far none of the 10'000 pilots using it crashed a plane, so I would say it works quite well.
Found a similar question about the difference between QAPlug-FindBugs and FindBugs-IDEA, but not about CheckStyle...
I think (from previous experience) with these plug-ins that one difference is that the QAPlug's CheckStyle version seems to be behind the CheckStyle-IDEA's CheckStyle version (I'm not referring to the versions of the plug-ins, but of the version of CheckStyle that's embedded in them).
Anyone knows of any other differences between those?
Advantages of CheckStyle-IDEA over QAPlug – Checkstyle:
Newer version of Checkstyle used
Community on GitHub
Fast scan before commit
Support for multiple configurations
Support for third-party checks
I haven't noticed any use case when QAPlug is better.
I know, I know, HTML5 mobile browsers include this support now, so why would anyone want to include their own? As anyone reading this is aware, WebDB is deprecated and IndexedDB is next. I am simply trying to be able to have my applications that use WebDB (and therefore, essentially, SQLite) continue to work with a minimum amount of re-writing if/when the mobile browsers all adopt IndexedDB.
I have been reading as much as I can, but can't find the answer to whether or not this is possible with an HTML5 application using Javascript. It seems possible in a C environment, but that is not what I am looking for.
As new versions of Mercurial are released, we want to somehow enforce that developers, designers, and others are using the approved (or later) version of Mercurial. For example, we are currently on version 1.8.3 I'd like someway of automatically preventing/denying users access our repositories using anything before 1.8.3, and allow any verson after. Can I do this in a hook?
We run our server on Windows and IIS. I thought about writing an IIS extension that returned 500 errors for clients not at the right version, but the client doesn't send any version information in its HTTP requests, just "mercurial/proto 1.0", which I assume means version 1.0 of Mercurial's HTTP protocol.
Is what I want possible? Are there any other ways to solve this?
We want to do this because Mercurial is case-sensitive. We are 100% on case-insensitive Windows. This causes us numerous case-folding collisions. We waste hours on them. Although Mercurial has improved its handling of case, it still has situations where case-folding issues can be introduced. As case-handling improvements are made in new versions, we want someway to enforce our users onto those versions so new problems aren't introduced that we have to spend time fixing.
Do you have strong reasons for wanting to enforce this? Mercurial has internal mechanisms that take care of version features themselves: If you create a repository with 1.8.3 that uses features not yet present in, say, 1.6, then an 1.6 client will refuse to interact with such a repository. In other words, mercurial itself denies access, but not based on version number, but based on actual features. This way, if a new release doesn't break compatibility either way, you can use both versions alongside each other without problems.
Internally, this works because mercurial adds a list of required features to the repository's metainformation, and checks this list before attempting to do anything with it. If the list contains a feature mercurial doesn't know about (yet), it concludes that it cannot meaningfully interact with it and refuses to cooperate.
So IMO the best thing to do would be to simply instate a policy that requires developers to use an up-to-date version, but not add additional technical measures. If someone tries to push with a version that's really too old, then they'll receive an error message, and if they complain, you can simply point them at the official policy.
If you're on Windows, how about deploying the Mercurial installer using Domain policies somehow?
I'm involved in some browser-compatibility testing, and we're looking at tools and so forth. One thing we need to do is visual inspection of our site in a range of different browsers on different OSs and platforms.
My question is whether there are documented differences (or someone can post some HTML+CSS) where a page will render differently in IE6 on Windows 2000 than it will in IE6 on Windows XP (say). Or IE7/XP vs IE7/Vista. Or Safari4/MacOSX Leopard vs Safari4/MacOSX Snow Leopard.
We're hoping to be able to slim down the count of combinations.
I've seen this other SO question, and don't think it's quite the same thing. The answers direct me to quirksmode.org. We're not looking for a breakdown of which elements/CSS-rules are supported in which browsers; we've got an existing site that for better or worse uses what it uses, and we'd like to get it under test to be able to make changes more safely.
You can submit to http://browsershots.org/ multiple times, eventually a different OS version will get called for the same browser version. This is not the ideal solution.