Groups > comp.lang.javascript > #7962 > unrolled thread

jQuery takes down the Guardian

Started by	David Mark <dmark.cinsoft@gmail.com>
First post	2011-11-03 12:52 -0700
Last post	2011-11-05 07:36 -0700
Articles	13 — 9 participants

Back to article view | Back to comp.lang.javascript

  jQuery takes down the Guardian David Mark <dmark.cinsoft@gmail.com> - 2011-11-03 12:52 -0700
    Re: jQuery takes down the Guardian RobG <rgqld@iinet.net.au> - 2011-11-03 13:56 -0700
      Re: jQuery takes down the Guardian Matt McDonald <matt@fortybelow.ca> - 2011-11-03 15:47 -0600
        Re: jQuery takes down the Guardian Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-04 00:24 +0100
        Re: jQuery takes down the Guardian RobG <rgqld@iinet.net.au> - 2011-11-03 16:30 -0700
          Re: jQuery takes down the Guardian Matt McDonald <matt@fortybelow.ca> - 2011-11-03 19:16 -0600
            Re: jQuery takes down the Guardian Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-04 11:05 +0100
            Re: jQuery takes down the Guardian Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-04 13:25 +0100
              Re: jQuery takes down the Guardian Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-04 15:33 +0000
      Re: jQuery takes down the Guardian "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-03 22:42 -0200
    Re: jQuery takes down the Guardian Andrew Poulos <ap_prog@hotmail.com> - 2011-11-04 12:50 +1100
      Re: jQuery takes down the Guardian David Mark <dmark.cinsoft@gmail.com> - 2011-11-04 03:37 -0700
    Re: jQuery takes down the Guardian "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2011-11-05 07:36 -0700

#7962 — jQuery takes down the Guardian

From	David Mark <dmark.cinsoft@gmail.com>
Date	2011-11-03 12:52 -0700
Subject	jQuery takes down the Guardian
Message-ID	<32fd8b28-5e5b-4d8e-818b-49b12ccdac2b@a7g2000yqd.googlegroups.com>

Nah, those fabled attr issues don't cause problems in the "real
world".

http://www.guardian.co.uk/info/developer-blog/2011/nov/03/javascript-upgrade-comment-platform

I'm so jealous of those (soon to be) unemployed developers. :)

[toc] | [next] | [standalone]

#7964

From	RobG <rgqld@iinet.net.au>
Date	2011-11-03 13:56 -0700
Message-ID	<5809e801-f3de-4455-990e-bb80b4635f5d@v5g2000vbh.googlegroups.com>
In reply to	#7962

On Nov 4, 5:52 am, David Mark <dmark.cins...@gmail.com> wrote:
> Nah, those fabled attr issues don't cause problems in the "real
> world".
>
> http://www.guardian.co.uk/info/developer-blog/2011/nov/03/javascript-...
>
> I'm so jealous of those (soon to be) unemployed developers.

The article itself seems somewhat clueless. The markup examples use
XHTML, yet The Guardian web site uses <!DOCTYPE html>[1].

They seem to be under the illusion that javascript changes the markup.

There is also:

|  In jQuery 1.6, this method now returns "undefined",
|  which Javascript gurus will know is not the same
|  as false (unless you use === comparison).

Really?

Anyhow, a design "feature" to wait for the user to start typing before
enabling the submit button is plain dumb.

But kudos for being honest.

1. http://www.guardian.co.uk/

--
Rob

[toc] | [prev] | [next] | [standalone]

#7967

From	Matt McDonald <matt@fortybelow.ca>
Date	2011-11-03 15:47 -0600
Message-ID	<j8v255$olk$1@dont-email.me>
In reply to	#7964

On 11-11-03 2:56 PM, RobG wrote:
> They seem to be under the illusion that javascript changes the markup.

