«

Richard Cornford wrote:

......

> Which explains you log statistics, you design for a limited set of
> browsers/configurations, the users of other browsers/configurations
> don't hang around clocking up log entries (because they rapidly realise
> they are wasting their time), and then you use the log entries to
> justify designing for the browsers that your visitors appear to use.
> It's a chicken and egg relationship that becomes a vicious circle.

I think actually they specify their desires against a larger
set of statistics. In practice they're doing 90-10% rules of thumb. The first
90% takes half the total development. Somewhere along the path to 100% browser
acceptance is a cut-off point where the additional work cannot be justified.

If a big client rings up our end user saying that something's amiss with his MAC
IE 5.2 then we fix it.
.....

>
> Cross-browser scripts do not have to be complex. Indeed K.I.S.S. is a
> very worthwhile design principle to follow.
>

I agree totally, but their complexity is in the knowledge base that I or any one
else needs to have to get 90, 95 or 100% usability. If I look at any of the web
sites devoted to listing the foibles of the various browsers there are probably
thousands of differences. That is complexity.

> The economic relationship is not being meaningfully judged. It is always
> going to be relatively expensive to employ someone who doesn't know how

No matter who is employed to do web programming there will be bugs. The cost of
an expert such as yourself may not be low enough to justify the additional 4% of
browsers that might be supportable. The testing costs alone of supporting an
additional 30 browsers would be considerable.

The mechanic argument is relevant. Average cars are now a job for specialists only.

>
> Differentiation is not in the interests of JS programmers; we are not
> masochists. We are working without the certainty of a known environment,

I believe earlier you said that companies should employ best qualified people.
You assert as well that we can support cleanly all browsers. The conclusion is
obvious. Differentiation certainly benefits expert js programmers. I assume they
are masochists only if they really believe it's desirable to support 30-50
platforms.

>
> Richard.
>
>


--
Robin Becker

Robin Becker wrote:
> Richard Cornford wrote:
<snip>
>> Which explains you log statistics, you design for a limited set of
>> browsers/configurations, the users of other browsers/configurations
>> don't hang around clocking up log entries (because they rapidly
>> realise they are wasting their time), and then you use the log
>> entries to justify designing for the browsers that your visitors
>> appear to use. It's a chicken and egg relationship that becomes a
>> vicious circle.
>
> I think actually they specify their desires against a larger
> set of statistics. In practice they're doing 90-10% rules of thumb.
> The first 90% takes half the total development. Somewhere along the
> path to 100% browser acceptance is a cut-off point where the
> additional work cannot be justified.
>
> If a big client rings up our end user saying that something's amiss
> with his MAC IE 5.2 then we fix it.

And the big potential client using Mac IE 5.2 (or Safari)? Doesn't
he/she go and look elsewhere?

>> Cross-browser scripts do not have to be complex. Indeed K.I.S.S. is a
>> very worthwhile design principle to follow.
>>
>
> I agree totally, but their complexity is in the knowledge base that I
> or any one else needs to have to get 90, 95 or 100% usability. If I
> look at any of the web sites devoted to listing the foibles of the
> various browsers there are probably thousands of differences. That is
> complexity.

You are looking at the details and missing the design issue. For any
script there are just two possibilities, the browser fully supports the
features required by the script, or it doesn't (with all javascript
incapable browsers falling into the latter category). To support 100% of
browsers (without even knowing anything about all of those browsers) it
is only necessary to design the HTML so it makes sense when the script
fails and write the script so the it detects the availability of the
features that it needs prior to attempting to use them and only acts
when they have been verified as being available.

That simple design pattern covers 100% of browsers from the outset, the
work is in maximising the number of browsers that fall into the
supporting category for each individual script. But now it doesn't
matter if script development cannot push that past 90% of javascript
capable browsers because the remaining 10% are still supported by the
site (along with all javascript incapable browsers) as the underlying
HTML makes sense without the script.

>> The economic relationship is not being meaningfully judged. It is
>> always going to be relatively expensive to employ someone who
>> doesn't know how
>
> No matter who is employed to do web programming there will be bugs.
> The cost of
> an expert such as yourself may not be low enough to justify the
> additional 4% of browsers that might be supportable.

Where does 4% come form? The most often quoted figure for javascript
disabled/incapable browsers is 8-12% (so the javascript capable browsers
that lack the required features would be on top of that).

