subject:"\[WSG\] Javascript"

Interesting blog entry by the creators of the Cappuccino project 
(http://cappuccino.org) on the subject on Web Accessibility vs 
JavaScript Availability:


http://rossboucher.com/2009/02/26/accessibility-degradation-in-cappuccino

Personally im in favour of the distinction he makes, but the expectation 
for the WAI ARIA team to contact _them_ to help their framework use it 
is rather unrealistic although the WAI ARIA team (as with the W3C in 
general) need to start producing more palatable documentation rather 
than just having huge technical manuals on the subject.


Interested to know others thoughts on the subject.

David

--
David Dixon

t: 07967 569 489
e: da...@digitaloasis.co.uk

linkedin | http://www.linkedin.com/in/davidjdixon
twitter  | http://twitter.com/daviddixon



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

RE: [WSG] Javascript Accessibility

2009-03-02 Thread michael.brockington

David,
I think you are reading things differently to me. I don't know the
authors true intention, but I read his words as being a call for anyone
who wants to see ARIA implemented to join their team, not necessarily
someone who is on the ARIA team.

I do also agree with the sentiments though - there is an obvious need to
treat 'applications' differently from 'content' in quite a number of
ways, and at the moment there is not even a way to signal this
explicitly.

Regards,
Mike


-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org]
On Behalf Of David Dixon
Sent: 01 March 2009 14:33
To: li...@webstandardsgroup.org
Subject: [WSG] Javascript  Accessibility

Interesting blog entry by the creators of the Cappuccino project
(http://cappuccino.org) on the subject on Web Accessibility vs
JavaScript Availability:

http://rossboucher.com/2009/02/26/accessibility-degradation-in-cappuccin
o

Personally im in favour of the distinction he makes, but the expectation
for the WAI ARIA team to contact _them_ to help their framework use it
is rather unrealistic although the WAI ARIA team (as with the W3C in
general) need to start producing more palatable documentation rather
than just having huge technical manuals on the subject.

Interested to know others thoughts on the subject.

David


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Javascript Accessibility

2009-03-02 Thread Mathew Robertson





 David Dixon da...@terrainferno.net wrote:
 
 Interesting blog entry by the creators of the Cappuccino project 
 (http://cappuccino.org) on the subject on Web Accessibility vs 
 JavaScript Availability:
 
 http://rossboucher.com/2009/02/26/accessibility-degradation-in-cappuccino
 
 
 Personally im in favour of the distinction he makes, but the expectation 
 
 for the WAI ARIA team to contact _them_ to help their framework use it 
 is rather unrealistic although the WAI ARIA team (as with the W3C in 
 general) need to start producing more palatable documentation rather 
 than just having huge technical manuals on the subject.
 
 Interested to know others thoughts on the subject.

Its been possible to do ARIA style accessibility since about 1995 - its just 
now that people are starting to care.

Mathew Robertson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Javascript Accessibility


michael.brocking...@bt.com wrote:

David,
I think you are reading things differently to me. I don't know the
authors true intention, but I read his words as being a call for anyone
who wants to see ARIA implemented to join their team, not necessarily
someone who is on the ARIA team.


Thanks Mike, t'was a fairly minor point, but yes i think you're 
interpretation of the request is more accurate than my initial one.


David
--
David Dixon

t: 07967 569 489
e: da...@digitaloasis.co.uk

linkedin | http://www.linkedin.com/in/davidjdixon
twitter  | http://twitter.com/daviddixon


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Javascript Accessibility


Mathew Robertson wrote:
 Its been possible to do ARIA style accessibility since about 1995 - 
its just now that people are starting to care.


 Mathew Robertson

Before this question gets sidetracked, the request was for opinion on 
the position of the distinction of accessibility vs availability, not on 
WAI ARIA, apologies if the content of my original email didn't make this 
clear.


My issue with ARIA is one of documentation, and would prefer deal with 
ARIA in a separate conversation.


David
--
David Dixon

t: 07967 569 489
e: da...@digitaloasis.co.uk

linkedin | http://www.linkedin.com/in/davidjdixon
twitter  | http://twitter.com/daviddixon


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

RE: [WSG] Javascript Accessibility - ARIA

2009-03-02 Thread Foskett, Mike

Dude, that's a little unrealistic and a tad bitter:

  Its been possible to do ARIA style accessibility since about 1995 -
its just now that people are starting to care.

Personally I've been waiting for ARIA to come of age now both assistive
technologies and browsers offer support.
With the imminent release of IEv8 (with ARIA support) it's time to
re-examine state of play.
I'm interested in how's of implementation, and what's happening with W3C
validation?

Can it be used with XHTML v1.0 yet?
Will it ever be?
Does serving the page as text/html still have issues?
Is there a fully usable Doctype yet?
Is there a simple method to implement liveregion areas?

Any news or thoughts greatly appreciated.


Mike Foskett
http://websemantics.co.uk/


-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org]
On Behalf Of Mathew Robertson
Sent: 02 March 2009 10:03
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] Javascript  Accessibility





 David Dixon da...@terrainferno.net wrote:

 Interesting blog entry by the creators of the Cappuccino project
 (http://cappuccino.org) on the subject on Web Accessibility vs
 JavaScript Availability:


http://rossboucher.com/2009/02/26/accessibility-degradation-in-cappuccin
o


 Personally im in favour of the distinction he makes, but the
expectation

 for the WAI ARIA team to contact _them_ to help their framework use it

 is rather unrealistic although the WAI ARIA team (as with the W3C in
 general) need to start producing more palatable documentation rather
 than just having huge technical manuals on the subject.

 Interested to know others thoughts on the subject.

Its been possible to do ARIA style accessibility since about 1995 - its
just now that people are starting to care.

Mathew Robertson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***


This is a confidential email. Tesco may monitor and record all emails. The 
views expressed in this email are those of the sender and not Tesco.

Tesco Stores Limited
Company Number: 519500
Registered in England
Registered Office: Tesco House, Delamare Road, Cheshunt, Hertfordshire EN8 9SL
VAT Registration Number: GB 220 4302 31


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Javascript Accessibility

2009-03-02 Thread Matt Morgan-May

On 3/2/09 2:02 AM, Mathew Robertson mat...@optusnet.com.au wrote:
 Its been possible to do ARIA style accessibility since about 1995 - its just
 now that people are starting to care.

Not sure what value you were hoping to add to the conversation, but MSAA,
the Windows accessibility API, didn't come out until April 1997. And that
much of what ARIA has to offer is actually enabled by the IAccessible2 or
User Interface Automation APIs, which are much more recent and
comprehensive. ARIA is a very ambitious spec, and a number of companies
contributing to its support in a very short period of time, relative to the
work that's necessary.

But, thanks for the cynicism! We don't get enough of that on the Internet
these days. :)

-
m



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Javascript Accessibility

Guys please, move this to a different topic, this ARIA issue has now 
clouded the original question.


David
--
David Dixon

t: 07967 569 489
e: da...@digitaloasis.co.uk

linkedin | http://www.linkedin.com/in/davidjdixon
twitter  | http://twitter.com/daviddixon

Matt Morgan-May wrote:

As someone who's on the working group producing ARIA, I have to say the
editors have done a pretty remarkable job in terms of documenting a
specification that hasn't even advanced past Working Draft.

First, there's the spec itself:
http://www.w3.org/TR/wai-aria/

Then there's the User Agent Implementation Guide, for browser developers to
follow:
http://www.w3.org/TR/wai-aria-implementation/

And the Best Practices Guide, for authors:
http://www.w3.org/TR/wai-aria-practices/

In addition, Steve Faulkner, also in the PFWG, has done lots of writing on
the subject:
http://www.paciellogroup.com/blog/?cat=23

And Universal Design for Web Applications, the book I co-wrote with Wendy
Chisholm, has a more basic introductory chapter on ARIA. The point is, it
may not all have a W3C banner at the top, but generally speaking, W3C is
more responsible for being complete and precise, than being prosaic. I
expect that the Web Standards Curriculum is most likely to have
author-friendly material on ARIA, and that's only when the spec is stable
enough for general consumption.

-
m

On 3/1/09 6:32 AM, David Dixon da...@terrainferno.net wrote:

although the WAI ARIA team (as with the W3C in
general) need to start producing more palatable documentation rather
than just having huge technical manuals on the subject.




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***





***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Javascript Accessibility

2009-03-02 Thread Al Sparber


On 3/2/09 2:02 AM, Mathew Robertson mat...@optusnet.com.au wrote:
Its been possible to do ARIA style accessibility since about 1995 - its 
just

now that people are starting to care.


But ARIA, as deployed by companies like Yahoo with its ARIA Menu [1] is very 
nice, but with JavaScript disabled there is a not-so-nice blank page.


[1] http://developer.yahoo.com/yui/examples/menu/menuwaiaria_source.html

Getting worked up over stuff like, for the average developer/designer is 
going to be as illogical and incongruous as ever.


--
Al Sparber - PVII
http://www.projectseven.com







***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] JavaScript and Accessibility

2009-01-20 Thread Simon Pascal Klein

I thought a bit more about this and I realised perhaps a better option  
would be to display the JS-injected messages and errors that a screen  
reader could not read but upon submission of the form, reload the page  
and provide all the messages and errors again (the form could not be  
completed anyway due to the errors; where else would to send the user  
to?). This way users browsing with an accessibility aid like a screen  
reader would not see the injected errors which are a nifty feature but  
still be presented with them upon submission of the form and the page  
reload.


Why I didn’t think of this earlier is beyond me. D’oh.


—Pascal


On 20/01/2009, at 12:57 PM, james.duc...@gmail.com wrote:

after all it's impossible to tell those users using an  
accessibility aid like a screen reader
from those who do not, and hey, the growing number of users who  
purposefully disable

JavaScript won't see the glitzy JavaScript injected errors anyway.


Agreed, and any decent validation is going to be done server-side
validation anyway, so you're going to have to (or at least you should)
implement the server-side responses in any case.

- James

--
James Ducker
Web Developer
http://www.studioj.net.au


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



---
Simon Pascal Klein
Concept designer

(w) http://klepas.org
(e) kle...@klepas.org



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

RE: [WSG] JavaScript and Accessibility

2009-01-20 Thread Chris Taylor

 From: Chris Knowles
 I wouldn't be waiting for ARIA to get out of draft before using it :) It
 has pretty good support in browsers already so get stuck in. And because
 essentially all you are doing with ARIA is adding attributes to tags,
 the worst that can happen is your pages no longer validate - but who
 cares if you are making them more accessible?

I think validation is still important to ensure a consistent and future-proof 
experience across browsers, but ARIA is definitely needed. So seeing as ARIA 
attributes are there to offer a solution to problems introduced by JavaScript, 
why don't we use JavaScript to add the ARIA attributes. Using a similar idea to 
my Performer script [1] we could add these using CSS:

p id=updates class=aria-live-politeThis content will be updated by an 
AJAX-type script/p

A simple script could parse all elements in the DOM tree, and anything with the 
class aria-live-polite add the attribute aria-live with a value of 
polite. If this was done before any other JavaScript was run it would prepare 
the page with ARIA attributes before it is needed, whilst keeping the code 
validating. The resulting code in this example would be:

p id=updates class=aria-live-polite aria-live=politeThis content will 
be updated by an AJAX-type script/p

Of course, elements with ARIA classes could be styled differently if required:

.aria-live-polite { border: 1px dotted #CCC; }

If JavaScript is not present or disabled, the ARIA attributes will not get 
applied. But that won't be a problem, as no other JavaScript will be run anyway.

There are actually a lot of ARIA attribute variations so this idea may not 
scale very well, but for simple use it may be a suitable answer to the ARIA / 
validation problem.

Chris

[1] http://performerjs.org - add JavaScript features using just CSS classes and 
standard attributes. New website and lots more features coming very soon. Get 
in touch if you'd be interested in helping / testing.


This message has been scanned for malware by SurfControl plc. 
www.surfcontrol.com

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

RE: [WSG] JavaScript and Accessibility

2009-01-20 Thread Chris Taylor

 From: Chris Knowles
 yes, so you still run your code through the validator and make sure it
 only fails on the ARIA attributes -  that way you save yourself a whole
 lot of trouble. I don't really understand inserting attributes with
 javascript just so you get a tick from the validator? Maybe I'm missing
 something but what benefit does that bring? And validators will catch up
 at some point anyway.

Quite apart from the satisfaction I get from those green ticks (I loves me them 
green ticks), I think providing a validating page to the browser is an 
important part of creating a web that is accessible to all. We all know the 
problems that certain (ahem) browser manufacturers have with a 
properly-validating document, but if we have these document definitions in 
place we should use them.

Adding ARIA attributes using JavaScript is therefore part of progressive 
enhancement, much like using any AJAX-type features is - or at least should be. 
It's not ideal, I'm not pretending for one minute it is, but that's the web 
world we live in.

Hopefully, in the fullness of time, all these measures will become unnecessary 
and we'll all bask in the warm glow of browsers that natively handle all the 
goodies which are being waved in front of our noses (not just ARIA, CSS3, HTML5 
etc). But I'm not holding my breath for that day.

Chris


This message has been scanned for malware by SurfControl plc. 
www.surfcontrol.com

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] JavaScript and Accessibility

