Using "new function() {...}" as a Singleton [JavaScript]

Prev: A function that tells itself
Next: IE9--the end of the line for browser sniffers?

From: Garrett Smith on 7 Jun 2010 01:43

On 5/30/2010 8:53 AM, David Mark wrote:
> On May 30, 3:07 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote:
>> On 5/29/2010 11:05 PM, Garrett Smith wrote:
>>
>>> On 5/25/2010 4:09 AM, David Mark wrote:
>>>> Garrett Smith wrote:
>>>>> On 5/24/2010 6:57 PM, David Mark wrote:
>>>>>> Garrett Smith wrote:
>>>>>>> On 5/24/2010 2:11 PM, David Mark wrote:
>>>>>>>> Garrett Smith wrote:
>>>>>>>>> On 5/22/2010 1:25 PM, David Mark wrote:
>>>>>>>>>> Ry Nohryb wrote:
>>>>>>>>>>> On May 22, 5:13 pm, Stefan Weiss<krewech...(a)gmail.com> wrote:
>>>>>>>>>>>> On 22/05/10 16:22, Johannes Baagoe wrote:
>>
>>>>>>>>>>>>> Dmitry A. Soshnikov :
>>
>>>>>>>>> [...]
>>
>> [...]
>>
>>>> http://www.cinsoft.net/size.html
>>
>>> That one's obviously no good. If you'd tested it you would probably have
>>> realized that.
>>
>> I meant the following (position) is no good. The previous one (size)
>> looks OK.
>
> OK?! Quirks mode, standards mode, any units, box-model variations,
> etc. It's a rock. Compare and contrast to jQuery's nonsense (as
> cited in the page).
>
>>
>>>> Positions too:
>>
>>>> http://www.cinsoft.net/position.html
>>
>>> Where are the unit tests?
>>
>
> Unit tests for a test page? And I tested it to death in a heart-
> stopping number of browsers. I did far more tests than are
> demonstrated on the page, including fixed positioning and elements
> positioned with only a single rule (e.g. right).
>

That is a demo, or a "functional test".

A unit test would check all edge cases and ensure that all code paths
are executed.

Try putting the element in a table, getting the position values from a
child of BODY, elements with display: inline, floats. For any case that
you don't want to support, you could create the test and annotate it as
IGNORE with a comment.

// This case is not supported because [reason]

You'll probably run into edges.

Copy'n'pasting your function from position.html into a simple test page
that we discussed last year, I get different results in different
versions of IE.

I removed 'testinput', had the function call onload, and set ids = ["i7"];

http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.javascript/2009-11/msg00010.html

> Perhaps you don't understand the concept? It is designed to retrieve
> a pair (e.g. left/top, right/bottom, right/top, etc.) The caller must
> know which pair they are interested in. For example, given an element
> positioned like this:-
>

I see what it's supposed to do and what it does.

Anything using offsetTop, offsetLeft, or offsetParent must not be trusted.

> #myelement {
> top:20px;
> }
>
> ...the test function will dutifully fill in two of the three
> "blanks" (left and right). Obviously you can't use both of them
> together. In this case, you could make use of the top/left or top/
> right pairs.
>
> My plan is to eventually replace the more complex
> getElementPositionStyle function in My Library (which is limited to
> figuring left/top) with this version. For that, I will add an
> argument for the caller to specify which pair they want and it will
> return null if that pair cannot be determined. Get it?
>

So along the lines of:

getElementPositionStyle(el, "left");

?

Or:

Element.getPositionStyle("left")

?

> Beats the hell out of relying on getComputedStyle and the like (for
> many reasons which we discussed to death just a month or so ago).

getComputedStyle doesn't work in IE.

What perturbs me about getting styles is there's no good way to get
styles in a particular unit. At least I haven't figured out a way to do
animation in other units, such as EM, for example.

Garrett

From: Garrett Smith on 9 Jun 2010 03:15

