Prev: FAQ Topic - How can I create a Date object from a String? (2010-07-27)
Next: Javascript exception control
From: RobG on 27 Jul 2010 23:23
On Jul 28, 2:05 am, Karl Tikjøb Krukow <karl.kru...(a)gmail.com> wrote:
> Richard Cornford wrote:
[...]
> > "This is considered bad practice, a hack, by many.
> >    - Unreliable
> >    - Restricted accessibility
> >    - Maintenance"
>
> > I don't think that "accessibility" has much direct relevance to
> > browser sniffing. It can be restricted as much without it as with it.
>
> Again, I've used an incorrect word. I mean accessibility to many user
> agents - not users. I will rephrase (though I haven't got a concise word
> now...)

The use of the term "accessibility" to mean the quality of user
interaction is a misnomer, it should never have come into popular use.
What is meant is usability: that is, how well users can use a site.
The phrase you are looking for is "restricted usability", with the
implication that it is due to dysfunctional, inoperable or unavailable
user interface features that prevent suitable access to the data.

Consider a blind user whose screen reader is befuddled by text loaded
by XHR that is positioned in an appropriate spatial location in a
page, but does not sit in a logical place in the DOM. The screen
reader may well read it out of sequence so it is heard in the wrong
context. The user has accessed the data just fine, but they have
difficulty comprehending it because of awkard or inappropriate
presentation (i.e. the interface sucks).

In another case, a user might access the correct URI but because theu
are unable to cause an appropriate event to occur (say initiate a
hover event when using a touch interface or a click if using a
keyboard) in order to make information appear on the screen, then they
have a usability issue. They may have accessed the data, or at least
the correct URI, they just can't get it to display the information.

If, on the other hand, they access the URI but their internet
connection is too slow and the page times out, they have an
accessibility issue - they can't *get* to the information (or it can't
get to them).

However, I think I'm pissing in the wind on this one. :-(

[...]
> > Slide img10.html
>
> > The - typeof el.childNodes // 'function' - example for Safari is
> > probably inappropriate in context as the childNodes collection can be
> > called in that environment and so is a function, making the behaviour
> > fully conforming with the ECMAScript behaviour for a native function.
>
> Ok, the IE example should suffice to prove the point.

The Safari example shows that host objects can be infuriatingly
inconsistent even in browsers that claim to be more standards
compliant than the others (it just depends on what standard you happen
to be using for which behaviour).


--
Rob
From: Karl Tikjøb Krukow on 28 Jul 2010 00:27
On 28/07/10 05.23, RobG wrote:
> On Jul 28, 2:05 am, Karl Tikj�b Krukow<karl.kru...(a)gmail.com> wrote:
[snip]
>> Ok, the IE example should suffice to prove the point.
>
> The Safari example shows that host objects can be infuriatingly
> inconsistent even in browsers that claim to be more standards
> compliant than the others (it just depends on what standard you happen
> to be using for which behaviour).
>
>
> --
> Rob

Agreed, there is value in known that it's not "just IE".

I'll keep the document.all Safari example.

Thanks,
Karl.
From: Karl Tikjøb Krukow on 28 Jul 2010 01:10
On 28/07/10 00.01, David Mark wrote:
> On Jul 27, 2:46 pm, Karl Tikj�b Krukow<karl.kru...(a)gmail.com> wrote:
>> Karl Tikj�b Krukow wrote:
>>> Richard Cornford wrote:
>> [snip]
>>>> The "Potential cons" list:-
>>
>>>> - Does not mention that the libraries are rarely actually cross-
>>>> browser (but merely support a limited set of brewers, so are actually
>>>> little more than an elaboration of the "both browsers" scripts from
>>>> the end of the last century).
>>
>>> Ok, I've added a bullet "Rarely supports more than a handfull of browsers"
>>
>> [snip]
>>
>> Trade-off: if and what library to use
>> Potential pros:
>> - Responsibility of handling most cross-browser concerns are pushed to
>> the library developers
>
> That's virtually never a pro. Experienced developers know that
> complicated, monolithic do-everything-for-everybody scripts are
> inappropriate for a language that must be downloaded, runs in a single
> thread and must face many disparate environments. It's generally
> folly to try and the inexperienced are typically the ones who do.
>
> General-purpose JS libraries and frameworks are also the most
> challenging of browser scripting projects, so combined with mostly B
> Team contributors, the results are predictably disastrous.
>
> Furthermore, none of the "majors" is capable of supporting progressive
> enhancement in any meaningful way. The calling applications have no
> idea which methods will work and which will fall on their face. This
> precludes any possibility of graceful degradation in hostile or
> limited environments.

It was written as a "potential pro" :)

In an ideal scenario, pushing this responsibility to an experienced
cross-browser developer would be a pro. Obviously, when it is not
handled appropriately, it becomes a con: "You may not be happy with all
the solutions that library developers have chosen, nor consistency of
all APIs".


>
> AFAIK, there is but one (comprehensive) GP library that has come close
> to delivering a truly cross-browser (and largely maintenance-free)
> experience, while supporting progressive enhancement.
>
> http://www.cinsoft.net/
>
> That being said, I don't recommend telling your students to use it.
> They need to learn how to write browser scripts before they start
> trying to borrow code from others.

