Sencha Touch--Support 2 browsers in just 228K!
in [JavaScript]
|
Prev: FAQ Topic - What is JScript? (2010-07-16)
Next: How to find if statusbar is hidden or visible in firefox?
From: kangax on 18 Jul 2010 19:18 On 7/18/10 1:32 PM, David Mark wrote: > On Jul 18, 9:10 am, kangax<kan...(a)gmail.com> wrote: >> On 7/18/10 2:18 AM, Garrett Smith wrote: >> >>> On 2010-07-17 06:25 PM, David Mark wrote: >> [...] >> >>>> /** >>>> * Forces the browser to repaint this element >> >>> The name "repaint" has the outward indication of a mystical incantation. >>> We know that there is no way to force a repaint, and so when I see a >>> name like that, I know that the method won't directly cause the browser >>> to repaint and that it will, at best, perform an unrelated action that >>> was associated with addressing a perceived problem. >> >> I'm not sure where you coming from with this. >> >> There certainly are observable ways to trigger both � reflow and >> repaint; at least in WebKit (as that's the layout engine being discussed >> here). [...] >> Or am I missing something? >> > > Yes; the code in question seems to assert that it can make the browser > reflow/repaint at a specific point in the execution. And it doesn't > change the style rules, but does the styling equivalent of a no-op. I see what you mean. And yes, I see they're adding a class, then removing it in about 1 ms. I wonder what's the point of setting _both_ class and background; wouldn't class (with proper declarations) suffice? I also wonder about the need for a function like this in the first place. Reflows/repaints are usually being avoided as much as possible; What could be the use for such function? Perhaps some layout/positioning bug on mobile WebKit? -- kangax
From: David Mark on 18 Jul 2010 20:18 On Jul 18, 7:18 pm, kangax <kan...(a)gmail.com> wrote: > On 7/18/10 1:32 PM, David Mark wrote: > > > > > > > On Jul 18, 9:10 am, kangax<kan...(a)gmail.com> wrote: > >> On 7/18/10 2:18 AM, Garrett Smith wrote: > > >>> On 2010-07-17 06:25 PM, David Mark wrote: > >> [...] > > >>>> /** > >>>> * Forces the browser to repaint this element > > >>> The name "repaint" has the outward indication of a mystical incantation. > >>> We know that there is no way to force a repaint, and so when I see a > >>> name like that, I know that the method won't directly cause the browser > >>> to repaint and that it will, at best, perform an unrelated action that > >>> was associated with addressing a perceived problem. > > >> I'm not sure where you coming from with this. > > >> There certainly are observable ways to trigger both reflow and > >> repaint; at least in WebKit (as that's the layout engine being discussed > >> here). > [...] > >> Or am I missing something? > > > Yes; the code in question seems to assert that it can make the browser > > reflow/repaint at a specific point in the execution. And it doesn't > > change the style rules, but does the styling equivalent of a no-op. > > I see what you mean. And yes, I see they're adding a class, then > removing it in about 1 ms. I wonder what's the point of setting _both_ > class and background; wouldn't class (with proper declarations) suffice? There's an easy explanation. They added code until it seemed to "work". It's a classic mystical incantation. > > I also wonder about the need for a function like this in the first > place. There's good reason to wonder. Clearly they were having some sort of problem and rather than trying to determine the root of it, resorted to a magic spell (which may or may not hold up in future WebKit versions). > Reflows/repaints are usually being avoided as much as possible; Absolutely. It's critical for performance in many areas (e.g. animations, widgets). And if you don't understand how/when they happen, you will end up with twitches (i.e. early flashes of content). > What could be the use for such function? Perhaps some layout/positioning > bug on mobile WebKit? > Something they ran into in their zeal to make a monolithic do- everything library. Clearly they couldn't design around it as they needed to solve every problem for every context. Some things never change.
From: Garrett Smith on 18 Jul 2010 22:15 On 2010-07-18 02:42 PM, David Mark wrote: > On Jul 18, 5:18 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > > [...] > >> >> ext-touch-debug.js..............458k > > Not sure what sort of "debugging" they had in mind. All it does is > hide mistakes, rather than throwing exceptions for unexpected usage > patterns. > > But that measurement includes white space and penalizes long variable > names. That's why I prefer the equalizer of a minification when > making comparisons. jQuery (which does virtually nothing but queries) > is 70K+; Sencha (which supports only two WebKit variations) is 225K+ > and the full build of My Library (which does more than the two > *combined* and works in virtually every browser known to man) is 140K > +. And unlike the other two, mine is not hopelessly tangled up in > interdependencies, which makes it easy to create much smaller custom > builds. > > The marketers take the opposite tack of touting the sizes after > compression, which just confuses the uninitiated. For example, the > iPhone's cache limit is not based on the compressed size. For > another, if your HTML is 50K and CSS 30K, will the addition of the > "80K" Sencha Touch increase the payload by a factor of two or four? > Of course, the answer is four; but if you are going by the advertised > size, you would have to manually GZIP the HTML and CSS to find this > out. The marketers know that many developers will simply assume that > 80K of HTML/CSS is equivalent to "80K" of Sencha. > > [...] > >> >> I suspect it may be a holdover from previous jQuery-inspired efforts. >> Remember that older versions of jQuery supported XPath. >> > > How old? I only remember seeing XPath in Prototype. And AFAIK, they > are still trying to "support" it (despite the fact that it varies > wildly from their other forks). jQuery 1.1.4 had XPath support. Other libraries seem to have been inspired by that and the detritus from those libraries seems to remain in Ext even in Sencha. Ext provides additional syntax extensions to match style values (CSS Value Selectors. The documentation for Sencha states that those are supported, but they're not. Ext-JS's (full/big version) more recent design borrows from the jQuery NFD approach. The timeline is clear that jQuery did that first and the Ext copied it. Regardless, NFD is a design mistake, no matter how popular it becomes and no matter many libraries copy it. The reason I mention this is it seems that Ext-JS has been following what jQuery does, copying the mistakes and adding its own mistakes to that. Ext-JS actually makes jQUery look good. The Sencha documentation I mentioned earlier: <http://www.sencha.com/deploy/dev/docs/?class=Ext.DomQuery> The documnetation is quoted in full below. The reason I have done this is that the documentation may change and when it does, the comments I've made about it will not apply. By posting that inline, the comments will be relevant to what is posted here, even if the document at that URI changes. The documentation does not reflect what the code does. | Provides high performance selector/xpath processing by compiling | queries into reusable functions. New pseudo classes and matchers can | be plugged. It works on HTML and XML documents (if a content node is | passed in). | | DomQuery supports most of the CSS3 selectors spec, along with some | custom selectors and basic XPath. | | All selectors, attribute filters and pseudos below can be combined | infinitely in any order. For example "div.foo:nth-child(odd) | [@foo=bar].bar:first" would be a perfectly valid selector. Node | filters are processed in the order in which they appear, | which allows you to optimize your queries for your document structure. | Element Selectors: | That is an example claimed of XPath support. An error will be thrown if this is followed. Sencha does not support XPath selectors, except those that also match exactly the production for CSS Selectors, as [foo=bar], which is valid XPath and also a valid CSS Selector. | * * any element That operator is supported in Sencha, though not properly supported in Ext-JS, depending on the browser, its version, document mode, etc. The fundamental problem with the NFD approach that they borrowed from jQuery. | * E an element with the tag E | * E F All descendent elements of E that have the tag F | * E > F or E/F all direct children elements of E that have the tag F | * E + F all elements with the tag F that are immediately preceded by | an element with the tag E | * E ~ F all elements with the tag F that are preceded by a sibling | element with the tag E | | Attribute Selectors: | | The use of @ and quotes are optional. For example, div[@foo='bar'] is | also a valid attribute selector. | No, that's not how CSS Selectors work and an error will be thrown if this is followed. | * E[foo] has an attribute "foo" | * E[foo=bar] has an attribute "foo" that equals "bar" | * E[foo^=bar] has an attribute "foo" that starts with "bar" | * E[foo$=bar] has an attribute "foo" that ends with "bar" | * E[foo*=bar] has an attribute "foo" that contains the substring "bar" | * E[foo%=2] has an attribute "foo" that is evenly divisible by 2 | * E[foo!=bar] has an attribute "foo" that does not equal "bar" | | Pseudo Classes: | | * E:first-child E is the first child of its parent | * E:last-child E is the last child of its parent | * E:nth-child(n) E is the nth child of its parent (1 based as per the | spec) | * E:nth-child(odd) E is an odd child of its parent | * E:nth-child(even) E is an even child of its parent | * E:only-child E is the only child of its parent | * E:checked E is an element that is has a checked attribute that is | true | (e.g. a radio or checkbox) | * E:first the first E in the resultset | * E:last the last E in the resultset | * E:nth(n) the nth E in the resultset (1 based) | * E:odd shortcut for :nth-child(odd) | * E:even shortcut for :nth-child(even) | * E:contains(foo) E's innerHTML contains the substring "foo" | * E:nodeValue(foo) E contains a textNode with a nodeValue that equals | "foo" The syntax extensions there, including :nodeValue, will throw an error. | * E:not(S) an E element that does not match simple selector S | * E:has(S) an E element that has a descendent that matches simple | selector S | * E:next(S) an E element whose next sibling matches simple selector S | * E:prev(S) an E element whose previous sibling matches simple | selector S | * E:any(S1|S2|S2) an E element which matches any of the simple | selectors | S1, S2 or S3//\\ | | CSS Value Selectors: | These will all throw errors in Sencha and they do not work in Ext, either, as you've reviewed the section of code the reads styles, and that returns different results, when trying to read: {visibility=visible} - the result returned depends on the browser and how styles are calculated. For example, if the default value for visibility is used, the element's visibility is calcualted as "inherit" (which is correct) and in that case, the result won't include that element. Except where it does, and that depends on the browser. But that is about Ext-JS (big version), not Sencha. In Sencha, all of this stuff throws errors. (I've got a some errands to do, so I'm going to post the rest of this here wihout editing) | * E{display=none} css value "display" that equals "none" | * E{display^=none} css value "display" that starts with "none" | * E{display$=none} css value "display" that ends with "none" | * E{display*=none} css value "display" that contains the substring | "none" | * E{display%=2} css value "display" that is evenly divisible by 2 | * E{display!=none} css value "display" that does not equal "none" | | | | This class is a singleton and cannot be created directly. | Public Properties | Property Defined By | matchers : Object | Collection of matching regular expressions and code snippets. Each | capture group within () will be replace the {} in ... | Collection of matching regular expressions and code snippets. Each | capture group within () will be replace the {} in the select statement | as specified by their index. | DomQuery | pseudos : Object | Object hash of "pseudo class" filter functions which are used when | filtering selections. Each function is passed two ... | | Object hash of "pseudo class" filter functions which are used when | filtering selections. Each function is passed two parameters: | | * c : Array | An Array of DOM elements to filter. | * v : String | The argument (if any) supplied in the selector. | | A filter function returns an Array of DOM elements which conform to | the pseudo class. | | In addition to the provided pseudo classes listed above such as | first-child and nth-child, developers may add additional, custom psuedo | class filters to select elements according to application-specific | requirements. | | For example, to filter <a> elements to only return links to external | resources: | | Ext.DomQuery.pseudos.external = function(c, v){ | var r = [], ri = -1; | for(var i = 0, ci; ci = c[i]; i++){ | // Include in result set only if it's a link to an external resource | if(ci.hostname != location.hostname){ | r[++ri] = ci; | } | } | return r; | }; | | Then external links could be gathered with the following statement: | | var externalLinks = Ext.select("a:external"); | | DomQuery | Public Methods | Method Defined By | compile( String selector, [String type] ) : Function | Compiles a selector/xpath query into a reusable function. The returned | function takes one parameter "root" (optional)... | Compiles a selector/xpath query into a reusable function. The returned | function takes one parameter "root" (optional), which is the context | node from where the query should start. | Parameters: | | * selector : String | The selector/xpath query | * type : String | (optional) Either "select" (the default) or "simple" for a simple | selector match | | Returns: | | * Function | | DomQuery | filter( Array el, String selector, Boolean nonMatches ) : Array | Filters an array of elements to only include matches of a simple | selector (e.g. div.some-class or span:first-child) | Filters an array of elements to only include matches of a simple | selector (e.g. div.some-class or span:first-child) | Parameters: | | * el : Array | An array of elements to filter | * selector : String | The simple selector to test | * nonMatches : Boolean | If true, it returns the elements that DON'T match the selector instead | of the ones that match | | Returns: | | * Array | An Array of DOM elements which match the selector. If there are no | matches, and empty Array is returned. | | DomQuery | is( String/HTMLElement/Array el, String selector ) : Boolean | Returns true if the passed element(s) match the passed simple selector | (e.g. div.some-class or span:first-child) | Returns true if the passed element(s) match the passed simple selector | (e.g. div.some-class or span:first-child) | Parameters: | | * el : String/HTMLElement/Array | An element id, element or array of elements | * selector : String | The simple selector to test | | Returns: | | * Boolean | | DomQuery | jsSelect( String selector, [Node/String root] ) : Array | Selects a group of elements. | Selects a group of elements. | Parameters: | | * selector : String | The selector/xpath query (can be a comma separated list of selectors) | * root : Node/String | (optional) The start of the query (defaults to document). | | Returns: | | * Array | An Array of DOM elements which match the selector. If there are no | matches, and empty Array is returned. | | DomQuery | operators() : void | Collection of operator comparison functions. The default operators are | =, !=, ^=, $=, *=, %=, |= and ~=. New operator... | Collection of operator comparison functions. The default operators are | =, !=, ^=, $=, *=, %=, |= and ~=. New operators can be added as long | as the match the format c= where c is any character other than space, | > <. | Parameters: | | * None. | | Returns: | | * void | At least half of these operators are syntax extensions. | DomQuery | selectNode( String selector, [Node root] ) : Element | Selects a single element. | Selects a single element. | Parameters: | | * selector : String | The selector/xpath query | * root : Node | (optional) The start of the query (defaults to document). | | Returns: | | * Element | The DOM element which matched the selector. | | DomQuery | selectNumber( String selector, [Node root], Number defaultValue ) : | Number | Selects the value of a node, parsing integers and floats. Returns the | defaultValue, or 0 if none is specified. | Selects the value of a node, parsing integers and floats. Returns the | defaultValue, or 0 if none is specified. | Parameters: | | * selector : String | The selector/xpath query | * root : Node | (optional) The start of the query (defaults to document). | * defaultValue : Number | | Returns: | | * Number | | DomQuery | selectValue( String selector, [Node root], String defaultValue ) : | String | Selects the value of a node, optionally replacing null with the | defaultValue. | Selects the value of a node, optionally replacing null with the | defaultValue. | Parameters: | | * selector : String | The selector/xpath query | * root : Node | (optional) The start of the query (defaults to document). | * defaultValue : String | | Returns: String | | DomQuery The `selectValue` and `selectNumber` methods are missing altogether from Sencha. typeof Ext.DomQuery.selectValue "undefined" -- Garrett
From: David Mark on 18 Jul 2010 23:26 On Jul 18, 10:15 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > On 2010-07-18 02:42 PM, David Mark wrote: > > > On Jul 18, 5:18 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > > > [...] > > >> ext-touch-debug.js..............458k > > > Not sure what sort of "debugging" they had in mind. All it does is > > hide mistakes, rather than throwing exceptions for unexpected usage > > patterns. > > > But that measurement includes white space and penalizes long variable > > names. That's why I prefer the equalizer of a minification when > > making comparisons. jQuery (which does virtually nothing but queries) > > is 70K+; Sencha (which supports only two WebKit variations) is 225K+ > > and the full build of My Library (which does more than the two > > *combined* and works in virtually every browser known to man) is 140K > > +. And unlike the other two, mine is not hopelessly tangled up in > > interdependencies, which makes it easy to create much smaller custom > > builds. > > > The marketers take the opposite tack of touting the sizes after > > compression, which just confuses the uninitiated. For example, the > > iPhone's cache limit is not based on the compressed size. For > > another, if your HTML is 50K and CSS 30K, will the addition of the > > "80K" Sencha Touch increase the payload by a factor of two or four? > > Of course, the answer is four; but if you are going by the advertised > > size, you would have to manually GZIP the HTML and CSS to find this > > out. The marketers know that many developers will simply assume that > > 80K of HTML/CSS is equivalent to "80K" of Sencha. > > > [...] > > >> I suspect it may be a holdover from previous jQuery-inspired efforts. > >> Remember that older versions of jQuery supported XPath. > > > How old? I only remember seeing XPath in Prototype. And AFAIK, they > > are still trying to "support" it (despite the fact that it varies > > wildly from their other forks). > > jQuery 1.1.4 had XPath support. Other libraries seem to have been > inspired by that and the detritus from those libraries seems to remain > in Ext even in Sencha. Yes, Ext has it. And, like Prototype, there's not a chance in hell it matches their other forks. For example, they are all afflicted by the same misconceptions about attributes. It you look at documents as database tables, elements as rows and attributes as fields, the monumental futility of CSS selector query engines (as implemented in all of the "major" libraries) is clear. Who would use such a database? The only defense I've heard from those who lean on these things is that they don't care because they somehow manage to avoid the problems (which vary wildly from one browser to the next) at least in the browsers they "care" about. Of course that would require an inhuman amount of memorization to make work and there would always be the chance that the ever-shifting libraries could invalidate their map at any time. And then there are the browsers they've never heard of (most notably the ones that have yet to be published). > > Ext provides additional syntax extensions to match style values (CSS > Value Selectors. The documentation for Sencha states that those are > supported, but they're not. Of course not. We've seen how Ext/Sencha deal with styles. They are just as clumsy with those as they are with attributes. Thus large portions of their documentation are pure fantasy. > > Ext-JS's (full/big version) more recent design borrows from the jQuery > NFD approach. The timeline is clear that jQuery did that first and the > Ext copied it. Yes, Sizzle was a fraud perpetrated on jQuery users, dressed up as a performance increase. Here's John Resig lamenting what should have been the end of his old query code:- http://ejohn.org/blog/thoughts-on-queryselectorall/#postcomment ....then he went ahead and piled QSA on top of it. His fellow "luminaries" predictably followed suit. And speaking of the other efforts; you mentioned that ExtJS was the worst of the worst with respect to queries. But I don't know how you could get much more inept than Dojo's, which relies on their "attr" function, which has always been complete gibberish. It's only a couple of dozen lines of code and I once tried to explain its illogic to them, but they just kept chirping: "show me where it fails". I was reluctant to do that as it would predictably lead to patches without understanding (or fixing) the general problem. But even after producing a couple of failure cases, they were still hesitant to change anything, lest they break compatibility. Of course, "compatibility" that produces one result in IE8 standards mode and another in its compatibility view is not something to preserve. Furthermore, their "vaunted" widgets and parser rely heavily on this function, so the mistakes manifest themselves in virtually everything they do. Their forums, mailing lists, etc. are full of confused questions (and even more confused answers) related to these issues. > Regardless, NFD is a design mistake, no matter how > popular it becomes and no matter many libraries copy it. Of course it is. A child could see that. > The reason I > mention this is it seems that Ext-JS has been following what jQuery > does, copying the mistakes and adding its own mistakes to that. It appears that way. And they have the gall to charge people to use recycled garbage. > > Ext-JS actually makes jQUery look good. It's apples and oranges, but if you just compare the Ext core to jQuery, then I'd have to agree. Pity. And people wonder why I don't like *any* of these things. > > The Sencha documentation I mentioned earlier: > <http://www.sencha.com/deploy/dev/docs/?class=Ext.DomQuery> > > The documnetation is quoted in full below. The reason I have done this > is that the documentation may change and when it does, the comments I've > made about it will not apply. By posting that inline, the comments will > be relevant to what is posted here, even if the document at that URI > changes. > > The documentation does not reflect what the code does. > > | Provides high performance selector/xpath processing by compiling > | queries into reusable functions. New pseudo classes and matchers can > | be plugged. It works on HTML and XML documents (if a content node is > | passed in). That sounds like an optimistic appraisal of ExtJS, but Sencha Touch does nothing of the sort. It "compiles" nothing and certainly won't work with XML documents. > | > | DomQuery supports most of the CSS3 selectors spec, along with some > | custom selectors and basic XPath. > | > | All selectors, attribute filters and pseudos below can be combined > | infinitely in any order. Infinitely. :) Of course, even one selector may get the wrong result, depending on browser, rendering mode, phase of the moon, etc. Why do developers insist on buying in to this stuff? The whole idea was doomed from the start, has failed miserably and yet is more popular than ever. The popularity is often used as an excuse to use queries, while the myriad technical issues are brushed off as irrelevant. Go figure. > For example "div.foo:nth-child(odd) > | [@foo=bar].bar:first" would be a perfectly valid selector. Node > | filters are processed in the order in which they appear, > | which allows you to optimize your queries for your document structure. > | Element Selectors: > | > > That is an example claimed of XPath support. An error will be thrown if > this is followed. > > Sencha does not support XPath selectors, except those that also match > exactly the production for CSS Selectors, as [foo=bar], which is valid > XPath and also a valid CSS Selector. Yes, occasionally works by coincidence. > > | * * any element > > That operator is supported in Sencha, though not properly supported in > Ext-JS, depending on the browser, its version, document mode, etc. The > fundamental problem with the NFD approach that they borrowed from jQuery. Yes, the native implementations are incompatible with the scripted query engines, which are often incompatible with themselves (e.g. changing from one version of jQuery to the next). > > | * E an element with the tag E > | * E F All descendent elements of E that have the tag F > | * E > F or E/F all direct children elements of E that have the tag F > | * E + F all elements with the tag F that are immediately preceded by > | an element with the tag E > | * E ~ F all elements with the tag F that are preceded by a sibling > | element with the tag E > | > | Attribute Selectors: > | > | The use of @ and quotes are optional. For example, div[@foo='bar'] is > | also a valid attribute selector. > | > > No, that's not how CSS Selectors work and an error will be thrown if > this is followed. When it comes to attributes, they've got so many problems that developers should just forget about using such queries. Of course, many jQuery tutorials demonstrate querying by attribute values. > > | * E[foo] has an attribute "foo" > | * E[foo=bar] has an attribute "foo" that equals "bar" > | * E[foo^=bar] has an attribute "foo" that starts with "bar" > | * E[foo$=bar] has an attribute "foo" that ends with "bar" > | * E[foo*=bar] has an attribute "foo" that contains the substring "bar" > | * E[foo%=2] has an attribute "foo" that is evenly divisible by 2 > | * E[foo!=bar] has an attribute "foo" that does not equal "bar" > | > | Pseudo Classes: > | > | * E:first-child E is the first child of its parent > | * E:last-child E is the last child of its parent > | * E:nth-child(n) E is the nth child of its parent (1 based as per the > | spec) > | * E:nth-child(odd) E is an odd child of its parent > | * E:nth-child(even) E is an even child of its parent > | * E:only-child E is the only child of its parent > | * E:checked E is an element that is has a checked attribute that is > | true > | (e.g. a radio or checkbox) That's not right. For one, a checked attribute cannot be "true" (except in an invalid document) and the :checked pseudo queries the *property* so as to take user input into account. Fortunately, I think that's what they all do anyway; but unfortunately, they do the same thing when querying the CHECKED attribute. In my experience, most of the participants in these projects don't know the difference. > | * E:first the first E in the resultset > | * E:last the last E in the resultset > | * E:nth(n) the nth E in the resultset (1 based) > | * E:odd shortcut for :nth-child(odd) > | * E:even shortcut for :nth-child(even) > | * E:contains(foo) E's innerHTML contains the substring "foo" > | * E:nodeValue(foo) E contains a textNode with a nodeValue that equals > | "foo" > > The syntax extensions there, including :nodeValue, will throw an error. Yes. The :contains pseudo was in at least one of the Selectors drafts, but was eventually dropped, so QSA implementations can't parse it. > > | * E:not(S) an E element that does not match simple selector S > | * E:has(S) an E element that has a descendent that matches simple > | selector S > | * E:next(S) an E element whose next sibling matches simple selector S > | * E:prev(S) an E element whose previous sibling matches simple > | selector S > | * E:any(S1|S2|S2) an E element which matches any of the simple > | selectors > | S1, S2 or S3//\\ > | > | CSS Value Selectors: > | > > These will all throw errors in Sencha and they do not work in Ext, > either, as you've reviewed the section of code the reads styles, and > that returns different results, when trying to read: > > {visibility=visible} > > - the result returned depends on the browser and how styles are calculated. Yes, using these things to query by style values is even less predictable than querying by attribute values. > > For example, if the default value for visibility is used, the element's > visibility is calcualted as "inherit" (which is correct) and in that > case, the result won't include that element. Except where it does, and > that depends on the browser. No, "inherit" would be incorrect for getComputedStyle. For elements without a visibility rule, "visible" is the expected result. Now, IE's "cascaded styles" will indeed return "inherit" as IE doesn't compute styles at all, simply returning whatever is specified in applicable rules (or the default value, which is "inherit" in this case). Regardless, I'm sure that ExtJS fails to account for this (among many other things). Just like jQuery! :) > > But that is about Ext-JS (big version), not Sencha. In Sencha, all of > this stuff throws errors. Of course as it has no query engine; it simply hands off all queries to QSA. > > (I've got a some errands to do, so I'm going to post the rest of this > here wihout editing) > > | * E{display=none} css value "display" that equals "none" > | * E{display^=none} css value "display" that starts with "none" > | * E{display$=none} css value "display" that ends with "none" > | * E{display*=none} css value "display" that contains the substring > | "none" There's not a chance in hell they got any of those right cross- browser. > | * E{display%=2} css value "display" that is evenly divisible by 2 LOL. What on earth would that mean? > | * E{display!=none} css value "display" that does not equal "none" > | > | > | > | This class is a singleton and cannot be created directly. It's neither a class nor a singleton. > | Public Properties All JS properties are public. > | Property Defined By > | matchers : Object > | Collection of matching regular expressions and code snippets. Each > | capture group within () will be replace the {} in ... > | Collection of matching regular expressions and code snippets. Each > | capture group within () will be replace the {} in the select statement > | as specified by their index. > | DomQuery > | pseudos : Object > | Object hash of "pseudo class" filter functions which are used when > | filtering selections. Each function is passed two ... Oh God. As usual, these types of projects get ten steps ahead of themselves. I mean, it's 2010 and their basic queries are still broken. What's the point of piling all of this other nonsense on top? [snip more delusions] > | > | DomQuery > | selectNumber( String selector, [Node root], Number defaultValue ) : > | Number > | Selects the value of a node, parsing integers and floats. Returns the > | defaultValue, or 0 if none is specified. > | Selects the value of a node, parsing integers and floats. Returns the > | defaultValue, or 0 if none is specified. > | Parameters: > | > | * selector : String > | The selector/xpath query > | * root : Node > | (optional) The start of the query (defaults to document). > | * defaultValue : Number > | > | Returns: > | > | * Number > | > | DomQuery > | selectValue( String selector, [Node root], String defaultValue ) : > | String > | Selects the value of a node, optionally replacing null with the > | defaultValue. > | Selects the value of a node, optionally replacing null with the > | defaultValue. > | Parameters: > | > | * selector : String > | The selector/xpath query > | * root : Node > | (optional) The start of the query (defaults to document). > | * defaultValue : String > | > | Returns: String > | > | DomQuery > > The `selectValue` and `selectNumber` methods are missing altogether from > Sencha. There's a lot of that going on. They were clearly pressed for time. > > typeof Ext.DomQuery.selectValue > > "undefined" Here's a good acid test for a Web application:- typeof Ext == 'undefined' ,,,with true being the desired result. ;)
From: Ry Nohryb on 19 Jul 2010 01:51
On Jul 18, 8:18 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > The name "repaint" has the outward indication of a mystical incantation. > We know that there is no way to force a repaint, and so when I see a > name like that, I know that the method won't directly cause the browser > to repaint and that it will, at best, perform an unrelated action that > was associated with addressing a perceived problem. > You're mistaken, again, Garrett. Yes, there are ways to force both reflows and repaints. For example, this (google groups) page can be forced to repaint with: document.body.style.opacity= 0; setTimeout(function(){document.body.style.opacity= 1},0); Or with: document.body.style.visibility= "hidden"; setTimeout(function(){document.body.style.visibility= ""},0); And to reflow (+ repaint): document.body.style.maxWidth= "50px"; setTimeout(function(){document.body.style.maxWidth= ""},0); HTH, -- Jorge. |