On 5/30/2010 7:39 AM, David Mark wrote:
> On May 30, 2:05 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote:
>> On 5/25/2010 4:09 AM, David Mark wrote:
>>
>>> Garrett Smith wrote:
>>>> On 5/24/2010 6:57 PM, David Mark wrote:
>>>>> Garrett Smith wrote:
>>>>>> On 5/24/2010 2:11 PM, David Mark wrote:
>>>>>>> Garrett Smith wrote:
>>>>>>>> On 5/22/2010 1:25 PM, David Mark wrote:
>>>>>>>>> Ry Nohryb wrote:
>>>>>>>>>> On May 22, 5:13 pm, Stefan Weiss<krewech...(a)gmail.com> wrote:
>>>>>>>>>>> On 22/05/10 16:22, Johannes Baagoe wrote:
>>
>>>>>>>>>>>> Dmitry A. Soshnikov :
[...]

>>> That's why you should use my patented avoidance technique.
>>
>>> http://www.cinsoft.net/size.html
>>
>> That one's obviously no good. If you'd tested it you would probably have
>> realized that.
>
> Don't be silly.

That one looks fine. I meant the other. I did write that in my follow up.

>>
>>> Positions too:
>>
>>> http://www.cinsoft.net/position.html
>>
>> Where are the unit tests?
>
> That's all you ever say. Where is your understanding of the basic
> logic. IIRC, that one was posted to refute your assertion that
> computed styles should be used to determine positions. At the time,
> you seemed to be the only one who didn't get it.
>

It would be helpful to look at them to see what was being tested. You
wrote that you had tests, so where are they? Given time, I'd like to
look into them.

My offsetTop knowledge has has waned in the last 2 years; the number of
problems with that and friends are too much to retain, however I know
enough not to trust anything that uses them, not without tests and
testing all the edge cases I mentioned in my other reply. A good test
can provide quicker verification than a demo.

>>
>>>> So, if that element is matched in the author's selector query
>>>> "img[width=600]" the query would not be doing what he says it does.
>>>> Namely, it would not match "all the images whose width is 600px".
>>
>>> Yes, it's all nonsense. Don't rely on these silly query engines (or
>>> their documentation).
>>
>>> http://www.cinsoft.net/slickspeed.html
>>
>> Pass on that.
>
> Whether you pass or not, it is quite a demonstration of the futility
> of the query-based libraries.
>

A little. I'd rather more see expected results and failed results; speed
is secondary to correctness.

The first column would be a good place for that. For examaple:

+------------------+----------+------------------+
| Selector | Expected | NWMatcher 1.2.1 |
| div[class^=dia] | Error | ??? |
+------------------+----------+------------------+

Who has any idea what nonstandard selectors should do? Based on what?
jQuery documentation? The libraries all copied the jQuery library and
the jQuery library has always had vague documentation and inconsistent
results across browsers an between versions of jQuery.

What can "td[colspan!=1]" or "div[class!=madeup]" be expected to do,
other than throw an error? To answer that, you need documentation. The
most obvious place to look for documentation would be the w3c Selectors
API, and that will tell you that an error must be thrown because the
attribute value is neither an identifier nor a string.

MSDN documentation, is wrong, too

http://msdn.microsoft.com/en-us/library/aa358822%28VS.85%29.aspx
| att Must be either an Identifier or a String.
| val Must be either an Identifier or a String.

`att` should be an attribute name, not an identifier or a string.

In CSS, identifiers (including element names, classes, and IDs in
selectors) can contain only the characters [a-zA-Z0-9] and ISO 10646
characters U+00A1 and higher, plus the hyphen (-) and the underscore
(_); they cannot start with a digit, or a hyphen followed by a digit.
Identifiers can also contain escaped characters and any ISO 10646
character as a numeric code (see next item). For instance, the
identifier "B&W?" may be written as "B\&W\?" or "B\26 W\3F".

(quoted from the CSS2.1 specification).

What happens if jQuery removes support for a particular selector?
Haven't they done that in the past for nth-of-type or attribute style
selectors, XPath, and @attr?

What should a:link match? Should it throw an error? What should be the
expected result set of `null`?

If that is not what you want it to do; if you want something other than
an error, you need to state what and why; you need documentation.

A better test would be side-by-side comparison of NodeSelector. A good
test case might be to take the w3c NodeSelector interface and rewrite it
to make sure it fails for all the invalid syntax that is allowed in
these things.

