dmethvin

Posted elsewhere, but https://github.com/jquery/jquery/blob/master/src/selector-na...

I didn't mean to say that's _all_ you can do, but people often expect more than qSA can deliver, especially if they've been using jQuery/Sizzle for a while. Sizzle also works around bugs in qSA implementations when they exist.

qSA's design shortcomings have been well documented, John Resig did a blog long ago about them [1].

The list of what you lose if you remove Sizzle is in the native selector file [2].

[1] http://ejohn.org/blog/thoughts-on-queryselectorall/ [2] https://github.com/jquery/jquery/blob/master/src/selector-na...

Since people see jQuery as a solution for cross-browser issues, dropping some browser support is the biggest change imaginable.

There's a difference between working as a web page in all browsers and working in all HTML-rendering environments such as the ones listed in the bullet points in the blog. For example, Windows 8 apps or Chrome add-ons have additional security restrictions on .innerHTML.

If you use really simple class and id selectors, the qSA-based selector engine may be fine. However, I think a lot of devs would be surprised about how much Sizzle is doing for them.

Sorry if I seem cranky, but did you READ the blog post? jQuery 1.9 supports those browsers and the jQuery team still supports it. Do you have a problem with us supporting a second version that can be smaller, faster, and work in places other than obsolete browsers?

Hi Ian, I think you're doing an amazing job, but basically by yourself if the GitHub graphs are any indication [1]. It helps to have a group of people with differing experiences and perspectives when designing an API, and of course more people to do the heavy lifting as well. If docs aren't your thing, then there should be someone to review and write the docs. Since jqMobi has diverged from jQuery, that makes docs even more important because the name implies to people that it works like jQuery.

As far as the attr/prop thing goes, we changed it a couple of years ago in jQuery 1.6 and deprecated the old behavior, but there is still a lot of code out there that does the wrong thing. That's why 1.9 was such a code breaker for a lot of people.

    [1] https://github.com/01org/appframework/contributors

jqMobi and jQuery Mobile are two very different things. Despite "jq" in the name, jqMobi is not jQuery (or jQuery Mobile) compatible. It has a similar syntax and implements a subset of features, but even the APIs with the same names are not always fully compatible.

My main question would be whether there is a long-term commitment to jqMobi by Intel. For something with Intel's name on it, the project pages have an embarrassing number of spelling and grammar errors. [1] I don't see a lot of contributors to the repo [2] and the unit tests haven't been updated in 3 months despite quite a bit of recent activity in the repo.

    [1] http://app-framework-software.intel.com/
    [2] https://github.com/01org/appframework

