Browser sniffing alive and well

[Andrew Poulos]

Despite that its known that browser sniffing is bad its funny to see
that its survived unscathed:
<http://jquery-howto.blogspot.com/2010/09/iphone-ipod-detection-using-jquery.html>

Andrew Poulos

[Gregor Kofler]

Hey, it has the jQuery buzzword in it.

Not a single line of code utilizing jQuery (what for, anyway?) but it is
still

"iPhone / iPod detection using jQuery & JavaScript"...

Well, perhaps the avid jQuery "developer" needs insightful articles like
these...

Gregor


--
http://vxweb.net

[Mike Duffy]

Gregor Kofler <use...@gregorkofler.com> wrote in
news:j59pp9$lt8$1...@dont-email.me:

> Am 2011-09-20 10:58, schrieb Andrew Poulos:
>> Despite that its known that browser sniffing is bad its funny to see
>> that its survived unscathed:
>> <http://jquery-howto.blogspot.com/2010/09/iphone-ipod-detection-using-
>> jquery.html>

>

> Well, perhaps the avid jQuery "developer" needs insightful articles
> like these...
>

I liked the sectionat the bottom:

As final words, I would like to remind you that sometimes your visitors
would not like to be redirected to mobile versions of your websites.

--
http://pages.videotron.ca/duffym/index.htm#

[S.T.]

What feature test would you use to determine if a browser is an iPod?

[dhtml]

On Sep 20, 1:58 am, Andrew Poulos <ap_p...@hotmail.com> wrote:
> Despite that its known that browser sniffing is bad its funny to see
> that its survived unscathed:

> <http://jquery-howto.blogspot.com/2010/09/iphone-ipod-detection-using-...>
>
That article is now a full year old, but still, the "detect and
redirect" mistake is over 10 years old.

Project leaders want their seemingly daunting problems solved quickly
and fall for the lure of JS libs being able to satisfy that need.

And for the web designers, the libraries -- and jQuery in particular
-- hide the DOM, presenting instead the library authors' confusing
view of how browsers and the DOM work.

I think RobG may be right; HTML5 will obviate some of the perceived
need for these things. Sanity in 2014?
--
Garrett

[Eric Bednarz]

Wrong question.

The iPad is a piece of hardware, not a browser, and even if you *would*
know that the hardware is an iP(ad|hone|od), capabilities are further
restricted by
* the hardware version
* the iOS version
* the browser (3rd-party browsers exist, and unlike Safari they have to
do with the UIWebView component [0])



[0] there is no (automated) feature test for problems like this:
http://m.bednarz.nl/o/

[S.T.]

On 9/20/2011 1:13 PM, Eric Bednarz wrote:
> "S.T."<an...@anon.com> writes:
>
>> On 9/20/2011 1:58 AM, Andrew Poulos wrote:
>>> Despite that its known that browser sniffing is bad its funny to see
>>> that its survived unscathed:
>>> <http://jquery-howto.blogspot.com/2010/09/iphone-ipod-detection-using-jquery.html>
>>>
>>
>> What feature test would you use to determine if a browser is an iPod?
>
> Wrong question.
>
> The iPad is a piece of hardware, not a browser, and even if you *would*
> know that the hardware is an iP(ad|hone|od), capabilities are further
> restricted by
> * the hardware version
> * the iOS version
> * the browser (3rd-party browsers exist, and unlike Safari they have to
> do with the UIWebView component [0])
>

You're looking at this from too technical a standpoint. This article
seems geared towards presentation, not concern over whether scripts are
going to break in different environments. Sometimes not only is browser
sniffing suitable, it's preferred.

Example: You have a site that sells widgets. You want iPad users to see
the "normal" website while iPhone/iPod users to see a site that caters
to tiny screens - "mobile site" for lack of a better term.

