Side navigation
#10697 closed bug (fixed)
Opened November 07, 2011 02:14AM UTC
Closed May 28, 2012 04:54PM UTC
Sizzle revamp
| Reported by: | timmywil | Owned by: | timmywil |
|---|---|---|---|
| Priority: | blocker | Milestone: | 1.8 |
| Component: | selector | Version: | 1.7 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
This ticket is for tracking enhancements and reductions for Sizzle. Some of these may belong in separate tickets, but I need to compile the list somewhere. I plan on doing/researching all of this in 1.8.
These are my ideas so far:
1. Reorganize the main Sizzle function to be one function that contains shortcuts for id, tag, class, and document.body and an internal select function that uses qsa if available. Sizzle somewhat does this already, but not completely. I think it would reduce the size of Sizzle itself. We also do some of this in jQuery.fn.init and duplicate some of what is already in a qsa Sizzle. This could remove the need for that duplication and shave even more bytes.
2. This may not be feasible, but I want to look into adding local vars for the most common things referenced from within Sizzle instead of using.long.property.accesses internally.
3. The implementation of prefilters seems a bit wet. I'd like to dry up some of that code and look into reducing the call stack on that codepath.
4. Add a support-test regex builder for places in which we know QSA will fail, such as with :checked on select elements in webkit (there are about 6 others). This should not hurt performance at all if done correctly.
5. Remove matchesSelector support completely. I know this sounds scary, but as Dave noticed in his event testing, even the native matchesSelector is really slow. It may actually be faster, especially in the most common use cases, to do our own filtering all the time. This could also remove the need for quickIs in event.js.
6. Combine dirNodeCheck and dirCheck into a single function.
7. Add a better fallback for Sizzle.contains.
8. There are a couple tests for Opera 9.6 and Safari 3.2, which we don't support anymore, for getElementsByClassName. We could remove that cruft.
9. Look into simplifying Sizzle's makeArray to not use Array slice at all. When building minimaljs, I noticed that a simple array builder is actually faster than using slice, so it does not seem worth it.
10. Check how many bytes it would save to build the chunker and all other regexes using strings to reduce duplication.
11. Follow spec for acceptable character ranges. Currently, we use "\\u00c0-\\uFFFF\\", which may not be correct. third party pull https://github.com/jquery/sizzle/pull/61
Attachments (0)
Change History (15)
Changed November 07, 2011 02:14AM UTC by comment:1
| component: | unfiled → selector |
|---|---|
| milestone: | None → 1.8 |
| owner: | → timmywil |
| priority: | undecided → blocker |
| status: | new → assigned |
Changed November 07, 2011 01:10PM UTC by comment:2
| keywords: | → 1.8-discuss |
|---|
+1 !!!!!!
Changed November 07, 2011 02:12PM UTC by comment:3
| description: | This ticket is for tracking enhancements and reductions for Sizzle. Some of these may belong in separate tickets, but I need to compile the list somewhere. I plan on doing/researching all of this in 1.8. \ \ These are my ideas so far: \ 1. Reorganize the main Sizzle function to be one function that contains shortcuts for id, tag, class, and document.body and an internal select function that uses qsa if available. Sizzle somewhat does this already, but not completely. I think it would reduce the size of Sizzle itself. We also do some of this in jQuery.fn.init and duplicate some of what is already in a qsa Sizzle. This could remove the need for that duplication and shave even more bytes. \ 2. This may not be feasible, but I want to look into adding local vars for the most common things referenced from within Sizzle instead of using.long.property.accesses internally. \ 3. The implementation of prefilters seems a bit wet. I'd like to dry up some of that code and look into reducing the call stack on that codepath. \ 4. Add a support-test regex builder for places in which we know QSA will fail, such as with :checked on select elements in webkit (there are about 6 others). This should not hurt performance at all if done correctly. \ 5. Remove matchesSelector support completely. I know this sounds scary, but as Dave noticed in his event testing, even the native matchesSelector is really slow. It may actually be faster, especially in the most common use cases, to do our own filtering all the time. This could also remove the need for quickIs in event.js. \ 6. Combine dirNodeCheck and dirCheck into a single function. \ 7. Add a better fallback for Sizzle.contains. \ 8. There are a couple tests for Opera 9.6 and Safari 3.2, which we don't support anymore, for getElementsByTagName. We could remove that cruft. \ 9. Look into simplifying Sizzle's makeArray to not use Array slice at all. When building minimaljs, I noticed that a simple array builder is actually faster than using slice, so it does not seem worth it. \ 10. Check how many bytes it would save to build the chunker and all other regexes using strings to reduce duplication. \ 11. Follow spec for acceptable character ranges. Currently, we use "\\u00c0-\\uFFFF\\", which may not be correct. third party pull https://github.com/jquery/sizzle/pull/61 \ 12. Double check the most up-to-date of w3c selectors and make sure we are not leaving any out that would be easy to support. \ → This ticket is for tracking enhancements and reductions for Sizzle. Some of these may belong in separate tickets, but I need to compile the list somewhere. I plan on doing/researching all of this in 1.8. \ \ These are my ideas so far: \ 1. Reorganize the main Sizzle function to be one function that contains shortcuts for id, tag, class, and document.body and an internal select function that uses qsa if available. Sizzle somewhat does this already, but not completely. I think it would reduce the size of Sizzle itself. We also do some of this in jQuery.fn.init and duplicate some of what is already in a qsa Sizzle. This could remove the need for that duplication and shave even more bytes. \ 2. This may not be feasible, but I want to look into adding local vars for the most common things referenced from within Sizzle instead of using.long.property.accesses internally. \ 3. The implementation of prefilters seems a bit wet. I'd like to dry up some of that code and look into reducing the call stack on that codepath. \ 4. Add a support-test regex builder for places in which we know QSA will fail, such as with :checked on select elements in webkit (there are about 6 others). This should not hurt performance at all if done correctly. \ 5. Remove matchesSelector support completely. I know this sounds scary, but as Dave noticed in his event testing, even the native matchesSelector is really slow. It may actually be faster, especially in the most common use cases, to do our own filtering all the time. This could also remove the need for quickIs in event.js. \ 6. Combine dirNodeCheck and dirCheck into a single function. \ 7. Add a better fallback for Sizzle.contains. \ 8. There are a couple tests for Opera 9.6 and Safari 3.2, which we don't support anymore, for getElementsByClassName. We could remove that cruft. \ 9. Look into simplifying Sizzle's makeArray to not use Array slice at all. When building minimaljs, I noticed that a simple array builder is actually faster than using slice, so it does not seem worth it. \ 10. Check how many bytes it would save to build the chunker and all other regexes using strings to reduce duplication. \ 11. Follow spec for acceptable character ranges. Currently, we use "\\u00c0-\\uFFFF\\", which may not be correct. third party pull https://github.com/jquery/sizzle/pull/61 \ 12. Double check the most up-to-date of w3c selectors and make sure we are not leaving any out that would be easy to support. \ |
|---|
Changed November 11, 2011 08:49AM UTC by comment:4
+1
Awesome, sounds great!
Changed November 21, 2011 05:07PM UTC by comment:5
| description: | This ticket is for tracking enhancements and reductions for Sizzle. Some of these may belong in separate tickets, but I need to compile the list somewhere. I plan on doing/researching all of this in 1.8. \ \ These are my ideas so far: \ 1. Reorganize the main Sizzle function to be one function that contains shortcuts for id, tag, class, and document.body and an internal select function that uses qsa if available. Sizzle somewhat does this already, but not completely. I think it would reduce the size of Sizzle itself. We also do some of this in jQuery.fn.init and duplicate some of what is already in a qsa Sizzle. This could remove the need for that duplication and shave even more bytes. \ 2. This may not be feasible, but I want to look into adding local vars for the most common things referenced from within Sizzle instead of using.long.property.accesses internally. \ 3. The implementation of prefilters seems a bit wet. I'd like to dry up some of that code and look into reducing the call stack on that codepath. \ 4. Add a support-test regex builder for places in which we know QSA will fail, such as with :checked on select elements in webkit (there are about 6 others). This should not hurt performance at all if done correctly. \ 5. Remove matchesSelector support completely. I know this sounds scary, but as Dave noticed in his event testing, even the native matchesSelector is really slow. It may actually be faster, especially in the most common use cases, to do our own filtering all the time. This could also remove the need for quickIs in event.js. \ 6. Combine dirNodeCheck and dirCheck into a single function. \ 7. Add a better fallback for Sizzle.contains. \ 8. There are a couple tests for Opera 9.6 and Safari 3.2, which we don't support anymore, for getElementsByClassName. We could remove that cruft. \ 9. Look into simplifying Sizzle's makeArray to not use Array slice at all. When building minimaljs, I noticed that a simple array builder is actually faster than using slice, so it does not seem worth it. \ 10. Check how many bytes it would save to build the chunker and all other regexes using strings to reduce duplication. \ 11. Follow spec for acceptable character ranges. Currently, we use "\\u00c0-\\uFFFF\\", which may not be correct. third party pull https://github.com/jquery/sizzle/pull/61 \ 12. Double check the most up-to-date of w3c selectors and make sure we are not leaving any out that would be easy to support. \ → This ticket is for tracking enhancements and reductions for Sizzle. Some of these may belong in separate tickets, but I need to compile the list somewhere. I plan on doing/researching all of this in 1.8. \ \ These are my ideas so far: \ 1. Reorganize the main Sizzle function to be one function that contains shortcuts for id, tag, class, and document.body and an internal select function that uses qsa if available. Sizzle somewhat does this already, but not completely. I think it would reduce the size of Sizzle itself. We also do some of this in jQuery.fn.init and duplicate some of what is already in a qsa Sizzle. This could remove the need for that duplication and shave even more bytes. \ 2. This may not be feasible, but I want to look into adding local vars for the most common things referenced from within Sizzle instead of using.long.property.accesses internally. \ 3. The implementation of prefilters seems a bit wet. I'd like to dry up some of that code and look into reducing the call stack on that codepath. \ 4. Add a support-test regex builder for places in which we know QSA will fail, such as with :checked on select elements in webkit (there are about 6 others). This should not hurt performance at all if done correctly. \ 5. Remove matchesSelector support completely. I know this sounds scary, but as Dave noticed in his event testing, even the native matchesSelector is really slow. It may actually be faster, especially in the most common use cases, to do our own filtering all the time. This could also remove the need for quickIs in event.js. \ 6. Combine dirNodeCheck and dirCheck into a single function. \ 7. Add a better fallback for Sizzle.contains. \ 8. There are a couple tests for Opera 9.6 and Safari 3.2, which we don't support anymore, for getElementsByClassName. We could remove that cruft. \ 9. Look into simplifying Sizzle's makeArray to not use Array slice at all. When building minimaljs, I noticed that a simple array builder is actually faster than using slice, so it does not seem worth it. \ 10. Check how many bytes it would save to build the chunker and all other regexes using strings to reduce duplication. \ 11. Follow spec for acceptable character ranges. Currently, we use "\\u00c0-\\uFFFF\\", which may not be correct. third party pull https://github.com/jquery/sizzle/pull/61 \ 12. Double check the most up-to-date of w3c selectors and make sure we are not leaving any out that would be easy to support. \ 13. Per Dave's suggestion, explore a parsed selection cache that would hold 50 (or however many) of the most recent selectors already parsed. This would remove the need for quickIs in event and make matchesSelector use in event delegation much faster. This supplements #5. \ |
|---|
Changed December 10, 2011 07:05PM UTC by comment:6
| blocking: | → 7010 |
|---|
Changed December 13, 2011 01:34PM UTC by comment:7
| description: | This ticket is for tracking enhancements and reductions for Sizzle. Some of these may belong in separate tickets, but I need to compile the list somewhere. I plan on doing/researching all of this in 1.8. \ \ These are my ideas so far: \ 1. Reorganize the main Sizzle function to be one function that contains shortcuts for id, tag, class, and document.body and an internal select function that uses qsa if available. Sizzle somewhat does this already, but not completely. I think it would reduce the size of Sizzle itself. We also do some of this in jQuery.fn.init and duplicate some of what is already in a qsa Sizzle. This could remove the need for that duplication and shave even more bytes. \ 2. This may not be feasible, but I want to look into adding local vars for the most common things referenced from within Sizzle instead of using.long.property.accesses internally. \ 3. The implementation of prefilters seems a bit wet. I'd like to dry up some of that code and look into reducing the call stack on that codepath. \ 4. Add a support-test regex builder for places in which we know QSA will fail, such as with :checked on select elements in webkit (there are about 6 others). This should not hurt performance at all if done correctly. \ 5. Remove matchesSelector support completely. I know this sounds scary, but as Dave noticed in his event testing, even the native matchesSelector is really slow. It may actually be faster, especially in the most common use cases, to do our own filtering all the time. This could also remove the need for quickIs in event.js. \ 6. Combine dirNodeCheck and dirCheck into a single function. \ 7. Add a better fallback for Sizzle.contains. \ 8. There are a couple tests for Opera 9.6 and Safari 3.2, which we don't support anymore, for getElementsByClassName. We could remove that cruft. \ 9. Look into simplifying Sizzle's makeArray to not use Array slice at all. When building minimaljs, I noticed that a simple array builder is actually faster than using slice, so it does not seem worth it. \ 10. Check how many bytes it would save to build the chunker and all other regexes using strings to reduce duplication. \ 11. Follow spec for acceptable character ranges. Currently, we use "\\u00c0-\\uFFFF\\", which may not be correct. third party pull https://github.com/jquery/sizzle/pull/61 \ 12. Double check the most up-to-date of w3c selectors and make sure we are not leaving any out that would be easy to support. \ 13. Per Dave's suggestion, explore a parsed selection cache that would hold 50 (or however many) of the most recent selectors already parsed. This would remove the need for quickIs in event and make matchesSelector use in event delegation much faster. This supplements #5. \ → This ticket is for tracking enhancements and reductions for Sizzle. Some of these may belong in separate tickets, but I need to compile the list somewhere. I plan on doing/researching all of this in 1.8.\ \ These are my ideas so far:\ 1. Reorganize the main Sizzle function to be one function that contains shortcuts for id, tag, class, and document.body and an internal select function that uses qsa if available. Sizzle somewhat does this already, but not completely. I think it would reduce the size of Sizzle itself. We also do some of this in jQuery.fn.init and duplicate some of what is already in a qsa Sizzle. This could remove the need for that duplication and shave even more bytes.\ 2. This may not be feasible, but I want to look into adding local vars for the most common things referenced from within Sizzle instead of using.long.property.accesses internally.\ 3. The implementation of prefilters seems a bit wet. I'd like to dry up some of that code and look into reducing the call stack on that codepath.\ 4. Add a support-test regex builder for places in which we know QSA will fail, such as with :checked on select elements in webkit (there are about 6 others). This should not hurt performance at all if done correctly.\ 5. Remove matchesSelector support completely. I know this sounds scary, but as Dave noticed in his event testing, even the native matchesSelector is really slow. It may actually be faster, especially in the most common use cases, to do our own filtering all the time. This could also remove the need for quickIs in event.js.\ 6. Combine dirNodeCheck and dirCheck into a single function.\ 7. Add a better fallback for Sizzle.contains.\ 8. There are a couple tests for Opera 9.6 and Safari 3.2, which we don't support anymore, for getElementsByClassName. We could remove that cruft.\ 9. Look into simplifying Sizzle's makeArray to not use Array slice at all. When building minimaljs, I noticed that a simple array builder is actually faster than using slice, so it does not seem worth it.\ 10. Check how many bytes it would save to build the chunker and all other regexes using strings to reduce duplication.\ 11. Follow spec for acceptable character ranges. Currently, we use "\\u00c0-\\uFFFF\\", which may not be correct. third party pull https://github.com/jquery/sizzle/pull/61\ 12. Double check the most up-to-date of w3c selectors and make sure we are not leaving any out that would be easy to support.\ 13. Per Dave's suggestion, explore a parsed selection cache that would hold 50 (or however many) of the most recent selectors already parsed. This would remove the need for quickIs in event and make matchesSelector use in event delegation much faster. This supplements #5.\ |
|---|
+1, When people think jQuery, they think fast and simple selection. Sounds like this needs to be done.
Changed December 13, 2011 02:47PM UTC by comment:8
+1
Changed December 13, 2011 04:21PM UTC by comment:9
+1
Changed December 13, 2011 06:05PM UTC by comment:10
| description: | This ticket is for tracking enhancements and reductions for Sizzle. Some of these may belong in separate tickets, but I need to compile the list somewhere. I plan on doing/researching all of this in 1.8.\ \ These are my ideas so far:\ 1. Reorganize the main Sizzle function to be one function that contains shortcuts for id, tag, class, and document.body and an internal select function that uses qsa if available. Sizzle somewhat does this already, but not completely. I think it would reduce the size of Sizzle itself. We also do some of this in jQuery.fn.init and duplicate some of what is already in a qsa Sizzle. This could remove the need for that duplication and shave even more bytes.\ 2. This may not be feasible, but I want to look into adding local vars for the most common things referenced from within Sizzle instead of using.long.property.accesses internally.\ 3. The implementation of prefilters seems a bit wet. I'd like to dry up some of that code and look into reducing the call stack on that codepath.\ 4. Add a support-test regex builder for places in which we know QSA will fail, such as with :checked on select elements in webkit (there are about 6 others). This should not hurt performance at all if done correctly.\ 5. Remove matchesSelector support completely. I know this sounds scary, but as Dave noticed in his event testing, even the native matchesSelector is really slow. It may actually be faster, especially in the most common use cases, to do our own filtering all the time. This could also remove the need for quickIs in event.js.\ 6. Combine dirNodeCheck and dirCheck into a single function.\ 7. Add a better fallback for Sizzle.contains.\ 8. There are a couple tests for Opera 9.6 and Safari 3.2, which we don't support anymore, for getElementsByClassName. We could remove that cruft.\ 9. Look into simplifying Sizzle's makeArray to not use Array slice at all. When building minimaljs, I noticed that a simple array builder is actually faster than using slice, so it does not seem worth it.\ 10. Check how many bytes it would save to build the chunker and all other regexes using strings to reduce duplication.\ 11. Follow spec for acceptable character ranges. Currently, we use "\\u00c0-\\uFFFF\\", which may not be correct. third party pull https://github.com/jquery/sizzle/pull/61\ 12. Double check the most up-to-date of w3c selectors and make sure we are not leaving any out that would be easy to support.\ 13. Per Dave's suggestion, explore a parsed selection cache that would hold 50 (or however many) of the most recent selectors already parsed. This would remove the need for quickIs in event and make matchesSelector use in event delegation much faster. This supplements #5.\ → This ticket is for tracking enhancements and reductions for Sizzle. Some of these may belong in separate tickets, but I need to compile the list somewhere. I plan on doing/researching all of this in 1.8. \ \ These are my ideas so far: \ 1. Reorganize the main Sizzle function to be one function that contains shortcuts for id, tag, class, and document.body and an internal select function that uses qsa if available. Sizzle somewhat does this already, but not completely. I think it would reduce the size of Sizzle itself. We also do some of this in jQuery.fn.init and duplicate some of what is already in a qsa Sizzle. This could remove the need for that duplication and shave even more bytes. \ 2. This may not be feasible, but I want to look into adding local vars for the most common things referenced from within Sizzle instead of using.long.property.accesses internally. \ 3. The implementation of prefilters seems a bit wet. I'd like to dry up some of that code and look into reducing the call stack on that codepath. \ 4. Add a support-test regex builder for places in which we know QSA will fail, such as with :checked on select elements in webkit (there are about 6 others). This should not hurt performance at all if done correctly. \ 5. Remove matchesSelector support completely. I know this sounds scary, but as Dave noticed in his event testing, even the native matchesSelector is really slow. It may actually be faster, especially in the most common use cases, to do our own filtering all the time. This could also remove the need for quickIs in event.js. \ 6. Combine dirNodeCheck and dirCheck into a single function. \ 7. Add a better fallback for Sizzle.contains. \ 8. There are a couple tests for Opera 9.6 and Safari 3.2, which we don't support anymore, for getElementsByClassName. We could remove that cruft. \ 9. Look into simplifying Sizzle's makeArray to not use Array slice at all. When building minimaljs, I noticed that a simple array builder is actually faster than using slice, so it does not seem worth it. \ 10. Check how many bytes it would save to build the chunker and all other regexes using strings to reduce duplication. \ 11. Follow spec for acceptable character ranges. Currently, we use "\\u00c0-\\uFFFF\\", which may not be correct. third party pull https://github.com/jquery/sizzle/pull/61 \ 12. Double check the most up-to-date of w3c selectors and make sure we are not leaving any out that would be easy to support. \ 13. Per Dave's suggestion, explore a parsed selection cache that would hold 50 (or however many) of the most recent selectors already parsed. This would remove the need for quickIs in event and make matchesSelector use in event delegation much faster. This supplements #5. \ |
|---|
+1, In the 1.8 theme, it would also be nice if item 1 could be isolated as a "tiny Sizzle" -- let's call it "Small Fry"?
Changed December 15, 2011 11:41PM UTC by comment:11
+1
Changed December 19, 2011 05:34PM UTC by comment:12
+1
Changed January 11, 2012 04:49PM UTC by comment:13
#11109 is a duplicate of this ticket.
Changed May 28, 2012 04:45PM UTC by comment:14
| description: | This ticket is for tracking enhancements and reductions for Sizzle. Some of these may belong in separate tickets, but I need to compile the list somewhere. I plan on doing/researching all of this in 1.8. \ \ These are my ideas so far: \ 1. Reorganize the main Sizzle function to be one function that contains shortcuts for id, tag, class, and document.body and an internal select function that uses qsa if available. Sizzle somewhat does this already, but not completely. I think it would reduce the size of Sizzle itself. We also do some of this in jQuery.fn.init and duplicate some of what is already in a qsa Sizzle. This could remove the need for that duplication and shave even more bytes. \ 2. This may not be feasible, but I want to look into adding local vars for the most common things referenced from within Sizzle instead of using.long.property.accesses internally. \ 3. The implementation of prefilters seems a bit wet. I'd like to dry up some of that code and look into reducing the call stack on that codepath. \ 4. Add a support-test regex builder for places in which we know QSA will fail, such as with :checked on select elements in webkit (there are about 6 others). This should not hurt performance at all if done correctly. \ 5. Remove matchesSelector support completely. I know this sounds scary, but as Dave noticed in his event testing, even the native matchesSelector is really slow. It may actually be faster, especially in the most common use cases, to do our own filtering all the time. This could also remove the need for quickIs in event.js. \ 6. Combine dirNodeCheck and dirCheck into a single function. \ 7. Add a better fallback for Sizzle.contains. \ 8. There are a couple tests for Opera 9.6 and Safari 3.2, which we don't support anymore, for getElementsByClassName. We could remove that cruft. \ 9. Look into simplifying Sizzle's makeArray to not use Array slice at all. When building minimaljs, I noticed that a simple array builder is actually faster than using slice, so it does not seem worth it. \ 10. Check how many bytes it would save to build the chunker and all other regexes using strings to reduce duplication. \ 11. Follow spec for acceptable character ranges. Currently, we use "\\u00c0-\\uFFFF\\", which may not be correct. third party pull https://github.com/jquery/sizzle/pull/61 \ 12. Double check the most up-to-date of w3c selectors and make sure we are not leaving any out that would be easy to support. \ 13. Per Dave's suggestion, explore a parsed selection cache that would hold 50 (or however many) of the most recent selectors already parsed. This would remove the need for quickIs in event and make matchesSelector use in event delegation much faster. This supplements #5. \ → This ticket is for tracking enhancements and reductions for Sizzle. Some of these may belong in separate tickets, but I need to compile the list somewhere. I plan on doing/researching all of this in 1.8. \ \ These are my ideas so far: \ 1. Reorganize the main Sizzle function to be one function that contains shortcuts for id, tag, class, and document.body and an internal select function that uses qsa if available. Sizzle somewhat does this already, but not completely. I think it would reduce the size of Sizzle itself. We also do some of this in jQuery.fn.init and duplicate some of what is already in a qsa Sizzle. This could remove the need for that duplication and shave even more bytes. \ 2. This may not be feasible, but I want to look into adding local vars for the most common things referenced from within Sizzle instead of using.long.property.accesses internally. \ 3. The implementation of prefilters seems a bit wet. I'd like to dry up some of that code and look into reducing the call stack on that codepath. \ 4. Add a support-test regex builder for places in which we know QSA will fail, such as with :checked on select elements in webkit (there are about 6 others). This should not hurt performance at all if done correctly. \ 5. Remove matchesSelector support completely. I know this sounds scary, but as Dave noticed in his event testing, even the native matchesSelector is really slow. It may actually be faster, especially in the most common use cases, to do our own filtering all the time. This could also remove the need for quickIs in event.js. \ 6. Combine dirNodeCheck and dirCheck into a single function. \ 7. Add a better fallback for Sizzle.contains. \ 8. There are a couple tests for Opera 9.6 and Safari 3.2, which we don't support anymore, for getElementsByClassName. We could remove that cruft. \ 9. Look into simplifying Sizzle's makeArray to not use Array slice at all. When building minimaljs, I noticed that a simple array builder is actually faster than using slice, so it does not seem worth it. \ 10. Check how many bytes it would save to build the chunker and all other regexes using strings to reduce duplication. \ 11. Follow spec for acceptable character ranges. Currently, we use "\\u00c0-\\uFFFF\\", which may not be correct. third party pull https://github.com/jquery/sizzle/pull/61 \ \ |
|---|
Moving 12 and 13 to their own tickets.
Changed May 28, 2012 04:54PM UTC by comment:15
| blocking: | 7010 |
|---|---|
| keywords: | 1.8-discuss |
| resolution: | → fixed |
| status: | assigned → closed |