jQuery takes down the Guardian

R

RobG

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/
 
M

Matt McDonald

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.
 
T

Thomas 'PointedEars' Lahn

Matt said:
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
 
R

RobG

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
 
J

J.R.

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
 
M

Matt McDonald

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
 
T

Thomas 'PointedEars' Lahn

Matt said:
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 …".
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
 
D

David Mark

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.
 
E

Eric Bednarz

Matt McDonald said:
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.
 
D

Denis McMahon

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
 
M

Michael Haufe (TNO)

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top