2009-01-20 Thread Chris Knowles

Chris Taylor wrote:
 From: Chris Knowles
 I wouldn't be waiting for ARIA to get out of draft before using it :) It
 has pretty good support in browsers already so get stuck in. And because
 essentially all you are doing with ARIA is adding attributes to tags,
 the worst that can happen is your pages no longer validate - but who
 cares if you are making them more accessible?

 I think validation is still important to ensure a consistent and
future-proof experience across browsers

yes, so you still run your code through the validator and make sure it
only fails on the ARIA attributes -  that way you save yourself a whole
lot of trouble. I don't really understand inserting attributes with
javascript just so you get a tick from the validator? Maybe I'm missing
something but what benefit does that bring? And validators will catch up
at some point anyway.

-- 
Chris Knowles


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] JavaScript and Accessibility

2009-01-20 Thread Chris Knowles

Chris Taylor wrote:

 Adding ARIA attributes using JavaScript is therefore part of progressive 
 enhancement

does that actually work? My understanding is that one problem ARIA
addresses is that when javascript alters the DOM, assistive technologies
don't necessarily get notified of the changes. So do they get notified
that you've injected ARIA attributes?

-- 
Chris Knowles


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

RE: [WSG] JavaScript and Accessibility

2009-01-20 Thread Chris Taylor

 -Original Message-
 From: Chris Knowles
 does that actually work? My understanding is that one problem ARIA
 addresses is that when javascript alters the DOM, assistive technologies
 don't necessarily get notified of the changes. So do they get notified
 that you've injected ARIA attributes?

The thought had crossed my mind, but unfortunately I have no reliable way to 
test it. If anyone wants to let us know whether this idea is a goer, I'd be 
very grateful.

Chris


This message has been scanned for malware by SurfControl plc. 
www.surfcontrol.com

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] JavaScript and Accessibility

2009-01-19 Thread Simon Pascal Klein

If there were further communication between the user and server  
between submission of the form that would entail a page reload then a  
screen user shouldn’t have an issue, whereas if JavaScript would run  
in the background and inject errors or suggestions as it thinks the  
user makes them (e.g. password complexity recommendations, username  
not available messages) numerous accessibility issues arise.


The only solution that came to mind was having a generic message (such  
as ‘please fill out all marked (*) fields’ or the like) that could be  
hidden using CSS and through JavaScript ‘unhidden’ when an error  
appears (though it could only be a generic error). As dandy as these  
automatic feedback and error messages are through JavaScript maybe a  
full submission and subsequent page reload is best—after all it’s  
impossible to tell those users using an accessibility aid like a  
screen reader from those who do not, and hey, the growing number of  
users who purposefully disable JavaScript won’t see the glitzy  
JavaScript injected errors anyway.


Just my 0.2¢.


On 19/01/2009, at 5:52 PM, Rimantas Liubertas wrote:


Isn't 'aria-required' a non-standard attribute?


Sadly, yes. But there is some hope: it is possible that ARIA will be
accepted in HTML5 and there is an initiative to provide validation for
(X)HTML+ARIA: http://lists.w3.org/Archives/Public/wai-xtech/2008Sep/0381.html

Validator.nu already has experimental support for HTML5+ARIA, and I
believe (did not check) http://qa-dev.w3.org/wmvs/HEAD/ provides the
same for document type HTML5.

There is also a possibility to add ARIA attributes with Javascript.
All the options are controversial, but that's how it is for now :(

Regards,
Rimantas
--
http://rimantas.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



---
Simon Pascal Klein
Concept designer

(w) http://klepas.org
(e) kle...@klepas.org



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

RE: [WSG] JavaScript and Accessibility

2009-01-19 Thread michael.brockington

There were a couple of articles on SitePoint (if I recall correctly) six
months ago or so, that covered this, in a fairly positive light.
I'm afraid I'm not in a position to chase after them right now; perhaps
someone else does have the time?

Mike 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] JavaScript and Accessibility

2009-01-19 Thread james . ducker

 after all it's impossible to tell those users using an accessibility aid like 
 a screen reader
 from those who do not, and hey, the growing number of users who purposefully 
 disable
 JavaScript won't see the glitzy JavaScript injected errors anyway.

Agreed, and any decent validation is going to be done server-side
validation anyway, so you're going to have to (or at least you should)
implement the server-side responses in any case.

- James

-- 
James Ducker
Web Developer
http://www.studioj.net.au


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] JavaScript and Accessibility

2009-01-19 Thread james . ducker

Hmm, I made a typo. Coffee time.

On 1/20/09, james.duc...@gmail.com james.duc...@gmail.com wrote:
 after all it's impossible to tell those users using an accessibility aid
 like a screen reader
 from those who do not, and hey, the growing number of users who
 purposefully disable
 JavaScript won't see the glitzy JavaScript injected errors anyway.

 Agreed, and any decent validation is going to be done server-side
 validation anyway, so you're going to have to (or at least you should)
 implement the server-side responses in any case.

 - James

 --
 James Ducker
 Web Developer
 http://www.studioj.net.au



-- 
James Ducker
Web Developer
http://www.studioj.net.au


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] JavaScript and Accessibility

2009-01-19 Thread Anthony Ziebell





Server side validation is of course a must...
however, if the visually impaired visitor has _javascript_ turned on and
these error elements are created, they won't exactly get to the server
side validation now, will they? ARIA looks good, looking forward to it
getting out of draft status.

Thanks,
Anthony.


james.duc...@gmail.com wrote:

  Hmm, I made a typo. Coffee time.

On 1/20/09, james.duc...@gmail.com james.duc...@gmail.com wrote:
  
  

  after all it's impossible to tell those users using an accessibility aid
like a screen reader
from those who do not, and hey, the growing number of users who
purposefully disable
_javascript_ won't see the glitzy _javascript_ injected errors anyway.
  

Agreed, and any decent validation is going to be done server-side
validation anyway, so you're going to have to (or at least you should)
implement the server-side responses in any case.

- James

--
James Ducker
Web Developer
http://www.studioj.net.au


  
  

  




***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***

Re: [WSG] JavaScript and Accessibility

2009-01-19 Thread james . ducker

Sorry, I was a bit vague. I'm saying do all validation server-side. If
you're looking for a quick and dirty solution to the element injection
issues when screen readers are being used, you can try setting focus
back to the new element's parent, though shifting focus is a practice
often frowned upon.

On 1/20/09, Anthony Ziebell anth...@fatpublisher.com.au wrote:
 Server side validation is of course a must... however, if the visually
 impaired visitor has JavaScript turned on and these error elements are
 created, they won't exactly get to the server side validation now, will
 they? ARIA looks good, looking forward to it getting out of draft status.

 Thanks,
 Anthony.


 james.duc...@gmail.com wrote:

 Hmm, I made a typo. Coffee time.

 On 1/20/09, james.duc...@gmail.com james.duc...@gmail.com wrote:


 after all it's impossible to tell those users using an accessibility aid
 like a screen reader
 from those who do not, and hey, the growing number of users who
 purposefully disable
 JavaScript won't see the glitzy JavaScript injected errors anyway.


 Agreed, and any decent validation is going to be done server-side
 validation anyway, so you're going to have to (or at least you should)
 implement the server-side responses in any case.

 - James

 --
 James Ducker
 Web Developer
 http://www.studioj.net.au






 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***


-- 
James Ducker
Web Developer
http://www.studioj.net.au


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] JavaScript and Accessibility

2009-01-19 Thread Chris Knowles

Anthony Ziebell wrote:
 ARIA looks good, looking forward to it getting out of draft status.

I wouldn't be waiting for ARIA to get out of draft before using it :) It
has pretty good support in browsers already so get stuck in. And because
essentially all you are doing with ARIA is adding attributes to tags,
the worst that can happen is your pages no longer validate - but who
cares if you are making them more accessible?

-- 
Chris Knowles


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] JavaScript and Accessibility

2009-01-19 Thread Anthony Ziebell





My only concern with a draft is that things change...

Chris Knowles wrote:

  Anthony Ziebell wrote:
  
  
ARIA looks good, looking forward to it getting out of draft status.

  
  
I wouldn't be waiting for ARIA to get out of draft before using it :) It
has pretty good support in browsers already so get stuck in. And because
essentially all you are doing with ARIA is adding attributes to tags,
the worst that can happen is your pages no longer validate - but who
cares if you are making them more accessible?

  




***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***

[WSG] JavaScript and Accessibility

2009-01-18 Thread Anthony Ziebell





Hey group,

Does anyone have any ideas on standards based form validation, which is
non-obtrusive, however remains accessible?

Reason I ask, is that some form validations inject an element say under
a form input, explaining the error. Now, without any alerts, how would
a blind person / screen reader pick up the fact that the element is now
there and read out this error?

Has anyone been able to cater for this requirement?

Thanks,
Anthony.




***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***

Re: [WSG] JavaScript and Accessibility

2009-01-18 Thread nedlud

I'll confess my ignorance on this issue, but how do screen readers
handle DHTML type injection of content into the DOM?

Without using alerts, you could add the warning into the actual
document. But how does a screen reader know the document has changed?

L.

On Mon, Jan 19, 2009 at 4:30 PM, Anthony Ziebell
anth...@fatpublisher.com.au wrote:
 Hey group,

 Does anyone have any ideas on standards based form validation, which is
 non-obtrusive, however remains accessible?

 Reason I ask, is that some form validations inject an element say under a
 form input, explaining the error. Now, without any alerts, how would a blind
 person / screen reader pick up the fact that the element is now there and
 read out this error?

 Has anyone been able to cater for this requirement?

 Thanks,
 Anthony.

 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] JavaScript and Accessibility

2009-01-18 Thread Rimantas Liubertas

 Without using alerts, you could add the warning into the actual
 document. But how does a screen reader know the document has changed?

For starters: http://dev.opera.com/articles/view/introduction-to-wai-aria/

Regards,
Rimantas
--
http://rimantas.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] JavaScript and Accessibility

2009-01-18 Thread Anthony Ziebell





Isn't 'aria-required' a non-standard attribute?

Rimantas Liubertas wrote:

  
Without using alerts, you could add the warning into the actual
document. But how does a screen reader know the document has changed?

  
  
For starters: http://dev.opera.com/articles/view/introduction-to-wai-aria/

Regards,
Rimantas
--
http://rimantas.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***


  




***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***

[WSG] JavaScript as External File vs. Internal Code and linking to images

2009-01-06 Thread Brett Patterson

Recently, I experimented with changing check boxes with JavaScript. If the
user clicked on the words next to the check box, then the box would be
checked, once checked if the user clicked again, then the box would be
unchecked. I wound up having to apply the same code to the check box itself
in order to get it to work. In addition, I added code that would change the
background image of the page to either a solid color, if checked, or back to
the original image, if unchecked. It did not work. So after changing it some
more and still getting no results (I think I even asked here), I did some
research and found another way to link images directly in JavaScript.
I should make note that all the code was in an external file at the time.
The following is the structure of the site:

-container (the name of the containing folder for all files)
||
--index.html (home page where the code will be used)
--scripts (the scripts folder, contains all the scripts)
|
---scripts.js (the scripts file itself)
^^
--styles (stylesheets folder located directly within the container
folder)
||
---styles.css (contains style declarations)
^^
--images  (located directly within the container folder)
|
---linkedimage.png (the image to be changed in page background)

I hope the structure above makes sense. Anyway, while linking the image in
the scripts.js file, I found it never switched back, yet the code never
showed any problems. When I found the other way to link images directly in
JavaScript, I changed the image link code to what would amount to being
directly in the HTML file itself: The first is the original way I linked it
the second is the new way.

   - (../images/linkedimage.png);
   - from above, changed to
   - (images/linkedimage.png);

After the change above, the code worked. I went back to reading about the
JavaScript standard, I thought that JavaScript was read like an external CSS
file was read, where you would have to use the (../) part to link to the
image if it was in a different folder one level above the current folder.
(as the first line of code above is.) Is that not how JavaScript works? When
it comes to linked images?

--
Brett P.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] JavaScript as External File vs. Internal Code and linking to images

2009-01-06 Thread David Dorward


Brett Patterson wrote:
Recently, I experimented with changing check boxes with JavaScript. If 
the user clicked on the words next to the check box, then the box 
would be checked, once checked if the user clicked again, then the box 
would be unchecked.

Sounds like a label would have been easier.

I thought that JavaScript was read like an external CSS file was read, 
where you would have to use the (../) part to link to the image if it 
was in a different folder one level above the current folder. (as the 
first line of code above is.) Is that not how JavaScript works? When 
it comes to linked images?
You aren't reading the resource at the URL from JavaScript though - you 
are changing the DOM so it references a different URL (and it is still 
using the URI of the HTML document as a base).



--
David Dorward
http://dorward.me.uk/



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

RE: [WSG] JavaScript as External File vs. Internal Code and linking to images