And it would be a mistake to assume that any expertise in browser
scripting carries a premium, it doesn't. Most of the IT world regard
javascript as a toy language that any fool can write (and are usually
happy to assign the task to the nearest fool available, with the
consequences that we observe on the Internet).

But the numbers game is a little more complex than just getting back the
potential customers lost through failing to support their browsers. Lets
say that is 5%, and lets say that 20 competitors are doing the same and
turning away 5% of their potential customers as well (and they are). Now
the first of those sites to welcome all customers regardless of their
browser is not just regaining the 5% they had been turning away but is
potentially picking up the 5% that each of those competitors is still
turning away (5*20 == 100).

Coincidentally, I have just been reading an article reporting a
£50,000.00 out of court settlement of a case brought using the UK
disability discrimination act against a web site for denying access to
its services to the users of the types of browsers/browser
configurations favoured by some groups covered by that act.

> The testing costs alone of supporting an
> additional 30 browsers would be considerable.
>
> The mechanic argument is relevant. Average cars are now a job for
> specialists only.

Which is why it makes sense to hire a suitable specialist to do the job.

>> Differentiation is not in the interests of JS programmers; we are not
>> masochists. We are working without the certainty of a known
>> environment,
>
> I believe earlier you said that companies should employ best
> qualified people.

Suitably qualified will do.

> You assert as well that we can support cleanly all browsers.

Absolutely.

> The conclusion is obvious. Differentiation certainly
> benefits expert js programmers.

Differentiation might necessitate browser scripting expertise, but you
won't find many javascript programmers who wouldn't have preferred
complete standardisation of browsers from the outset. Unfortunately we
have to deal with the world as it is rather than as we would like it to
be, and at lest the resulting design challenge is a worthy application
for the intellect.

> I assume they are masochists only if they really believe
> it's desirable to support 30-50 platforms.

There are something in the order of 130 existing web browsers, and new
ones all the time.

Richard.

"Richard Cornford" <> wrote:
> That simple design pattern covers 100% of browsers from the outset, the
> work is in maximising the number of browsers that fall into the
> supporting category for each individual script. But now it doesn't
> matter if script development cannot push that past 90% of javascript
> capable browsers because the remaining 10% are still supported by the
> site (along with all javascript incapable browsers) as the underlying
> HTML makes sense without the script.

Richard, you write novels on this group every day, but I've never seen
real-world examples of your work, or a web site of the libraries you've
written, or anything. Do you have anything?

I mean, if you actually have time to write all the stuff you do here every
day, and create great reusable code to the standards you push, and put that
into practice in a real-world setting with a project manager hounding you
and clients making ridiculous requests, then more power to you. I'd like to
see the results. I mean, is it all talk and wishful thinking, or do you
actually manage to practice what you preach? The real world is not always as
ideal as you make it sound

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/

optimistx wrote:
> What about this strategy:
>
> Project1. Construct the application with pure html, no
> javascript. Cost is C1, calendar time T1
>
> Project2. When the project P1 has been completed, everything
> is working well, customers are satisfied, boss is happy,
> make a new proposal to the management .
>
> Probaly cost C2 is about the same order of magnitude as
> C1, and the duration T2 about the same as T1.

You haven't actually stated what Project 2 is, which makes judging what
it would cost and how long it would take extremely speculative.

If it is a complete replacement for Project 1 then it probably will cost
much the same (aided only by the fact that the back-end programmers will
be able to lift most of the logic directly from Project 1). But that
also renders much of the cost of Project 1 wasted.

If it is a layering of client-side scripting over Project 1 then there
is no reason to expect it to be nearly as expensive or time consuming.
Granted if your proposed design strategy is to be taken literally and
Project 1 has been implemented with no consideration of it's suitability
for client-side manipulation the results will be more expensive and time
consuming than they need to be.

The best of both worlds would be most effectively achieved by planning
for the layering of client-side scripting over a 100% reliable
server-side fall-back from the outset, but then you don't have two
projects any more, and most of the design work for what was project 2
now happens in parallel with the designing of the back-end.

Or were you thinking in terms of that stupid "lets deal with disabled
users by having two web sites, one with the full presentation and a text
only version for anyone who can't use the first", with its consequent
ongoing maintenance burden, and the eventual divergence of the content
as the text version gets a low priority and is eventually forgotten.

