see suggested repos (based on watcher relationships)

visitor.js is a small piece of JavaScript that provides you with information on your site’s visitors, so you can target them with custom-tailored content.

http://onethingwell.org/post/15669923906/visitor-js

Example of a "Toolbar" bookmarklet

Example of a "Toolbar" bookmarklet

https://plusone.google.com/*
www.google.com##BUTTON[name="eswidget"]

There is Lagger - flexible open-source PHP library for errors/exceptions/debugs handling in PHP http://code.google.com/p/lagger

Lightweight alternative of Lagger is class PhpConsole
http://code.google.com/p/php-console/source/browse/trunk/PhpConsole

PHP Console is extension that displays errors/exceptions/debug messages handled by class PhpConsole and Lagger in Google Chrome console and in notification popups.

Changelog http://code.google.com/p/php-console/wiki/Changelog
Report bugs and features http://code.google.com/p/php-console/issues
Author http://linkedin.com/in/barbushin
See also my JavaScript Errors Notifier extension http://goo.gl/uo9Ro

--- FEATURES ---

✔ No icons on Toolbar, only in Address bar (when enabled on server)
✔ Configure from context menu (just right click on web-page)
✔ Handle exceptions and all errors (even FATAL)
✔ Display debug and errors messages in Google Chrome console
✔ Display debug and errors messages in Notification popups
✔ First popup is displayed with 3 second lifetime
✔ All other popups are displayed with configured lifetime
✔ Popup is not hiding if mouse is over or if popup window is selected
✔ All popups can be closed by clicking on close icon (x) of any popup
✔ Display errors/exceptions backtrace in console (click on >Object)
✔ Display errors/exceptions backtrace in notification (click on #source_path link)
✔ Display JavaScript errors messages in Notification popups
✔ It does not overrides user-defined JavaScript errors handlers
✔ Errors source URLs in popup are clickable
✔ Ignore repeated errors
✔ Ignore Google Chrome extensions internal errors
✔ Catch messages from any sources
✔ Web page
✔ AJAX
✔ IFrame
✔ Make custom actions on errors and debug messages (with Lagger):
✔ Log to file
✔ Send Email
✔ Send SMS
✔ Send to STDOUT

--- HOW TO USE ---

### With PhpConsole class:

1. Install PHP Console extension
2. Download PhpConsole class - http://code.google.com/p/php-console/downloads
3. Test code:

require_once('PhpConsole.php');
PhpConsole::start();

// test
debug('test message');
debug('SELECT * FROM users', 'sql');
unkownFunction($unkownVar);

### With Yii Framework extension using class PhpConsole

http://www.yiiframework.com/extension/php-console

### With Symfony Framework plugin using class PhpConsole

http://www.symfony-project.org/plugins/stPhpConsolePlugin

### With WordPress plugin using class PhpConsole

http://wpengineer.com/2197/php-console-with-chrome-and-wordpress

### With Lagger:

1. Install PHP Console extension
2. Download Lagger - http://code.google.com/p/lagger/downloads
3. Test code:

define('LAGGER_BASE_DIR', '../library/');
function autoloadLaggerClasses($class) {
if(strpos($class, 'Lagger_') === 0) {
require_once (LAGGER_BASE_DIR . str_replace('_', '/', $class) . '.php');
}
}
spl_autoload_register('autoloadLaggerClasses');
$laggerES = new Lagger_Eventspace();
$debug = new Lagger_Handler_Debug($laggerES);
$errors = new Lagger_Handler_Errors($laggerES);
$exceptions = new Lagger_Handler_Exceptions($laggerES);
$chromeConsole = new Lagger_Action_ChromeConsole();
$debug->addAction($chromeConsole);
$errors->addAction($chromeConsole);
$exceptions->addAction($chromeConsole);

function debug($message, $tags = null) {
$GLOBALS['debug']->handle($message, $tags);
}

// test
debug('debug message', 'some,test,tags');
echo $unkownVar;
unkownFunction();

See video:
http://www.youtube.com/watch?v=hBCMB2Jiyvk
For all available Lagger features using see:
http://code.google.com/p/lagger/source/browse/trunk/examples/lagger_init.php

XV is an XML viewer for Google Chrome. Online demo: http://media.chikuyonok.ru/xmlview/

*** Version 1.0.3 overrides native XML tree viewer in Chrome 11.x. There might be a flash of native viewer (depends on XML size), this may be fixed in future versions of Google Chrome only. ***

Features:

* Collapsable elements: Alt+click to expand/collapse all descendant elements. Double-click on opening or closing tag to collapse it.

* Outline for better document overview

* Search by name or XPath. By default uses simple search mode which looks for a partial match in element‘s or attribute’s name; use special symbols like '/' or '[' to search by XPath

* Quick XPath mode: hold down Command (Mac) or Ctrl (PC) key while moving mouse cursor over element‘s or attribute’s name to enter Quick XPath mode. Use Shift key to cycle through available XPath variants and then drag’n’drop element under cursor into text editor, click on element will copy XPath to clipboard

Scraper is a simple data mining extension for Google Chrome™ that is useful for online research when you need to quickly analyze data in spreadsheet form.

To use it: highlight a part of the webpage you'd like to scrape, right-click and choose "Scrape similar...". Anything that's similar to what you highlighted will be rendered in a table ready for export, compatible with Google Docs™.

This is a work-in-progress (i.e. there are bugs), and is currently intended for intermediate to advanced users who are comfortable with XPath, though jQuery is also supported to an extent.

Add-ons provide many useful features and functions, but they can also cause Firefox to become slower. Some add-ons can even slow Firefox to a crawl and make it difficult to use for regular web browsing. If you think add-ons might be the reason Firefox is lethargic, check the list below for some of the biggest bottlenecks. And remember, for best performance you should disable add-ons that you no longer use regularly.

has.js
Pure feature detection library, a la carte style.

This document is not complete.

About

Browser sniffing and feature inference are flawed techniques for detecting browser support in client side JavaScript. The goal of has.js is to provide a collection of self-contained tests and unified framework around using pure feature detection for whatever library consumes it.

You likely won't see has.js as a public API in any library. The idea is that %yourfavoritelibrary% will import some or all the available tests, based on their own needs for providing you a normalized future proof API against common tasks.

Mobile tests - index

This is a mobile-optimised (i.e. style-less) link page to all my mobile pages.

Major changes may occur without warning. I advise you to save only this index page in your bookmarks.

Identification

I’m currently testing if StatCounter is good enough to use. What I really want to do is rewrite their detection script.

(Old mobile browser detect. Don’t use)

Browserscope tests

If you arrive here by mobile browser, please follow the link to the Browserscope test pages and let them run.

Browserscope
Current tests

Flash on Adobe’s product page
Simple WebGL test
@font-face test by Robert Nyman.
W3C Mobile Web Compatibility Test
HTML5 test
Ultra-simple canvas test
SVG test; London Underground map.
Touch action
Width tests
Zooming tests
clientX/Y, pageX/Y, screenX/Y
DOM speed
Drag-and-drop (iPhone, Android, Dolfin, desktop)
Multitouch drag-and-drop (iPhone)
Scrolling layer (iPhone, Android, Dolfin, BlackBerry)
jQuery Touch test page
Sencha test page
HTML Unknown
position: fixed
touchmove ghost click
Demo of position: device-fixed
Compatibility tables

The touch events
Widths and friends
Compatibility table (optimised for screen)
CSS compatibility table (optimised for screen)
Widget object compatibility table.
Phones of my Twitter followers (sortable table; doubles as medium-complex DOM test for test phones).
DOM Core module
CSS OM module (window width/height, offsets, getClientRects(), etc.)
Device properties list (not mine).
Old tests

Simple click test
Basic font CSS
Font sizes
Focus and blur events
Scroll event
Key events
Click event
Basic DOM
Basic Ajax
CSS @media handheld
Media queries
orientationchange, related events, and screen width and height - mobile
Basic event registration
Other tests

Acid 2 and Acid 3
Jake Archibald’s closure memory test
TaskSpeed tests
Cameron Moll’s mobile HTML and CSS tests
W3C compatibility test for mobile phones
Simon Pieters’s XHTML tests. Seems to be an older test; I don’t recognize any of the phone types he lists.
Mobile concurrency test by CloudFour.
Modernizr touch test

# The Undetectables

These things cannot be feature detected. They must rely on either:

1. UA sniffing
2. Browser inferences
3. Providing the same (slow) fix to everyone

## Categories of Undetectables:

### HTML5
* `registerProtocolHandler()` support (exist[[ed|http://code.google.com/p/chromium/issues/detail?id=44984]] in webkit but doesnt do anything, still live in iOS/Android likely.)
* File Drag 'n Drop (webkit doesnt expose a global DataTransfer constuctor to inspect) [[issue 57|https://github.com/Modernizr/Modernizr/issues#issue/57]]
* webforms UI: datepicker, colorpicker UIs cannot be detected, only the associated constraint validation
* inability to edit things in contenteditable/designMode in mobile Webkit browsers


### Audio/Video
* `timeupdate` video/audio event fires inconsistently across webkit and moz
* HTML5 video `readyState` is inconsistent across webkit(4) and moz(3)
* `canPlayType()` results on mobile are unreliable
* `preload` attribute support, can't be tested without bandwidth-consuming tests (Chrome has implemented the preload-IDL, but not the feature)
* `loop` attribute support, can't be tested without bandwidth-consuming tests (support for this attribute is practically non-existent)

### Networking
* `script` tag onload/onerror/onreadystatechange actual behaviour (atomicity, order, etc etc)
* `link` tag / stylesheet onload actual behaviour (exists in webkit / ff but never fires)
* Network related metrics, a la the [[Browserscope Networking Results |http://www.browserscope.org/?category=network&]] (|| script, css, etc)



### Typography / Text
* Support for ­ or <wbr>
* ClearType disabling during opacity changes
* FOUT behavior of Gecko's @font-face support
* font rendering (like smoothing, anti-aliasing, font-weight diffs among browsers/platforms)
* consistent rendering ( in the page and alert() dialogs) of HTML entities
* proper handling of CSS `text-overflow:ellipsis` behavior on text



### Events
* keyboard event bugs, especially related to the `keydown/keypress` events, and the `keyCode/charCode` event properties.
* Best documented and fixed by the [[Google Closure guys |http://code.google.com/p/closure-library/source/browse/trunk/closure/goog/events/keyhandler.js]]
* the order (and reliability) of mousedown, click, and mouseup events (especially if a mousedblclick is happening)
* especially when fired on a form element like a checkbox, reliability of state update of the element compared to when the events fire
* whether a scroll wheel event is coming from a continuous device like a trackpad or the Magic Mouse or from a traditional clicking scroll wheel (in webkit).
* [`MozMousePixelScroll`](https://developer.mozilla.org/en/Gecko-Specific_DOM_Events#MozMousePixelScroll)
* `onhashchange` is case insensitive in IE8 (maybe 9 too?), all others are case sensitive (HTML5 requires case sensitivity). Can't be detected without actually triggering a hashchange event.
* IE8 in compatibility view mode has `onhashchange`, but doesn't support it. Workaround is to test for `document.documentMode && document.documentMode >= 9`.
* support for `DOMContentLoaded`.
* You can add an event listerner and hope, fall back to `document.readyState` or `window.onload` or in IE, the `doScroll` hack.
* `submit` + [`required` attribute](http://www.w3.org/TR/html5/common-input-element-attributes.html#attr-input-required) for form inputs: browsers that support this HTML5 attribute can **cancel** the form submit if required values are missing, but the "submit" **event still bubbles up** (Opera, Firefox 4) and it can't be detected that `preventDefault()` is called on it
* `focusin` & `focusout`: it looks like it can't be detected if these events bubble up; their implementation (as well as that of `focus` and `blur`, which shouldn't bubble) is inconsistent—for instance, `focusin/out` doesn't bubble in Mobile Safari


### CSS
* `<select>` display in IE6
* PNG alpha transparency
* The look of the various *-resize cursors is very different across browsers and platforms.
* ie6 css bugs like [[duplicate characters bug |http://www.positioniseverything.net/explorer/dup-characters.html]]
* IE display transparency bug on height > 4096px
* CSS Generated Content support
* (Updated) Solution: using generated content to alter the width or height of an element ([[Dirty example (updated) |http://jsfiddle.net/z7fTg/7/]]) [example now checks for partial CSS2 support, .e.g, Firefox < 3.5, and CSS3 support]
* [[modernizr test for gencontent |https://github.com/KrofDrakula/Modernizr/commit/cdb322bdbdc]]
* False positives for `box-shadow`, `border-radius`, etc (happens in Aurora/Midori/etc) [[issue 169 |https://github.com/Modernizr/Modernizr/issues#issue/169]]
* `pointer-events` false positive in Opera
* `position:fixed` support in iOS and Android


### Edge cases
* IE CSS bug where certain types of positioning of an `<input type=text>` element can cause that element's autocomplete box to not render at the same location as the actual input box.
* strange treatment of `<!-- -->` comment nodes in the DOM (in IE)... like in some cases, a comment node will be moved to be a child of the previous element even though it's not a child proper. Can cause things like `:empty` to fail differently.
* resize event firing rate. e.g. you can't keep an element's position smoothly updated in response to resize or scroll.


### General undetectables
* Memory leaks
* DOM/JS performance (e.g.: [[innerHTML vs. DOM manipulation|http://blog.stevenlevithan.com/archives/faster-than-innerhtml]])
* Testable, but typically not feasible to test just to avoid code forking.
* Hardware Acceleration
* Whether a CSS transition can use (or did use) [accelerated compositing](https://trac.webkit.org/wiki/QtWebKitGraphics#Acceleratedcompositing). If an effect isn't going to be hardware-accelerated, then a setTimeout animation is often more performant than a non-accelerated CSS transition. No reliable way to measure the framerate of a CSS transition.


## This might not be a complete list

Add to the list if you know more Undetectables. Likewise, link to possible solutions if you think an item listed here can be feature-detected.

Contributors: paulirish, jaubourg, rwaldron, zachleat, snover, devongovett, rgrove, savetheclocktower, getify, garann, jdalton, michaelbrundage, necolas, mislav

Bookmarklet to turn any webpage back into a wireframe with "lorem ipsum" text

Vimperator is a Firefox browser extension with strong inspiration from the Vim text editor, with a mind towards faster and more efficient browsing. It has similar key bindings and you could call it a modal web browser, as key bindings differ according to which mode you are in. For example, it has a special Hint mode, where you can follow links easily with the keyboard only. Also most functionality is available as commands, typing :back will go back within the current page history, just like hitting the back button in the toolbar.

But Vimperator is more than just a simple command interface to Firefox — it is a complete development environment as well. If you are a web developer, you can enjoy an interactive JavaScript shell — even with completion support. Or if you want to extend Vimperator, you can easily do that by just dropping a JavaScript file in its plugin directory. Browse through our wiki pages for nice tips to customize Vimperator and for frequently asked questions. If you have more questions, you can visit us on IRC, in #vimperator on freenode.

If cookies are so precious, you might find yourself asking why browsers don't do a better job of protecting their cookies. I know my friend was. Well, there is a way to protect cookies from most malicious JavaScript: HttpOnly cookies.

When you tag a cookie with the HttpOnly flag, it tells the browser that this particular cookie should only be accessed by the server. Any attempt to access the cookie from client script is strictly forbidden. Of course, this presumes you have:

1. A modern web browser
2. A browser that actually implements HttpOnly correctly

The good news is that most modern browsers do support the HttpOnly flag: Opera 9.5, Internet Explorer 7, and Firefox 3. I'm not sure if the latest versions of Safari do or not. It's sort of ironic that the HttpOnly flag was pioneered by Microsoft in hoary old Internet Explorer 6 SP1, a bowser which isn't exactly known for its iron-clad security record.

Regardless, HttpOnly cookies are a great idea, and properly implemented, make huge classes of common XSS attacks much harder to pull off. Here's what a cookie looks like with the HttpOnly flag set:

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.0
Set-Cookie: ASP.NET_SessionId=ig2fac55; path=/; HttpOnly
X-AspNet-Version: 2.0.50727
Set-Cookie: user=t=bfabf0b1c1133a822; path=/; HttpOnly
X-Powered-By: ASP.NET
Date: Tue, 26 Aug 2008 10:51:08 GMT
Content-Length: 2838

This isn't exactly news; Scott Hanselman wrote about HttpOnly a while ago. I'm not sure he understood the implications, as he was quick to dismiss it as "slowing down the average script kiddie for 15 seconds". In his defense, this was way back in 2005. A dark, primitive time. Almost pre YouTube.

HttpOnly cookies can in fact be remarkably effective. Here's what we know:

* HttpOnly restricts all access to document.cookie in IE7, Firefox 3, and Opera 9.5 (unsure about Safari)
* HttpOnly removes cookie information from the response headers in XMLHttpObject.getAllResponseHeaders() in IE7. It should do the same thing in Firefox, but it doesn't, because there's a bug.
* XMLHttpObjects may only be submitted to the domain they originated from, so there is no cross-domain posting of the cookies.

A Firefox plugin called Firesheep was released this week that makes it easy to capture and exploit other user's HTTP session cookies sent over insecure connections on untrusted networks. This vulnerability makes it possible to login to other people's accounts on a variety of services by spying on network traffic and extracting those cookies. Wikipedia has a decent article on this technique: Session Hijacking.

GitHub was susceptible to this attack, but we have now taken measures to protect you and your data. As a result, you will be prompted to re-login to the site on your next visit. This is necessary in order to switch you to the more secure system.
The Technical Details

Today, we're rolling out the first in a series of measures we have planned to make GitHub more resilient to session hijacking attacks. The basic approach revolves around setting a second cookie (in addition to the normal session cookie) that is marked as secure. Cookies marked secure, are sent only over SSL requests and are omitted on non-SSL requests. They look like this on the wire:

Set-Cookie: somename=somevalue; path=/; secure

When someone logs on, we set the secure cookie (_github_sec in our case) to the checksum of the user's id and password hash along with a secret (known only to the application) salt value. Then, on subsequent SSL requests, we verify that the cookie's value matches the same checksum. If the values are different, authentication fails.

Most browsers have a way of viewing cookie details. Here, we see the cookie is sent only over secure requests:
cookie inspector

Since we already require SSL for all sensitive requests, including browsing/admin'ing private repositories and viewing/editing account details, this extra bit of verification ensures that sidejacked session cookies cannot be used to gain access to any sensitive information.
Broader Solutions

Sidejacking is still a problem for many sites on the internet. The only way to protect yourself on every site you visit is to secure and encrypt your connection for all requests. SheepSafe from Nick Sieger is an easy to install solution for Mac that relies on an SSH tunnel and SOCKS proxy to encrypt every HTTP request you make, no matter what site you're on.

The hover pseudo-element in CSS can be a powerful tool in a front-end developers arsenal, it’s not only for changing a links colour. In good browsers the hover element can be applied to almost anything but unfortunately ie6 & 7 only support the hover selector on the anchor tag, but of course that isn’t going to stop us accomplishing something cool. I’ll be looking at using the hover pseudo-element to add some clever functionality when a user hovers over an image.

A bigass bulleted list of features.

I commonly need to get a big list of all the stuff people think of when they think new and shiny these days. This list is for that.

I take a very inclusionist approach to it. 1

boomerang is a piece of javascript that you add to your web pages, where it measures the performance of your website from your end user's point of view. It has the ability to send this data back to your server for further analysis. With boomerang, you find out exactly how fast your users think your site is.

t happens as your web app grows in size and team members that some parts of the stylesheets become obsolete, no one remembers why they were there in the first place, but no one has cojones to remove them, because of fear that removing them might break something you forgot to take into consideration. Same case when you have the same stylesheet for 50 different pages and on some pages only some of the styles are actually used. I was wondering, do you pay performance penalty when you have style rules that refer to images, but the rules are never needed to render the page? Will the browser download all those unneeded images? The answer is No. The browser will try to avoid downloading the image assets as much as possible. And this behavior is pleasantly consistent across IE, FF, Safari (for Windows), Opera.

I saw this bookmarklet here and it's beautiful. When you start it, it puts a textarea at the bottom of your page and you can type javascript in it, then eval()-uate it. Perfect! Only ... it doesn't work in frames. So I did the same thing but when you have frames (works without frames as well). The way mine works is - you first select some text in a frame, then you click the bookmarklet. A new textarea, ready to execute javascript will be placed in this frame (or iframe) that you selected. Also in this case when you type document.something, it refers to the document in the frame, not the frameset.
If you don't select any text and click the bookmarklet, it will place the textarea in the topmost document, so it will work for frame-free pages as well.

So here's the bookmarklet.
textarea eval

And here's a page where you can test.
Bookmarklet 2 - dump anything

After having my beautiful textarea, I wanted to be able to dump variables, like print_r() or var_dump() but for Javascript. I googled and I found this little script. All I did then is to make it a bookmarklet. How it works? You select the bookmarklet, it gives you a prompt, where you type whatever you want to dump, like document.location for example. Then it shows you an alert with all properties of this thing you typed. (Don't try to dump document though, or something else that recurses, because the script won't handle the recursion and will freeze)

A better approach is to make your bookmarklet as small as possible, and have it load and run the bulk of its code from an external site that you control. You can do this by employing a clever hack someone came up with a while back: write a new script tag to the end of your document containing your code, and then call functions from it. You can test new versions on your own workstation by keeping a “test” bookmarklet pointing at a different script. Every time you fix a bug or add a new feature, just push the change to that link, and people will transparently start using the new code.

In the very first browser, created by Tim Berners-Lee in 1990, web pages could be edited directly in the browser in WYSIWYG mode. The web was conceived as a read-write medium. Later browsers however, were basically read-only. Only plain text could be entered through form controls.

WYSIWYG editing in the browser returned to the mainstream with Internet Explorer 5: The new designMode property allowed a whole document to become editable by the user. At first the feature was somewhat overlooked, possible because it came among a flurry of equally underspecified, Windows-specific, proprietary extensions to IE.

In recent years the other competing browsers—Mozilla, Safari and Opera—have followed the lead and implemented editing similar to the implementation in IE. The WHATWG-group is working on standardizing the editing system—the designMode and contentEditable DOM properties intoduced in HTML 5. It seems in-browser WYSIWYG editing at last is about to become an integral part of the Web.

This article looks at the basic concepts and challenges involved in utilizing the HTML 5 editing features in recent browsers. The subjects covered are:

* The different ways of enabling editing
* The editing commands
* The HTML generated by editing
* The interaction with the DOM

The article is the first part of two. The second part will cover a detailed example of how to implement an editor.

Note: I am only considering the editing features in the latest major browser versions: Opera 9.5, Firefox 2+ and Safari 3, since previous versions are simply too buggy and inconsistent. The implementation in IE hasn’t changed significantly since IE 5.5)