2009-01-06 Thread Tatham Oddie

Brett,

 

CSS is defining the image links, so the paths are relative to the CSS file
itself.

 

JavaScript is a bit different. It is basically just setting properties on
the HTML elements and this is no different to setting those properties
yourself. As such, any image references are relative to the HTML page and
not the JS file.

 

Does that help?

 

 

(Disclaimer: I know this isn't the 100% perfect explanation of DHTML but it
serves the purpose of answering this question. If you're a JS nut, please
don't pounce.)

 

 

Thanks,

 

Tatham Oddie

 callto:+61414275989 call:+61414275989,  callto:+61280113982
call:+61280113982,  skype:tathamoddie?call skype:tathamoddie,
msnim:chat?contact=tat...@oddie.com.au msn:tat...@oddie.com.au,
http://tatham.oddie.com.au/ tatham.oddie.com.au

 

From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On
Behalf Of Brett Patterson
Sent: Wednesday, 7 January 2009 12:08 AM
To: wsg@webstandardsgroup.org
Subject: [WSG] JavaScript as External File vs. Internal Code and linking to
images

 

Recently, I experimented with changing check boxes with JavaScript. If the
user clicked on the words next to the check box, then the box would be
checked, once checked if the user clicked again, then the box would be
unchecked. I wound up having to apply the same code to the check box itself
in order to get it to work. In addition, I added code that would change the
background image of the page to either a solid color, if checked, or back to
the original image, if unchecked. It did not work. So after changing it some
more and still getting no results (I think I even asked here), I did some
research and found another way to link images directly in JavaScript. 
I should make note that all the code was in an external file at the time.
The following is the structure of the site:

-container (the name of the containing folder for all files)
||
--index.html (home page where the code will be used)
--scripts (the scripts folder, contains all the scripts)
|
---scripts.js (the scripts file itself)
^^
--styles (stylesheets folder located directly within the container
folder)
||
---styles.css (contains style declarations)
^^
--images  (located directly within the container folder)
|
---linkedimage.png (the image to be changed in page background)

I hope the structure above makes sense. Anyway, while linking the image in
the scripts.js file, I found it never switched back, yet the code never
showed any problems. When I found the other way to link images directly in
JavaScript, I changed the image link code to what would amount to being
directly in the HTML file itself: The first is the original way I linked it
the second is the new way.

*   (../images/linkedimage.png);
*   from above, changed to
*   (images/linkedimage.png);

After the change above, the code worked. I went back to reading about the
JavaScript standard, I thought that JavaScript was read like an external CSS
file was read, where you would have to use the (../) part to link to the
image if it was in a different folder one level above the current folder.
(as the first line of code above is.) Is that not how JavaScript works? When
it comes to linked images?

--
Brett P.

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] JavaScript as External File vs. Internal Code and linking to images

2009-01-06 Thread Brett Patterson

:) I like the disclaimer. Thanks to both of you, that does explain it. By
the way, I am not a JS nut. :) I am new.

--
Brett P.


On Tue, Jan 6, 2009 at 8:23 AM, Tatham Oddie tat...@oddie.com.au wrote:

  Brett,



 CSS is defining the image links, so the paths are relative to the CSS file
 itself.



 JavaScript is a bit different. It is basically just setting properties on
 the HTML elements and this is no different to setting those properties
 yourself. As such, any image references are relative to the HTML page and
 *not* the JS file.



 Does that help?





 (Disclaimer: I know this isn't the 100% perfect explanation of DHTML but it
 serves the purpose of answering this question. If you're a JS nut, please
 don't pounce.)





 Thanks,



 Tatham Oddie

 call:+61414275989 callto:+61414275989, 
 call:+61280113982callto:+61280113982,
 skype:tathamoddie, msn:tat...@oddie.com.au, tatham.oddie.com.au



 *From:* li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] *On
 Behalf Of *Brett Patterson
 *Sent:* Wednesday, 7 January 2009 12:08 AM
 *To:* wsg@webstandardsgroup.org
 *Subject:* [WSG] JavaScript as External File vs. Internal Code and linking
 to images



 Recently, I experimented with changing check boxes with JavaScript. If the
 user clicked on the words next to the check box, then the box would be
 checked, once checked if the user clicked again, then the box would be
 unchecked. I wound up having to apply the same code to the check box itself
 in order to get it to work. In addition, I added code that would change the
 background image of the page to either a solid color, if checked, or back to
 the original image, if unchecked. It did not work. So after changing it some
 more and still getting no results (I think I even asked here), I did some
 research and found another way to link images directly in JavaScript.
 I should make note that all the code was in an external file at the time.
 The following is the structure of the site:

 -container (the name of the containing folder for all files)
 ||
 --index.html (home page where the code will be used)
 --scripts (the scripts folder, contains all the scripts)
 |
 ---scripts.js (the scripts file itself)
 ^^
 --styles (stylesheets folder located directly within the container
 folder)
 ||
 ---styles.css (contains style declarations)
 ^^
 --images  (located directly within the container folder)
 |
 ---linkedimage.png (the image to be changed in page background)

 I hope the structure above makes sense. Anyway, while linking the image in
 the scripts.js file, I found it never switched back, yet the code never
 showed any problems. When I found the other way to link images directly in
 JavaScript, I changed the image link code to what would amount to being
 directly in the HTML file itself: The first is the original way I linked it
 the second is the new way.

- (../images/linkedimage.png);
- from above, changed to
- (images/linkedimage.png);

 After the change above, the code worked. I went back to reading about the
 JavaScript standard, I thought that JavaScript was read like an external CSS
 file was read, where you would have to use the (../) part to link to the
 image if it was in a different folder one level above the current folder.
 (as the first line of code above is.) Is that not how JavaScript works? When
 it comes to linked images?

 --
 Brett P.


 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***

 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] JavaScript as External File vs. Internal Code and linking to images

2009-01-06 Thread Ben Buchanan

 Recently, I experimented with changing check boxes with JavaScript. If the
 user clicked on the words next to the check box, then the box would be
 checked, once checked if the user clicked again, then the box would be
 unchecked.

As someone has mentioned, that's precisely what putting the text into a
label does (without the need for any javascript at all). I'm just curious
to know if you are using labels and/or if there was something in your
scenario that meant labels weren't producing the effect you wanted?

-- 
--- http://weblog.200ok.com.au/
--- The future has arrived; it's just not
--- evenly distributed. - William Gibson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] JavaScript clarification please - versions


Brett Patterson skrev:
I am sorry, but I must ask. Are you saying that the term JavaScript is 
owned by Sun? Or just the Java part? And, yes, JavaScript is implemented 
in Internet Explorer.




I see that your question has already been answered. I will give some 
additional points.


Mocha was Brendan Eich's internal name during initial development at 
Netscape. It was renamed LiveScript by him and his fellow enginers, but 
changed to JavaScript by the *marketing* department.


JScript in MSIE 6 and 7 is *roughly* comparable to JavaScript 1.2 and to 
ECMAScript 3.0.


There is a document, produced by MS, that in very high detail outlines 
how JScript, and other browsers JS engines, differs from the spec. It is 
available at https://developer.mozilla.org/en/JavaScript


The JavaScript support in Safari, Google Chrome and Opera is *roughly* 
comparable to JavaScript 1.5, and some parts of JavaScript 1.6.


(Note: 99 % of the time when one curses the differences between 
browsers, it is not because of their deviations from each other in 
Java/J/EcmaScript, but how they differ from each other on the DOM.)


Mozilla is allowed by the ECMAScript spec to develop JavaScript as a 
superset to ECMAScript, and indeed they have. JavaScript 1.8 contains 
quite a few features that (probably) will not even make it into 
ECMAScript 3.1 (generators, iterators, let-blocks - personally I really 
like let blocks!).


A few years ago Netscape proposed a JavaScript 2.0 version. Many 
features from that proposal has made it into ActionScript and into 
JScript.NET (used on the server). ECMAScript 4.0 that was being worked 
upon altered from the original JS 2.0 proposal in some ways. That work 
has however been halted. One group, led by Mozilla and Adobe, wanted to 
*add* to ECMAScript in radical ways. One group, led by MS and Yahoo 
(Doug Crockford), wanted primarily a *subset*, getting rid of the bad 
parts. They soon added features, though, and the language was in 
essence forked.


A compromise has been reached. ECMAScript Harmony will most probably 
be released as version 4, but not for a couple of years. And it will 
differ from the ES 4 proposal as stood in June.


It is the intention of the EcmaScript working group to release ES 3.1 
next year, at which time they hope to have two interoperable and 
complete implementations. One will most probably be SpiderMonkey 
(Mozilla) and the other might be V8.


The new ES 4, i.e. Harmony, will probably not see the light of day 
until 2010 or 2011.



Lars Gunther


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please - object methods are properties


Keryx Web skrev:
JavaScript has no pure hash-tables, aka associative arrays. Object 
properties can be used to emulate associative arrays, though. A PHP 
programmer will feel very limited, though.


A JavaScript object *is* not an array ...
It can have methods as well as properties.


geekspeak
Nitpicking on myself. JavaScript makes no real distinction between a 
property value that is a function (and therefore becomes an object 
method) and property values that simply store a simple type. i.e. a 
method *is* a property, that stores a function, which is possible since 
they are first class objects.

/geekspeak


Lars Gunther


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Javascript classical inheritence [was: JavaScript clarification please]


Mathew Robertson skrev:

All this talk over JavaScript not supporting classes, is incorrect. I put together a 
little demo of classical class-based inheritence.

The only real limitation is that you can't do protected members and friends 
and the syntax might be considered to be a little clunky.

http://members.optusnet.com.au/~mathew/js/


Liorean has already provided clarification on the difference between 
supporting class-based inheritance through emulation, vz. having native 
support.


I would like to point out that John Resig writes about this topic in hos 
book Pro JavaScript Techniques, and that it is implemented in one form 
or another in many libraries.


There was also an effort to support the now canceled ECMAScript 4 syntax 
in older browsers, Mascara, that included support for classes. 
http://ecmascript4.com/ I suppose its status is uncertain.


In short, as MR shows: If you feel intimidated by prototypal 
inheritance, there are tools available to make JavaScript behave in a 
fashion that is more suited to your tastes. :-)



Lars Gunther


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please - versions

2008-10-29 Thread Brett Patterson

I like that explanation. I get it now. Thanks. One more quick question
though, what is a let-block, in general? Thanks. That really does make it a
lot easier to understand.

Brett

On Wed, Oct 29, 2008 at 6:04 AM, Keryx Web [EMAIL PROTECTED] wrote:

 Brett Patterson skrev:

 I am sorry, but I must ask. Are you saying that the term JavaScript is
 owned by Sun? Or just the Java part? And, yes, JavaScript is implemented in
 Internet Explorer.


 I see that your question has already been answered. I will give some
 additional points.

 Mocha was Brendan Eich's internal name during initial development at
 Netscape. It was renamed LiveScript by him and his fellow enginers, but
 changed to JavaScript by the *marketing* department.

 JScript in MSIE 6 and 7 is *roughly* comparable to JavaScript 1.2 and to
 ECMAScript 3.0.

 There is a document, produced by MS, that in very high detail outlines how
 JScript, and other browsers JS engines, differs from the spec. It is
 available at https://developer.mozilla.org/en/JavaScript

 The JavaScript support in Safari, Google Chrome and Opera is *roughly*
 comparable to JavaScript 1.5, and some parts of JavaScript 1.6.

 (Note: 99 % of the time when one curses the differences between browsers,
 it is not because of their deviations from each other in Java/J/EcmaScript,
 but how they differ from each other on the DOM.)

 Mozilla is allowed by the ECMAScript spec to develop JavaScript as a
 superset to ECMAScript, and indeed they have. JavaScript 1.8 contains quite
 a few features that (probably) will not even make it into ECMAScript 3.1
 (generators, iterators, let-blocks - personally I really like let blocks!).

 A few years ago Netscape proposed a JavaScript 2.0 version. Many features
 from that proposal has made it into ActionScript and into JScript.NET (used
 on the server). ECMAScript 4.0 that was being worked upon altered from the
 original JS 2.0 proposal in some ways. That work has however been halted.
 One group, led by Mozilla and Adobe, wanted to *add* to ECMAScript in
 radical ways. One group, led by MS and Yahoo (Doug Crockford), wanted
 primarily a *subset*, getting rid of the bad parts. They soon added
 features, though, and the language was in essence forked.

 A compromise has been reached. ECMAScript Harmony will most probably be
 released as version 4, but not for a couple of years. And it will differ
 from the ES 4 proposal as stood in June.

 It is the intention of the EcmaScript working group to release ES 3.1 next
 year, at which time they hope to have two interoperable and complete
 implementations. One will most probably be SpiderMonkey (Mozilla) and the
 other might be V8.

 The new ES 4, i.e. Harmony, will probably not see the light of day until
 2010 or 2011.


 Lars Gunther


 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: [EMAIL PROTECTED]
 ***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please - let blocks


