potch

The low contrast must have impaired your reading ability:

> just as the Reactive Manifesto reminded us that new branding can give a youthful glow to decades-old ideas

I do this too- works great and GifBrewery is a nice tradeoff of quality and usability.

Incidentally, you can do this without installing an addon. In about:config, set the `browser.newtab.url` to any URL (file:///, local, or otherwise) you wish.

This is really slick- nice work!

Otherwise healthy adults die of the flu every year.

Here's a list of DOM bugs in browsers that jQuery works around:

https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0Rlh...

Pretty sure they're not all fixed, and this is just the ignorance du jour.

Yeah! We should find these engineers who might have families and shame them to the world! They'll never work in this town again after they traded in their scruples for a few bucks.

In other news, I'm excited to announce my social dating startup just got acquired for a bunch of money! We'll be deleting all the data and shutting down.

Mozilla was the one who decided not to renew.

I will interpret this as a bug report. What browser are you testing in?

This is a project under active development, and was created to address of the need of mobile app developers who expect some form of UI toolkit for building mobile webapps.

Hey, Brick project member here. Completely agreed, the styling for these components is not where it needs to be. We're a small team that works in the open, and like to ship.

22/7 app sux not close enough to pi

I work for Mozilla. I suppose you have evidence I do not.

Yes, we made extra sure this add-on got updated. Lots of TST users at Mozilla :)

I work for Mozilla. I support Brendan as our CEO. I strongly, vehemently oppose his views on gay marriage. I personally won't tolerate any CEO-level chicanery on our internal and external policies of tolerance, though I do not expect any. I am not alone in this feeling amongst the staff. I think his leadership is good for the organization and its goals. This cognitive dissonance will likely make me even more diligent in ensuring Mozilla is an equitable place to work.

Engineers aren't just resources to be allocated. Quality isn't a zero-sum game. If a manager said "all of you should only be working on performance", it would be a waste of a lot of people's time who aren't performance engineers.

This is speculation: The reason Google is moving forward quickly with Shadow DOM implementation is that this polyfill is dog slow. Think about what it takes to make DOM invisible in the browser in a polyfill- overriding every DOM method to filter out shadowed nodes. I've heard reports of 10x slowdowns on DOM operations with this polyfill in place. The kicker? Web Components (specifically Custom Elements) lose almost all their encapsulation without Shadow DOM. Those of us who are betting heavy on Web Components as The Future™ are pretty anxious about this.

The concern is shipping a non-standard solution and then encouraging developers to use it is the first step toward lock-in. No matter how much you flag something as experimental, it will be used, and the developers who built things using it will move on. When other browsers later implement the standard, nobody goes back to build it in to their projects- they're working on new projects now. This is how Firefox can support Web Audio and still not have it work on the majority of sites that use it. A differing implementation is just as bad as a prefix, and hurtful to future developers who will have to code for it to reach a compatibility matrix.

I'm suggesting if people in the appropriate working group feel as if a particular solution to a problem (regardless of how old the problem is) wasn't given due consideration, the notion of "speak now or we'll ship anyway" is not productive. I don't believe that Google in particular is a bad actor in the standards community. Far from it! I do feel as if something as fundamentally paradigm-shifting as Web Components needs care and thought to be done correctly and respectfully. Saying "we're going to ship this solution ASAP, any last-minute objections" puts unnecessary stress and time constraints on the task of making the best, most useful solution possible.

The historical processes boil down to:

1) Single Browser Ideates -> Single Browser Ships -> Time Passes -> Other Browsers Ship -> Standard. This caused delay in implementation and vendor prefix hell.

2) W3C Ideates -> W3C Bikesheds -> Browsers Implement. This causes things like AppCache that work on paper, but don't adequately cover developer use cases and address the needs of the platform.

The ideal process (in my opinion)

1) Single Vendor Ideates -> W3C Evaluates/Refines -> Browsers Implement Under Feature Flags -> Standard -> Feature Flags are removed. This process, depending on the size/scope of the change, should take about 6mo to a year. For a permanent irrevocable change to a cross-browser API? That is mature and prudent.

edit: formatting.

You're right, the MPAA example is inapt.

As regards what makes Shadow DOM special? It's not special. The issue is that Google has made many public claims toward a Brand New Day of participation in standards with Blink. [1] Vendors and developers were beginning to have cautious optimism that upcoming standards wouldn't be as rushed and fragmanted as they were in the past. This action directly contradicts the previous goodwill.

[1] http://www.chromium.org/blink#new-features

Google should respect the desire of other parties to be given adequate time to review their proposals. Being told "you have to object NOW because we're going to ship" doesn't allow third parties to actually identify technical issues. It's like someone committing code without letting their peers review that code for flaws. It's a recipe for cementing flaws into the web platform. Intended or not, there is arrogance in the notion that external discussion of Google's proposal won't improve it.

When the features don't work the same way in every browser, it hurts the platform. Poorly designed features are impossible to take back. (see also AppCache). Web Components is moving quickly, but there has to be an element of care. Shipping features before they're ready is driven by marketing and PR, not engineering maturity.

The problem is the standards process exists to keep people from swinging their weight to force rushed/poorly thought-out technologies into a platform some already accuse of fragmentation and bloat. And to people who "But this is Google!" Throwing the process under the bus today because you think your favorite tech company can do no wrong screws everyone later when management changes. Management will change. The process is here to protect the web's interests regardless of whether any one actor's intent is good or not. If Google steamrolls everyone today, who will steamroll everyone tomorrow? The MPAA is on the W3C too.

This article is not actually correct. There are really 2 or three techniques for centering a block level element. The post repeats these techniques for multiple scenarios, and is wrong about the first vertical centering technique.

Sounds like a great spot to set up a hacker commune!

I always wonder where people learned the notion that hypocrisy instantly invalidates any argument in a puff of smug smoke. Yes, Valleywag are pots to the Silicon Valley kettle. It's still funny, and still shines a good light on the idiotic self-important traipsing of the tech scene.

If you use a browser extension that allows for site-specific user CSS, the following does the trick beautifully:

.diff-line-pre { white-space: pre-wrap; }

If you set up a git server yourself, you can disable --force pushes globally: http://randyfay.com/content/avoiding-git-disasters-gory-stor...

Name another software runtime that even partially works as well cross-platform. Or another runtime that has the notion of multiple competing implementors.

This article reads like this comic: http://imgs.xkcd.com/comics/rock_band.png

goes back to happily writing JavaScript