We Keep Coding

Can I use jquery within my custom Polymer elements?

The Polymer documentation says:
Polymer provides a custom API for manipulating DOM such that local DOM and light DOM trees are properly maintained. These methods and properties have the same signatures as their standard DOM equivalents, except that properties and methods that return a list of nodes return an Array, not a NodeList.
Note: All DOM manipulation must use this API, as opposed to DOM API directly on nodes.
Jquery has a lot of useful methods though, which make my life easier, like toggleClass, hasClass, addClass, one...
I have been able to use some of these methods without consequence in my elements, but I am wondering what exactly the semantics are behind the bold part of the above quote, so I can reason about things more clearly.
Note: I'm not talking about using jquery in the main document, I am talking about using it when I am inside the shadow boundary, like in an element's ready callback for instance.

You can, actually. You'll just have to use Polymer.dom(this.root).querySelector and wrap that returned element in jquery.
Here's an example. http://jsbin.com/purudu/edit?html,output

JavaScript: document.createNode or plain html?

Is it better to use
document.createNode();
or plain text like
var foo = '<div> bar </div>';
to create HTML markup with JavaScript?

There is no "better" in this particular case, it is going to boil down to what is most easily maintained. and programmer preference.
In some browsers, using DOM to create elements and nodes is, in terms of performance, faster than others. Some user agents process strings faster, for example by setting the innerHTML property.
I personally prefer to use DOM objects always, but I use the mootools framework which lends itself to this approach. jQuery encourages string-based creation.
Check out this benchmark: http://jsperf.com/string-vs-createelement/3, but also consider these articles: http://www.quirksmode.org/dom/innerhtml_old.html and http://karma.nucleuscms.org/item/101

It is better to use the DOM node functions. If you want to create it using a string, look into jQuery, as it has ways to parse it correctly into DOM nodes for you.
var foo = $('<div> bar </div>');