I think it is time to wake up. For you and for all web developers.

You've written a long test that makes assertions about a loosely defined
interface -- the query function, that is specified in documentation that
is incredibly vague, and was aptly titled with an enigmatic identifier
-- the dollar function. That such an interface would be mimicked so many
times over, and with variations, is alarming and I think indicates a
problem with the industry.

>>
>>
>>
>>>> That expectation is based on observations of design bug of jQuery and
>>>> even at that, the query will fail, matching an element whose display is
>>>> "none" in those recent browsers that implement getComputedStyle. In IE8
>>>> and below, it will not match the element, and so it will do what the
>>>> author says it does.
>>
>>> I think you are a bit confused about how jQuery's Sizzle thing works.
>>
>> [...]
>>
>> Are you bluffing?
>
> No.
>

OK. Take a look at ATTR:

ATTR: function(elem, match){
var name = match[1],
result = Expr.attrHandle[ name ] ?
Expr.attrHandle[ name ]( elem ) :
elem[ name ] != null ?
elem[ name ] :
elem.getAttribute( name ),
value = result + "",
type = match[2],
check = match[4];

This line:

elem[ name ] != null ? elem[ name ]

- checks to see if the element's property is either null or undefined.
If that is the case, getAttribute is used as a fallback.

Where the property name is `width`, the property gets its value from how
wide the element actually is. It could be either offsetWidth or
computedStyle width, depending on the browser. It's not specified.

http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-13839076

Says that width is "The width of the image in pixels. " and refers to
HTML 4.01 for more information. It does not provide any more detail such
as how that "width" measurement is calculated. The width could be taken
from computedStyle and then rounded (because it is of type long), it
might include padding or border.

Regardless, that is the definition for the width property, not the width
attribute.

Observation shows that styles that have been rendered affect an img's
`width` property in all tested browsers and that in IE, if the img has
display: none, then `img.width` reports 0 in IE.

img {
padding: 1px;
}

<div onclick="alert(this.firstChild.width)"><img style="display: none"
width="100" src="http://www.w3.org/Icons/w3c_home">Clicke here!</div>

<img style="width: 40px" width="100" onclick="alert(this.width)"
src="http://www.w3.org/Icons/w3c_home">

The first img.width reports 100 in most browsers and 0 in IE.

The second, 40 in most browsers, 42 in IE in standards mode, 42 in
quirks mode.

HTML 5 codifies what most browsers do; that is, if the image is not
rendered, it gets the intrinsic width. If it is rendered, then it gets
the rendered width.

All that aside, the point of this is not to figure out how the `width`
property works; focusing on the anomalies would be totally missing the
point.

The width property is not the width attribute. Properties != attributes.
It's as simple as that.

The query img[width=600] will fail to match elements with display "none"
in IE8 and below. That outcome can only be considered a "failure" when
the success has been defined as performing a match and not throwing an
error. That expectation is nonstandard because the Selectors API
requires an error to be thrown. So, since the outcome is nonstandard, it
begs the question: What nonstandard results are you expecting?

If it is expected to match of all element's whose width is 600px, and if
so, does that mean "intrinsic" width, the "width" defined by CSS, the
offsetWidth, the width property, or the width attribute? If the width
attribute is wanted, then what is that expectation coming from? The
expectation be more in line with what the selectors API specifies, but
it is already established now that the selector is invalid and that the
expectation is nonstandard behavior, so it cannot be reasonably assumed
that other parts of the specification are expected to be upheld, and
certainly not in light of looking at the ATTR function which does
property matching. What is expected is not defined.

The result of not matching img that have display none can be explained
by looking at the code for ATTR and realizing that it is matching
property values. The algorithm for the value of that property is
unspecified by DOM 2 HTML. It is completely inconsistent with the
Selectors API.

The design of jQuery is not explained by the documentation. It is not
explained in that article. It is explained in the code, but what the
code says matches not what the jQuery docs state, nor the author of the
article states; not completely at least. The design of jQuery is
explained in the source code of jQuery.

Anyone who wants to know what anything does can just read the code.
Mine, yours, jQuery. doen'st matter, really.

Of course, therein lies a potential problem an that is code cleanliness.
Code that has long and complicated methods such as having nested if
else, typechecking, and variable behavior, tends to be harder to read
and understand.

For one who does not do javascript as his primary task, cross browser
coding is likely to be less familiar and natural. Such person is going
to be less likely to read the source code to learn what it does, and for
an API that has methods that have too much complexity, even if he does
read the source code, he's probably not going to grasp it quickly. It's
complicated. More likely, he'll learn from examples such as those in the
article.

>
>>
>> The author of that article stated that the attribute selectors provide a
>> "very accurate" way to "select the elements knowing their attributes and
>> values".
>
> Yes, he's obviously clueless.
>

He seems not to know the difference between attributes and properties.
Perhaps he has learned how selectors work by using jQuery.

Does the jQuery team know the difference between attributes and properties?

After all the code review that's been done, I see jQuery team advocating
this article and it begs the question: Do they know what that code does?
The code does not match attributes, so in that regard, it does not do
what the author says, but then the code does, in some cases, match
elements whose width is 600px, but only by virtue of having the rendered
width being reflected in the corresponding property.

jQUery has differeng attribute/property accessors. One is in attr,
you've raked that one over and over, the other, however, is in ATTR, and
that one still resolves properties.

If the only basis for design is retrofitting a public (permanent) API
with workarounds that addressed its initial design, and only in reaction
to having those problems drawn out in public, repeatedly, over and over
and over again, what was in the original API design that made it so
damned attractive that caused so many library authors to want to copy it?

Moreover, what does such copying say about the state of the industry?
How is the web doing?

>>
>> The examples he provided have a comment that contradicts what he says it
>> does in the article; that: "img[width=600]" matches "all the images
>> whose width is 600px".
>
> Yes, that was a stupid thing to say.
>

That's a fine example to illustrate my point. It is time to wake up.

>> YOu wanna know what's silly? Designing an API "to make a mockery of
>> jQuery".
>
> Why is that silly?
>

It does not serve a practical purpose. In the big picture, it is hardly
an improvement, it misses the point of what "API" stands for.

>> Worse yet, providing an interface with methods "E" and "Q" and
>> whatever the other one-letter method names are, along with other badly
>> named abstractions that provide value, such as gEBI or getEBI, etc. Just
>> use the real method: document.getElementById.
>
> For one, "E" and "Q" are no worse than "$" and "Y". And they aren't
> method names at all, but optional constructors for the OO interface,
> which sits atop the API. E is for Element, Q is for Query. What is
> "$" for?
>

E could mean Euler's log, Event, or Error. The identifier doesn't identify.

> And the getEBI function does provide added value (as was discussed
> back in 2007 when it was first published here). Where have you been?
>

Added value? What added value? Do you mean the workaround for giving an
element an ID where another element has that for its NAME? Avoiding
doing that is the best workaround.

[...]

Garrett

From: David Mark on 9 Jun 2010 06:57

On Jun 7, 1:43 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> On 5/30/2010 8:53 AM, David Mark wrote:
>
>
>
>
>
>
>
>
>
> > On May 30, 3:07 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote:
> >> On 5/29/2010 11:05 PM, Garrett Smith wrote:
>
> >>> On 5/25/2010 4:09 AM, David Mark wrote:
> >>>> Garrett Smith wrote:
> >>>>> On 5/24/2010 6:57 PM, David Mark wrote:
> >>>>>> Garrett Smith wrote:
> >>>>>>> On 5/24/2010 2:11 PM, David Mark wrote:
> >>>>>>>> Garrett Smith wrote:
> >>>>>>>>> On 5/22/2010 1:25 PM, David Mark wrote:
> >>>>>>>>>> Ry Nohryb wrote:
> >>>>>>>>>>> On May 22, 5:13 pm, Stefan Weiss<krewech...(a)gmail.com> wrote:
> >>>>>>>>>>>> On 22/05/10 16:22, Johannes Baagoe wrote:
>
> >>>>>>>>>>>>> Dmitry A. Soshnikov :
>
> >>>>>>>>> [...]
>
> >> [...]
>
> >>>>http://www.cinsoft.net/size.html
>
> >>> That one's obviously no good. If you'd tested it you would probably have
> >>> realized that.
>
> >> I meant the following (position) is no good. The previous one (size)
> >> looks OK.
>
> > OK?! Quirks mode, standards mode, any units, box-model variations,
> > etc. It's a rock. Compare and contrast to jQuery's nonsense (as
> > cited in the page).
>
> >>>> Positions too:
>
> >>>>http://www.cinsoft.net/position.html
>
> >>> Where are the unit tests?
>
> > Unit tests for a test page? And I tested it to death in a heart-
> > stopping number of browsers. I did far more tests than are
> > demonstrated on the page, including fixed positioning and elements
> > positioned with only a single rule (e.g. right).
>
> That is a demo, or a "functional test".

Semantics. Let's call it something I put on my server in response to
the latest revisiting of undeniably flawed computed styles vs. my
perfect positioning solution.

Remember this thread?

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/21c0aaa9e69cb88f/e310c3518c91a1bd?#e310c3518c91a1bd

Or perhaps the one before it (or the one before that). I've been
trying to make this point for years and you always pop up to muddy it.

>
> A unit test would check all edge cases and ensure that all code paths
> are executed.

Thanks for that. You seem to have it in your head that nothing could
possibly work without unit tests.

>
> Try putting the element in a table, getting the position values from a
> child of BODY, elements with display: inline, floats.

You seem to be latching on to calculating absolute offset positions,
which is odd as those have nothing to do with computed styles. The
point of the exercise to get the computed left/top, right/bottom or
whatever coordinate pairs so that they can be set back without moving
the elements. None of the above matter. The only caveat is that the
position must not be *static* as then the concept of positioning by
coordinates is meaningless.

> For any case that
> you don't want to support, you could create the test and annotate it as
> IGNORE with a comment.

No need to do any of that in this case. The algorithm used (for
years) is basic math and I gave you enough tests to get you started if
you wish to investigate further.

>
> // This case is not supported because [reason]
>
> You'll probably run into edges.

There's no such thing as edge cases in my book. Things work as
documented or they don't. If they don't, you adjust the code or
documentation.

>
> Copy'n'pasting your function from position.html into a simple test page
> that we discussed last year, I get different results in different
> versions of IE.

That's unsurprising as I'm sure you are confused about what you are
testing.

>
> I removed 'testinput', had the function call onload, and set ids = ["i7"];
>
> http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.javascript/200...

I see something about list items, which seems to confirm confusion on
the part of the tester.

>
> > Perhaps you don't understand the concept? It is designed to retrieve
> > a pair (e.g. left/top, right/bottom, right/top, etc.) The caller must
> > know which pair they are interested in. For example, given an element
> > positioned like this:-
>
> I see what it's supposed to do and what it does.

But you don't understand it. Apparently you don't understand what it
is even supposed to do, which would preclude understanding the
results.

>
> Anything using offsetTop, offsetLeft, or offsetParent must not be trusted..

For one, offsetParent is _not_ used. For two, and we went over this
fifty times in the last thread, the algorithm used factors out the
inconsistencies. That's why it works so consistently, despite
utilizing properties that are inconsistent cross-browser.

>
> > #myelement {
> > top:20px;
> > }
>
> > ...the test function will dutifully fill in two of the three
> > "blanks" (left and right). Obviously you can't use both of them
> > together. In this case, you could make use of the top/left or top/
> > right pairs.
>
> > My plan is to eventually replace the more complex
> > getElementPositionStyle function in My Library (which is limited to
> > figuring left/top) with this version. For that, I will add an
> > argument for the caller to specify which pair they want and it will
> > return null if that pair cannot be determined. Get it?
>
> So along the lines of:
>
> getElementPositionStyle(el, "left");