But two versions isn't the end of it. You want your call-to-action
marketing on the mobile site to vary. iPhones will being steered towards
phone numbers -- "To order your widget call <a href="tel:xxxx" -- for
click-to-call since they are, after all, holding a phone. Meanwhile the
call-to-actions for iPod users to be a more appropriate-for-them
form-based mechanisms ("Fill out this form for more info...").

Its not mission critical the above scenarios to occur with 100% accuracy
but it's better for conversions the more often you're able to match the
two.

So what do you do? You browser sniff. The overwhelming majority of
iPhone/iPod users will end up exactly where you want them. A small
percentage won't, but it hardly matters. You're not sending them to a
site that's going to crash on them. What's important is you increased
your conversion chances with the overwhelming majority.

Sometimes browser sniffing is the right tool.

[Eric Bednarz]

"S.T." <an...@anon.com> writes:

> You're looking at this from too technical a standpoint.

As a developer, no: in simple cases I just spoof the user agent,
if it is necessary and worth it, I use a proxy.
As a user, just no.

> So what do you do? You browser sniff. The overwhelming majority of
> iPhone/iPod users will end up exactly where you want them.

Every average person I ever talked to who invested good money in a
recent and rather expensive ‘mobile’ device was royally pissed off about
bullshit sites that either
a) redirect to some ‘optimized’ version or
b) keep bugging about installing some native app
because they usually already know the site they are visiting from using
a desktop browser and don’t want to learn a new UI for old news (it’s
also always a lot of fun not being able to find something you know is
there).

But as a professional developer who doesn’t speak for himself, I must
say that you are absoutely right; everybody with a website should have a
customized version and a native app for every device out there.

[Andrew Poulos]

Do you really believe that if a site fails for a user's then its the
user's fault or are you just trying to defend a bad practice?

Andrew Poulos

[S.T.]

On 9/20/2011 2:16 PM, Eric Bednarz wrote:
> "S.T."<an...@anon.com> writes:

>> So what do you do? You browser sniff. The overwhelming majority of
>> iPhone/iPod users will end up exactly where you want them.
>
> Every average person I ever talked to who invested good money in a
> recent and rather expensive ‘mobile’ device was royally pissed off about
> bullshit sites that either
> a) redirect to some ‘optimized’ version or
> b) keep bugging about installing some native app
> because they usually already know the site they are visiting from using
> a desktop browser and don’t want to learn a new UI for old news (it’s
> also always a lot of fun not being able to find something you know is
> there).

I think it depends how they do it. I use a newer model Android phone
with a 4" screen, which is near a third larger than an iPhone screen in
terms of area. Many regular sites are tough to enjoy on that small a
screen. Too much content, too complicated a layout that causes slow
rendering, etc. I usually like being sent to a mobile version provided:

a) I have easy access (i.e. obvious link) to the regular site should I
prefer it. It is really annoying to find it damn near impossible to
reach a regular version of a site when you want it.

b) The mobile site isn't too dumbed-down, meaning they don't split one
page of a desktop site to 10 bite-size pages on a mobile site. This is a
big problem on news sites as it seems they're unwilling to concede
advertising space so they splinter their home page into a dozen small
pages that net the same total amount of advertising.

That's my opinion, at least.

[S.T.]

On 9/20/2011 2:16 PM, Andrew Poulos wrote:
> Do you really believe that if a site fails for a user's then its the
> user's fault or are you just trying to defend a bad practice?

The site wouldn't fail. If a piece of browser sniffing logic failed to
catch an iPhone using Opera Mini, for example, they would just end up on
the "desktop" page rather than a custom page offering a slightly better
experience. Big deal. You can't program/design for the lowest common
denominator out of fear.

In many (most?) cases there are better alternatives to browser-sniffing.
In many cases there exists the possibility to break sites from using
browser sniffing. So yes, generally speaking using sniffing is poor
practice. But not always. Sometimes it is the right tool despite it's
lack of perfection, because perfection isn't required and there are no
better substitutes. Suggesting that writing about how to browser sniff
is wrong simply because it's about how to browser sniff is naive.