No, merely the illusion that setting a boolean attribute *value* to an 
empty string removes it (it doesn't). It still yields a DOM property of 
*true*, which clearly baffled them. Blame the software, not the 
implementer, right? *dunce*

Coincidentally, jQuery 1.7 hit the internet today. They sure have 
impeccable timing.

[toc] | [prev] | [next] | [standalone]

#7968

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Date	2011-11-04 00:24 +0100
Message-ID	<2020040.YEL58v44cs@PointedEars.de>
In reply to	#7967

Matt McDonald wrote:

> On 11-11-03 2:56 PM, RobG wrote:
>> They seem to be under the illusion that javascript changes the markup.
> 
> No, merely the illusion that setting a boolean attribute *value* to an
> empty string removes it (it doesn't). It still yields a DOM property of
> *true*, which clearly baffled them. Blame the software, not the
> implementer, right? *dunce*

They are completely delusional as they actually believe in "Javascript 
upgrade" (sic!) (when they mean jQuery upgrade instead).  After reading its 
title I already knew I did not have to waste more time on that article.
 
> Coincidentally, jQuery 1.7 hit the internet today. They sure have
> impeccable timing.

ACK


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

[toc] | [prev] | [next] | [standalone]

#7969

From	RobG <rgqld@iinet.net.au>
Date	2011-11-03 16:30 -0700
Message-ID	<afac1af0-1b98-4de4-b34b-f763df2411fb@h24g2000yqm.googlegroups.com>
In reply to	#7967

On Nov 4, 7:47 am, Matt McDonald <m...@fortybelow.ca> wrote:
> On 11-11-03 2:56 PM, RobG wrote:
>
> > They seem to be under the illusion that javascript changes the markup.
>
> No, merely the illusion that setting a boolean attribute *value* to an
> empty string removes it (it doesn't).

I have no idea what the attr method actually does in either version of
jQuery in this case, so I don't know what the actual effect on the DOM
is.

However, the HTML disabled attribute doesn't have a value at all, its
presence or absence changes the value of the related boolean DOM
property (something that is maintained in HTML5[1]), which is what the
document claimed to be). Attempting to explain the effect of jQuery's
attr using XHTML markup for an HTML document is an indicator that they
still don't know what is going on.

Interestingly, if they'd actually the latest HTML5 draft, they'd have
seen that this exact case is pointed out in section 1.9.3 under
"Errors that indicate a likely misunderstanding of the
specification"[2]:

|  For example, setting the disabled attribute to the value
|  "false" is disallowed, because despite the appearance of
|  meaning that the element is enabled, it in fact means that
|  the element is disabled (what matters for implementations
|  is the presence of the attribute, not its value).

The authors of HTML5 seem to delight in confusion since they
constantly refer to "attributes" in the context of both HTML
attributes and DOM properties.

> It still yields a DOM property of
> *true*, which clearly baffled them.

It may set the related DOM "disabled" property to true.

> Blame the software, not the
> implementer, right? *dunce*

Clearly they had no idea what the method actually does, and even if
they did, they don't seem to understand HTML DOMs anyway.

> Coincidentally, jQuery 1.7 hit the internet today. They sure have
> impeccable timing.

I guess it will roll out in their regular second Tuesday update.

1. http://dev.w3.org/html5/spec/Overview.html#attr-fe-disabled
2. http://dev.w3.org/html5/spec/Overview.html#restrictions-on-content-models-and-on-attribute-values

--
Rob

[toc] | [prev] | [next] | [standalone]

#7973

From	Matt McDonald <matt@fortybelow.ca>
Date	2011-11-03 19:16 -0600
Message-ID	<j8vecn$9fl$1@dont-email.me>
In reply to	#7969

On 11/3/2011 5:30 PM, RobG wrote:
> However, the HTML disabled attribute doesn't have a value at all, its
> presence or absence changes the value of the related boolean DOM
> property (something that is maintained in HTML5[1]), which is what the
> document claimed to be).

It all depends on the doctype, really.
HTML 4.01[0] and HTML 5[1] validate both the minimized and maximized 
forms, so (psuedocode):

* boolean
* boolean=""
* boolean="boolean"

XHTML 1.0 only validates the maximized form[2], so (pseudocode):

* boolean="boolean"

> The authors of HTML5 seem to delight in confusion since they
> constantly refer to "attributes" in the context of both HTML
> attributes and DOM properties.

Yes, the usage of "IDL attribute" as an alias for "DOM property" is 
quite confusing upon first glance. It seems it's because "idl" is the 
filetype in which these properties are defined as "attributes". Here's a 
look at one:

http://www.w3.org/TR/DOM-Level-2-HTML/idl/html2.idl

Clear as mud, right? ;)

> It may set the related DOM "disabled" property to true.

Ha, good catch. I was in a hurry this afternoon, so forgive the lack of 
elaboration.

Not to be a stickler, but I'd suggest linking to the HTML 5 spec via the 
multipaged version[3]. The full spec is a real hog. :)

[0]: http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.3.4.2
[1]: 
http://dev.w3.org/html5/spec/common-microsyntaxes.html#boolean-attributes
[2]: http://www.w3.org/TR/xhtml1/#h-4.5
[3]: http://dev.w3.org/html5/spec/spec.html