Brett Patterson skrev:
I like that explanation. I get it now. Thanks. One more quick question 
though, what is a let-block, in general? Thanks. That really does make 
it a lot easier to understand.


Brett


Normally JavaScript does not have block scope.

var foo = 1;
{
foo = 2;
}
alert(foo); // will give you 2

Let-blocks will provide block-scope on an opt in basis:

var foo = 1;
{
let foo = 2;
alert(foo); // 2
let bar = 3;
}
alert(foo); // 1
alert(bar); // undefined

Block scope is one feature that makes it easy to write interoperable 
code. My variables won't mess with your variables. Today we use function 
scope to accomplish the same thing:


var foo = 1;
(function() {
var foo = 2;
alert(foo); // 2
})() // last parenthesis invokes anonymous function
alert(foo); // 1


Let blocks are really handy in for loops:

var i = Hi there;
for ( let i = 0; i  10; i++) {
alert(i); // 0 - 9
}
alert(i); // Hi there

Self executing functions have another kind of power through closures and 
possible return values, so the two do not completely overlap.


More info on the New in JavaScript 1.7 article on MDC.


Lars Gunther



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please - let blocks

2008-10-29 Thread Brett Patterson

OK. Thanks

On Wed, Oct 29, 2008 at 11:00 AM, Keryx Web [EMAIL PROTECTED] wrote:

 Brett Patterson skrev:

 I like that explanation. I get it now. Thanks. One more quick question
 though, what is a let-block, in general? Thanks. That really does make it a
 lot easier to understand.

 Brett


 Normally JavaScript does not have block scope.

 var foo = 1;
 {
foo = 2;
 }
 alert(foo); // will give you 2

 Let-blocks will provide block-scope on an opt in basis:

 var foo = 1;
 {
let foo = 2;
alert(foo); // 2
let bar = 3;
 }
 alert(foo); // 1
 alert(bar); // undefined

 Block scope is one feature that makes it easy to write interoperable code.
 My variables won't mess with your variables. Today we use function scope to
 accomplish the same thing:

 var foo = 1;
 (function() {
var foo = 2;
alert(foo); // 2
 })() // last parenthesis invokes anonymous function
 alert(foo); // 1


 Let blocks are really handy in for loops:

 var i = Hi there;
 for ( let i = 0; i  10; i++) {
alert(i); // 0 - 9
 }
 alert(i); // Hi there

 Self executing functions have another kind of power through closures and
 possible return values, so the two do not completely overlap.

 More info on the New in JavaScript 1.7 article on MDC.


 Lars Gunther



 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: [EMAIL PROTECTED]
 ***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-28 Thread liorean

 liorean wrote:
 (Netscape had originally intended to use the name LiveScript.)

2008/10/28 Hassan Schroeder [EMAIL PROTECTED]:
 Actually, it was initially released as LiveScript and renamed later.

IIRC Navigator 2.0 also supported a mocha: pseudo-protocol like the
javascript: pseudo-protocol we have today, from the name it was given
before it became LiveScript. Anyway, by the time the first full
version of Navigator that had it was released (2.0) it had already
been renamed to JavaScript, so I'd hardly say it was released under
the LiveScript name.
-- 
David liorean Andersson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-28 Thread Brett Patterson

When you say support, are you saying that Internet Explorer will not execute
JavaScript, or it will execute JavaScript as JScript? And in the
http://en.wikipedia.org/wiki/JavaScript link you provided it states that
JavaScript is heavily object-based, so should I assume this as well to be
correct?

On Tue, Oct 28, 2008 at 3:55 AM, liorean [EMAIL PROTECTED] wrote:

  liorean wrote:
  (Netscape had originally intended to use the name LiveScript.)

 2008/10/28 Hassan Schroeder [EMAIL PROTECTED]:
  Actually, it was initially released as LiveScript and renamed later.

 IIRC Navigator 2.0 also supported a mocha: pseudo-protocol like the
 javascript: pseudo-protocol we have today, from the name it was given
 before it became LiveScript. Anyway, by the time the first full
 version of Navigator that had it was released (2.0) it had already
 been renamed to JavaScript, so I'd hardly say it was released under
 the LiveScript name.
 --
 David liorean Andersson


 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: [EMAIL PROTECTED]
 ***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] JavaScript clarification please

2008-10-28 Thread michael.brockington

 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Brett Patterson
 Sent: 28 October 2008 12:35
 To: wsg@webstandardsgroup.org
 Subject: Re: [WSG] JavaScript clarification please

 When you say support, are you saying that Internet Explorer will not
execute 
 JavaScript, or it will execute JavaScript as JScript? And in the
 http://en.wikipedia.org/wiki/JavaScript link you provided it states
that 
 JavaScript is heavily object-based, so should I assume this as well to
be correct?

As far as I can see, it does not say that.

The facts are that the JScript run-time engine will attempt to execute
whatever is thrown at it. In most cases something that looks like valid
Javascript will produce something like what was intended.  Think of it
like support for CSS: IE is always a little bit different, but it is
still CSS. And at the end of the day, JScript, ECMAscript, ActionScript
and JavaScript are more or less the same beast as far as this discussion
is concerned. They are all based on objects, they all implement
inheritance, and all of them can be used to write linear, procedural
code if required.

Regards,
Mike

Mike Brockington
Web Development Specialist

www.calcResult.com
www.stephanieBlakey.me.uk
www.edinburgh.gov.uk

This message does not reflect the opinions of any entity other than the
author alone.

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-28 Thread Brett Patterson

Actually it did say it is heavily object-based. But now, under Dynamic
Programming -- Objects as associated arrays, it says it is almost entirely
object-based. Looks like it just got updated. Internet Explorer does read
JavaScript, but does it support JavaScript as a whole, or does it read
JavaScript as JScript?

On Tue, Oct 28, 2008 at 10:43 AM, [EMAIL PROTECTED] wrote:

  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 On Behalf Of Brett Patterson
  Sent: 28 October 2008 12:35
  To: wsg@webstandardsgroup.org
  Subject: Re: [WSG] JavaScript clarification please
 
 
  When you say support, are you saying that Internet Explorer will not
 execute
  JavaScript, or it will execute JavaScript as JScript? And in the
  http://en.wikipedia.org/wiki/JavaScript link you provided it states
 that
  JavaScript is heavily object-based, so should I assume this as well to
 be correct?

 As far as I can see, it does not say that.

 The facts are that the JScript run-time engine will attempt to execute
 whatever is thrown at it. In most cases something that looks like valid
 Javascript will produce something like what was intended.  Think of it
 like support for CSS: IE is always a little bit different, but it is
 still CSS. And at the end of the day, JScript, ECMAscript, ActionScript
 and JavaScript are more or less the same beast as far as this discussion
 is concerned. They are all based on objects, they all implement
 inheritance, and all of them can be used to write linear, procedural
 code if required.

 Regards,
 Mike


 Mike Brockington
 Web Development Specialist

 www.calcResult.com
 www.stephanieBlakey.me.uk
 www.edinburgh.gov.uk

 This message does not reflect the opinions of any entity other than the
 author alone.


 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: [EMAIL PROTECTED]
 ***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-28 Thread Hassan Schroeder


liorean wrote:


  Anyway, by the time the first full
version of Navigator that had it was released (2.0) it had already
been renamed to JavaScript, so I'd hardly say it was released under
the LiveScript name.


Well, at this point I don't know exactly when a version of Navigator
was released with it under either name but certainly remember reading
plenty about LiveScript before the name change.

And there were certainly some interesting internal discussions at
JavaSoft about the whole issue. :-)

--
Hassan Schroeder - [EMAIL PROTECTED]
Webtuitive Design ===  (+1) 408-621-3445   === http://webtuitive.com

  dream.  code.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-28 Thread liorean

2008/10/28 Brett Patterson [EMAIL PROTECTED]:
 Actually it did say it is heavily object-based. But now, under Dynamic
 Programming -- Objects as associated arrays, it says it is almost entirely
 object-based. Looks like it just got updated. Internet Explorer does read
 JavaScript, but does it support JavaScript as a whole, or does it read
 JavaScript as JScript?

That depends on what you mean by JavaScript. Do you mean the language
that Netscape JavaScript and later Mozilla JavaScript reference[1] and
guide[2] specs specifies? JavaScript as in the language
text/javascript is interpreted as in browsers? Do you mean the
entire language and host environment making up the client side
scripting language for web pages?

The word JavaScript means different things in different contexts to
different people.


Internet Explorer uses Microsof't JScript engine which implements
ECMAScript, some parts of it buggy, some parts of it with proprietary
extensions. It doesn't in general implement Mozilla JavaScript
additions to ECMAScript. It does send all content that tells it it is
JavaScript/LiveScript/JScript/ECMAScript to the same engine.


[1] https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference
[2] https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide
-- 
David liorean Andersson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-28 Thread Brett Patterson

There is only one JavaScript, as created by Netscape. Though it can be used
for other things, such as programming an application, I think that is worded
right.

On Tue, Oct 28, 2008 at 12:10 PM, Hassan Schroeder [EMAIL PROTECTED]wrote:

 liorean wrote:

   Anyway, by the time the first full
 version of Navigator that had it was released (2.0) it had already
 been renamed to JavaScript, so I'd hardly say it was released under
 the LiveScript name.


 Well, at this point I don't know exactly when a version of Navigator
 was released with it under either name but certainly remember reading
 plenty about LiveScript before the name change.

 And there were certainly some interesting internal discussions at
 JavaSoft about the whole issue. :-)

 --
 Hassan Schroeder - [EMAIL PROTECTED]
 Webtuitive Design ===  (+1) 408-621-3445   === http://webtuitive.com

  dream.  code.


 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: [EMAIL PROTECTED]
 ***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-28 Thread Breton Slivka

JScript was originally created as an exact reverse engineering of
Javascript (including the mistakes), so that IE could read pages with
javascript on them. This was of course, during the browser wars when
they were competing for features. Jscript has fallen a bit behind
Javascript by now, so there are many features in Javascript that
Jscript does not support, such as Array extras, continuations and
function expressions.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-27 Thread Mark Harris


Anthony wrote:

My sentiments exactly.


On 27/10/2008, at 3:46 PM, Breton Slivka [EMAIL PROTECTED] wrote:



I'm afraid I will have to throw up
my hands and give up on you. You are a lost cause. you cannot be
reached.



Oh, good. Can we return the list to web standards now?


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-27 Thread Brett Patterson

Yes. But, one final question. Was the *first ever* implementation of
JavaScript designed to be object-oriented, object-based, or prototype-based?
Thank you all.

Oh and to David and Christian, in regards to the w3schools, I reread parts
of their site, and I understand now what you mean. My apologies.  :)

Thanks again,

Brett

On Mon, Oct 27, 2008 at 1:59 AM, Mark Harris [EMAIL PROTECTED] wrote:

 Anthony wrote:

 My sentiments exactly.


 On 27/10/2008, at 3:46 PM, Breton Slivka [EMAIL PROTECTED] wrote:


  I'm afraid I will have to throw up
 my hands and give up on you. You are a lost cause. you cannot be
 reached.


 Oh, good. Can we return the list to web standards now?



 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: [EMAIL PROTECTED]
 ***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008/10/27 Brett Patterson [EMAIL PROTECTED]:
 Yes. But, one final question. Was the first ever implementation of
 JavaScript designed to be object-oriented, object-based, or prototype-based?
 Thank you all.

The first implementation of JavaScript is still alive in the form of
Mozilla SpiredMonkey, even though much of it has been changed since
then. It was designed to be object oriented through usage of the
prototypal inheritance scheme, so it's pretty much all three at once.
Since everything in JavaScript is an object, it can be said to be
object based as well as object oriented. Anthony Ziebell's argument
that it's prototype-based rather than object oriented is a false
dichotomy since prototypal inheritance is in fact one of the ways to
achieve objevt orientation. As such, a system can become object
oriented as a result of adding prototypal inheritance to an object
based system.

Anthony Ziebell is arguing that it's not object oriented based on the
false premise that classical inheritance is the way to achieve object
orientation and prototypal inheritance is not, despite himself linking
articles stating the contrary.
-- 
David liorean Andersson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008/10/27 liorean [EMAIL PROTECTED]:
 The first implementation of JavaScript is still alive in the form of
 Mozilla SpiredMonkey

Or SpiderMonkey, as it is properly called :)
--
David liorean Andersson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-27 Thread James Jeffery

My statement was not worded correctly.

I use Java, C++, PHP and Javascript and I can tell you that out of the lot
of them, Javascript is the most difficult to incorperate conventional Object
Orientated design. For example you cannot simply define classes, or use
visability keywords (you can do it, but not the conventional way) and some
of the OOP design patterns are difficult to put into Javascript.

I have the Apress book on Javascript Design Patterns, which helped alot when
learning OOP in JS.

Sorry my wording was wrong. I think the above is what I meant.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-27 Thread Anthony


Not exactly.

My arguement was that while javascript has objects, it is indeed  
prototype-based


It is only through arguement did any mention of javascripts  
inheritence get a mention, which is also still true. This was not the  
underlying factor, but something somone brought up.