[Andrew Poulos]

On 21/09/2011 8:15 AM, S.T. wrote:

> On 9/20/2011 2:16 PM, Andrew Poulos wrote:
>> Do you really believe that if a site fails for a user's then its the
>> user's fault or are you just trying to defend a bad practice?
>
> The site wouldn't fail. If a piece of browser sniffing logic failed to
> catch an iPhone using Opera Mini, for example, they would just end up on
> the "desktop" page rather than a custom page offering a slightly better

The ipad 2's Safari browser, at least, does not show scrollbars so that
it may be difficult or impossible to reach content that is not currently
in the viewport. That is, the site would fail.

> experience. Big deal. You can't program/design for the lowest common
> denominator out of fear.

What lowest common denominator are you referring to? Savvy uses who put
"better" browsers on their mobile devices?

> In many (most?) cases there are better alternatives to browser-sniffing.
> In many cases there exists the possibility to break sites from using
> browser sniffing. So yes, generally speaking using sniffing is poor
> practice. But not always. Sometimes it is the right tool despite it's
> lack of perfection, because perfection isn't required and there are no
> better substitutes. Suggesting that writing about how to browser sniff
> is wrong simply because it's about how to browser sniff is naive.

You are not correct: <http://jibbering.com/faq/#detectBrowser>

Andrew Poulos

[dhtml]

On Sep 20, 3:15 pm, "S.T." <a...@anon.com> wrote:
> On 9/20/2011 2:16 PM, Andrew Poulos wrote:
>
> > Do you really believe that if a site fails for a user's then its the
> > user's fault or are you just trying to defend a bad practice?
>
> The site wouldn't fail. If a piece of browser sniffing logic failed to
> catch an iPhone using Opera Mini, for example, they would just end up on
> the "desktop" page

The author is drawing clear outlines of what to anticipate and that
scenario ain't in the picture.

[...]

> In many cases there exists the possibility to break sites from using
> browser sniffing. So yes, generally speaking using sniffing is poor
> practice. But not always. Sometimes it is the right tool despite it's
> lack of perfection, because perfection isn't required and there are

Great example, you provided.

no
> better substitutes. Suggesting that writing about how to browser sniff
> is wrong simply because it's about how to browser sniff is naive.

Detecting and redirecting is just plain awful approach. The author
even goes on to vaguely say when where and how:

| there are Safari specific CSS features that you might
| want to utilize and you need to know if the current
| browser is Safari, then you may also...

That poorly-written article is advertising redirection for CSS
support. If that's really a bad idea (and it is), then why write about
it as a solution?
--
Garrett

[S.T.]

On 9/20/2011 4:47 PM, Andrew Poulos wrote:
> On 21/09/2011 8:15 AM, S.T. wrote:
>> On 9/20/2011 2:16 PM, Andrew Poulos wrote:
>>> Do you really believe that if a site fails for a user's then its the
>>> user's fault or are you just trying to defend a bad practice?
>>
>> The site wouldn't fail. If a piece of browser sniffing logic failed to
>> catch an iPhone using Opera Mini, for example, they would just end up on
>> the "desktop" page rather than a custom page offering a slightly better
>
> The ipad 2's Safari browser, at least, does not show scrollbars so that
> it may be difficult or impossible to reach content that is not currently
> in the viewport. That is, the site would fail.

What in the hell are you talking about? You've described an iPad
"feature" relating to iframes and divs that scroll, and "difficult or
impossible to reach" involves using *two* fingers when you swipe. All of
which has exactly zero to do with any scenario or example I've provided
in this thread.

There is no possible leap in logic that would have led you to cite this
as an applicable counterpoint. I honestly think you're just trolling now.

>> experience. Big deal. You can't program/design for the lowest common
>> denominator out of fear.
>
> What lowest common denominator are you referring to? Savvy uses who put
> "better" browsers on their mobile devices?

