Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #12752

Re: David Mark's Essential Javascript Tips - Volume #8 - Tip #47E - Attaching and Detaching Event Listeners

Show all headers | View raw

On 03/15/2012 01:37 AM, David Mark wrote:
> On Mar 15, 12:36 am, Andrew Poulos<ap_p...@hotmail.com>  wrote:
>> On 15/03/2012 7:41 AM, David Mark wrote:
>>
>>> On Mar 14, 10:04 am, Adam Silver<adambsil...@gmail.com>    wrote:
>>>> Thanks David,
>>
>>>> We have most of this on the Jessie project now.
>>
>>> Good deal.  For those who don't know, the Jessie project is a
>>> libraryspace.  For those who don't know what that means, you haven't
>>> been following my Twitter account (and shame on you). :)
>>
>> I've no idea what a "libraryspace" is :-(
>
> It's a silly word I made up for Richard's suggestion (from four years
> ago) about a repository of interchangeable functions that could be
> used to build context-specific libraries. It's what the CWR project
> was before it was abandoned. I ended up turning my contributions into
> My Library. As mentioned at the time, a library (modular or not) was
> not what I wanted to do (but did anyway, just for the hell of it).
>
>>
>> Where can I found out more about the Jessie project (Google appears
>> unhelpful in this regard)?
>
> It's on Git. Basically, contributors are gathering up my examples from
> this series of tips and JSPerf at the moment. Ultimately, a builder
> (perhaps using node.js) will stitch the functions together to fit
> specified contexts. Not that you necessarily need a builder, assuming
> you have a clipboard. :)
>
> One key concept is that you build your library at the design stage, so
> you develop and test against the same code that will ultimately be
> released. Contrast with something like Google Closure where you
> develop/test with a huge mess and then try to filter out all of the
> unneeded bits at the last second. Also, their "compiler" is not
> context-specific in the same sense.
>
> Another, which is more important today than back in 2007, is that it
> allows the developer to decide on degradation points for the old
> MSHTML-based browsers (i.e. is the client okay with a static
> presentation for IE 6/7?) Typically, function renditions that fork for
> the old IE browsers are much larger than those that bail out in those
> environments. Contrast with monolithic GP libraries that send tons of
> IE 6/7 hacks to iPhones until the developers either:
>
> A. Stop "caring" about IE 6/7, at which time their sites
> unceremoniously break for corporate users stuck with those browsers
> B. Use client side browser sniffing to dynamically load browser-
> specific scripts (!)
> C. Give up and build a second site for mobile devices, which requires
> server side browser sniffing (!!)
>
> None of those is appealing if you are thinking straight, but C is the
> worst in terms of wasted effort and the potential to piss off
> visitors. I've always hated being redirected to alternate URI's by
> browser sniffers and an informal poll I conducted recently indicated
> that most end-users "hate" (their words) mobile sites. When asked why,
> the number one answer was: because they don't work. The "don't work"
> sentiment is subject to a number of interpretations. I know I hate it
> when I click a link to a specific news story and end up on the home
> page of a mobile site. Similarly, it's irritating when these sites try
> to imitate mobile OS's, stepping on expected browser behavior to get
> it "just right". Often they don't scale, crop overflowed content
> indiscriminately (e.g. html { overflow: hidden }), scroll poorly, etc.
> Just what you want on a tiny screen, right? And, of course, they often
> include huge scripts and style sheets to make all of this happen. :(
>
> Clearly the answer is "none of the above" (and it always has been). ;)
>

   It's 2012 and we still can't get hardware manufacturers to id stuff 
with proper mobile user-agents (if anyone wants to fake their user-agent 
then that's their problem). I prefer a mobile version over pages that 
scroll left and right, making me scroll around and double-tapping all 
over trying to see what I want to see. Problem is, the mobile versions 
need to be stripped down, no floatsam and jetsam. That's what I expect 
to see, not a bunch of (flash/Flash) ads that I obviously don't have the 
screen real estate for (but they gotta get those ads displayed!) You say 
this isn't acceptable but yet rather than design mobile pages, companies 
now create 'apps' that accomplish the same thing. There again, I 
shouldn't need to have an app for every site I like to visit.


-- 
Norman
Registered Linux user #461062
AMD64X2 6400+ Ubuntu 10.04 64bit

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: David Mark's Essential Javascript Tips - Volume #8 - Tip #47E - Attaching and Detaching Event Listeners Adam Silver <adambsilver@gmail.com> - 2012-03-14 07:04 -0700
  Re: David Mark's Essential Javascript Tips - Volume #8 - Tip #47E - Attaching and Detaching Event Listeners David Mark <dmark.cinsoft@gmail.com> - 2012-03-14 13:41 -0700
    Re: David Mark's Essential Javascript Tips - Volume #8 - Tip #47E - Attaching and Detaching Event Listeners Andrew Poulos <ap_prog@hotmail.com> - 2012-03-15 15:36 +1100
      Re: David Mark's Essential Javascript Tips - Volume #8 - Tip #47E - Attaching and Detaching Event Listeners David Mark <dmark.cinsoft@gmail.com> - 2012-03-14 22:37 -0700
        Re: David Mark's Essential Javascript Tips - Volume #8 - Tip #47E - Attaching and Detaching Event Listeners Norman Peelman <npeelmandog@cfl.rr.com> - 2012-03-15 06:38 -0400
          Re: David Mark's Essential Javascript Tips - Volume #8 - Tip #47E - Attaching and Detaching Event Listeners David Mark <dmark.cinsoft@gmail.com> - 2012-03-15 05:38 -0700

csiph-web