I'm not sure why it is so bad that javascript be prototype-based? I  
have said again and again that it still does have objects, sighted  
many sources which state javascript as a prototype-based language and  
other examples for the arguement along the way... It is still a good  
language and there is nothing negative about prototype?


Anyway I only respond again because I don't like to be miss- 
represented. If you still feel I am wrong and disprove of the wiki  
articles stating it is prototype-based, you really should edit them as  
it must be a miss-representation of javascript.


Regards,
Anthony.

Sent from my iPhone!

On 28/10/2008, at 12:43 AM, liorean [EMAIL PROTECTED] wrote:


2008/10/27 Brett Patterson [EMAIL PROTECTED]:

Yes. But, one final question. Was the first ever implementation of
JavaScript designed to be object-oriented, object-based, or  
prototype-based?

Thank you all.


The first implementation of JavaScript is still alive in the form of
Mozilla SpiredMonkey, even though much of it has been changed since
then. It was designed to be object oriented through usage of the
prototypal inheritance scheme, so it's pretty much all three at once.
Since everything in JavaScript is an object, it can be said to be
object based as well as object oriented. Anthony Ziebell's argument
that it's prototype-based rather than object oriented is a false
dichotomy since prototypal inheritance is in fact one of the ways to
achieve objevt orientation. As such, a system can become object
oriented as a result of adding prototypal inheritance to an object
based system.

Anthony Ziebell is arguing that it's not object oriented based on the
false premise that classical inheritance is the way to achieve object
orientation and prototypal inheritance is not, despite himself linking
articles stating the contrary.
--
David liorean Andersson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008/10/27 Anthony [EMAIL PROTECTED]:
 My arguement was that while javascript has objects, it is indeed
 prototype-based

Oh, we're not disputing that. But look at some of your earlier comments.



This for instance:
2008/10/24 Anthony Ziebell [EMAIL PROTECTED]:
 Sure, that's what an object is. But OOP is not just about an object.
 There is a lot more involved.

 Don't get me wrong, I am a fan of JavaScript - but it has faux classes and
 objects, and this is why my opinion of JavaScript is that it is prototype,
 not object.

First of all I'm assuming you meaning object-based and prototype-based
there, because the sentence as written just does not make sense.
Anyway, it's a false dichotomy because JavaScript is object-based AND
prototype-based. It's also object oriented.

Also, while you can say it's got faux classes (it actually has in the
ECMAScript specification, but nothing author accessible) those classes
have no greater importance to the author as they are not available to
user JavaScript.


Here's another such statement of yours:
2008/10/24 Anthony Ziebell [EMAIL PROTECTED]:
 Forgot to clarify one thing: ECMAScript is fully OO in my opinion, however
 JavaScript is not a full implementation of ECMAScript, unfortunately.

This sounds like you're insinuating that while ECMAScript is fully
object oriented, JavaScript is not. That's just plain false.


Another one:
2008/10/27 Anthony Ziebell [EMAIL PROTECTED]:
 There is a difference between the use of object and object-oriented
 programming. Coad / Yourdon suggests object-oriented being classes and
 objects, inheritance and communication with messages. Does JavaScript have
 classes?

Not user classes, no. Only implementation/host.

Can inheritance of JavaScript occur without prototype?

Not automatically, no. Why would it need another inheritance mechanism
in order to be object oriented?

 [snip]
 Object-oriented programming consists of native inheritance. Are you
 suggesting that a prototypical approach to inheritance one in the same as
 native inheritance?

Do you mean native as in the implementation language (machine
native, if you will) or native as in user JavaScript?

Anyway, the inheritance mechanism in JavaScript is prototype
delegation, and it certainly is the native method of inheritance for
JavaScript. It may or may not be the method of inheritance for host
objects, but that's another story.




2008/10/27 Anthony [EMAIL PROTECTED]:
 It is only through arguement did any mention of javascripts inheritence get
 a mention, which is also still true. This was not the underlying factor, but
 something somone brought up.

It's the core part of being a prototype-based language, so even if
you've not mentioned inheritance you've certainly talked about it. But
you have at several occasions mentioned inheritance, so that's beyond
the point.

 I'm not sure why it is so bad that javascript be prototype-based? I have
 said again and again that it still does have objects, sighted many sources
 which state javascript as a prototype-based language and other examples for
 the arguement along the way... It is still a good language and there is
 nothing negative about prototype?

We're not arguing about that. We're arguing that it being
prototype-based is the very factor that makes it object oriented. But
you on the other hand have at least seemingly argued that it is not
object oriented, which is the point we've been addressing all along.

 Anyway I only respond again because I don't like to be miss-represented. If
 you still feel I am wrong and disprove of the wiki articles stating it is
 prototype-based, you really should edit them as it must be a
 miss-representation of javascript.

We're not arguing against the articles. We've been arguing constantly
throughout this thread that JavaScript may be prototype-based, but
that does not make it any less object oriented. And I don't think I'm
missrepresenting you at all when I say you've argued against that
point.
-- 
David liorean Andersson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-27 Thread Anthony

Not once did I hear someone say it was prototype-based. Intact others  
have flat out denied it.


The question was is it either object or prototype. I merely stated if  
anything it should be seen as prototype, but it does have objects.


Then, it followed with all sorts of garbage from those trying to  
debunk the notion of javascript being prototype. Not once did I say it  
does not have objects. Intact I offered that it does.


Regards,
Anthony.

Sent from my iPhone!

On 28/10/2008, at 7:40 AM, liorean [EMAIL PROTECTED] wrote:


2008/10/27 Anthony [EMAIL PROTECTED]:

My arguement was that while javascript has objects, it is indeed
prototype-based


Oh, we're not disputing that. But look at some of your earlier  
comments.




This for instance:
2008/10/24 Anthony Ziebell [EMAIL PROTECTED]:
Sure, that's what an object is. But OOP is not just about an  
object.

There is a lot more involved.

Don't get me wrong, I am a fan of JavaScript - but it has faux  
classes and
objects, and this is why my opinion of JavaScript is that it is  
prototype,

not object.


First of all I'm assuming you meaning object-based and prototype-based
there, because the sentence as written just does not make sense.
Anyway, it's a false dichotomy because JavaScript is object-based AND
prototype-based. It's also object oriented.

Also, while you can say it's got faux classes (it actually has in the
ECMAScript specification, but nothing author accessible) those classes
have no greater importance to the author as they are not available to
user JavaScript.


Here's another such statement of yours:
2008/10/24 Anthony Ziebell [EMAIL PROTECTED]:
Forgot to clarify one thing: ECMAScript is fully OO in my opinion,  
however

JavaScript is not a full implementation of ECMAScript, unfortunately.


This sounds like you're insinuating that while ECMAScript is fully
object oriented, JavaScript is not. That's just plain false.


Another one:
2008/10/27 Anthony Ziebell [EMAIL PROTECTED]:

There is a difference between the use of object and object-oriented
programming. Coad / Yourdon suggests object-oriented being classes  
and
objects, inheritance and communication with messages. Does  
JavaScript have

classes?


Not user classes, no. Only implementation/host.


Can inheritance of JavaScript occur without prototype?


Not automatically, no. Why would it need another inheritance mechanism
in order to be object oriented?


[snip]
Object-oriented programming consists of native inheritance. Are you
suggesting that a prototypical approach to inheritance one in the  
same as

native inheritance?


Do you mean native as in the implementation language (machine
native, if you will) or native as in user JavaScript?

Anyway, the inheritance mechanism in JavaScript is prototype
delegation, and it certainly is the native method of inheritance for
JavaScript. It may or may not be the method of inheritance for host
objects, but that's another story.




2008/10/27 Anthony [EMAIL PROTECTED]:
It is only through arguement did any mention of javascripts  
inheritence get
a mention, which is also still true. This was not the underlying  
factor, but

something somone brought up.


It's the core part of being a prototype-based language, so even if
you've not mentioned inheritance you've certainly talked about it. But
you have at several occasions mentioned inheritance, so that's beyond
the point.

I'm not sure why it is so bad that javascript be prototype-based? I  
have
said again and again that it still does have objects, sighted many  
sources
which state javascript as a prototype-based language and other  
examples for
the arguement along the way... It is still a good language and  
there is

nothing negative about prototype?


We're not arguing about that. We're arguing that it being
prototype-based is the very factor that makes it object oriented. But
you on the other hand have at least seemingly argued that it is not
object oriented, which is the point we've been addressing all along.

Anyway I only respond again because I don't like to be miss- 
represented. If
you still feel I am wrong and disprove of the wiki articles stating  
it is

prototype-based, you really should edit them as it must be a
miss-representation of javascript.


We're not arguing against the articles. We've been arguing constantly
throughout this thread that JavaScript may be prototype-based, but
that does not make it any less object oriented. And I don't think I'm
missrepresenting you at all when I say you've argued against that
point.
--
David liorean Andersson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm

Re: [WSG] JavaScript clarification please

2008-10-27 Thread Breton Slivka

It is my understanding that the bulk of those OOP design patterns are
useful to get around the limitations of static languages like C++ and
Java, that don't allow you to arbitrarily add/remove properties from
instances, change the type of a value, or allow higher order functions
(functions that return functions values), or allow you to pass in
functions as values.   Given that javascript allows all those things,
much of those traditional OOP design patterns don't make much sense,
because they're getting around a limitation that doesn't exist.

I haven't extensively used the OOP facilities in PHP, I've always
found the syntax to be ugly as hell, I could never bring myself to
type that crap willingly. So unfortunately, I cannot speak
knowledgably about how difficult or hard it is in PHP.




On Tue, Oct 28, 2008 at 1:17 AM, James Jeffery
[EMAIL PROTECTED] wrote:
 My statement was not worded correctly.

 I use Java, C++, PHP and Javascript and I can tell you that out of the lot
 of them, Javascript is the most difficult to incorperate conventional Object
 Orientated design. For example you cannot simply define classes, or use
 visability keywords (you can do it, but not the conventional way) and some
 of the OOP design patterns are difficult to put into Javascript.

 I have the Apress book on Javascript Design Patterns, which helped alot when
 learning OOP in JS.

 Sorry my wording was wrong. I think the above is what I meant.

 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: [EMAIL PROTECTED]
 ***


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-27 Thread Keryx Web


Brett Patterson skrev:
 I am in the middle of a conversation with this guy who says that 
JavaScript is an object-oriented language. Is he correct? Could you 
please site some references?


I have read the whole thread up until now, but will answer your starting 
message, since I am not addressing a single specific respondent.


I am in charge of developing DOM Scripting courses for the Curriculum 
Framework of the WaSP Education Task Force[1]


I have therefore tried to read every single resource about JavaScript, 
ECMAScript and the DOM that has been written from a computer science 
perspective. There are not that many, which might be a reason behind the 
confusion.


Anyway: JavaScript (a term owned by Sun, licensed to Mozilla, and used 
by all browser vendors but Microsoft) is in all essence, as Liorean has 
stated, a superset of ECMAScript 3.0. That is also the sentiment of 
Brendan Eich - and should therefore be taken as a final word. (Anthony 
was indeed wrong about this.) JScript as implemented in Internet 
Explorer is roughly equivalent, but deviates in some small ways.


JavaScript is a mix of Self, Scheme and C (according to the ECMAScript 
3.1 draft, the love child between Scheme and C according to Brendan Eich).


JavaScript is indeed Object Oriented, but even though every script is 
run within a host object - usually the window object of a browser - a 
procedural style is possible to use. 90's DHTML scripts were usually 
procedural and used document.write (which is not ECMAScript but part of 
the DOM) in a way that reminds me of *standard streams*, which could be 
provided by the host object, but usually aren't.


Public, private and protected methods and properties are not easily 
implemented. Object Oriented design patterns (singletons, factories, 
registry, adaptors...) can usually be emulated. Sometimes this is only 
done through considerable wizardry using concepts like lambda and closures.


ECMAScript 4.0 aka JavaScript 2.0 was supposed to get a limited class 
based inheritance mechanism to *complement* the prototype based one we 
use today. Those plans have been halted. ECMAScript Harmony will most 
probably *not* get any class based inheritance.


(At least two JavaScript engines (V8 and Squirrelfish Extreme) emulate 
class based object creation as part of their just in time compilation, 
but that really is a compiler issue.)


ECMASCript 3.1 will get a few new methods to facilitate easier 
inheritance patterns. E.g. Object.freeze(). Many popular libraries also 
have methods that facilitate OO-patterns.


As old school cut' n' paste coding is getting superseded by libraries 
procedural code is becoming less seen and OO-style coding is getting 
more used.


Indeed, using object chaining in JQuery et al, the programming is even 
well on its way to become *declarative*.


Summary:

1. JavaScript *is* OO.
2. JavaScript uses a prototypal - class-less - inheritance mechanism.
3. Anyone writing a script can use procedural style, OO-style or even 
make forays into a declarative style.


Nit picking on some stuff in the thread:

JavaScript has no pure hash-tables, aka associative arrays. Object 
properties can be used to emulate associative arrays, though. A PHP 
programmer will feel very limited, though.