You could do that, but more like:-

getElementPositionStyles(el, "topleft");
getElementPositionStyles(el, "bottomright");

etc.

At the moment, it fills in all of the blanks that it can, which has
apparently led to some confusion about what the results mean (at least
I thought that was the source of your confusion). If you get back
top, left *and* right. You can use top/left or top/right (but not all
three).

>
> ?
>
> Or:
>
> Element.getPositionStyle("left")

Of course not.

>
> ?
>
> > Beats the hell out of relying on getComputedStyle and the like (for
> > many reasons which we discussed to death just a month or so ago).
>
> getComputedStyle doesn't work in IE.

Groan. That's my line.

>
> What perturbs me about getting styles is there's no good way to get
> styles in a particular unit. At least I haven't figured out a way to do
> animation in other units, such as EM, for example.

If you are lacking code as described here:-

http://www.cinsoft.net/position.html

....and presuming you wish to support IE and do not wish to use pixels
for everything (would make your site very unpopular with IE users),
you have no choice but to use other units. They aren't any harder
than pixels though. The letters tacked on to the end of the numbers
are just different (e.g. "px" vs. "em" vs. whatever).

From: David Mark on 9 Jun 2010 07:33

On Jun 9, 3:15 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> On 5/30/2010 7:39 AM, David Mark wrote:> On May 30, 2:05 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote:
> >> On 5/25/2010 4:09 AM, David Mark wrote:
>
> >>> Garrett Smith wrote:
> >>>> On 5/24/2010 6:57 PM, David Mark wrote:
> >>>>> Garrett Smith wrote:
> >>>>>> On 5/24/2010 2:11 PM, David Mark wrote:
> >>>>>>> Garrett Smith wrote:
> >>>>>>>> On 5/22/2010 1:25 PM, David Mark wrote:
> >>>>>>>>> Ry Nohryb wrote:
> >>>>>>>>>> On May 22, 5:13 pm, Stefan Weiss<krewech...(a)gmail.com> wrote:
> >>>>>>>>>>> On 22/05/10 16:22, Johannes Baagoe wrote:
>
> >>>>>>>>>>>> Dmitry A. Soshnikov :
>
> [...]
>
> >>> That's why you should use my patented avoidance technique.
>
> >>>http://www.cinsoft.net/size.html
>
> >> That one's obviously no good. If you'd tested it you would probably have
> >> realized that.
>
> > Don't be silly.
>
> That one looks fine. I meant the other. I did write that in my follow up.