> Which advantages can I show to the management in order to
> persuade to accept project P2?
>
> a) some seconds in access speeds sometimes ? (when
> checking form input, mainly).

If that is the only client-side functionality then your cost estimate is
way over the top. At this stage the validation algorithms have been
specified and Project 1 already contains a reference implementation (and
if the back-end was in JScript ASP the validation can virtually be cut
and pasted into the client-side).

> b) some frills, whistles, bells, which are completely
> unnecessary and even annoying for a serious customer?
<snip>

A strange thing with management (especially marketing management) is
that they are the ones who wanted those bells and whistles in the first
place.

In practice any new project will probably start form the position of an
existing site that is already dependent on a limited range of javascript
capable browsers, and has no shortage of bells and whistles that
somebody in the decision making process thought were a good idea. If
they are going to fund a replacement they are going to want it to be
just as capable as its predecessor was.

So the question is, can a replacement be designed that exploits the
capabilities of the browsers that the old version directly supported to
the same (or greater) extent and still be 100% usable and reliable for
the users of any other browsers browser (or unusual configuration of
those browsers)?

And the answer is yes, they can have just as much dynamic front end
stuff on at least as many browsers as it ever worked with, and they can
have 100% reliability for all through back-end fall-back, and they can
have it all in the same site. With the resulting maximised customer base
(and potential to avoid falling foul of national accessibility
legislation, where applicable).

Richard.

Matt Kruse wrote:
<snip>
> Richard, you write novels on this group every day,

The hour a day for two months I spent training myself to touch type has
proved one of the most productive things I have ever done over the
intervening years.

But are you complaining? What sort of discussion form would c.l.j. be if
everyone followed your example and contributed no more than references
to dubious javascript libraries? That is hardly going to contribute to
anyone's understanding and skills, a more universally functional
Internet, or the already tarnished reputation of javascript.

> but I've never seen
> real-world examples of your work,

If you are failing to find examples of scripts written by me that
demonstrate the application of the principles under discussion here then
I don't think you can be trying very hard.

> or a web site of the libraries you've
> written, or anything.

Didn't I write one of those novels explaining to you why libraries are
in inappropriate concept for Internet browser scripting?

> Do you have anything?

In what sense?

> I mean, if you actually have time to write all the stuff you do here
> every day, and create great reusable code to the standards you push,
> and put that into practice in a real-world setting with a project
> manager hounding you and clients making ridiculous requests, then
> more power to you. I'd like to see the results. I mean, is it all
> talk and wishful thinking, or do you actually manage to practice what
> you preach? The real world is not always as ideal as you make it
> sound

Why do you think that would have any baring? It either is possible to
create scripts that match their execution to the browser's ability to
support them, and cleanly degrade to viable underlying HTML when not
supported, avoiding introducing a dependency on client-side scripting
into a system that is otherwise 100% reliable, or it is not.

As it has been demonstrated that it in fact is possible to create
scripts to that standard it makes sense that this group should promote
that standard and disseminate an understanding of the techniques needed
to achieve it. Particularly baring in mind that on the occasions that a
particular proposed action is identified as not amenable to satisfactory
clean degradation the javascript dependent alternatives are always
demonstrably worse, as anyone viewing any page employing any of your
libraries with a javascript disabled browsers would rapidly discover.

Richard.

Richard Cornford wrote:
I don't think we have to reply!


--
Robin Becker

"Richard Cornford" <> wrote:
> But are you complaining? What sort of discussion form would c.l.j. be if
> everyone followed your example and contributed no more than references
> to dubious javascript libraries?

Dubious? Any specific criticisms are welcome.

There are various types of discussions on this group. One type is "Is there
a solution for X?" in which case I post my solution if I have one. My code
is fairly well-tested by thousands of users, and I get many thanks from
users of this group for directing them to a solution they can immediately
implement with success, rather than preaching about why they shouldn't be
doing what they need to do.

> That is hardly going to contribute to
> anyone's understanding and skills, a more universally functional
> Internet, or the already tarnished reputation of javascript.

I disagree. There is a lot to be learned by using and inspecting pre-written
libraries which solve the exact problem you are facing.

> If you are failing to find examples of scripts written by me that
> demonstrate the application of the principles under discussion here then
> I don't think you can be trying very hard.