A JavaScript object *is* not an array (once again Anthony got it wrong). 
It can have methods as well as properties. asideArrays are however 
objects, and confusingly


typeof [ 1, 2 ]

evalutes to object, not array. A major design flaw.

The best known way to test for an array is:

Object.prototype.toString.apply(value) === '[object Array]'

Discovered by Mark Miller of Google./aside

From a very strict computer science point of view averything in 
JavaScript is *not* an object. (No matter how much Alex Dojo Russel et 
al. reiterates that mantra.) In practice everything is. JavaScript has 
got a few primitives (numbers, strings, booleans, undefined). Whenever 
a primitive is referenced with an OO-syntax it is converted into its 
corresponding wrapper object. This was modeled after Java according to 
Brendan, and he has stated that it probably was a bad idea. (Search the 
ES4 mailing list for a reference.)



Lars Gunther

Sources:

MDC, including https://developer.mozilla.org/En/About_JavaScript
ES 3.0 spec
ES 3.1 spec draft
JavaScript, The Definitive Guide (latest edition)
ES3.1 mailing list
ES 4/Harmony mailing list
Doug Crockfords site and book (JavaScript, the good parts)
Numerous other JavaScript books

1. 
http://www.webstandards.org/2008/07/31/announcing-the-wasp-curriculum-framework/




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-27 Thread Breton Slivka

On Mon, Oct 27, 2008 at 11:00 PM, Brett Patterson
[EMAIL PROTECTED] wrote:
 Yes. But, one final question. Was the first ever implementation of
 JavaScript designed to be object-oriented, object-based, or prototype-based?
 Thank you all.


Here is Brenden Eich, Javascript's creator, pontificating on the
history and genesis of javascript

http://weblogs.mozillazine.org/roadmap/archives/2008/04/popularity.html#more

Quote:  I'm not proud, but I'm happy that I chose Scheme-ish
first-class functions and Self-ish (albeit singular) prototypes as the
main ingredients.

So in short, Yes, it was object oriented, with prototype-based
inheritence, first class scheme like functions, and (thanks to
netscape management) Java like syntax right from the start.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-27 Thread Anthony Ziebell

Hey Breton,

I think the examples you gave are implemented in the PHP object and are
relatively simple to implement.

Cheers,
Anthony.

Breton Slivka wrote:

It is my understanding that the bulk of those OOP design patterns are
useful to get around the limitations of static languages like C++ and
Java, that don't allow you to arbitrarily add/remove properties from
instances, change the type of a value, or allow higher order functions
(functions that return functions values), or allow you to pass in
functions as values. Given that _javascript_ allows all those things,
much of those traditional OOP design patterns don't make much sense,
because they're getting around a limitation that doesn't exist.

I haven't extensively used the OOP facilities in PHP, I've always
found the syntax to be ugly as hell, I could never bring myself to
type that crap willingly. So unfortunately, I cannot speak
knowledgably about how difficult or hard it is in PHP.

On Tue, Oct 28, 2008 at 1:17 AM, James Jeffery
[EMAIL PROTECTED] wrote:

My statement was not worded correctly.

I use Java, C++, PHP and _javascript_ and I can tell you that out of the lot
of them, _javascript_ is the most difficult to incorperate conventional Object
Orientated design. For example you cannot simply define classes, or use
visability keywords (you can do it, but not the conventional way) and some
of the OOP design patterns are difficult to put into _javascript_.

I have the Apress book on _javascript_ Design Patterns, which helped alot when
learning OOP in JS.

Sorry my wording was wrong. I think the above is what I meant.

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***

Re: [WSG] JavaScript clarification please

2008-10-27 Thread Anthony Ziebell





Thanks Keryx,

Some interesting information. Nice point on the arrays actually being
objects. At one point you did mention _javascript_ is object-based, then
in another, prototype-based. So that confuses me a little. If your
point is that it is object-based and uses prototype to inherit objects,
I think I understand your point.

Still confuses me though - if someone is object-orientated but is in
essence prototype-based (with regards to object, inheritance, etc), why
is it incorrect to say _javascript_ is prototype-based?

Cheers,
Anthony.



Keryx Web wrote:
Brett
Patterson skrev:
  
 I am in the middle of a conversation with this guy who says that
_javascript_ is an object-oriented language. Is he correct? Could you
please site some references?
  
  
I have read the whole thread up until now, but will answer your
starting message, since I am not addressing a single specific
respondent.
  
  
I am in charge of developing DOM Scripting courses for the Curriculum
Framework of the WaSP Education Task Force[1]
  
  
I have therefore tried to read every single resource about _javascript_,
ECMAScript and the DOM that has been written from a computer science
perspective. There are not that many, which might be a reason behind
the confusion.
  
  
Anyway: _javascript_ (a term owned by Sun, licensed to Mozilla, and used
by all browser vendors but Microsoft) is in all essence, as Liorean has
stated, a superset of ECMAScript 3.0. That is also the sentiment of
Brendan Eich - and should therefore be taken as a final word. (Anthony
was indeed wrong about this.) JScript as implemented in Internet
Explorer is roughly equivalent, but deviates in some small ways.
  
  
_javascript_ is a mix of Self, Scheme and C (according to the ECMAScript
3.1 draft, the "love child between Scheme and C" according to Brendan
Eich).
  
  
_javascript_ is indeed Object Oriented, but even though every script is
run within a host object - usually the window object of a browser - a
procedural style is possible to use. 90's DHTML scripts were usually
procedural and used document.write (which is not ECMAScript but part of
the DOM) in a way that reminds me of *standard streams*, which could be
provided by the host object, but usually aren't.
  
  
Public, private and protected methods and properties are not easily
implemented. Object Oriented design patterns (singletons, factories,
registry, adaptors...) can usually be emulated. Sometimes this is only
done through considerable wizardry using concepts like lambda and
closures.
  
  
ECMAScript 4.0 aka _javascript_ 2.0 was supposed to get a limited class
based inheritance mechanism to *complement* the prototype based one we
use today. Those plans have been halted. ECMAScript "Harmony" will most
probably *not* get any class based inheritance.
  
  
(At least two _javascript_ engines (V8 and Squirrelfish Extreme) emulate
class based object creation as part of their just in time compilation,
but that really is a compiler issue.)
  
  
ECMASCript 3.1 will get a few new methods to facilitate easier
inheritance patterns. E.g. Object.freeze(). Many popular libraries also
have methods that facilitate OO-patterns.
  
  
As old school cut' n' paste coding is getting superseded by libraries
procedural code is becoming less seen and OO-style coding is getting
more used.
  
  
Indeed, using object chaining in JQuery et al, the programming is even
well on its way to become *declarative*.
  
  
Summary:
  
  
1. _javascript_ *is* OO.
  
2. _javascript_ uses a prototypal - class-less - inheritance mechanism.
  
3. Anyone writing a script can use procedural style, OO-style or even
make forays into a declarative style.
  
  
Nit picking on some stuff in the thread:
  
  
_javascript_ has no pure hash-tables, aka associative arrays. Object
properties can be used to emulate associative arrays, though. A PHP
programmer will feel very limited, though.
  
  
A _javascript_ object *is* not an array (once again Anthony got it
wrong). It can have methods as well as properties. asideArrays
are however objects, and confusingly
  
  
typeof [ 1, 2 ]
  
  
evalutes to "object", not "array". A major design flaw.
  
  
The best known way to test for an array is:
  
  
Object.prototype.toString.apply(value) === '[object Array]'
  
  
Discovered by Mark Miller of Google./aside
  
  
>From a very strict computer science point of view averything in
_javascript_ is *not* an object. (No matter how much Alex "Dojo" Russel
et al. reiterates that mantra.) In practice everything is. _javascript_
has got a few "primitives" (numbers, strings, booleans, undefined).
Whenever a primitive is referenced with an OO-syntax it is converted
into its corresponding wrapper object. This was modeled after Java
according to Brendan, and he has stated that it probably was a bad
idea. (Search the ES4 mailing list for a reference.)
  
  
  
Lars Gunther
  
  
Sources:
  
  
MDC, including https://developer.mozilla.org/En/About_JavaScript
  
ES 3.0 spec

Re: [WSG] JavaScript clarification please

2008/10/27 Anthony [EMAIL PROTECTED]:
 Not once did I hear someone say it was prototype-based. Intact others have
 flat out denied it.

 The question was is it either object or prototype. I merely stated if
 anything it should be seen as prototype, but it does have objects.

Now you're doing that again. What do you mean when you say is it
either object or prototype? Because the sentence as you write it is
nonsensical. If you mean object-based and prototype-based
respectively, then say that. If you mean object oriented, then say
that. If you mean that it has objects, then say that. But saying
javascript is object or javascript is prototype is nonsensical.

For the record, pretty much everyone has said either that it uses
prototypal inheritance - which means the same thing as saying it's
prototype-based - or have said that it is prototype-based.


 Then, it followed with all sorts of garbage from those trying to debunk the
 notion of javascript being prototype. Not once did I say it does not have
 objects. Intact I offered that it does.

it has objects does not mean the same as object oriented. It doesn't
even mean the same as object-based.

You've argued that it's prototype-based rather than object oriented,
and every time we've said that it's both you've argued against us. We
have not debunked that it's prototype-based, in fact we've brought up
the fact it has prototypal inheritance and this is one of the
mechanisms that makes it object oriented several times.
-- 
David liorean Andersson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-27 Thread Keryx Web


Anthony Ziebell skrev:
Still confuses me though - if someone is object-orientated but is in 
essence prototype-based (with regards to object, inheritance, etc), why 
is it incorrect to say JavaScript is prototype-based?




Your confusion comes from comparing apples to steam trains.

Prototypes are an inheritance mechanism for objects.

Classes are another inheritance mechanism.

A language may implement either one or both (very rare).

It does not matter which inheritance mechanism that is used. It is still 
an OO language.


It is *not* incorrect to say JavaScript is prototype based. It is. No 
one is denying it.


It is *not* incorrect to say JavaScript is OO. It is, since OO is a 
paradigm for programming which JS fits very neatly in. It is de facto 
called OO in the ECMAScript spec.


It is *not* incorrect to say JavaScript is object based. It is - since 
it has object wrappers for all primitive values.


You really did seem to say that classes are needed for a language to be 
called OO. Now you have stated that you did not intend to say that. Case 
closed.



Lars Gunther


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-27 Thread Anthony Ziebell





Ok, great.

It was my intent to acknowledge some standards / submissions for OO
which inferred classes / native inheritance were needed.

Thanks for your help :)

Cheers,
Anthony.

Keryx Web wrote:
Anthony
Ziebell skrev:
  
  Still confuses me though - if someone is
object-orientated but is in essence prototype-based (with regards to
object, inheritance, etc), why is it incorrect to say _javascript_ is
prototype-based?


  
  
Your confusion comes from comparing apples to steam trains.
  
  
Prototypes are an inheritance mechanism for objects.
  
  
Classes are another inheritance mechanism.
  
  
A language may implement either one or both (very rare).
  
  
It does not matter which inheritance mechanism that is used. It is
still an OO language.
  
  
It is *not* incorrect to say _javascript_ is prototype based. It is. No
one is denying it.
  
  
It is *not* incorrect to say _javascript_ is OO. It is, since OO is a
paradigm for programming which JS fits very neatly in. It is de facto
called OO in the ECMAScript spec.
  
  
It is *not* incorrect to say _javascript_ is object based. It is - since
it has object wrappers for all primitive values.
  
  
You really did seem to say that classes are needed for a language to be
called OO. Now you have stated that you did not intend to say that.
Case closed.
  
  
  
Lars Gunther
  
  
  
***
  
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
  
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
  
Help: [EMAIL PROTECTED]
  
***
  
  
  




***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***

[WSG] Javascript classical inheritence [was: JavaScript clarification please]

2008-10-27 Thread Mathew Robertson


All this talk over JavaScript not supporting classes, is incorrect. I put 
together a little demo of classical class-based inheritence.

The only real limitation is that you can't do protected members and friends 
and the syntax might be considered to be a little clunky.

http://members.optusnet.com.au/~mathew/js/

I hope this helps clear things up a bit.
Mathew Robertson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Javascript classical inheritence [was: JavaScript clarification please]

2008/10/28 Mathew Robertson [EMAIL PROTECTED]:
 All this talk over JavaScript not supporting classes, is incorrect. I put 
 together a little demo of classical class-based inheritence.

 The only real limitation is that you can't do protected members and 
 friends and the syntax might be considered to be a little clunky.

 http://members.optusnet.com.au/~mathew/js/

 I hope this helps clear things up a bit.

That's support for classes in the same way C has support for classes
though - you can design them on top of the language, but you don't get
support for it for ordinary language elements or for built in
operators.

You're still not getting around that there's no built in support for
classical inheritance, other than the pseudo-classes that are used in
the ECMAScript spec internally but not for language for us users.
-- 
David liorean Andersson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Javascript classical inheritence