Don't worry about it. You're never going to figure it out anyhow.

>> In many (most?) cases there are better alternatives to browser-sniffing.
>> In many cases there exists the possibility to break sites from using
>> browser sniffing. So yes, generally speaking using sniffing is poor
>> practice. But not always. Sometimes it is the right tool despite it's
>> lack of perfection, because perfection isn't required and there are no
>> better substitutes. Suggesting that writing about how to browser sniff
>> is wrong simply because it's about how to browser sniff is naive.
>
> You are not correct: <http://jibbering.com/faq/#detectBrowser>

FAQ != fact. Unfortunately that might require you to think on your own.

[S.T.]

On 9/20/2011 4:43 PM, dhtml wrote:
> On Sep 20, 3:15 pm, "S.T."<a...@anon.com> wrote:
>> In many cases there exists the possibility to break sites from using
>> browser sniffing. So yes, generally speaking using sniffing is poor
>> practice. But not always. Sometimes it is the right tool despite it's
>> lack of perfection, because perfection isn't required and there are
>
> Great example, you provided.
>
> no
>> better substitutes. Suggesting that writing about how to browser sniff
>> is wrong simply because it's about how to browser sniff is naive.
>
> Detecting and redirecting is just plain awful approach. The author
> even goes on to vaguely say when where and how:
>

What's the non-sniffing solution to my scenario?

You have a mobile version of a site and a client wants:

- iPhone users to see a version of a site that emphasizes the store's
phone number and the outstanding service they'll receive by calling,
because we *know* they have a phone and a lead who calls is
substantially more likely to convert to a customer.

- iPod Touch users to be directed to either fill out a form or call the
phone number if it's convenient, because you don't want to suggest to
someone who doesn't have a phone nearby that the form-based service
they'll receive is inferior to those who call. Call this the default view.

How do you do it?

[Andrew Poulos]

On 21/09/2011 10:28 AM, S.T. wrote:
> On 9/20/2011 4:47 PM, Andrew Poulos wrote:
>> On 21/09/2011 8:15 AM, S.T. wrote:
>>> On 9/20/2011 2:16 PM, Andrew Poulos wrote:
>>>> Do you really believe that if a site fails for a user's then its the
>>>> user's fault or are you just trying to defend a bad practice?
>>>
>>> The site wouldn't fail. If a piece of browser sniffing logic failed to
>>> catch an iPhone using Opera Mini, for example, they would just end up on
>>> the "desktop" page rather than a custom page offering a slightly better
>>
>> The ipad 2's Safari browser, at least, does not show scrollbars so that
>> it may be difficult or impossible to reach content that is not currently
>> in the viewport. That is, the site would fail.
>
> What in the hell are you talking about? You've described an iPad
> "feature" relating to iframes and divs that scroll, and "difficult or
> impossible to reach" involves using *two* fingers when you swipe. All of

No, you are wrong. That some content that's bigger that a mobile
viewpoint can be reached by swiping does not negate the fact that there
exists content that can reached by scrolling on a desktop browser that
cannot be reached by swiping on a mobile device's browser. I know
because I'm actually working on a site now which displays this behaviour.

> which has exactly zero to do with any scenario or example I've provided
> in this thread.

Again you are wrong. When your browser sniffing fails then a site you
designed with two versions (one for the desktop and one for the browser
would fail)

> There is no possible leap in logic that would have led you to cite this
> as an applicable counterpoint. I honestly think you're just trolling now.

'ad hominem' number 1.

>>> experience. Big deal. You can't program/design for the lowest common
>>> denominator out of fear.
>>
>> What lowest common denominator are you referring to? Savvy uses who put
>> "better" browsers on their mobile devices?
>
> Don't worry about it. You're never going to figure it out anyhow.

'ad hominem' number 2.