Yes. I saw it when I got to it (after I had replied to the
original). And I still contend it is more than fine. Like the
position one, it is the perfect solution to a problem that seems to
afflict virtually every library, framework, widget, etc. on the
market. It baffles me as I've been using similar code since 1998.
Yet, as seen in the last message, I am still having to argue the
points in 2010.

>
>
>
> >>> Positions too:
>
> >>>http://www.cinsoft.net/position.html
>
> >> Where are the unit tests?
>
> > That's all you ever say. Where is your understanding of the basic
> > logic. IIRC, that one was posted to refute your assertion that
> > computed styles should be used to determine positions. At the time,
> > you seemed to be the only one who didn't get it.
>
> It would be helpful to look at them to see what was being tested. You
> wrote that you had tests, so where are they?

Groan. All I want to know is what is the name of the guy on first
base.

> Given time, I'd like to
> look into them.

You have looked at them. In fact, I put up those two primers partly
for your benefit. And I can't believe they didn't help.

>
> My offsetTop knowledge has has waned in the last 2 years; the number of
> problems with that and friends are too much to retain,

You don't have to retain *any* of it. Zero. I don't think about
their quirks either. I create equations that account for *any* quirks
by factoring them out of the answer. It's really not that complicated
if you think about it (and read my many examples and previous
explanations).