2008-10-27 Thread Mathew Robertson


  http://members.optusnet.com.au/~mathew/js/
 
  I hope this helps clear things up a bit.
 
 That's support for classes in the same way C has support for classes
 though - you can design them on top of the language, but you don't get
 support for it for ordinary language elements or for built in
 operators.

I'm not sure what ordinary language elements means...  C cant do this (but 
the example page can):

some_type o = new some_type();
bool result = o.some_method();

where some_method is from a base-class.  C could do this:

some_type o = some_type_constructor();
bool result = some_method(o);

but then some_method would require the developer to somehow first cast down 
the inheritence chain, then fallback when nothing is found (all of which is 
automatically done for you in class-based OOP languages).

So, if the example page isn't OOP using class-based inheritence, I'm not sure 
what is

Operator overloading is a feature of some languages - Java doesn't have it, so 
why is there an expectation that javascript should have it?  Also, I'm not sure 
what you mean by no support for built in operators, since new blah(...) is 
supported by javascript (aka 'new' is an operator).

 You're still not getting around that there's no built in support for
 classical inheritance, other than the pseudo-classes that are used in
 the ECMAScript spec internally but not for language for us users.

The internals of ECMAScript are irrelevant - it doesn't matter *how* I do it - 
and it doesn't matter if they are psuedo classes or not - it only matters 
that I can indeed create my own application specific class heirarchies.

And as it turns out, the syntax isn't too crap either, ie: we have effectively 
created the Class keyword:

  var NewType = Class(NewType,{ /* implementation */}, BaseType);
  var o = new NewType(...);

And we can even access the baseclass methods independently:

  o.some_method();
  o.SUPER.some_method();

What else do us users need?

Mathew Robertson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-27 Thread Brett Patterson

I am sorry, but I must ask. Are you saying that the term JavaScript is owned
by Sun? Or just the Java part? And, yes, JavaScript is implemented in
Internet Explorer.

On Mon, Oct 27, 2008 at 6:18 PM, Anthony Ziebell 
[EMAIL PROTECTED] wrote:

  Ok, great.

 It was my intent to acknowledge some standards / submissions for OO which
 inferred classes / native inheritance were needed.

 Thanks for your help :)

 Cheers,
 Anthony.

 Keryx Web wrote:

 Anthony Ziebell skrev:

 Still confuses me though - if someone is object-orientated but is in
 essence prototype-based (with regards to object, inheritance, etc), why is
 it incorrect to say JavaScript is prototype-based?


 Your confusion comes from comparing apples to steam trains.

 Prototypes are an inheritance mechanism for objects.

 Classes are another inheritance mechanism.

 A language may implement either one or both (very rare).

 It does not matter which inheritance mechanism that is used. It is still an
 OO language.

 It is *not* incorrect to say JavaScript is prototype based. It is. No one
 is denying it.

 It is *not* incorrect to say JavaScript is OO. It is, since OO is a
 paradigm for programming which JS fits very neatly in. It is de facto called
 OO in the ECMAScript spec.

 It is *not* incorrect to say JavaScript is object based. It is - since it
 has object wrappers for all primitive values.

 You really did seem to say that classes are needed for a language to be
 called OO. Now you have stated that you did not intend to say that. Case
 closed.


 Lars Gunther


 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: [EMAIL PROTECTED]
 ***



 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: [EMAIL PROTECTED]
 ***



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008/10/28 Brett Patterson [EMAIL PROTECTED]:
 I am sorry, but I must ask. Are you saying that the term JavaScript is owned
 by Sun? Or just the Java part? And, yes, JavaScript is implemented in
 Internet Explorer.

Yes, it's a registred trademark of Sun, licenced to Netscape once upon
a time as part of a marketing deal including bundling the Java runtime
with Navigator. (Netscape had originally intended to use the name
LiveScript.)


And it would be more correct to say Microsoft implements ECMAScript
than to say they implement JavaScript. They do not implement most of
the Netscape/Mozilla JavaScript additions to ECMAScript.

The name JavaScript is very seldom used by Microsoft. If you read
Microsoft employee blogs and official statements, you almost never
encounter that term. They prefer to either use their own JScript name
or the ECMAScript name.
-- 
David liorean Andersson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-27 Thread Breton Slivka

The term Javascript is indeed owned by Sun. The implementation of
Ecmascript in IE is called JScript, not Javascript, so it doesn't
infringe the trademark (technically, but it's similar enough that
people can still easily think that IE calls it Javascript)


On Tue, Oct 28, 2008 at 12:20 PM, Brett Patterson
[EMAIL PROTECTED] wrote:
 I am sorry, but I must ask. Are you saying that the term JavaScript is owned
 by Sun? Or just the Java part? And, yes, JavaScript is implemented in
 Internet Explorer.

 On Mon, Oct 27, 2008 at 6:18 PM, Anthony Ziebell
 [EMAIL PROTECTED] wrote:

 Ok, great.

 It was my intent to acknowledge some standards / submissions for OO which
 inferred classes / native inheritance were needed.

 Thanks for your help :)

 Cheers,
 Anthony.

 Keryx Web wrote:

 Anthony Ziebell skrev:

 Still confuses me though - if someone is object-orientated but is in
 essence prototype-based (with regards to object, inheritance, etc), why is
 it incorrect to say JavaScript is prototype-based?


 Your confusion comes from comparing apples to steam trains.

 Prototypes are an inheritance mechanism for objects.

 Classes are another inheritance mechanism.

 A language may implement either one or both (very rare).

 It does not matter which inheritance mechanism that is used. It is still
 an OO language.

 It is *not* incorrect to say JavaScript is prototype based. It is. No one
 is denying it.

 It is *not* incorrect to say JavaScript is OO. It is, since OO is a
 paradigm for programming which JS fits very neatly in. It is de facto called
 OO in the ECMAScript spec.

 It is *not* incorrect to say JavaScript is object based. It is - since it
 has object wrappers for all primitive values.

 You really did seem to say that classes are needed for a language to be
 called OO. Now you have stated that you did not intend to say that. Case
 closed.


 Lars Gunther


 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: [EMAIL PROTECTED]
 ***



 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: [EMAIL PROTECTED]
 ***

 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: [EMAIL PROTECTED]
 ***


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-27 Thread Hassan Schroeder


Brett Patterson wrote:
I am sorry, but I must ask. Are you saying that the term JavaScript is 
owned by Sun? 


Yes, and googling javascript trademark gives a first hit of
  http://en.wikipedia.org/wiki/JavaScript


And, yes, JavaScript is implemented in Internet Explorer.


And, no, the same reference will explain why that's incorrect.

FWIW,
--
Hassan Schroeder - [EMAIL PROTECTED]
Webtuitive Design ===  (+1) 408-621-3445   === http://webtuitive.com

  dream.  code.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008/10/28 liorean [EMAIL PROTECTED]:
 Yes, it's a registred trademark of Sun,

Actually a Trademark, not a Registred Trademark, apparently.
-- 
David liorean Andersson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

2008-10-27 Thread Hassan Schroeder


liorean wrote:


(Netscape had originally intended to use the name LiveScript.)


Actually, it was initially released as LiveScript and renamed later.

So much backstory on that, but at this point I have no idea what's
covered by my then employment contract. Regardless, good times. :-)

--
Hassan Schroeder - [EMAIL PROTECTED]
Webtuitive Design ===  (+1) 408-621-3445   === http://webtuitive.com

  dream.  code.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Replacing a paragraph with JS [was: Re: [WSG] JavaScript clarification please]

2008-10-26 Thread Benjamin Hawkes-Lewis


Brett Patterson wrote:
On a different 
note, I have a problem with the JavaScript code I am writing.


If you're going to begin a new topic, you should always begin a new 
thread to avoid confusing the old thread with irrelevant material and to 
attract potential readers who are disinterested in the old thread's topic.


The code is suppose to replace a 
paragraph for Microsoft Internet Explorer users, using the replace().


Note that selectively displaying user guidance based on browser
detection is problematic since:

1. Other browsers that you haven't tested might have the same behavior,
especially if they use the same web engine (Trident) as Internet
Explorer, as Maxthon and Avant do.

2. If all other popular browsers have a different behavior, a future
version of Internet Explorer might change to mimic them, or vice versa.

3. Browser detection is not robust, since browsers (either by default or
by users configuration) often spoof other browsers in order to
circumvent browser detection (for example, because it is used to track
them, block their access to a site, or provide them with a behaviors
designed for an earlier version of their browser that no longer work).

Where possible, feature detection should be preferred to browser
detection and providing the user with all available guidance should be
preferred to trying to second-guess what guidance is relevant to them.

Given users' natural propensity to click on things, when you have to
explain that you need click on something in order for something to
happen, that is often a sign of an interface that is too hard to use.
Requiring users to differentiate between single-, double-, and
triple-clicking sounds especially difficult, and especially hard to
translate when using alternative input devices - how do you triple-click
using a keyboard, or speech recognition, and a mobile phone touchscreen?

I'm also curious about why Internet Explorer might differ from other
browsers in this case, and why only it only sometimes differs.
Triple-clicking, in low-level Windows terms, appears to be either three
clicks in quick succession or a double click followed by a single click
or a single followed by a double click:

http://msdn.microsoft.com/en-us/magazine/cc163628.aspx

As 
I understand it, there is a maximum of 255 characters in a line, and 
here is the line I am using. 


Per line of what? Understand from where? There are no line length limits
in HTML or JavaScript as far as I know.


How do I get it to work?


Passing your JavaScript code through JSLint and running it with a
debugger would be a good start, since it has machine-detectable syntax
errors:

http://www.jslint.com/

Debugging with Gecko: http://www.getfirebug.com/

Debugging with Trident: 
http://www.my-debugbar.com/wiki/CompanionJS/HomePage (or IE 8 Beta 2)


Debugging with WebKit: http://webkit.org/blog/197/web-inspector-redesign/

Debugging with Opera:
http://www.opera.com/products/dragonfly/

See also:

http://siliconforks.com/doc/debugging-javascript/


This is the code I am using:


When asking about HTML and JS code, it is best to provide a full HTML
document and a full JS script not a snippet, since how the snippet works
can be drastically changed by HTML and JS elsewhere in the page.

See also this article about test case reduction when reporting bugs from
the WebKit project:

http://webkit.org/quality/reduction.html

Often the very process of test case reduction can reveal where your
problem lies.

p class=notessupNote:/sup If you want to view only a specific 
table, you will have to double-click on each drop-down Title, in order 
to view individual tables.br /


Note that the use of markup for presentational purposes (sup and br) 
is discouraged in favor of CSS applied to markup used for semantic and 
structural purposes. See also:


   * Opera Web Standards Curriculum
 http://www.opera.com/wsc/

   * Shirley E. Kaiser: Semantics, HTML, XHTML, and Structure:
 http://brainstormsandraves.com/articles/semantics/structure/

   * maxdesign CSS tutorials:
 http://css.maxdesign.com.au/


script type=text/javascript
!--
 var str=supNote:/supnbsp;If you want to view only a specific 
table, you will have to double-click on each drop-down Title, in order 
to view individual tables.;


Note that according to the HTML 4.01 specification (although
implementations tend to ignore this point), your inline script ends at
the first occurrence of the sequence / , and so strictly speaking your
script consists of the following error:

var str=supNote:

You can get around this by breaking up the string with a normal
JavaScript character escape:

var str=supNote:\/supnbsp;If you want to view only a specific
table, you will have to double-click on each drop-down Title, in order
to view individual tables.;


 var browser = navigator.appName;
if(browser==Microsoft Internet Explorer)


Note that some older versions of Opera, for example, claim to be
Microsoft Internet Explorer in

Re: [WSG] JavaScript clarification please

2008-10-26 Thread Luke Hoggett


Indeed, as Alan Kay inventor of Smalltalk and OOP said

I invented the term Object-Oriented, and I can tell you I did not have 
C++ in mind.


cheers
L


liorean wrote:

2008/10/24 James Jeffery [EMAIL PROTECTED]:
  

The language itself is NOT object-orientated, its proto-type based. It can
be used in an OOP fashion, but this is not true Object Orientation as it is
in languages such as C++.



Two serious problems with this statement: First, the prototype system
is in fact one of several ways of implementing inheritance in OOP
languages. Second, you're assuming C++ is object oriented. It's one of
several languages that is known to be OOP by programmers while in
actuality it's core is not OOP. Sure, it's possible to use C++ for
object oriented programming, but C++ allows doing things that actually
break object orientation. You can't do that in more OOP languages, for
example JavaScript.

C++ and Java are known as object oriented languages, but they are not
the ultimate in object orientation. There are plenty of languages that
are more object oriented. But they use classical inheritance, and
because JavaScript does not some people have got into their heads that
Classical inheritance == OOP which means JavaScritp != OOP. But that's
a misconception.
  



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

Luke,

Discrediting c++ has nothing to do with the question "Is _javascript_
object-orientated?". With that, and in closing, I would like to point
out that my comments were based on the actual question - asking if
_javascript_ were object-oriented, not if it has objects.
Prototype has objects, and it is of my opinion that _javascript_ is more
prototype than anything else.