>>> In many (most?) cases there are better alternatives to browser-sniffing.
>>> In many cases there exists the possibility to break sites from using
>>> browser sniffing. So yes, generally speaking using sniffing is poor
>>> practice. But not always. Sometimes it is the right tool despite it's
>>> lack of perfection, because perfection isn't required and there are no
>>> better substitutes. Suggesting that writing about how to browser sniff
>>> is wrong simply because it's about how to browser sniff is naive.
>>
>> You are not correct: <http://jibbering.com/faq/#detectBrowser>
>
> FAQ != fact. Unfortunately that might require you to think on your own.

'ad hominem' number 3.

That you choose to defend, what I believe are your misconceptions, by
pointing out non-existent negative characteristics in another is
something you should consider receiving counselling about.

Andrew Poulos

[dhtml]

On Sep 20, 5:56 pm, "S.T." <a...@anon.com> wrote:
> On 9/20/2011 4:43 PM, dhtml wrote:
>
> > On Sep 20, 3:15 pm, "S.T."<a...@anon.com>  wrote:
> >> In many cases there exists the possibility to break sites from using
> >> browser sniffing. So yes, generally speaking using sniffing is poor
> >> practice. But not always. Sometimes it is the right tool despite it's
> >> lack of perfection, because perfection isn't required and there are
>
> > Great example, you provided.
>
> >   no
> >> better substitutes. Suggesting that writing about how to browser sniff
> >> is wrong simply because it's about how to browser sniff is naive.
>
> > Detecting and redirecting is just plain awful approach. The author
> > even goes on to vaguely say when where and how:
>
> What's the non-sniffing solution to my scenario?
>
> You have a mobile version of a site and a client wants:
>
> - iPhone users to see a version of a site that emphasizes the store's
> phone number and the outstanding service they'll receive by calling,
> because we *know* they have a phone and a lead who calls is
> substantially more likely to convert to a customer.
>

So you want to detect if the user has a phone. Interesting! I've never
faced that problem.

> - iPod Touch users to be directed

If you do that, I'm probably won't want to stay. I don't like being
redirected to mobile sites and I hate it when I get a URL that has m.*
-- and when I do, the content is usually designed to fail in anything
but what the author thinks the user is on. YouTube m.* links in
twitter, for example.

to either fill out a form or call the
> phone number if it's convenient, because you don't want to suggest to
> someone who doesn't have a phone nearby that the form-based service
> they'll receive is inferior to those who call. Call this the default view.
>
> How do you do it?

Can we put the phone number on the site? An email address or a link to
a contact page with a form?

I'm not convinced that this problem is unsolvable without browser
detection. Nor am I convinced that browser detection would have a good
outcome.
--
Garrett

[Jeff North]

On Tue, 20 Sep 2011 17:56:42 -0700, in comp.lang.javascript "S.T."
<an...@anon.com>

I would be looking into CSS3 media queries to alter the layout of the
page. Google for css3 media queries.
http://coding.smashingmagazine.com/2010/07/19/how-to-use-css3-media-queries-to-create-a-mobile-version-of-your-website/

[Dr J R Stockton]

In comp.lang.javascript message <m27h525...@nntp.bednarz.nl>, Tue,
20 Sep 2011 23:16:17, Eric Bednarz <bed...@fahr-zur-hoelle.org> posted:

>But as a professional developer who doesn’t speak for himself, I must
>say that you are absoutely right; everybody with a website should have a
>customized version and a native app for every device out there.

That might be sarcasm.

Otherwise, if the constructors of the site are not resource-limited,
then it is indeed best to offer versions adapted for each possible
medium, provided that the user on any device can access any version he
might want to.

But, if the authoring is resource-limited, and time is a resource, ISTM
generally much better to produce two entirely different pages or sites
both written with a good desktop PC / Mac / UNIX / etc. in mind, than to
produce with those limited resources one page which is designed for
devices of multiple types. Except when the application is, like a map,
particularly needed for mobile use, and suchlike.