> however I know
> enough not to trust anything that uses them, not without tests and
> testing all the edge cases I mentioned in my other reply. A good test
> can provide quicker verification than a demo.

You would rather trust something you know is broken and/or absent
(e.g. getComputedStyle/currentStyle)? My solutions work whether the
properties in question are broken or not. And I've tested in
virtually every major browser that has come out this century (and a
few from the last century).

>
>
>
> >>>> So, if that element is matched in the author's selector query
> >>>> "img[width=600]" the query would not be doing what he says it does..
> >>>> Namely, it would not match "all the images whose width is 600px".
>
> >>> Yes, it's all nonsense. Don't rely on these silly query engines (or
> >>> their documentation).
>
> >>>http://www.cinsoft.net/slickspeed.html
>
> >> Pass on that.
>
> > Whether you pass or not, it is quite a demonstration of the futility
> > of the query-based libraries.
>
> A little. I'd rather more see expected results and failed results; speed
> is secondary to correctness.

Expected results would be a good addition and I plan to add those.
For now, note that the two non-fantasy columns (e.g. mine), which
query with and without QSA agree in the latest major browsers in all
rendering modes. Then go back one version. Then another. Then
another. As they all agree, you can be pretty damned sure that the
answers are expected as that's what I did before I published them.
Now, look at all of the columns to the left. A horror show, right?
Blacked out squares everywhere. Exceptions thrown in browsers that
just came out a couple of years ago, miscounts in browsers that came
out yesterday. jQuery 1.4 disagrees with 1.3, which disagrees with
1.2. Dojo gets more answers wrong than right in Opera 9. And so on,
and so on... Lots of flailing and destruction and still nothing close
to a solid foundation for the "major" libraries and frameworks.
Somehow those things are seen as an "easier" way to do the most
important task in browser scripting (e.g. read documents).