Thanks,
Anthony.

Luke Hoggett wrote:

Indeed, as Alan Kay inventor of
Smalltalk and OOP said

"I invented the term
Object-Oriented, and I can tell you I did not have C++ in mind."

cheers
L

liorean wrote:

2008/10/24 James Jeffery [EMAIL PROTECTED]:

The language itself is NOT object-orientated, its proto-type based. It can
be used in an OOP fashion, but this is not true Object Orientation as it is
in languages such as C++.

Two serious problems with this statement: First, the prototype system
is in fact one of several ways of implementing inheritance in OOP
languages. Second, you're assuming C++ is object oriented. It's one of
several languages that is known to be OOP by programmers while in
actuality it's core is not OOP. Sure, it's possible to use C++ for
object oriented programming, but C++ allows doing things that actually
break object orientation. You can't do that in more OOP languages, for
example _javascript_.

C++ and Java are known as object oriented languages, but they are not
the ultimate in object orientation. There are plenty of languages that
are more object oriented. But they use classical inheritance, and
because _javascript_ does not some people have got into their heads that
Classical inheritance == OOP which means JavaScritp != OOP. But that's
a misconception.

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***

Re: [WSG] JavaScript clarification please

On Mon, Oct 27, 2008 at 12:02 PM, Anthony Ziebell
[EMAIL PROTECTED] wrote:
 Luke,

 Discrediting c++ has nothing to do with the question Is JavaScript
 object-orientated?. With that, and in closing, I would like to point out
 that my comments were based on the actual question - asking if JavaScript
 were object-oriented, not if it has objects. Prototype has objects, and it
 is of my opinion that JavaScript is more prototype than anything else.

 Thanks,
 Anthony.


Yes that's fine anthony, but the problem is that statement doesn't
actually mean anything. it is logically invalid, and quite nonsensical
to say javascript is not object oriented, it's more prototype based,
because the two things are not mutually exclusive. Javascript having
prototypical inheritence has absolutely nothing to do with the
question of whether it is object oriented or not. It can be both
object oriented, AND based on prototypal inheritence, and in fact, it
is both. 100%. This is not my opinion. it is a fact.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please

Breton,

There is a difference between the use of object and object-oriented
programming. Coad / Yourdon suggests object-oriented being classes and
objects, inheritance and communication with messages. Does _javascript_
have classes? Can inheritance of _javascript_ occur without prototype?

May I provide the following resource, pointing out second paragraph
under 'Adding a Method':
http://www.kevlindev.com/tutorials/_javascript_/inheritance/index.htm

Object-oriented programming consists of native inheritance. Are you
suggesting that a prototypical approach to inheritance one in the same
as native inheritance?

Thanks,
Anthony.

Breton Slivka wrote:

On Mon, Oct 27, 2008 at 12:02 PM, Anthony Ziebell
[EMAIL PROTECTED] wrote:

Luke,

Discrediting c++ has nothing to do with the question "Is _javascript_
object-orientated?". With that, and in closing, I would like to point out
that my comments were based on the actual question - asking if _javascript_
were object-oriented, not if it has objects. Prototype has objects, and it
is of my opinion that _javascript_ is more prototype than anything else.

Thanks,
Anthony.

Yes that's fine anthony, but the problem is that statement doesn't
actually mean anything. it is logically invalid, and quite nonsensical
to say "_javascript_ is not object oriented, it's more prototype based",
because the two things are not mutually exclusive. _javascript_ having
prototypical inheritence has absolutely nothing to do with the
question of whether it is object oriented or not. It can be both
object oriented, AND based on prototypal inheritence, and in fact, it
is both. 100%. This is not my opinion. it is a fact.

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***

Re: [WSG] JavaScript clarification please

On Mon, Oct 27, 2008 at 1:17 PM, Anthony Ziebell
[EMAIL PROTECTED] wrote:
 Breton,

 There is a difference between the use of object and object-oriented
 programming.

Yes you say that, but you never go into any detail about it.  In what
way in particular is the concept and use of objects independant from
object orient programming. Did the concept of objects *not* come
from smalltalk, the original OOP language? Can you cite any occurance
of the concept of an object in programming that predates smalltalk?
Do you then, think it's therefore possible to create a language with
Objects that is not in any way inspired by, or derivative of
smalltalk? Because honestly, I'm confused about where you think the
concept of OOP came from to begin with.

 Coad / Yourdon suggests object-oriented being classes and
 objects, inheritance and communication with messages. Does JavaScript have
 classes? Can inheritance of JavaScript occur without prototype?


Those are typical elements in OOP languages, yes, and they all existed
in the original smalltalk. Are you suggesting that any slight
deviation from small talk renders a language completely not OOP? If
that were the case, you would pretty much have to rule out any
language that was not smalltalk itself. But let's assume you have a
less extreme position. What is your methodology to determine how far a
language can deviate from smalltalk before it is no longer OOP? You
seem fixated on the concept of classical inheritence being essential
for a language to be OOP, but this is contradicted by the existance of
numerous OOP languages that do not have classes. How do you account
for this?

Javascript in fact, does have classes, but not as a mechanism of
inheritence. Javascript's inheritence is prototypal. You seem to be
suggesting that this makes it not OOP. I would like to suggest that if
this makes Javascript not OOP, then you would have to say that a dozen
other OOP langauges are also not OOP.  The choice of class as a
defining characteristic of OOP seems arbitrary. If you can suggest
that any arbitrary deviation, such as class, from smalltalk makes a
language not OOP, then C++ and JAVA are not OOP either, due to their
numerous deviations.


 May I provide the following resource, pointing out second paragraph under
 'Adding a Method':
 http://www.kevlindev.com/tutorials/javascript/inheritance/index.htm

 Object-oriented programming consists of native inheritance. Are you
 suggesting that a prototypical approach to inheritance one in the same as
 native inheritance?


This is a red herring. With this, you have attempted to change the
topic from whether javascript is OOP or not, to whether it has
classical inheritence or not. Or, if you have not changed the topic,
you appear to be assuming that everyone is in agreement that classes
are a required attribute of OOP. This is arbitrary and nonsensical.

 Thanks,
 Anthony.

 Breton Slivka wrote:

 On Mon, Oct 27, 2008 at 12:02 PM, Anthony Ziebell
 [EMAIL PROTECTED] wrote:


 Luke,

 Discrediting c++ has nothing to do with the question Is JavaScript
 object-orientated?. With that, and in closing, I would like to point out
 that my comments were based on the actual question - asking if JavaScript
 were object-oriented, not if it has objects. Prototype has objects, and it
 is of my opinion that JavaScript is more prototype than anything else.

 Thanks,
 Anthony.


 Yes that's fine anthony, but the problem is that statement doesn't
 actually mean anything. it is logically invalid, and quite nonsensical
 to say javascript is not object oriented, it's more prototype based,
 because the two things are not mutually exclusive. Javascript having
 prototypical inheritence has absolutely nothing to do with the
 question of whether it is object oriented or not. It can be both
 object oriented, AND based on prototypal inheritence, and in fact, it
 is both. 100%. This is not my opinion. it is a fact.


 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: [EMAIL PROTECTED]
 ***




 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: [EMAIL PROTECTED]
 ***


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please





Hello,

Lets all just agree then, that the first insulin is simply the best, so
no further development in this area is needed. I am going to link you
to two more resources. If you feel that the first ever implementation
of object should mandate all others (such as the first insulins), then
I welcome you to submit edits to this article.

"Prototype-based programming is a style of object-oriented programming
in which classes are not present, and behavior reuse (known as
inheritance in class-based languages) is performed via a process of
cloning existing objects that serve as prototypes. This model can also
be known as class-less, prototype-oriented or instance-based
programming."

Source: http://en.wikipedia.org/wiki/Prototype-based_programming

"The most common criticism made against prototype-based languages is
that the community of software developers is not familiar with them,
despite the popularity and market permeation of _javascript_. This
knowledge level of prototype based systems seems to be changing with
the proliferation of _javascript_ frameworks and increases in the complex
use of _javascript_ as "Web 2.0" matures."

Source:
http://en.wikipedia.org/wiki/Prototype-based_programming#Criticism

Thanks,
Anthony.

Breton Slivka wrote:

  On Mon, Oct 27, 2008 at 1:17 PM, Anthony Ziebell
[EMAIL PROTECTED] wrote:
  
  
Breton,

There is a difference between the use of object and object-oriented
programming.

  
  
Yes you say that, but you never go into any detail about it.  In what
way in particular is the concept and use of "objects" independant from
"object orient programming". Did the concept of "objects" *not* come
from smalltalk, the original OOP language? Can you cite any occurance
of the concept of an "object" in programming that predates smalltalk?
Do you then, think it's therefore possible to create a language with
Objects that is not in any way inspired by, or derivative of
smalltalk? Because honestly, I'm confused about where you think the
concept of OOP came from to begin with.

  
  
Coad / Yourdon suggests object-oriented being classes and
objects, inheritance and communication with messages. Does _javascript_ have
classes? Can inheritance of _javascript_ occur without prototype?


  
  
Those are typical elements in OOP languages, yes, and they all existed
in the original smalltalk. Are you suggesting that any slight
deviation from small talk renders a language completely not OOP? If
that were the case, you would pretty much have to rule out any
language that was not smalltalk itself. But let's assume you have a
less extreme position. What is your methodology to determine how far a
language can deviate from smalltalk before it is no longer OOP? You
seem fixated on the concept of classical inheritence being essential
for a language to be OOP, but this is contradicted by the existance of
numerous OOP languages that do not have classes. How do you account
for this?

_javascript_ in fact, does have classes, but not as a mechanism of
inheritence. _javascript_'s inheritence is prototypal. You seem to be
suggesting that this makes it not OOP. I would like to suggest that if
this makes _javascript_ not OOP, then you would have to say that a dozen
other OOP langauges are also not OOP.  The choice of class as a
defining characteristic of OOP seems arbitrary. If you can suggest
that any arbitrary deviation, such as class, from smalltalk makes a
language not OOP, then C++ and JAVA are not OOP either, due to their
numerous deviations.


  
  
May I provide the following resource, pointing out second paragraph under
'Adding a Method':
http://www.kevlindev.com/tutorials/_javascript_/inheritance/index.htm

Object-oriented programming consists of native inheritance. Are you
suggesting that a prototypical approach to inheritance one in the same as
native inheritance?


  
  
This is a red herring. With this, you have attempted to change the
topic from whether _javascript_ is OOP or not, to whether it has
classical inheritence or not. Or, if you have not changed the topic,
you appear to be assuming that everyone is in agreement that classes
are a required attribute of OOP. This is arbitrary and nonsensical.

  
  
Thanks,
Anthony.

Breton Slivka wrote:

On Mon, Oct 27, 2008 at 12:02 PM, Anthony Ziebell
[EMAIL PROTECTED] wrote:


Luke,

Discrediting c++ has nothing to do with the question "Is _javascript_
object-orientated?". With that, and in closing, I would like to point out
that my comments were based on the actual question - asking if _javascript_
were object-oriented, not if it has objects. Prototype has objects, and it
is of my opinion that _javascript_ is more prototype than anything else.

Thanks,
Anthony.


Yes that's fine anthony, but the problem is that statement doesn't
actually mean anything. it is logically invalid, and quite nonsensical
to say "_javascript_ is not object oriented, it's more prototype based",
because the two things are not mutually exclusive.

Re: [WSG] JavaScript clarification please

On Mon, Oct 27, 2008 at 2:27 PM, Anthony Ziebell
[EMAIL PROTECTED] wrote:
 Hello,

 Lets all just agree then, that the first insulin is simply the best, so no
 further development in this area is needed. I am going to link you to two
 more resources. If you feel that the first ever implementation of object
 should mandate all others (such as the first insulins), then I welcome you
 to submit edits to this article.

You seem to have missed my point. My point was, if we are to count
arbitrary deviations from smalltalk as discounting a language from
being oop (such as a lack of classical inheritence), then the only OOP
language is smalltalk. This is clearly absurd. Therefore, javascript
must be OOP.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] JavaScript clarification please





You seem to have missed my point and many references
too.

Try reading some of the references and come back with an informed
opinion, not just nit-picking at analogies I am providing to attempt to
help you understand (as I gather you would not be reading any
references I have provided, which conflict with your argument anyway).

Thanks,
Anthony.

Breton Slivka wrote:

  On Mon, Oct 27, 2008 at 2:27 PM, Anthony Ziebell
[EMAIL PROTECTED] wrote:
  
  
Hello,

Lets all just agree then, that the first insulin is simply the best, so no
further development in this area is needed. I am going to link you to two
more resources. If you feel that the first ever implementation of object
should mandate all others (such as the first insulins), then I welcome you
to submit edits to this article.

  
  
You seem to have missed my point. My point was, if we are to count
arbitrary deviations from smalltalk as discounting a language from
being oop (such as a lack of classical inheritence), then the only OOP
language is smalltalk. This is clearly absurd. Therefore, _javascript_
must be OOP.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***


  




***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***

Re: [WSG] JavaScript clarification please