Jibbering is up.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.

[dhtml]

On Sep 21, 11:38 am, Dr J R Stockton <reply1...@merlyn.demon.co.uk>
wrote:
> In comp.lang.javascript message <m27h5252zi....@nntp.bednarz.nl>, Tue,
> 20 Sep 2011 23:16:17, Eric Bednarz <bedn...@fahr-zur-hoelle.org> posted:

>
> >But as a professional developer who doesn’t speak for himself, I must
> >say that you are absoutely right; everybody with a website should have a
> >customized version and a native app for every device out there.
>
> That might be sarcasm.

Seems obviously so to me. Though someone might not take it with the
blatant irony as it struck me.
--
Garrett

[RobG]

On 22/09/11 4:38 AM, Dr J R Stockton wrote:

> Jibbering is up.

Perhaps at the instant you wrote, it isn't now and has not been whenever
I've tried to visit it in the last several months.

--
Rob

[Scott Sauyet]

Interesting. Every time someone says it's down, I go to look and it's
always worked for me.

Very odd.

-- Scott

[Stuart McCall]

> Interesting. Every time someone says it's down, I go to look ...

You need to get out more :)

[Eric Bednarz]

dhtml <dhtmlk...@gmail.com> writes:

> Dr J R Stockton wrote:

>> Eric Bednarz posted:

[iWhatNot detection]

>>> But as a professional developer who doesn’t speak for himself, I
>>> must say that you are absoutely right; everybody with a website
>>> should have a customized version and a native app for every device
>>> out there.
>>
>> That might be sarcasm.

I genuinely adore the British art of understatement.

> Seems obviously so to me. Though someone might not take it with the
> blatant irony as it struck me.

Oh well.

In defendence of most people who get flamed here for asking the wrong
questions or giving the wrong answers, this newsgroup is totally
detached from J. Random Developer’s daily reality, where stupid ideas
have been originating from or sanctioned by Interaction Designers in the
first place.

[Thomas 'PointedEars' Lahn]

Eric Bednarz wrote:

> In defendence of most people who get flamed here for asking the wrong
> questions or giving the wrong answers, this newsgroup is totally
> detached from J. Random Developer’s daily reality, where stupid ideas
> have been originating from or sanctioned by Interaction Designers in the
> first place.

You don't have to give in to people having stupid ideas, you know.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[dhtml]

On Sep 24, 5:35 pm, Eric Bednarz <bedn...@fahr-zur-hoelle.org> wrote:
> dhtml <dhtmlkitc...@gmail.com> writes:
[...]

> In defendence of most people who get flamed here for asking the wrong
> questions or giving the wrong answers, this newsgroup is totally
> detached from J. Random Developer’s daily reality, where stupid ideas
> have been originating from or sanctioned by Interaction Designers in the
> first place.

And they get their common practices from the GP library authors/
promoters.

This works because libraries give something to the user: Empowerment.
They empower the otherwise average developer to do things -- even if
badly -- that he would otherwise be incapable of doing. Often these
things are not that hard for experienced javascript programmers to do
well, but that is not a concern nowadays.

Ideas originating from c.l.js, including feature testing, have made
good headway. And from the same library people who have shunned the
place (no need to mention names here).

If any attribution is to be made for ideas originating here, it should
be to the right thread or post.
--
Garrett

[RobG]

On 25/09/11 4:39 AM, Stuart McCall wrote:
>> Interesting. Every time someone says it's down, I go to look ...
>
> You need to get out more :)

Your revisionist quoting might be humerous, but when doing so please
indicate your modifications.


--
Rob

[Dr J R Stockton]

In comp.lang.javascript message <F4OdnbBtoJCVruDTnZ2dnUVZ_rKdnZ2d@westne
t.com.au>, Sat, 24 Sep 2011 11:31:50, RobG <rg...@iinet.net.au> posted:

It's up now, though I think it was dozing.