>
> The first column would be a good place for that. For examaple:
>
> +------------------+----------+------------------+
> | Selector | Expected | NWMatcher 1.2.1 |
> | div[class^=dia] | Error | ??? |
> +------------------+----------+------------------+
>
> Who has any idea what nonstandard selectors should do? Based on what?
> jQuery documentation? The libraries all copied the jQuery library and
> the jQuery library has always had vague documentation and inconsistent
> results across browsers an between versions of jQuery.

Understand that CSS selector queries came long before the standard
specification. In fact, there would be no such specification if not
for such scripts. The specification is not retroactive and the tests
in question predate the documentation on the W3C site as well.

>
> What can "td[colspan!=1]" or "div[class!=madeup]" be expected to do,

Obviously, the same thing that they would do with quotes around them.
You are focusing on irrelevant minutiae. The point is that jQuery and
the like often trip over such queries (with or without the quotes).
How can that be? Well, see my discussion here with Resig around
Halloween 2007 (or search the archive for about a hundred follow-ups,
usually involving Matt Kruse who spent years swearing such obvious
mistakes were to be expected). That should answer all of the
questions. If only it had for them. :(

> other than throw an error? To answer that, you need documentation. The
> most obvious place to look for documentation would be the w3c Selectors
> API,

Ugh. Chicken and the egg. The code and tests predate the writeup.
Get it?

> and that will tell you that an error must be thrown because the
> attribute value is neither an identifier nor a string.

This isn't one of those Terminator movies. The W3C can't go back in
time and abort jQuery, SlickSpeed and the like.

>
> MSDN documentation, is wrong, too

Wouldn't shock me.

>
> http://msdn.microsoft.com/en-us/library/aa358822%28VS.85%29.aspx
> | att Must be either an Identifier or a String.
> | val Must be either an Identifier or a String.
>
> `att` should be an attribute name, not an identifier or a string.

Depends on what you consider to be right. Clearly you don't have a
grasp on that yet, so I won't bother investigating the alleged mistake
on MSDN. I presume they are documenting their rendition of QSA. Just
as they previously documented their rendition of innerHTML,
offsetHeight, etc. When and if these things get written up as
recommendations by the W3C, it will not render the previous behavior
and documentation "wrong".

>
> In CSS, identifiers (including element names, classes, and IDs in
> selectors) can contain only the characters [a-zA-Z0-9] and ISO 10646
> characters U+00A1 and higher, plus the hyphen (-) and the underscore
> (_); they cannot start with a digit, or a hyphen followed by a digit.
> Identifiers can also contain escaped characters and any ISO 10646
> character as a numeric code (see next item). For instance, the
> identifier "B&W?" may be written as "B\&W\?" or "B\26 W\3F".
>
> (quoted from the CSS2.1 specification).
>
> What happens if jQuery removes support for a particular selector?

They only support about half of them at this point I think. Certainly
they are nowhere near compliance with CSS3 (which they disingenuously
claim to be). And their script is not 24K by any comparison rooted in
reality (i.e. prior to GZIP). They simply feed tripe to those naive
enough to swallow it. Did you know My Library is roughly 42K after
compression? The whole thing (which does 100 times more than jQuery,
including queries). :)