A search for "Richard Cornford" +javascript returns few results
And IMO, snippets of example code are useful and great for discussing the
finer points of the language and its use, but they aren't solutions.
Writing small snippets to do very specific low-level tasks is one thing, but
writing solutions which solve real problems on real web sites using a wide
range of browsers and supporting features that would be needed by a wide
range of users is quite another.

In many cases, the "right way to do things" simply doesn't work in
real-world situations, because of browser bugs and quirks, or because it's
not generalized enough to be widely useful.

> Didn't I write one of those novels explaining to you why libraries are
> in inappropriate concept for Internet browser scripting?

Yes, and I still think you represent about 2% of javascript developers with
that opinion

> > Do you have anything?
> In what sense?

An example. A finished product. I'm not being facetious. I've learned from
your posts and your articles, and I would find it interesting to see a
finished site which degraded nicely for all browsers and implemented complex
functionality in the ways that you recommend. Or multiple sites.

> It either is possible to
> create scripts that match their execution to the browser's ability to
> support them, and cleanly degrade to viable underlying HTML when not
> supported, avoiding introducing a dependency on client-side scripting
> into a system that is otherwise 100% reliable, or it is not.

And in any given situation, it's either worth the effort, or it is not.
Just because something can be done perfectly doesn't mean it justifies the
time or expense to do so. The 80/20 rule.
If everyone waited for perfect solutions before releasing software, we would
never have any software!

> As it has been demonstrated that it in fact is possible to create
> scripts to that standard it makes sense that this group should promote
> that standard and disseminate an understanding of the techniques needed
> to achieve it.

I think it's always best to promote the best solution to any given problem.
But a bunch of "code-perfect" snippets still require subtantial effort and
knowledge to assemble into a working solution. If someone comes here with a
question about how to achieve X, we can either point out 25 ways to code
correctly and write clean code which degrades perfectly and leave them with
nothing but pieces to glue together, or we can offer them a packaged
solution which will solve their problem in 10 minutes with 5 lines of code.
I prefer the latter, which they can dig into and learn from.

> Particularly baring in mind that on the occasions that a
> particular proposed action is identified as not amenable to satisfactory
> clean degradation the javascript dependent alternatives are always
> demonstrably worse, as anyone viewing any page employing any of your
> libraries with a javascript disabled browsers would rapidly discover.

Anyone viewing my pages containing _javascript libraries_ without javascript
enabled is surely missing the point, and I don't care if the page is broken
for them. I have a limited amount of time in my day, and I can't cater to
everyone, nor do I try

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/

On Thu, 15 Apr 2004 20:12:22 +0300, "optimistx"
<> wrote:

>Project1. Construct the application with pure html, no javascript. Cost is
>C1, calendar time T1
>
>Project2. When the project P1 has been completed, everything is working
>well, customers are satisfied, boss is happy,
>make a new proposal to the management .
>
>Probaly cost C2 is about the same order of magnitude as C1, and the duration
>T2 about the same as T1.
>
>Which advantages can I show to the management in order to persuade to accept
>project P2?