-- 
Matt McDonald: Web/Flash Developer; Edmonton, Alberta, Canada

[toc] | [prev] | [next] | [standalone]

#7980

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Date	2011-11-04 11:05 +0100
Message-ID	<3000820.SPkdTlGXAF@PointedEars.de>
In reply to	#7973

Matt McDonald wrote:

> On 11/3/2011 5:30 PM, RobG wrote:
>> However, the HTML disabled attribute doesn't have a value at all, its
>> presence or absence changes the value of the related boolean DOM
>> property (something that is maintained in HTML5[1]), which is what the
>> document claimed to be).
> 
> It all depends on the doctype, really.
> HTML 4.01[0] and HTML 5[1] validate both the minimized and maximized
> forms, so (psuedocode):
> 
> * boolean
> * boolean=""
> * boolean="boolean"
> 
> XHTML 1.0

XHTML in general.

> only validates the maximized form[2], so (pseudocode):
> 
> * boolean="boolean"

The statement "$markup_language validates only …" does not make sense.  A 
*validator* validates code supposedly written in $markup_language against 
the formal specification of $markup_language.  Therefore, a proper 
expression would be "… is valid in $markup_language" or "$markup_language 
requires …".

>> The authors of HTML5 seem to delight in confusion since they
>> constantly refer to "attributes" in the context of both HTML
>> attributes and DOM properties.
> 
> Yes, the usage of "IDL attribute" as an alias for "DOM property" is
> quite confusing upon first glance. It seems it's because "idl" is the
> filetype in which these properties are defined as "attributes".

No, the Object Management Group (OMG) Interface Definition Language (IDL), a 
C++-like interface description language which has been developed for CORBA, 
is the preferred form of specifying language-independent (W3C) DOM 
interfaces.  The filename suffix (which you misname "filetype") is only 
evidence of that.

> Here's a look at one:
> 
> http://www.w3.org/TR/DOM-Level-2-HTML/idl/html2.idl
> 
> Clear as mud, right? ;)

It is very clear.  Problems arise when one fails to differentiate between 
language-independent IDL attributes, properties that implement them in a 
specific programming language, and markup attributes of a specific related 
SGML-rooted markup language like HTML or XHTML.

PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#7984

From	Eric Bednarz <bednarz@fahr-zur-hoelle.org>
Date	2011-11-04 13:25 +0100
Message-ID	<m2aa8caxci.fsf@nntp.bednarz.nl>
In reply to	#7973

Matt McDonald <matt@fortybelow.ca> writes:

> HTML 4.01[0] and HTML 5[1] validate both the minimized and maximized
> forms, so (psuedocode):
>
> * boolean
> * boolean=""

That is obviously *not* valid in HTML 4. You can omit the attribute
name, not the value.

> * boolean="boolean"

-- 
λ

[toc] | [prev] | [next] | [standalone]

#7989

From	Denis McMahon <denismfmcmahon@gmail.com>
Date	2011-11-04 15:33 +0000
Message-ID	<4eb405e1$0$28490$a8266bb1@newsreader.readnews.com>
In reply to	#7984

On Fri, 04 Nov 2011 13:25:17 +0100, Eric Bednarz wrote:

> Matt McDonald <matt@fortybelow.ca> writes:

>> HTML 4.01[0] and HTML 5[1] validate both the minimized and maximized
>> forms, so (psuedocode):

>> * boolean=""

> That is obviously *not* valid in HTML 4. You can omit the attribute
> name, not the value.

Indeed, testing the following on the w3 validator:

<input type="checkbox" checked>
<input type="checkbox" checked=>
<input type="checkbox" checked="">
<input type="checkbox" checked="fred">
<input type="checkbox" checked="checked">

Only two are valid:

<input type="checkbox" checked="checked">
<input type="checkbox" checked>

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#7972

From	"J.R." <groups_jr-1@yahoo.com.br>
Date	2011-11-03 22:42 -0200
Message-ID	<j8vcdu$vuh$1@speranza.aioe.org>
In reply to	#7964

On 03/11/2011 18:56, RobG wrote:
> On Nov 4, 5:52 am, David Mark<dmark.cins...@gmail.com>  wrote:
>> Nah, those fabled attr issues don't cause problems in the "real
>> world".
>>
>> http://www.guardian.co.uk/info/developer-blog/2011/nov/03/javascript-...
>>
>> I'm so jealous of those (soon to be) unemployed developers.
>
> The article itself seems somewhat clueless. The markup examples use
> XHTML, yet The Guardian web site uses<!DOCTYPE html>[1].
>
> They seem to be under the illusion that javascript changes the markup.
>
> There is also:
>
> |  In jQuery 1.6, this method now returns "undefined",
> |  which Javascript gurus will know is not the same
> |  as false (unless you use === comparison).
>
> Really?
>
> Anyhow, a design "feature" to wait for the user to start typing before
> enabling the submit button is plain dumb.
>
> But kudos for being honest.
>
>
> 1. http://www.guardian.co.uk/
>