> Haven't they done that in the past for nth-of-type or attribute style
> selectors, XPath, and @attr?

nth-of-type? No idea what they did with that. IIRC, mine is the only
one I know of that attempts to support those (and as I've recently
realized, I didn't quite nail it). The SlickSpeed tests can be
confusing to the uninitiated as most of the libraries now hand off to
QSA, so it may appear that unsupported selectors work. Of course,
that's a big part of the problem. Neophytes like to test in just the
latest browsers and avoid IE as much as possibly. IE8 has QSA. IE9
will likely augment its capabilities in that department. So you can
have applications that appear to work if tested just in IE8 standards
mode and/or IE9 but have no shot at all in Compatibility View or IE <
8. That's why jQuery 1.2.6 (and not 1.2.1 as that was a misprint)
remains on the test page along side 1.3.x and 1.4.x. That's the last
one that didn't hand off queries to the browser.

>
> What should a:link match? Should it throw an error? What should be the
> expected result set of `null`?

What do you think it should match? It won't match anything in any
query engine I know of. No coincidence it is not featured on any of
the test pages.

>
> If that is not what you want it to do; if you want something other than
> an error, you need to state what and why; you need documentation.

Who are you talking to? I've said (and demonstrated) from the start
that these query engines are a waste of time. Lack of documentation
is the least of the worries.

>
> A better test would be side-by-side comparison of NodeSelector. A good
> test case might be to take the w3c NodeSelector interface and rewrite it
> to make sure it fails for all the invalid syntax that is allowed in
> these things.

Nope. More wasted time.

>
> I think it is time to wake up. For you and for all web developers.

Me?! You are just parroting my lines years later. Where do you get
the gall?

>
> You've written a long test that makes assertions about a loosely defined
> interface -- the query function, that is specified in documentation that
> is incredibly vague, and was aptly titled with an enigmatic identifier
> -- the dollar function.

Wrong. MooTools wrote that stupid test years ago. And all of those
stupid libraries that it was written to test used the "$" function. I
just added more test cases and gave my getEBCS function a "$" alias.
Where have you been? These are discussions from over two years ago.

> That such an interface would be mimicked so many
> times over, and with variations, is alarming and I think indicates a
> problem with the industry.

Mine is not mimicry. It is parody to make a point. And I think it is
(finally) getting through loud and clear.

>
>
>
> >>>> That expectation is based on observations of design bug of jQuery and
> >>>> even at that, the query will fail, matching an element whose display is
> >>>> "none" in those recent browsers that implement getComputedStyle. In IE8
> >>>> and below, it will not match the element, and so it will do what the
> >>>> author says it does.
>
> >>> I think you are a bit confused about how jQuery's Sizzle thing works.
>
> >> [...]
>
> >> Are you bluffing?
>
> > No.
>
> OK. Take a look at ATTR:

Are you really showing jQuery's attribute handling to *me*?!

>
> ATTR: function(elem, match){
> var name = match[1],
> result = Expr.attrHandle[ name ] ?
> Expr.attrHandle[ name ]( elem ) :
> elem[ name ] != null ?
> elem[ name ] :
> elem.getAttribute( name ),
> value = result + "",
> type = match[2],
> check = match[4];
>
> This line:
>
> elem[ name ] != null ? elem[ name ]

Same as you! Same as YOU! I throw the ball to who. Whoever it is drops
the ball and the guy runs to second. Who picks up the ball and throws
it to What. What throws it to I Don't Know. I Don't Know throws it
back to Tomorrow, Triple play. Another guy gets up and hits a long fly
ball to Because. Why? I don't know! He's on third and I don't give a
darn!

From: David Mark on 9 Jun 2010 08:09

First | Prev | Next | Last
Pages: 8 9 10 11 12 13 14 15 16 17 18 19
Prev: A function that tells itself
Next: IE9--the end of the line for browser sniffers?