[Edit: I should say I'm on the jQuery team]

Right, and even better than a document fragment since fragments have both unusual semantics and API limitations that normal elements do not (e.g., no getElementsByTagName or getElementById).

In the comments they mention about 1/4 the energy density of a lithium ion battery, so yes they don't compete on that measure. But full charging can happen in a minute or two, and you could top up a charge in seconds. Perhaps public areas would have inductive chargers on the wall; you'd just walk over and hold your phone or tablet up to it for a few seconds. Airline tray tables could have an inductive charger built in.

Higher energy densities aren't without issues, as Boeing found out with their 787. A battery like that is basically an explosive and it can be tricky to manage.

> Any blog that excerpts a bit of a news story is now guilty of copyright infringement

It wasn't "a bit" at all, read the article. News stories are written in pyramid style, with the most important summary being in the lede, the first paragraph. That is what was being copied, as well as the title and any mention in the article that contained whatever keyword the user used for the search.

In this case the copier was also charging users directly for the content, it wasn't some indirect thing. Your summary seems both inaccurate and alarmist.

Why pick on Chrome? How does this differ from extensions offered by Firefox or Internet Explorer? They all allow essentially similar behavior. Eventually it comes down to whether you trust the extension.

If I'm running AdBlock it needs to be able to modify the HTML of any page and occasionally update its lists using the Internet. But AdBlock Extra Evil Edition might also be paid by someone to not block their ads or to leave beacons in place.

A form filling application could potentially push evil information into a form and submit it before I could do anything. Or it may work the way I expect and only fill in data that I want to be filled. How do you allow the good stuff without also allowing the bad stuff?

I like my Thinkpad Carbon X1 Touch. It's kind of like a Macbook Air with a 14-inch touch screen. When sitting down I tend to stay with the keyboard and trackpad. However, when on conference calls I find myself walking around with the notebook cradled in one arm and using the touch screen with the other hand. It's a very nice combination.

On the other hand I spend basically NO time in the start menu and have installed Classic Start, so it's really like an enhanced Windows 8 to me.

First, it's a very nice new streams interface. Second, the core functionality can't change that much at this point if people want their old code to work. Read the discussion of streams2 and see how much thought went into avoiding breakage. http://blog.nodejs.org/2012/12/20/streams2/

The thing I miss most about vinyl is the creative canvas that was the album cover. There's no way to hear _Dark Side of the Moon_ or _Sticky Fingers_ without also seeing the album in your mind.

The answers in that thread seem to be reasonable. XP is a decade-old OS, we should be glad that it will finally pass on April 2014. Supporting multiple operating systems takes time, especially for one that old. At some point it's best to move on.

If your company is affected by lack of XP support in this PHP build, it should be a temporary convenience at worst. What are your plans to migrate off XP over the next year? As of next April there will be no patches or security fixes coming for XP. Is your company planning on paying Microsoft for continued support, or will it negotiate extended XP support in return for buying company-wide Windows 8 licenses and start the ride over again?

I suspect that many of the people using XP today are frozen and wouldn't upgrade their PHP anyway, for the same reasons they're using XP and IE6. They either don't want to change their software because of cost/risk issues or the people who wrote it moved on years ago and they have no idea how it works.

That's the Dunning-Kruger Effect.

I invite you to submit your work from 14 years ago and have it judged by 2013 standards.

In either 1.9 or 2.0 you have the option to exclude XHR or animations as well as several other functional modules. More feature-lopping capability will be coming soon.

Before getting into web dev I spent a lot of time doing development in C/C++. That code needed to be portable across systems and versions but it was an entirely different kind of portable than we grapple with on the web. For C code we could handle the issue with conditional compilation, build scripts, or dynamic loading.

On the web it's all dynamic; all the code for handling every situation you might encounter comes down to the client when the page loads and you sort out the details at runtime while the user taps their fingers on the table. If there is a large amount of code to fix one specific browser you can break that out and pull it down only for that browser, but the kind of bugs that jQuery works around tend to be of the death-by-a-thousand-little-cuts variety where it just doesn't pay to refactor that way.

I was only comparing the version-spread problem of WebKit to the one we have in IE, not comparing the two browsers.

Yes, we try to put a link into our tracker with the ticket in their tracker for both bugs and spec ambiguities. Note that several are a few years old and are still open.

http://bugs.jquery.com/ticket/11663 http://bugs.jquery.com/ticket/12986 http://bugs.jquery.com/ticket/12968 http://bugs.jquery.com/ticket/12964 http://bugs.jquery.com/ticket/10509 http://bugs.jquery.com/ticket/12577

That wasn't a bug that jQuery reported or has encountered. The ones we report probably aren't half a line of code to fix. And as for why we don't fix them ourselves, I can't speak for the rest of the jQuery team but one unpaid volunteer open source job is plenty for me.

I suspect that was a well-orchestrated commit to show that Opera had joined the WebKit collective. It was mentioned in Opera's press release.

This must be an enterprise product, because I can't tell exactly what it does from the blog post or the home page. Is it like Errorception? What languages does it support? No need to explain in a comment here, just point me to the page on their site that I can't find -- but must be there -- that explains in simple terms.

Preach it brother! The people who don't care about the RC are the ones who jump on it day 1 of the release because it's "finally ready" and then complain about the bugs.

> A delightful solution to this would be a similar degree of modularity as there is in, for example, jQuery UI

Except that jQuery Core is a completely different thing. You know if you're using jQuery UI Menu but not jQuery UI Dialog so you can decide to include them or not with a custom web-based builder just by clicking boxes.

The jQuery Core features used by all the plugins you collected to build your site are not immediately obvious. Did they use .replaceWith() for example, is it safe to leave that out? What about .load(), did they use that API? Oh, wait, there are two different things that .load() does, one is AJAX-y and one is event-y, if they did use it which one did they mean?

By having the full library there you don't need to spend lots of time tracing down these dependencies. And in JavaScript these are all dynamic, you can never really be sure you got the dependencies right until you find out you didn't.

That's why I strongly advocate that the average programmer should just use the whole standard jQuery core library unless you are in some spot where saving 10-20KB gzipped is so important that you're willing to chase down those dependencies yourself.

It really feels a lot like the shuttle disasters, with Boeing playing the part of NASA and delegating work out to contractors who feel they must get something out or risk losing the next big contract. God forbid if this does come down to a disaster it will be even more difficult to unravel, since this time it will cross political and cultural boundaries.

It sucks when you run a bug tracker and it's spammed relentlessly because you allow anonymous comments. It sucks when someone files a legit bug anonymously and there's no way to reach them for followup or clarification.

Buy.com is now Rakuten.com? Talk about choosing the wrong domain name to consolidate under!