Using DOM manipulation functions you can have a reference to the created elements, one by one, and will be easier to modify the code later on, for example modify the tree order, adding or removing an element, and also for debugging purposes.
This said, there are some times I experienced myself in which the DOM manipulation functions are not the best way.
For example I had the necessity to modify real time the content of a style tag, to control the style of the elements directly via text css rules, something you can't achieve in all browsers using the various JS style objects, because they contain read-only properties.
In this case the style tag html was read-only for IE (or at least IE didn't like to modify it via innerHtml or similar), the only solution I found was to read the old html value, change it, remove the element and create a new style tag element with the new html directly typed in the string when creating the element.
This said, I would go with the DOM node functions whenever possible.

Get element by tag name shorthand?

I don't know what it's called, but I know that there's a way to get elements based on their tags without getElementsByTagName. It returns the same thing, but it's shorter and I'm using tags a lot in my project. What I'm talking about is document.frames[x] and document.images[x], but with other elements, like document.b[x] or document.a[x]. Seeing as document.images isn't the same as the <img> tag, it seems like if there are more they'd be named differently as well. Would anyone happen to know what it's called when using this method and/or have a list of accepted tags? Thanks.
P.S. Please do not suggest using a library such as jQuery. This project is meant to be a learning experience, so I want to use regular JavaScript.

As mentioned elsewhere in the answers, this doesn't have anything to do with JavaScript really, these are DOM properties and methods accessible via the JavaScript language binding for the DOM.
With reference to addressing elements such as document.frames[x] (note that this is incorrect, it should be window.frames[x]) and document.images[x] - these are Document Object/HTML Collections and the W3C standard includes only images, applets, links, forms and anchors.
So unless I'm looking in completely the wrong place, from what I can tell from the DOM-1 and DOM-2 specs, there doesn't seem to any way of arbitrarily addressing elements by tag name the way that you remember doing.
Update
The MDC entry on HTMLCollection is more understandable; it reads
The following lists each item (and its specific properties) which return an HTMLCollection: Document (images, applets, links, forms, anchors); form (elements); map (areas); table (rows, tBodies); tableSection (rows); row (cells)

Other than other JavaScript libraries creating these shorthands, I am not aware of any that are built into the language. It would be trivial to map this to your own shorthand:
var $ = document.getElementsByTagName;
// you can then use it like so:
$('SPAN').// and so on
Other than this, there is no built-in array-like access to all of the tags in the document:
http://www.javascriptkit.com/jsref/document.shtml

Create your own reference,
document.tag = document.getElementsByTagName;
or a wrapper,
function tag(name) {
return document.getElementsByTagName(name);
}
The only APIs I know of that support querying by element name are,
DOM
getElementsByTagName
CSS Selectors
querySelectorAll
XPath
evaluate
E4X
(mozilla only, and doesn't work with the DOM yet)

Is it a bad practice to reference Javascript objects from DOM elements?

As a "best practice" for front-end developers, is it bad to use the "control" property to reference back to the Javascript object?
Here's a link to the property in question:
https://developer.mozilla.org/en/XUL/Property/control
I've seen a lot of Javascript functions that reference DOM elements using selectors and then perform DOM manipulation that way. But what if we started by traversing through the DOM tree and we have the DOM element first?
EDIT 1
Okay, it seems like there are some interest here but no contributions for some reason. This started as a conversation between me and my co-worker. He was concerned about circular references and possible cases of losing references... does that apply here? I thought as long as we don't call delete <javascript object> then we're fine.
EDIT 2 I found this: JQuery methods and DOM properties
In my world right now, I'm using the Microsoft AJAX Library where we created multiple ScriptControls and put them on various pages; which in turn, (the ScriptControls) get "modified" by page's events and sometimes events of other ScriptControls. When pages need to do something with the DOM element, the Javascript would use the respective Javascript Object's methods.
However, it seems in JQuery (based on the other question), it's common to get the DOM element then use .get(0) to grab the JQuery object out of it (if it exists).
So I guess this is a witch hunt so far and there's still no right answer to my question :(
I know I'm still lacking an example but I'm not sure how to approach this.

I am not too sure what exactly you're referring to. Could you provide a simple code example? Otherwise, your question is a bit vague IMHO. I'll give it a shot anyways:
I do not understand why there would be any lost or circular references. The control attribute is just the id (string) of the "controlling" DOM Element, not a reference to the actual DOM Element. If you delete label.control it will no longer be associated with the other DOM Element.

jQuery: what is it "forbidden" to do in plain Javascript

A jQuery best practices question.
I am writing a very jQuery intensive web page. I am new to jQuery and notice its power, but as I come with heavy javascript experience and knowledge, my question is: What should be done in jQuery and what in plain javascript.
For example, there are callbacks that send a plain DOM object as an argument. Should I use that or should I wrap it ( like $(this)).
Does it matter if I do this.x=y or $(this).attr("x", y).

If your function receives a DOM object and you don't need any jQuery functionality for that DOM object, then there is no need to make convert it to a jQuery object. For instance, if you receive a checkbox object, you can examine the checked property without any use of jQuery.
However, if you need to navigate to a different element from that checkbox, it might be worthwhile to convert it:
function yourCallback(cb) {
cb = $(cb);
var sel = $(cb).closest('td').next().find('select');
// For example, update the options in a neighboring select field
...
}
jQuery (as do other libraries) blend in smoothly with native JS. If you need extra functionality, augment the object in question.
As for your last question: You might find the data function useful to avoid nonstandard DOM attributes. If your property x in your question is in fact a valid DOM attribute, you can write either this.x = y or $(this).attr('x', y), IMO it does not matter much. However, if x is not a DOM attribute, use
$(this).data('key', value)
That way, you can store arbitrary key-value pairs with the DOM element, where value can be an arbitrary primitive value or object.

I think it's a judgement call. Use your common sense.
For instance, if you have 1000 div's on the page, you probably wouldn't want to wrap it inside $(..)
$('div').click(function() {
this.id = Random.guid(); // instead of $(this).attr('id', Random.guid());
});
As for other assignments, as long as you understand what jQuery is doing, you can stick with it just for consistency, but be aware of performance issues like in the above example.
As #colinmarc mentions, at times jQuery blurs the distinction between element attributes and object properties which can be misleading and buggy.

When your using jQuery, it always returns an instance of jQuery unless obv your using a function like val();
the reason we use $(this).value instead of this.value is to make sure that this is an instance of jQuery.
if somewhere in your code you set a variable called my_link witch is equal a DOM Object and not a jQuery function.. further in your application my_link.val() would result into an error, but by doing $(my_link).val() will assure you that the function val will be available. as $() returns an instance of jquery.
Sorry for the miss understanding in my previous post.

Since jQuery objects have richer functionality than nature JS DOM nodes, if you're on the fence, you might as well wrap in jQuery. JQuery is so lightweight, there's not really much reason not to use jQuery objects.
Does it matter if I do this.x=y or $(this).attr("x", y).
The native will be slightly faster, but you'll probably spend more time in other code-- DOM traversal or building. In this specific example, the former is more concise, so I'd choose that. Since jQuery is so lightweight, I tend to switch back and forth fluidly.
Here are other guidelines we follow:
For callbacks, like a click handler, you'll need to follow the API-- usually a DOM node. Code you write that is similar should probably just take DOM nodes as well. But if you have a list of items, always use a jQuery object.
For most code, I try to see if you can structure the code as a jQuery plugin-- applying some transformation to a set of DOM nodes. If you can do that, you'll gain some guidance from the plugin architecture.
I use jQuery's bind/trigger mechanism as it is quite flexible and low-coupling.
To keep code straight, I'd recommend name prefixing jQuery objects with a dollar sign. For example, var $this = $(this);. Although it's really no big deal to call $() excessively, it does end up looking a sloppy if you call it too much.
Hope this helps.