Of course, since any change to the main content of the FAQ will be
triumphantly announced, regulars should not need to fetch a Web copy
whenever they want to read the material, since they can keep a copy on
their own system(s).

It would, of course, be useful if some regular with adequate bandwidth
and memory were to arrange to serve a mirror copy, and make it known to
search engines. Maybe "dhtml" would fill the bill.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk IE8 FF3 Op12 Sf5 Cr12
news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
<http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[dhtml]

On Sep 25, 11:06 am, Dr J R Stockton <reply1...@merlyn.demon.co.uk>
wrote:

> In comp.lang.javascript message <F4OdnbBtoJCVruDTnZ2dnUVZ_rKdnZ2d@westne
> t.com.au>, Sat, 24 Sep 2011 11:31:50, RobG <rg...@iinet.net.au> posted:
>
> >On 22/09/11 4:38 AM, Dr J R Stockton wrote:
>
> >> Jibbering is up.
>

Don't blink.

> >Perhaps at the instant you wrote, it isn't now and has not been
> >whenever I've tried to visit it in the last several months.
>
> It's up now, though I think it was dozing.
>

You blinked.

> Of course, since any change to the main content of the FAQ will be
> triumphantly announced,

By whom? Last I was aware, there was no maintainer.

Req's include knowledge & skill in: Writing code and explaining it in
English, browsers, ES, diplomacy.

regulars should not need to fetch a Web copy
> whenever they want to read the material, since they can keep a copy on
> their own system(s).
>
> It would, of course, be useful if some regular with adequate bandwidth
> and memory were to arrange to serve a mirror copy, and make it known to
> search engines.  Maybe "dhtml" would fill the bill.

Dhtmlkitchen.com is now owned by Paolo Fragomeni. Paolo is recreating
the site using Node.js (thanks for that!). I'm converting the articles
from XHTML to HTML5 and helping with any js that is needed or wanted.
If he wants to have the FAQ on that site, that would be a good option
and result in greater visibility of the FAQ.

The current FAQ XML and parsing has so many problems that warrant
looking at things anew, and considering new technology. It might be a
good idea to use Node to generate the markup and/or daily postings.
--
Garrett

[RobG]

On Sep 26, 12:29 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
> On Sep 25, 11:06 am, Dr J R Stockton <reply1...@merlyn.demon.co.uk>
> wrote:> In comp.lang.javascript message <F4OdnbBtoJCVruDTnZ2dnUVZ_rKdnZ2d@westne
> > t.com.au>, Sat, 24 Sep 2011 11:31:50, RobG <rg...@iinet.net.au> posted:
>
> > >On 22/09/11 4:38 AM, Dr J R Stockton wrote:
>
> > >> Jibbering is up.
>
> Don't blink.
>
> > >Perhaps at the instant you wrote, it isn't now and has not been
> > >whenever I've tried to visit it in the last several months.
>
> > It's up now, though I think it was dozing.
>
> You blinked.