The page 3 site of "The Sun" uses JQuery too, but it seems that no one 
cares about it...

Cheers,
JR

[toc] | [prev] | [next] | [standalone]

#7974

From	Andrew Poulos <ap_prog@hotmail.com>
Date	2011-11-04 12:50 +1100
Message-ID	<QvmdndCMJ8p22S7TnZ2dnUVZ_rKdnZ2d@westnet.com.au>
In reply to	#7962

On 4/11/2011 6:52 AM, David Mark wrote:
> Nah, those fabled attr issues don't cause problems in the "real
> world".
>
> http://www.guardian.co.uk/info/developer-blog/2011/nov/03/javascript-upgrade-comment-platform

The issue would be no different to a lead developer changing a feature 
of some custom js code a project ran on and failed to document it 
properly, or that those underneath her didn't understand js well enough.

To be fair, even though they don't understand the issues they were able 
to fix it pretty quickly (in that they were able to get their site 
working "properly"). The next time they'll just test first before they 
deploy.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#7981

From	David Mark <dmark.cinsoft@gmail.com>
Date	2011-11-04 03:37 -0700
Message-ID	<02f18aae-2192-4da2-a8b0-191179dbdea7@o19g2000vbk.googlegroups.com>
In reply to	#7974

On Nov 3, 9:50 pm, Andrew Poulos <ap_p...@hotmail.com> wrote:
> On 4/11/2011 6:52 AM, David Mark wrote:
>
> > Nah, those fabled attr issues don't cause problems in the "real
> > world".
>
> >http://www.guardian.co.uk/info/developer-blog/2011/nov/03/javascript-...
>
> The issue would be no different to a lead developer changing a feature
> of some custom js code a project ran on and failed to document it
> properly, or that those underneath her didn't understand js well enough.

Sort of. The problem is that Web developers abdicate responsibility to
"lead developers" that they don't know. Their only documentation is
the jQuery documentation, which is rubbish. For years, the "attr"
function has been documented to get/set attributes, but it never did
that at all (except when it "detected" an XML DOM). The well-
documented boondoggle with jQuery 1.6 was the result of changing the
method to match the name/documentation (and never mind that it broke
thousands of extant apps). Then they put it back the way it used to be
on the next release. They are just going around in circles.

>
> To be fair, even though they don't understand the issues they were able
> to fix it pretty quickly (in that they were able to get their site
> working "properly"). The next time they'll just test first before they
> deploy.

What they did is the standard mystical incantation: rearranging
patterns of code until they seem to work. Ultimately, they settled on
using the "removeAttr" method, which was the centerpiece of my last
jQuery review. For those who missed it, that method is confused
nonsense as well (and changes periodically as their "test-driven"
knowledge gathering reveals more cracks in their assumptions). If only
they would RTFM, they wouldn't be causing so much confusion among
beginners who rely on their "expertise" to keep them out of trouble.

[toc] | [prev] | [next] | [standalone]

#8040

From	"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date	2011-11-05 07:36 -0700
Message-ID	<5accba40-2223-4781-b1f4-18f46139709b@eh5g2000vbb.googlegroups.com>
In reply to	#7962

On Nov 3, 2:52 pm, David Mark <dmark.cins...@gmail.com> wrote:
> Nah, those fabled attr issues don't cause problems in the "real
> world".
>
> http://www.guardian.co.uk/info/developer-blog/2011/nov/03/javascript-...
>
> I'm so jealous of those (soon to be) unemployed developers. :)


Repent sinner.

"[...]nothing goes into jQuery that
cannot be reproduced in...

IE 6, 7, 8 & 9
Firefox 3.6, 6 & 7
Chrome 14, 15
Safari 5, 5.1
Opera 11.01, 11.5

[...]"

<https://mail.mozilla.org/pipermail/es-discuss/2011-November/
017993.html>

[toc] | [prev] | [standalone]

csiph-web

jQuery takes down the Guardian

Contents

#7962 — jQuery takes down the Guardian

#7964

#7967

#7968

#7969

#7973

#7980

#7984

#7989

#7972

#7974

#7981

#8040