| // Highlights all custom elements on the page. | |
| // 7/31/2016: updated to work with both shadow dom v0 and v1. | |
| // To create a bookmarklet, use http://ted.mielczarek.org/code/mozilla/bookmarklet.html | |
| var allCustomElements = []; | |
| function isCustomElement(el) { | |
| const isAttr = el.getAttribute('is'); | |
| // Check for <super-button> and <button is="super-button">. | |
| return el.localName.includes('-') || isAttr && isAttr.includes('-'); |
As I understand it, the original Custom Elements concept had a crystalline form: attach a class to a tag-name.
Using the yet-to-be ES6 syntax, it would look something like this:
class MyElement extends HTMLElement {
constructor() {
}
doStuff() {
}
This gist is meant to help me compile "tips" for getting involved in the standards process. It will be used as a source of material for a talk I'm giving at LXJS in a couple days. The tips are meant to be somewhat tactical, i.e. provide concrete advice for first-timers, and not general sweeping statements about how standards bodies work in the abstract.
If you have any additional tips, please leave them in a comment or email them to me at [email protected], and they'll hopefully make it into my presentation.
As with all new communities you're joining, you'll get better results if you lurk first, both in IRC and on the relevant mailing lists. You'll get to know who's active in what area; what kind of topics are on the group's radar; which issues are contentious; and even basic stuff like how to write emails (prefer plain text, never top-quote).
The goals of this project are to define a layered architecture for the client-side web platform[1] that W3C working groups can use to define new platform features and refine existing platform features.
Specifically, this architecture defines a clear relationship between markup and imperative code.
Rustpkg is a revamp of Cargo that brings awesome new features such as a build system described in build scripts.
It's a purely functional package manager that has no central sources of any kind,
but rather installs via URLs. It's similar to how Go's go get tool works, except
Rustpkg requires a central metadata file (pkg.rs) in the repository, archive or folder
in order to figure out how to build the package. This is a side effect of Rustpkg
allowing multiple crates to be defined in a single package (i.e. a package is defined
as a set of crates rather than a package being exactly the same as one crate).
There's a plan to make it so the pkg.rs is not needed for single-crate packages,
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs
| # %(mysite)s - run %(mysite)s instances (default is the main production instance) | |
| # | |
| # This runs gunicorn-django for %(mysite)s; to install: | |
| # * sudo ln -s <this file> /etc/init/%(mysite)s | |
| # * sudo initctl reload-configuration | |
| # | |
| # it expects the following directory layout: | |
| # | |
| # /home/%(mysite)s/public_html | |
| # \-env -> virtualenv |