As Henry Crun said to Minnie Bannister (applogies to the Goon Show, I
can't remember which episode):

"Speak up, I can't hear you when you're not talking!!"

--
Rob

[Dr J R Stockton]

In comp.lang.javascript message <1557989.c...@PointedEars.de>,
Sun, 25 Sep 2011 03:08:35, Thomas 'PointedEars' Lahn
<Point...@web.de> posted:

>Eric Bednarz wrote:
>
>> In defendence of most people who get flamed here for asking the wrong
>> questions or giving the wrong answers, this newsgroup is totally
>> detached from J. Random Developer’s daily reality, where stupid ideas
>> have been originating from or sanctioned by Interaction Designers in the
>> first place.
>
>You don't have to give in to people having stupid ideas, you know.

Indeed. That is why some of us still occasionally try to persuade you
to get your personality normalised.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike 6.05 WinXP.
Web <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.

[Dr J R Stockton]

In comp.lang.javascript message <f3c0df5a-13e3-4a05-8f85-9ef6c8c3d121@m1
5g2000vbk.googlegroups.com>, Sun, 25 Sep 2011 19:29:01, dhtml
<dhtmlk...@gmail.com> posted:

>On Sep 25, 11:06 am, Dr J R Stockton <reply1...@merlyn.demon.co.uk>
>wrote:

Jibbering is up.

>> Of course, since any change to the main content of the FAQ will be
>> triumphantly announced,
>By whom? Last I was aware, there was no maintainer.

Indeed. We don't know who, if anyone, may at some time become a
maintainer; but, if someone does produce and publish a revised version,
it can be predicted with reasonable confidence that there will be a
(reasonably or otherwise) triumphant announcement.

>Req's include knowledge & skill in: Writing code and explaining it in
>English, browsers, ES, diplomacy.

And in reading and understanding English.

>regulars should not need to fetch a Web copy
>> whenever they want to read the material, since they can keep a copy on
>> their own system(s).
>>
>> It would, of course, be useful if some regular with adequate bandwidth
>> and memory were to arrange to serve a mirror copy, and make it known to
>> search engines.  Maybe "dhtml" would fill the bill.
>
>Dhtmlkitchen.com is now owned by Paolo Fragomeni. Paolo is recreating
>the site using Node.js (thanks for that!). I'm converting the articles
>from XHTML to HTML5 and helping with any js that is needed or wanted.
>If he wants to have the FAQ on that site, that would be a good option
>and result in greater visibility of the FAQ.
>
>The current FAQ XML and parsing has so many problems that warrant
>looking at things anew, and considering new technology. It might be a
>good idea to use Node to generate the markup and/or daily postings.

It is important that a FAQ should be portable between maintainers. The
automated system, whatever it was, that was set up by Jim seemed
entirely satisfactory in the hands of Jim, but since then it has seemed
to be more of a handicap to its users. To be reliably portable between
maintainers, a FAQ needs to be maintained in ASCII and editable with
Notepad and Mac/UNIX/etc. equivalents (so that a maintainer's preferred
plain-text editing tools can be used). In addition, the source layout
should be easy to read.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Website <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

[Dr J R Stockton]

In comp.lang.javascript message <758392df-6f2f-49ff-82e4-d05fbc325844@m3
7g2000yqc.googlegroups.com>, Sun, 25 Sep 2011 22:00:33, RobG
<rg...@iinet.net.au> posted:

>
>As Henry Crun said to Minnie Bannister (applogies to the Goon Show, I
>can't remember which episode):
>
> "Speak up, I can't hear you when you're not talking!!"

<http://www.bbc.co.uk/radio4extra/programmes/schedules> will no doubt
tell you, in time, if you listen. "Genghis Khan" is on this week.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

[dhtml]

Sometimes attribution is misplaced, yet other times, mistakes aren't
seen, not even 10 years late. E.g. From S. Souders blog entry: "UA
switching: be careful" http://www.stevesouders.com/blog/2011/09/27/ua-switching-be-careful/

Where he tells of "normal" websites that "do serverside UA detection"
and don't cause problems, whereas the "new" so-called "responsive-
design" can create trouble for device analysis. The site he is talking
about uses media queries and javascript to load images. The site is
not without it's problems, all readily viewable in its source code and
takes about 3 sec to spot things like appending elements to
documentElement (Modernizr approach, req'd to raise exception), the
use of Modernizr (which does that), the use of jQuery, a faulty
"hasClass" method, etc. But overall, the idea is to provide one site
and then make it work in more browsers, which is the right goal. But
then look at what Souders has to say:

| Websites that look at the UA string on the serverside to determine
| how to alter the page would also be okay.

10 years late and despite the browser-detection-free examples that he
is blogging about, he can't see the inherent problems with browser
detection. Is it that hard to admit that what he has been advocating
all along is indeed faulty? Or is he really that stupid?
--
Garrett