Yes, I mention "My Library" as a notable exception (a long with Fork and
APE, but they don't look as comprehensive nor maintained).

Hopefully, by the end of the course they will be able to comprehend why
code such as "My Library" is written as it is. Hopefully they will
understand the general principles and techniques, albeit they will not
have extensive knowledge of various bugs and quirks of particular
browsers. I won't recommend any particular library: hopefully they will
be able to make an informed decision on their own.

At least that is the goal.

>>
>> - Common utility functions and reusable components
>>
>> - One place to go for documentation, and a single community
>
> That's not necessarily a pro either. There are lots of places to go
> to find information about JS and browser scripting in general (granted
> most of them are very bad). There is but one jQuery documentation
> site.
>
> As for community. As Richard noted, the "support" communities are
> mostly the blind leading the blind.

Again, a "potential" pro. At the course, I will discuss the warning that
Richard and yourself are giving.

> Furthermore, it's not always true that there is a single point of
> contact. Many of these efforts get fragmented over the years (see
> Dojo and Ext JS), even so much as to break their Google search results
> by changing domain names (Ext JS and Dojo each did that *twice* at
> least).
>

While I agree that it is not always true, usually it is a single (or a
few) points of contact. I think I will keep this bullet.

>>
>> Potential cons:
>> - You may not be happy with all the solutions that library developers
>> have chosen, nor consistency of all APIs
>
> That's an understatement of a disclaimer.

Yes, I am deliberately not using too strong statements in this
presentation.

[snip]

>> - Browser detection requires continous maintainance/upgrades
>
> And it may well fail *today* (in environments unknown to or unobserved
> by) the developers. Furthermore, the "upgrades" invariably break
> yesterday's browsers, leading them to be lopped off the "supported"
> list. Of course, end-users don't read such lists and cannot be
> expected to upgrade their browsers in perfect step with the library
> developers.

I will include this point explicitly.

>>
>> - Monolithic/non-modular libraries will inevitably contain many features
>> that you won't use
>
> And must be "upgraded" in one go, requiring a reboot of regression
> testing. It's a nightmare in practice (again Dojo, Ext JS and the
> like are the most extreme examples).

Do you mean as opposed to a modular library where you would be able to
upgrade a particular module, keeping other modules in an older version?

That is a good point.

>>
>> - Libraries will inevitably not contain all you need.
>
> No question there. JQuery has never featured anything that I need
> (and likely never will). In fact, it could be argued that a 70K CSS
> selector query engine that disagrees with its own QSA shim is a pig in
> a poke for anybody these days. There really are no valid arguments
> for it. All I ever hear are generalizations like "I use it as a
> tool".
>
>> Extensibility is
>> useful.
>
> Extensibility for JS libraries typically involves augmenting
> "namespace" objects. You can add properties to objects in any script,
> so any script can be considered extensible in this way. Granted, some
> take it a step further with additional syntactic sugar, but rarely to
> any real positive effect. If anything, it encourages "plug-in"
> authors who really shouldn't be writing JS in the first place (let
> alone extensions for widely used libraries).
>

I guess extensibility and customization is only relevant for "widget"
libraries.

The notion of extensibility that you consider is a property of the
language itself. It is often not sufficient to be practical: I think the
widgets should be designed with the mindset that the user should be able
to easily change certain properties, provided that they still satisfy
the same contract of the widget API.

But I guess it is really just a question of how well-designed it is: if
well designed, extensibility and customization will probably follow.

>> Advice on libraries
>>
>> * Consider your context
>> - General web vs. intranet.
>> - Accessibility requirements?
>> - Constrained devices? Unknown devices?
>> - App-in-a-page or hyper-text document? In between?
>>
>> * Be aware of the costs and benefits of using a particular library or not
>> - Make an informed decision
>> - Don't include a library �by default�
>> - If you choose to use one, consider which one to use based on
>> context: Don't decide by �what is hot� or �what I know�
>>
>
> Those are good points, but you need more.

Would you mind helping me with what additional points I need? (unless
you mean the points discussed in the present post).

Thanks for taking the time.
Karl.
From: Karl Tikjøb Krukow on 28 Jul 2010 01:39
On 28/07/10 00.01, David Mark wrote:
> On Jul 27, 2:46 pm, Karl Tikj�b Krukow<karl.kru...(a)gmail.com> wrote:
>> Karl Tikj�b Krukow wrote:
[snip]
>> - Libraries will inevitably not contain all you need.
>
> No question there. JQuery has never featured anything that I need
> (and likely never will). In fact, it could be argued that a 70K CSS
> selector query engine that disagrees with its own QSA shim is a pig in
> a poke for anybody these days. There really are no valid arguments
> for it. All I ever hear are generalizations like "I use it as a
> tool".
>

OT: Well, you need jQuery to add numbers

http://www.doxdesk.com/img/updates/20091116-so-large.gif

:)

Karl.
From: David Mark on 28 Jul 2010 02:01
On Jul 28, 1:39 am, Karl Tikjøb Krukow <karl.kru...(a)gmail.com> wrote:
> On 28/07/10 00.01, David Mark wrote:
>
> > On Jul 27, 2:46 pm, Karl Tikjøb Krukow<karl.kru...(a)gmail.com>  wrote:
> >> Karl Tikjøb Krukow wrote:
> [snip]
> >> - Libraries will inevitably not contain all you need.
>
> > No question there.  JQuery has never featured anything that I need
> > (and likely never will).  In fact, it could be argued that a 70K CSS
> > selector query engine that disagrees with its own QSA shim is a pig in
> > a poke for anybody these days.  There really are no valid arguments
> > for it.  All I ever hear are generalizations like "I use it as a
> > tool".
>
> OT: Well, you need jQuery to add numbers
>
> http://www.doxdesk.com/img/updates/20091116-so-large.gif
>
> :)
>

Good one, Karl. :)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: FAQ Topic - How can I create a Date object from a String? (2010-07-27)
Next: Javascript exception control