jquery question on slideUp fadeIn and show
Kevin Lucas
jquery noob question here. I've got a php script that runs a few price
checker kiosks out on the sales floor at work and I've got a <p> element
that I can get to slide up when a product is scanned and slide back down
after a 5 second pause with:
$(function() {
$("p").slideUp("slow");
setTimeout(function(){ $("p").slideDown("slow"); }, 5000);
});
but when I change the slideUp and slideDown to fadeIn and fadeOut I'm not
getting the element to fade in or out. Instead the element shows up on the
screen then after 5 seconds the element appears in the position where it
ends up after a slideUp.
Similarly if I change the slideUp and slideDown to 'show' and 'hide' the
element again shows up in the spot that it starts the slideUp from then
slides up after 5 seconds.
Any thoughts on what I'm doing wrong?
Thanks in advance.
P.S. would've posted this in a jquery newgroup but couldn't find one carried
on my news server. :\
kev.
RobG
> P.S. would've posted this in a jquery newgroup but couldn't find one carried
> on my news server. :\
That's because the jQuery group doesn't use Usenet[1], it is a Google
Group[2], so you need access to the WWW:
<URL: http://groups.google.com/group/jquery-en?lnk= >
1. <URL: http://en.wikipedia.org/wiki/Usenet >
2. <URL: http://en.wikipedia.org/wiki/Google_groups >
--
Rob
JR
<klucas_de_oh_tee-.garb...@teksavvy.com> wrote:
> jquery noob question here. [...]
OMG... The anti-jQuery crusaders are bringing the axe...
Kevin Lucas
Thanks Rob, I'll post there.
kev.
Kevin Lucas
Gulp, oh boy. That bad huh?
kev.
Thomas 'PointedEars' Lahn
Yes, jQuery is that bad. If you take a moment to look beyond $() calls, you
might notice it.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Kevin Lucas
> Kevin Lucas wrote:
>> JR wrote:
>>> On Sep 13, 6:38 pm, Kevin Lucas
>>> <klucas_de_oh_tee-.garb...@teksavvy.com> wrote:
>>>
>>>> jquery noob question here. [...]
>>> OMG... The anti-jQuery crusaders are bringing the axe...
>>
>> Gulp, oh boy. That bad huh?
>
> Yes, jQuery is that bad. If you take a moment to look beyond $() calls,
> you might notice it.
>
>
> PointedEars
Yes, the original question is a moot point as the embedded browser that the
price checkers use don't support it. Should've been suspicious when it
didn't work in Konqueror ;).
kev.
David Mark
Ah, another triumph. :) The clock is running out on that script for
sure.
S.T.
> On Sep 14, 9:57 am, Kevin Lucas
>
> sure.
>
... or, more likely, Konqueror's time is running out. Aside from JQuery
(and presumably most JS libraries) substantial Google and Yahoo
properties don't bother to support KJS -- the Gmail UI, Yahoo! Mail,
Google Calendar and Reader, etc.
David Mark
Lets assume there is no Konquerer. That leaves n - 1 browsers to
support. Throw out whatever is embedded in his price checker and you
get n - 2. How many do jQuery (or GMail or whatever) do well? The
point is that these failings are symptoms and likely to get worse with
each browser produced. Dismissing them in turn is wishful thinking.
The current failings of other sites, whatever script(s) they may use,
don't enter into it.
RobG
> David Mark wrote:
> > On Sep 14, 9:57 am, Kevin Lucas
>
> > Ah, another triumph. :) The clock is running out on that script for
> > sure.
>
> ... or, more likely, Konqueror's time is running out. Aside from JQuery
> (and presumably most JS libraries) substantial Google and Yahoo
> properties don't bother to support KJS
If that logic had any merit, the only browser anyone would "bother to
support" would be IE 6.
--
Rob
S.T.
> Lets assume there is no Konquerer. That leaves n - 1 browsers to
> support. Throw out whatever is embedded in his price checker and you
> get n - 2. How many do jQuery (or GMail or whatever) do well?
You seem concerned about how many browsers a site supports. That may be
a reasonable goal for a public service site to ask -- though
whitehouse.gov uses (and old version of) JQuery, so perhaps not. However
it's not the concern for most commercial entities.
Commercial sites are concerned about... well.. commercial interests.
They care about user reach, not browser reach. Yahoo probably spells it
out best:
http://www.yuiblog.com/blog/2009/07/02/gbs-update-20090702/
> The
> point is that these failings are symptoms and likely to get worse with
> each browser produced. Dismissing them in turn is wishful thinking.
>
> The current failings of other sites, whatever script(s) they may use,
> don't enter into it.
Surfing traffic doesn't consider the sites as having failings. If a site
doesn't work on one browser but does on another - it's the browser's
fault. They'll switch soon enough.
The market penetration of JQuery alone is huge:
http://trends.builtwith.com/javascript/JQuery
Tie in various Google and Yahoo properties, along with all the others
that use a similar design, development and testing criteria, and a huge
chunk of the sites out there have set the standard for browsers to
follow. A new browser is welcome to join the mix but if it's user base
finds it has to use an old, awkward Yahoo Mail UI, ESPN and Amazon don't
work as expected cause of JQuery and Google Reader won't function at all
-- it's not going to have much of a user base anyways.
Like it or not, content now controls standards.
Stefan Weiss
> Yahoo probably spells it out best:
> http://www.yuiblog.com/blog/2009/07/02/gbs-update-20090702/
YUI's "graded browser support" is nothing to be proud of. They're openly
admitting that they only do QA for the most common browsers, and that
they won't even accept bug reports for those who didn't make the "A"
list. That includes FF3.0 and Opera 10, by the way, among many others.
At least FF3.0 and Opera are still in what they call their "X" grade.
And then there's the "C" grade: "Approximately 3% of our audience
receives a C-grade experience" (core content and functionality, [..]
delivered via nothing more than semantic HTML). 3% would be completely
unacceptable for me. IMHO, a company the size of Yahoo could put in a
little more effort.
cheers,
stefan
PS: Apparently there's no "B" grade. The divide their clients into the
good, the bad, and the weird.
David Mark
> David Mark wrote:
> > Lets assume there is no Konquerer. That leaves n - 1 browsers to
> > support. Throw out whatever is embedded in his price checker and you
> > get n - 2. How many do jQuery (or GMail or whatever) do well?
>
> You seem concerned about how many browsers a site supports.
A valid concern.
> That may be
> a reasonable goal for a public service site to ask -- though
> whitehouse.gov uses (and old version of) JQuery, so perhaps not.
So what does that prove?
> However
> it's not the concern for most commercial entities.
Their concern is typically collecting money from as many people as
possible.
>
> Commercial sites are concerned about... well.. commercial interests.
Unsurprisingly.
> They care about user reach, not browser reach.
Your momentum just gave out. What do users use?
> Yahoo probably spells it
> out best:http://www.yuiblog.com/blog/2009/07/02/gbs-update-20090702/
I doubt it.
>
> > The
>
> > point is that these failings are symptoms and likely to get worse with
> > each browser produced. Dismissing them in turn is wishful thinking.
>
> > The current failings of other sites, whatever script(s) they may use,
> > don't enter into it.
>
> Surfing traffic doesn't consider the sites as having failings.
Failings are what they are. As for traffic, everything's relative.
Just because a popular site makes mistakes doesn't mean you should try
to replicate them.
> If a site
> doesn't work on one browser but does on another - it's the browser's
> fault. They'll switch soon enough.
Who will switch what?
>
> The market penetration of JQuery alone is huge:http://trends.builtwith.com/javascript/JQuery
So what?
>
> Tie in various Google and Yahoo properties, along with all the others
> that use a similar design, development and testing criteria, and a huge
> chunk of the sites out there have set the standard for browsers to
> follow.
I have no idea what you are talking about (and assume you are
similarly affected). :)
> A new browser is welcome to join the mix but if it's user base
> finds it has to use an old, awkward Yahoo Mail UI, ESPN and Amazon don't
> work as expected cause of JQuery and Google Reader won't function at all
> -- it's not going to have much of a user base anyways.
>
> Like it or not, content now controls standards.
But that's not how things work. Browser developers don't bend for
dubious blobs of Javascript (they usually break them on purpose). And
what standards are you talking about, anyway?
RobG
> Commercial sites are concerned about... well.. commercial interests.
> They care about user reach, not browser reach. Yahoo probably spells it
> out best:http://www.yuiblog.com/blog/2009/07/02/gbs-update-20090702/
Yahoo! is not a paragon of browser development. Last I saw, their
marketshare was slipping so badly they had to do a deal with MS to
survive. Whatever they are doing now, it's not working for them as
well as what they were doing before.
Maybe if they'd switched to jQuery they'd be back on top of Google.
> > The
>
> > point is that these failings are symptoms and likely to get worse with
> > each browser produced. Dismissing them in turn is wishful thinking.
>
> > The current failings of other sites, whatever script(s) they may use,
> > don't enter into it.
>
> Surfing traffic doesn't consider the sites as having failings. If a site
> doesn't work on one browser but does on another - it's the browser's
> fault. They'll switch soon enough.
Yes, they'll switch sites very quickly and if it works better for
them, that's where they'll stay.
> The market penetration of JQuery alone is huge:http://trends.builtwith.com/javascript/JQuery
Read the history of the rise and fall if IE 6. Maybe all browsers
should just have emulated it and forgotten about innovation. Maybe all
those Linux and Apple freaks should just ditch their niche machines
and the whole world should run Windows. While we're at it, lets kill
anything other than Vista or Win7, who cares about anyone who can't
afford the latest and greatest PC and OS?
What was the WWW all about anyway? Glad we got rid of those bleeding
heart lefties...
[...]
> Like it or not, content now controls standards.
If content is king, development tools should aim to maximise access.
Selecting tools that deliberately marginalise a measurable number of
potential consumers is inconsistent with that logic.
--
Rob
Matt Kruse
> > However
> > it's not the concern for most commercial entities.
> Their concern is typically collecting money from as many people as
> possible.
s/possible/practical/
See also: The law of diminishing returns.
Matt Kruse
David Mark
And your deal is that any excuse is valid. Sure, use an obviously
wacky (and widely misunderstood) 50K blob of script on your e-commerce
site. Why not? Not practical, otherwise. Matt Kruse said so. Of
course, he doesn't know anyone who has an iPhone either. ;)
Matt Kruse
> On Sep 17, 11:20 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> > On Sep 16, 8:38 pm, David Mark <dmark.cins...@gmail.com> wrote:
> > > > However
> > > > it's not the concern for most commercial entities.
> > > Their concern is typically collecting money from as many people as
> > > possible.
> > s/possible/practical/
> > See also: The law of diminishing returns.
Nah, I just get tired of hearing the argument that the goal of web
sites (especially those attempting to make a profit) is surely to get
sales from every possible potential customer, and that is their only
goal bar none. It's just a dumb argument.
There is a cost associated with targetting any slice of the market. If
you can target and support the vast majority of potential customers
for low cost, that makes economic sense. If the cost to target and
support the additional 3% or whatever is significantly higher, then
that may not be worth it.
Argue the cost/benefit specifics all you want, or the pros and cons of
different approaches, but resorting to the argument that 100% support
for all users is always (or should always be) the goal is ridiculous
for most people. IMO.
Matt Kruse
David Mark
> On Sep 17, 11:17 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Sep 17, 11:20 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> > > On Sep 16, 8:38 pm, David Mark <dmark.cins...@gmail.com> wrote:
> > > > > However
> > > > > it's not the concern for most commercial entities.
> > > > Their concern is typically collecting money from as many people as
> > > > possible.
> > > s/possible/practical/
> > > See also: The law of diminishing returns.
> > And your deal is that any excuse is valid. [...]
>
> Nah, I just get tired of hearing the argument that the goal of web
> sites (especially those attempting to make a profit) is surely to get
> sales from every possible potential customer, and that is their only
> goal bar none. It's just a dumb argument.
>
Nobody said that. But it is dumb to knowingly deploy a script that
isn't even consistent across *IE* versions. Even dumber for these
"practical" Ajax sites to jarringly exclude all IE users who have
ActiveX disabled. And oh BTW, it fails in lots of other agents as
well. There's really no argument for such a thing. But then, that's
never stopped you.
S.T.
> Yahoo! is not a paragon of browser development. Last I saw, their
> marketshare was slipping so badly they had to do a deal with MS to
> survive. Whatever they are doing now, it's not working for them as
> well as what they were doing before.
>
> Maybe if they'd switched to jQuery they'd be back on top of Google.
Yahoo's doing fine as an overall entity, though yes... losing market
share in search (which is browser-neutral). They made $400mil last year
on revenues of $7B+. I'm fairly certain the decision to ignore certain
browsers wasn't made on a whim.
Google most-famously doesn't bother supporting Opera. Try creating a
Google doc spreadsheet with Opera and see what happens, or see the
latest GMail interface. Won't happen. The horror! Yet they manage to do ok.
>> Surfing traffic doesn't consider the sites as having failings. If a site
>> doesn't work on one browser but does on another - it's the browser's
>> fault. They'll switch soon enough.
>
> Yes, they'll switch sites very quickly and if it works better for
> them, that's where they'll stay.
So, you're suggesting some user downloads a new niche browser and finds
the sites they visit don't work as expected -- they're going to visit
other sites rather than ditch this new browser? Good luck with that.
>> The market penetration of JQuery alone is huge:http://trends.builtwith.com/javascript/JQuery
>
> Read the history of the rise and fall if IE 6. Maybe all browsers
> should just have emulated it and forgotten about innovation. Maybe all
> those Linux and Apple freaks should just ditch their niche machines
> and the whole world should run Windows. While we're at it, lets kill
> anything other than Vista or Win7, who cares about anyone who can't
> afford the latest and greatest PC and OS?
I think you're missing the point. IE6 (which was unbelievably
successful, by the way -- even though it's a pile of garbage) is the
reason things like 'Graded Browser Support' exist. Site developers are
no longer letting the browsers dictate the terms. It's a good thing.
> What was the WWW all about anyway? Glad we got rid of those bleeding
> heart lefties...
I see. You're viewing the WWW as some sort of grand social experiment.
Again, that's fair enough for the public sector. A huge chunk of the web
is commercial in nature though and their interest is profit, not sharing
content with all the world's citizens.
> [...]
>> Like it or not, content now controls standards.
>
> If content is king, development tools should aim to maximise access.
> Selecting tools that deliberately marginalise a measurable number of
> potential consumers is inconsistent with that logic.
The market is fairly rational. If it was more profitable to cater to a
lowest common denominator surfer the practice would be MUCH more
prevalent than is currently the case.
Gabriel Gilini
> On Sep 16, 8:38 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > However
> > > it's not the concern for most commercial entities.
> > Their concern is typically collecting money from as many people as
> > possible.
>
> s/possible/practical/
There, I fixed it for you.
The fact that developers are blindly telling their bosses that Safari
2, Konqueror, X, Y or Z are not used anymore, and that they'll be just
fine using the lib-of-the-moment does not automatically validates that
as the best alternative.
I'm sure that a great share of those using jQuery could improve their
reach - and therefore, their profit - with a small investment.
Matt Kruse
> The fact that developers are blindly telling their bosses that Safari
> 2, Konqueror, X, Y or Z are not used anymore, and that they'll be just
> fine using the lib-of-the-moment does not automatically validates that
> as the best alternative.
Agreed, but it also doesn't invalidate the option.
Personally, if I had a solution available to me that would not work in
Safari2 or Konqueror, it wouldn't matter to me at all. Others may have
different requirements, which is fine.
> I'm sure that a great share of those using jQuery could improve their
> reach - and therefore, their profit - with a small investment.
For some, certainly. For others, probably not.
It just depends on the situation. Which is why I would never blindly
recommend using jQuery (or Dojo, or Prototype, or YUI, or anything)
nor would I ever blindly recommend against it. It always depends.
Matt Kruse
Garrett Smith
> RobG wrote:
>
>> Yahoo! is not a paragon of browser development. Last I saw, their
>> marketshare was slipping so badly they had to do a deal with MS to
>> survive. Whatever they are doing now, it's not working for them as
>> well as what they were doing before.
>>
>> Maybe if they'd switched to jQuery they'd be back on top of Google.
>
> Yahoo's doing fine as an overall entity,
Yahoo is failing miserably.
though yes... losing market
> share in search (which is browser-neutral). They made $400mil last year
> on revenues of $7B+. I'm fairly certain the decision to ignore certain
> browsers wasn't made on a whim.
>
In a large company, decisions often take longer to make and mistakes
take even longer to rectify.
> Google most-famously doesn't bother supporting Opera.
Google's front-end code has significant problems with both internal
(source code) and external quality (the UX).
Try creating a
> Google doc spreadsheet with Opera and see what happens, or see the
> latest GMail interface. Won't happen. The horror! Yet they manage to do
> ok.
>
So what? Yahoo managed OK before Google.
You seem to be of the opinion that code quality does not matter.
Your opinion on the significance of code quality does not rank that highly.
Given an open and focused mind, one can learn plenty of interesting
things to learn about here.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
Matt Kruse
> So, you're suggesting some user downloads a new niche browser and finds
> the sites they visit don't work as expected -- they're going to visit
> other sites rather than ditch this new browser? Good luck with that.
Perhaps. Different things drive the market.
More people are browsing the web using mobile devices now, and they
will probably continue to do so even if the experience sucks. But they
just might change from one site to another if one doesn't work nicely
with their phone and another does. Eventually, this market may be
enough that it starts demanding the web support it. And at that point,
it will.
This may be the kind of environment shift that challenges the use of
scripts like jQuery, et al. And it may just grow to be enough to
either force a drop in jQuery use or force jQuery to change to
something more compatible. If this happens, I'm confident that there
will be other options that step up and become available. When and if
that becomes a concern for developers, they'll adapt.
That's the way it's always worked so far. How many people used
horrible MM_* functions for a long time? It fit their needs for a
time, then better options became practical, and people moved on. The
same will surely happen to jQuery, Dojo, Prototype, YUI, etc. It's
just a matter of when and what drives it.
Matt Kruse
Richard Cornford
> David Mark wrote:
>> Lets assume there is no Konquerer. That leaves n - 1 browsers
>> to support. Throw out whatever is embedded in his price checker
>> and you get n - 2. How many do jQuery (or GMail or whatever)
>> do well?
>
> You seem concerned about how many browsers a site supports. That
> may be a reasonable goal for a public service site to ask --
> though whitehouse.gov uses (and old version of) JQuery, so
> perhaps not. However it's not the concern for most commercial
> entities.
>
> Commercial sites are concerned about... well.. commercial
> interests. They care about user reach, not browser reach.
In what sense could the relationship - maximum browser support ==
maximum potential users/customers - not apply?
> Yahoo probably spells it out best:
> http://www.yuiblog.com/blog/2009/07/02/gbs-update-20090702/
Yahoo's browser grading notion is symptomatic of other factors. It
shouldn't be considered as factor in the early stages of a design
process when it just the consequence of a cause and effect relationship
that only applies following other factors (design decisions and other
considerations).
The problem with grouping browsers into such crude sets is that the
decision is based on the browser's ability to satisfy the most extreme
demand that could be made on the browser, without any consideration of
whether you are actually going to (or going to need to) demand that
thing from a browser. No real context makes every possible demand of the
browsers that use it; rather they make sets of specific requests and
demands that may range from the utterly mundane to the extreme.
Pretty much the lowest demand of a web browsers is that it be able to
receive an (un-styled) HTML document over HTTP(S) and present its
contents to the user in a viable way. Falling below that level would
result in the "browser's" right to be called a 'web browser' being
questioned.
At the lower end of scripted demands, there is client-side form
validation. A single particular formulation of code will successfully
achieve client-side form validation on every scriptable web browser that
has ever existed, and (because the facilities needed have been
standardised) will continue to work on every scriptable web browser that
can be foreseen. (This is minus some regular expression facilities, the
use of which in the validation would not be supported on the older
browsers.) So where client-side form validation is concerned every
scriptable web browser is a "grade A" browser (at lest if you set about
the validation in the correct way).
Looking towards the upper end of scripted demands you might pick on
things like animation, but that does not really qualify. If you wanted
to animate the movement of an absolutely positioned element from one
point to another then Netscape 4 could do that, and the (generally very
non-dynamic) Opera 6 could achieve it using code that would produce the
same effect on every dynamic desktop browser that has existed since. You
might look to DOM manipulation, say the sorting of the rows in a table
by appending them to a TBODY in particular order. Opera 6 could never
achieve that, but Opera 7 could, and again using code that would work
identically on every dynamic desktop browser that has existed since.
A better extreme requirement might be 'contentEditable' and its
equivalents. If you want users to be able to enter text with all the
facilities of a word processor (the ability to Bold, Italic, Underline
text, choose font faces and sizes, etc.) then only a relatively small
set of browsers could facilitate that.
So there is a discrimination between the browsers that can satisfy the
demands you make of them and the ones that cannot, but which browsers
will fall on each side of that discrimination will depend on the demands
made in any particular context, and vary from context to context. This
makes any general a priori grading of browsers irrational. The demands
of context may produce such a 'grading', and Yahoo have such a context,
but that does not mean that the outcome from one context should even be
considered in any other. The attempt to do so becomes more of an excuse
than anything else; an attempt to justify something that could not be
justified by any other means.
The true generality of Yahoo's browser grading list is highlighted by
the presence of IE 6 in the list. IE 6 is not in the same class as any
other browser in the list of "Grade A" browser; it is more in the class
of Opera 7 and Mozilla 1.0 (capable but not really up to date). We all
know why IE 6 is in that list; it is simple commercial expedience. But
the fact that it is in the list at all highlights the truth that the
'grading' is a consequence of Yahoo's particular context (and their
appreciation of the reality of their context). And while IE 6 support
may be a significant factor in nearly everyone else's contexts its
presence in Yahoo's context-driven list should be an indicator that
others should be deriving their own lists from their own contexts.
The appal(s) of such browser grading lists (from 'major' sources) are
fairly obvious; they can be held up as justifications for situations
that pertain as the consequences of other factors. Consider, for
example, any large (or large-ish) scale interdependent
library/framework. Such code will make a range of demands on the
browsers that are going to support it, and so it becomes the most
extreme demand made that becomes the constraining factor on its possible
browser support list. This is a consequence of interdependence, and if
seen in isolation might result in the questioning of the need for/value
of that interdependence. Indeed it may result in such interdependence
being seen as a poor design decision that needlessly results in
arbitrarily restricted browser support and so suggest a more granular
and modular approach to the design of such code. On the other hand,
waving someone else's very restricted browser support list in the air
might be enough to distract attention from what might otherwise be
perceived as poor fundamental design decisions.
A concrete example of an extreme outcome might be a website that needs
nothing more that some client-side form validation. As I have said, it
is possible (indeed, trivial, if you know how) to write such code so
that it works fine on every scriptable web browser that has ever
existed. Then there is no notion of restricting browser support. On the
other hand, there are people who would do that validation by importing
JQuery and a validation plug-in, and so instantly inherit all the
browser support limitations of JQuery. It would be quite reasonable for
a client to question the consequential restrictions in browser support,
and the people responsible cannot (honestly) argue need or cost as a
justification, but they can hold up someone else's browser support list
and say "if it is good enough for them ...".
Of course, in reality the clients usually don't question the browser
support they end up with, because if they knew the subject for
themselves they would not be employing others to do the work for them,
and it works fine on the "grade A" browser they use. Instead the client
relies of the professionalism of the people they employ to do their web
site creation work to properly take the pertinent considerations into
account, which makes it unfortunate if those 'professionals' are using
spurious justifications for not achieving what they could.
>> The point is that these failings are symptoms and likely to get
>> worse with each browser produced. Dismissing them in turn is
>> wishful thinking.
>>
>> The current failings of other sites, whatever script(s) they
>> may use, don't enter into it.
>
> Surfing traffic doesn't consider the sites as having
> failings.
Is "surfing traffic" (whatever that is supposed to be) something that is
capable of "considering"? It is individuals who adopt attitudes toward
the web sites they visit.
> If a site doesn't work on one browser
... the potential customer is off to find another site that does.
That is what I do. If I am trying to buy something then that is all I am
trying to do. I will not be stopping to switch browsers,
update/download/install plug-ins, modify browser configurations or even
to provide feedback for the owners of the sites that don't work. The
site that does want my business (the one that works with the browser) is
possibly the next one listed in the search engine output, and that is
where I will be going next.
Someone just lost my business to one of his or her competitors, and they
are never going to know that has happened. And the last time that
happened was yesterday; two websites decided that they did not want to
take 500 pounds off me, a third was happy to.
> but does on another - it's the browser's fault.
No it isn't. Generally if a site does not work with one browser it is
because someone responsible for that site had based design decisions on
unfounded assumptions.
> They'll switch soon enough.
No they won't. Some may, but many will look elsewhere on the Internet
for a site that does work, and many will have no control over (or
perceive themselves as having no control over) the browser they use and
so cannot switch. It is a common mistake of web developers to project
their own abilities/perceptions onto the general public. It is that
error that results in the showing of messages such as "This site
requires javascript ... ", with its failure to appreciate that most of
the population of the planet don't know what javascript is, and wouldn't
care less if told. Most people are not IT specialists, let alone web
developers.
> The market penetration of JQuery alone is huge:
> http://trends.builtwith.com/javascript/JQuery
>
> Tie in various Google and Yahoo properties, along with all the
> others that use a similar design, development and testing
> criteria, and a huge chunk of the sites out there have set
> the standard for browsers to follow.
Web browser manufacturers do accommodate common practices, for reasons
of expedience, but that is hardly a positive judgement on those
practices.
Consider the case of gathering sets of DOM elements using CSS style
selectors. Done with javascript code that can be quite an involved
process that can then be relatively slow. So slow in fact that it takes
a certain level of capabilities in hardware before it could become
practical/viable at all. Observing that people are going to be doing
that anyway a browser manufacturer may perceive a significant benefit in
terms of the perceived performance of their browser if they provide a
native code method to do the hard work for the javascript. The browser
providing such a method is not a judgment on the use of CSS selectors to
retrieve sets of DOM Elements, it is just a reaction to it.
> A new browser is welcome
> to join the mix but if it's user base finds it has to use an
> old, awkward Yahoo Mail UI, ESPN and Amazon don't work as
> expected cause of JQuery and Google Reader won't function at
> all -- it's not going to have much of a user base anyways.
Consider the browser on the Blackberry; is there an alternative (better)
browser that can be installed on the hardware, and even if so, do the
users know about it, or how to install it? Or is the user base of the
browser tied to the user base of the hardware?
> Like it or not, content now controls standards.
That is meaningless.
Richard.
S.T.
> On Sep 17, 12:45 pm, "S.T." <a...@anon.com> wrote:
>> So, you're suggesting some user downloads a new niche browser and finds
>> the sites they visit don't work as expected -- they're going to visit
>> other sites rather than ditch this new browser? Good luck with that.
>
> Perhaps. Different things drive the market.
>
> More people are browsing the web using mobile devices now, and they
> will probably continue to do so even if the experience sucks. But they
> just might change from one site to another if one doesn't work nicely
> with their phone and another does. Eventually, this market may be
> enough that it starts demanding the web support it. And at that point,
> it will.
Mobile *could* alter the landscape. To date the impact of mobile I've
seen has been trivial, albeit a small sample size (my sites). Aside from
minimal traffic, the referrers make it pretty clear most mobile users
are surfing for reference and research -- not so much transactions. I'm
all for letting reference-seekers access our site, but no way I'll be
retooling a site for this traffic at the possible expense of my
transaction-likely traffic (whether that means 'dumbing-down' a page, or
slowing down overall development).
When mobile browsing does become more commercially relevant I suspect
we'll see more mobile versions of websites rather than single websites
trying to accommodate both. That'll be my approach, at least. Nearly all
the content is databased already -- just need to output it in a manner
geared towards mobile devices, and have an economic motive to spend the
resources to do so. I suspect client-side scripting will be used
sparingly on mobile websites for a long time to come as well.
> This may be the kind of environment shift that challenges the use of
> scripts like jQuery, et al. And it may just grow to be enough to
> either force a drop in jQuery use or force jQuery to change to
> something more compatible. If this happens, I'm confident that there
> will be other options that step up and become available. When and if
> that becomes a concern for developers, they'll adapt.
Fair point. I think we're seeing some of that effect already. The JQuery
team announced v1.4 will include a build that caters to iPhone, Android,
Palm Pre and Fennec devices. I'm sure the other libraries have similar
goals (or have already done so). Perhaps some new library, wide of small
in scope, will emerge that serves this market best.
> That's the way it's always worked so far. How many people used
> horrible MM_* functions for a long time? It fit their needs for a
> time, then better options became practical, and people moved on. The
> same will surely happen to jQuery, Dojo, Prototype, YUI, etc. It's
> just a matter of when and what drives it.
I'd agree all the present libraries will eventually fade. However they
will fade because a new option comes along that provides greater utility
-- they won't disappear because the development community concludes they
must support 99.99% of all users as a basis for their business model.
Maybe better libraries evolve. Maybe browsers add more built-in
functionality that removes library's current advantages. However the
most vocal in this newsgroup keep pushing the mantra it's best to do all
scripting from scratch, and presumably cater towards and test versus an
absurd number of browsers and OS's. That will never happen on a
wide-scale in the present state of Javascript. No fiscal reason to do so.
S.T.
> S.T. wrote:
>> Commercial sites are concerned about... well.. commercial
>> interests. They care about user reach, not browser reach.
>
> In what sense could the relationship - maximum browser support ==
> maximum potential users/customers - not apply?
The same reason I can't go to a restaurant down the street and get a
copy of the menu in German, Italian, Chinese, Russian or French.
I can get the menu in English -- that's expected. Where I live there is
a significant population with Spanish as their first or only language,
and many restaurants will offer a Spanish version of their menu as a
result. I'd guess perhaps 30%-40% offer both languages.
There is also a healthy population of diverse immigrants and plenty of
international tourists to the area at any given time. Yet no such luck
for menus in any of their native tongues.
Could a restaurant reproduce their menus in a wide range of languages?
Sure they could.
Would any customers use these menus? Sure, now and then.
Would it cost much to have the menus translated? Not really. $15-$20
per translation via a Craigslist post. Hell, they could probably use an
online translation service and have a modestly useful translation done
for nothing more than the cost of time and a few sheets of paper.
Would a wide range of translated menus expand their potential customer
base? Yes, in theory. Couldn't hurt in any case.
Is there enough economic incentive to spend the time and/or resources to
offer these translations? Nope, there is not. Resources are finite and
utilized where they'll provide the greatest benefit. Trying to reach
every potential customer is not such a case.
The rest of your post looks pretty in-depth. I'll try and get through it
at a late point.
David Mark
[snip]
> Maybe better libraries evolve. Maybe browsers add more built-in
> functionality that removes library's current advantages. However the
> most vocal in this newsgroup keep pushing the mantra it's best to do all
> scripting from scratch,
Nobody, but nobody in this group has ever advocated such a thing.
> and presumably cater towards and test versus an
> absurd number of browsers and OS's. That will never happen on a
> wide-scale in the present state of Javascript. No fiscal reason to do so.
I still don't know what you are talking about. Is this some excuse to
use jQuery? With that script, it's not about backward of forward
compatibility, but current bugs in major browsers (and constant
rewrites to combat them). And what does it do when it blows up in
environments unknown (and presumably untested) anyway? Nobody really
knows and there's no way for the calling script to tell. Fair bet it
will leave the document in an unusable state. In that case, you'd
have been better off staying home on the JS front. ;)
Matt Kruse
> On Sep 17, 4:10 pm, "S.T." <a...@anon.com> wrote:
> > most vocal in this newsgroup keep pushing the mantra it's best to do all
> > scripting from scratch,
> Nobody, but nobody in this group has ever advocated such a thing.
Don't be obtuse. This point is repeated often: Write your own code,
build your own library of functions, and reuse them.
Since there has never been a library or set of code that is
recommended here as a starting point for most common tasks (despite
Peter's attempt), it is only reasonable to conclude that no such code
exists, and the preferred approach is to write code from scratch.
> I still don't know what you are talking about. Is this some excuse to
> use jQuery? With that script, it's not about backward of forward
> compatibility, but current bugs in major browsers (and constant
> rewrites to combat them).
If the functionality you use doesn't trigger those bugs, then it's a
moot point.
> And what does it do when it blows up in
> environments unknown (and presumably untested) anyway? Nobody really
> knows and there's no way for the calling script to tell.
If your environment is known to be supported, or if the number of
unsupported users is below your threshold of concern, then if it blows
up you wouldn't really care, would you? One of those two situations is
a prerequisite for using jQuery, IMO.
Matt Kruse
Thomas 'PointedEars' Lahn
> On Sep 17, 3:42 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> On Sep 17, 4:10 pm, "S.T." <a...@anon.com> wrote:
>>> most vocal in this newsgroup keep pushing the mantra it's best to do all
>>> scripting from scratch,
>> Nobody, but nobody in this group has ever advocated such a thing.
>
> Don't be obtuse. This point is repeated often: Write your own code,
> build your own library of functions, and reuse them.
>
> Since there has never been a library or set of code that is
> recommended here as a starting point for most common tasks (despite
> Peter's attempt), it is only reasonable to conclude that no such code
> exists, and the preferred approach is to write code from scratch.
No, the preferred approach is to make an informed assessment of the quality
of existing snippets of code, copy-pasting them where allowed, rewriting
them where necessary, instead of including a 50K blob without knowing what
one (and it) is really doing.
You have been told this several times, in fact ad nauseam, before.
Repeating this nonsensical argument of yours over and over again does
not make it any more valid or helpful; it just shows your ongoing
short-sightedness, and the dangerous degree of dependency that you have
developed to the tool(s) that you once decided to use (when you were
uninformed enough not to see an alternative), and that you are continuing to
use despite their obvious (and ad nauseam pointed out) shortcomings (jQuery
& friends).
IOW: You are deliberately advocating junk code/coding and hope nobody will
notice that (despite sufficient evidence to the contrary in the past).
Go away.
>> I still don't know what you are talking about. Is this some excuse to
>> use jQuery? With that script, it's not about backward of forward
>> compatibility, but current bugs in major browsers (and constant
>> rewrites to combat them).
>
> If the functionality you use doesn't trigger those bugs, then it's a
> moot point.
But it *does* trigger the bugs; does attr() ring a bell?
Eric Bednarz
> You seem concerned about how many browsers a site supports.
It may be foolish to think that you can just code according to rules and
have it work, but it is at least as foolish to think that you can safely
code for some specific browsers; all you can do is test that it works in
a very limited amount of installations/configurations of your end.
> Commercial sites are concerned about... well.. commercial
> interests. They care about user reach, not browser reach.
Ah. I remember *the* big 3-letter transport corporation over here
looking for developers who could make their booking system work in IE
5.0 about one and a half year ago.
> Yahoo probably spells it out best:
> http://www.yuiblog.com/blog/2009/07/02/gbs-update-20090702/
All this spells out is that the amount of browser scripting
generalization is inversely proportional to its compatibility.
(I remember how excited Resig was about this A-grade stuff coming from a
big player in his first book. Almost like mom saying that it is okay to
watch porn on the internets. :-)
Matt Kruse
wrote:
> No, the preferred approach is to make an informed assessment of the quality
> of existing snippets of code, copy-pasting them where allowed
Which existing snippets of code do you feel are worthy of being copied
and used? If this strategy is to be used, surely you have a set of
public-domain code snippets that a developer should start with, no?
>, rewriting
> them where necessary, instead of including a 50K blob without knowing what
> one (and it) is really doing.
I sometimes use jQuery, rewriting it when necessary. It seems like I
am in fact using your strategy. You just disagree with the specifics.
> > If the functionality you use doesn't trigger those bugs, then it's a
> > moot point.
> But it *does* trigger the bugs; does attr() ring a bell?
Of course attr() has some problems.
In some cases.
Avoid those cases.
Matt Kruse
David Mark
> On Sep 17, 4:14 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>
> > No, the preferred approach is to make an informed assessment of the quality
> > of existing snippets of code, copy-pasting them where allowed
>
> Which existing snippets of code do you feel are worthy of being copied
> and used? If this strategy is to be used, surely you have a set of
> public-domain code snippets that a developer should start with, no?
No, you are just angling for some public domain treasure trove of JS
that doesn't exist. Why don't you start with your own? If your
answer is that you don't have any...
>
> >, rewriting
> > them where necessary, instead of including a 50K blob without knowing what
> > one (and it) is really doing.
>
> I sometimes use jQuery, rewriting it when necessary. It seems like I
> am in fact using your strategy. You just disagree with the specifics.
No, that's the worst of both worlds.
>
> > > If the functionality you use doesn't trigger those bugs, then it's a
> > > moot point.
> > But it *does* trigger the bugs; does attr() ring a bell?
>
> Of course attr() has some problems.
Odd it is used in almost every example out there. I still don't think
it simplifies setting properties. :)
> In some cases.
> Avoid those cases.
Which cases and how is that of course? For jQuery, the cases are
different from one browser (or jQuery) version to the next.
Matt Kruse
> On Sep 17, 5:25 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> > Which existing snippets of code do you feel are worthy of being copied
> > and used? If this strategy is to be used, surely you have a set of
> > public-domain code snippets that a developer should start with, no?
> No, you are just angling for some public domain treasure trove of JS
> that doesn't exist. Why don't you start with your own? If your
> answer is that you don't have any...
The argument goes like this:
a) If I don't use a library, don't I have to write everything from
scratch?
b) No, of course not! Start with existing quality code, and modify and
build on it.
a) Which code should I start with?
b) You're just angling for a treasure trove of js!!!!!!
I, myself, personally, am not looking for anything.
But thinking as someone who is trying to follow the strategy that Mr.
Lahn recommends, then I would want to know where to find this code to
copy from that he says exists somewhere. Because that's the basis of
his strategy, after all. Without it, the developer must write
everything from scratch, and of course no one here recommends that,
right?
If no obvious example of code that should be copied exists, then I
call bullshit on the whole argument.
And if the code is too hard to find, or if "you should already know
where it is" then I call bullshit again, because someone looking for
code to start with surely is not going to scour the web looking for
the code that the experts say is copy-worthy. They are going to start
with a library that has a huge following and appears to be the most
commonly-accepted solution. And they will arrive at jQuery!
The point - unless you can show that your strategy of building a
library of code based on finding and modifying quality snippets is
feasible, then what good is it?
> > Of course attr() has some problems.
> Odd it is used in almost every example out there. I still don't think
> it simplifies setting properties. :)
Nor do I, obviously. It is an entirely useless method, and it is
unfortunate that it's used internally.
> [...]
Matt Kruse
RobG
[...]
> The market is fairly rational.
Getting off-topic here, but that statement is completely wrong. If
"markets" were rational, we wouldn't have had the global financial
crisis. They are demonstrably *not* rational[1]. If markets were
rational, you could predict with almost complete certainty how they
will behave, the fact that no-one has yet done that is a pretty clear
indication that they aren't.
And even if they were, it doesn't prove anything about development
tool choices.
> If it was more profitable to cater to a
> lowest common denominator surfer the practice would be MUCH more
> prevalent than is currently the case.
The point is that by simply selecting popular library X *because* it's
popluar, a reasonable number of potential visitors are
disenfranchised. It doesn't necessarily cost anything to support them.
For example, the BuiltWith site that you referenced earlier has a home
page with a single input field and a button. By choosing to implement
it using javascript rather than a simple form, they are imposing a
requirement that visitors have a browser supported by jQuery 1.2.6 and
stuff built with it.
No doubt in the near future someone will days "hey, version 1.3.2 is
out, we'd better upgrade". And since there are some significant
changes between the two, it will take another round of development and
testing, more time and money, and support even fewer browsers than it
did before.
For what? To support something that should have used an extremely
simple form that nearly any browser since Netscape 1.0 could have
used.
1. The Myth Of the Rational Market
<URL: http://www.time.com/time/magazine/article/0,9171,1904153,00.html
>
Rational Market Theory Takes Another Beating
<URL: http://mooreslore.corante.com/archives/2004/12/02/rational_market_theory_takes_another_beating.php>
Just Google "rational market", nearly all the hits are why it
*isn't* rational.
--
Rob
Gregor Kofler
> The market penetration of JQuery alone is huge:
> http://trends.builtwith.com/javascript/JQuery
Huh, impressive what they can analyze today. Apart from that: Those
figures are of course utter bullshit, but there are obviously enough
dimwits out there who buy into such "statistics".
Gregor
--
http://www.gregorkofler.com
http://web.gregorkofler.com - vxJS, a JS lib in progress
Richard Cornford
You are describing a situation where the return form maximising
potential restaurant customers is (possibly) insufficient to justify the
effort of doing so. That may be true but it says nothing to answer my
question.
The relationship - maximum browser support == maximum potential
users/customers - is still obviously true. All you are doing is raising
the cost/benefit consideration in maximising potential users/customs.
That is a consideration, but remember that any browser that can present
an HTML document and submit forms using HTTP(S) POST requests (so pretty
much anything that has any right to be called a web browser in the first
place) can be used in exchanging services/products for a customer's
money. So we are not starting from a position of supporting one piece of
software and making an effort to add more, but rather a position where
every time a browser is excluded from any supported list that is the
consequence of a design decision (a decision to move away form a design
that would work for everyone).
My concern is the extent to which these design decision are being made
on an informed basis, and whether they are being made by the correct
people. Much of the time it feels like the decision to limit browser
support to less than half a dozen popular desktop web browsers was no
more than the consequence of the person who did it not knowing how to do
anything else, that the costs of the alternatives are being estimated by
people who could not produce them (so don't actually know what is
involved), and that the people who will have to live with the financial
fall-out of these decisions don't even realise what has happened, and so
never could have ratified those decisions.
Richard.