User experience, get the management out of the office (or use their
GPRS connection or something back to the system, and they'll see how
long each page navigation takes, see how long each stupid mistake on a
form takes, and how much server resources are used (make sure you do
it on a roaming GPRS at 10 GBP per MB)

Get some test users in - the tea lady, the pizza delivery guy,
whoever, show how frustating and how many mistakes the users make as
they're not getting enough help, or the navigation is
counter-intuitive etc.

Show them how good JS can improve all those situations, resulting in
more sales or whatever

>The future for me as an enthusiastic javascript programmer does not look
>very bright, if this is true. Toy language, amusement park for teenagers?

Nope, there's money in JS, it's what I do for a crust.

Also remember we're in a particularly boring time of web-authoring,
there's been nothing new in ages. However XBL * is a very nice
looking technology and that relies on javascript to do anything
interesting, and who knows even XHTML 2.0 might have something
interesting?

Jim.

* The forthcoming W3 version, not the orginal Mozilla one.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

On Fri, 16 Apr 2004 17:52:21 -0500, "Matt Kruse"
<> wrote:
>> Didn't I write one of those novels explaining to you why libraries are
>> in inappropriate concept for Internet browser scripting?
>
>Yes, and I still think you represent about 2% of javascript developers with
>that opinion

None of the large commercial projects I've worked on use libraries,
yet many are in the thousands of lines of JS situation. Even the ones
where I've had no input at all to the system design.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Matt Kruse wrote:
> "Richard Cornford" <> wrote:
>> But are you complaining? What sort of discussion form would c.l.j.
>> be if everyone followed your example and contributed no more than
>> references to dubious javascript libraries?
>
> Dubious? Any specific criticisms are welcome.

What would be the point of enumerating the many specific implementation
flaws in your code when you refuse to even recognise the fundamental
design flaw?

<snip>
>> That is hardly going to contribute to
>> anyone's understanding and skills, a more universally functional
>> Internet, or the already tarnished reputation of javascript.
>
> I disagree. There is a lot to be learned by using and inspecting
> pre-written libraries which solve the exact problem you are facing.

There may be something to be learnt about language use, or the
employment of DOM features, but there won't be much to be learnt about
script design. But then you argue that your libraries "solve" the
problem with 10 minutes work, so they may never be subject to
examination by individuals employing them. And an attitude that it is
better to refer people to copy and paste scripts, rather than assisting
them in better understanding the task and its issues, will not assist
them in untangling the code within those libraries.

>> If you are failing to find examples of scripts written by me that
>> demonstrate the application of the principles under discussion here
>> then I don't think you can be trying very hard.
>
> A search for "Richard Cornford" +javascript returns few results

That doesn't seem like a search combination calculated to locate code.

> And IMO, snippets of example code are useful and great for discussing
> the finer points of the language and its use, but they aren't
> solutions.

You have a very personal definition of "solution". To my mind a solution
modifies a situation such that there are no problems remaining. In you
definition a solution modifies the problem into something you are willin
g to ignore.

> Writing small snippets to do very specific low-level tasks
> is one thing,

Encapsulating commonly needed and specific (usually low level) tasks
into efficient small components is a viable way of authoring re-usable
code. The individual components are not a solution to anything (except
not having to worry about how that particular aspect of the larger
problems is going to be handled), but they are the building blocks of
larger applications. And once any individual component has been
rigorously tested in isolation its behaviour can be relied upon to
contribute towards the creation of a reliable larger application.

Any sufficiently large collection of such components become the tools
with which anything can be built, and the nearest thing to a library
that is viable with browser scripting. Though such a collection would
never be imported complete into a web page, it would just be the source
form which suitable components were acquired for a specific application.

But there is no point trying to create and distribute such a collection
of components, the individuals using them need to understand what they
do and how they work in order to choose the correct component for any
situation, and employ it effectively. And any author may prefer to
choose a level of abstraction that suited their individual style. It is
also more practical to build such a collection in a response to
requirements, so a new requirement may require the creation of a new
component but, if suitably designed, that component becomes available
for re-use in future similar situations.

To that end the greatest good can be done for the prospective browser
scripter by teaching them to build their own components.

> but writing solutions which solve real problems on real web
> sites using a wide range of browsers and supporting features that
> would be needed by a wide range of users is quite another.

This has no baring. In the development of most things there will be a
stage where viability has been demonstrated (objectively) but no actual
application exists. What sort of progress would be possible if a
demonstration of viability was routinely dismissed because it preceded
its applications?

> In many cases, the "right way to do things" simply doesn't work in
> real-world situations, because of browser bugs and quirks, or because
> it's not generalized enough to be widely useful.

When the "right thing to do" has been demonstrated to be the only way of
handling all browsers (regardless of quirks and bugs) how can that not
be sufficiently general?

>> Didn't I write one of those novels explaining to you why libraries
>> are in inappropriate concept for Internet browser scripting?
>
> Yes, and I still think you represent about 2% of javascript
> developers with that opinion

You do like to throw numbers about don't you. The implication of that
statement is that on the occasions when the suitability of libraries for
use in a browser scripting context has been debated on this group 98% of
the readers of (and participators in) those debates have disagreed with
the proposition that they are unsuitable, but not one of them has
managed to think up a single viable counter argument to post. So if
there is such a widespread belief in the suitability of libraries in
that context then it doesn't appear to have any rational basis.

<snip>
>> It either is possible to
>> create scripts that match their execution to the browser's ability to
>> support them, and cleanly degrade to viable underlying HTML when not
>> supported, avoiding introducing a dependency on client-side scripting
>> into a system that is otherwise 100% reliable, or it is not.
>
> And in any given situation, it's either worth the effort, or it is
> not.

That is a running theme in these discussions, the people who can't do it
believe that there is more effort involved, the people who can do it
don't see much difference. But the latter group must be better qualified
to judge.

> Just because something can be done perfectly doesn't mean it
> justifies the time or expense to do so.

And if there is no significant difference in time or expense?

> The 80/20 rule.

And last week we were discussing the consequences of needlessly
designing out 5% of turnover.

But who's 80/20 rule is this? What does it actually state? Do your
commercial clients know that, as a software developer, you feel entitled
to design them out of up to 20% of their turnover based on some spurious
"rule" when that is demonstrably avoidable?

> If everyone waited for perfect solutions before releasing software,
> we would never have any software!

Software houses seem very interested in maximising the reliability of
their output. Running QA departments, investigating in and implementing
design, testing and project management practices intended to minimise
problems, and rapidly identify and rectify any that remain. They care
very much that what they release is of the highest achievable quality,
if they could identify perfection prior to releasing software then they
would. QA is there specifically to identify things that need to be fixed
prior to relaese.

>> As it has been demonstrated that it in fact is possible to create
>> scripts to that standard it makes sense that this group should
>> promote that standard and disseminate an understanding of the
>> techniques needed to achieve it.
>
> I think it's always best to promote the best solution to any given
> problem. But a bunch of "code-perfect" snippets still require
> subtantial effort and knowledge to assemble into a working solution.
> If someone comes here with a question about how to achieve X, we can
> either point out 25 ways to code correctly and write clean code which
> degrades perfectly and leave them with nothing but pieces to glue
> together, or we can offer them a packaged solution which will solve
> their problem in 10 minutes with 5 lines of code. I prefer the
> latter, which they can dig into and learn from.

Again you are applying your unusual definition of "solution". Take you
table sorting library, someone wants to sort the contents of a table by
clicking on column headers, a common enough desire. You direct them to
your table sorting library and 10 minutes later the have a web page in
which they can sort a table by clicking on the column headers (at least
on the sub-set of javascript capable browsers that fulfil your criteria
of suitability). You would say they have a "solution", they may also say
they have a solution, but what they actually have is a different
problem. Because now they have introduced a javascript dependency that
means no client-side scripting equals no table contents. (They may also
have rendered themselves subject to prosecution under some nation's
accessibility legislation, which may also be considered a problem.)

Now contrast that with the DOM table sorting scripts. OK, they only work
on javascript capable dynamic DOM browsers (but those fall on the
acceptable side of your 80/20 criteria anyway), so they detect the
required dynamic DOM support and only act when it is available, but the
table is defined in the HTML and only manipulated by the script. A worst
case failure may leave the user unable to sort the table (at least on
the client as this process is very amenable to direct server-side
fall-back) but whatever happens the user can still read the contents of
the table. The script provides a useful enhancement to the page, but
does not detract from its usability.

You library solves one problem by introducing another, the DOM version
solves the same problem (to the same criteria of acceptability) but does
not introduce any other problems into the situation.

Indeed the DOM version can be layered over a system that displayed and
sorted tables on the server in a way that enabled it to short-circuit
requests for server-side sorting and do that locally whenever the
browser supported dynamic DOM manipulation. Your library would
necessitate two distinct back end processes to achieve similar
reliability, and the transition to the servers-side backup in the event
of failure on the client side would be less that transparent. It is
maybe the way that the inappropriateness of the fundamental design of
your libraries would require you to jump through hoops to create a
reliable system that is contributing to your impression that creating a
reliable system is difficult, time-consuming and expensive.

>> Particularly baring in mind that on the occasions that a
>> particular proposed action is identified as not amenable to
>> satisfactory clean degradation the javascript dependent alternatives
>> are always demonstrably worse, as anyone viewing any page employing
>> any of your libraries with a javascript disabled browsers would
>> rapidly discover.
>
> Anyone viewing my pages containing _javascript libraries_ without
> javascript enabled is surely missing the point,

I would say that visiting a demonstration of any javascript code with a
javascript disabled browser is a very obvious test for the acceptability
of its degradation strategy (though the author may simplify the test
process by providing a means of directly disabling the script without
necessitating the disabling of javascript).

> and I don't care if the page is broken
> for them. I have a limited amount of time in my
> day, and I can't cater to everyone, nor do I try

You can cater for everyone, but not caring to try is guaranteed to mean
that you never will.

Richard.