Oh my! A somewhat standards compliant Internet Explorer? What about JavaScript?

[-Lost]

http://blogs.msdn.com/ie/archive/200...xplorer-8-and-
acid2-a-milestone.aspx

Oh my! A somewhat standards compliant Internet Explorer? What about
JavaScript?

Not that it proves much, but it is definitely a huge step in the
right direction.

Bruce Lawson of The Web Standards Project seems optimistic albeit a
mite cautiously, but this has significant implications in the way
Internet Explorer views CSS -- data URI's and generated content for
one.

But my question is what about JavaScript? Am I missing a blog or
technote somewhere? It appears that Internet Explorer 8 focuses on
the designer and not the architect... I'm not sure I understand.

Anyone? Thanks!

--
-Lost
Remove the extra words to reply by e-mail. Don't e-mail me. I am
kidding. No I am not.

[RobG]

On Dec 20, 4:55 pm, "-Lost" <[e-mail]:

http://blogs.msdn.com/ie/archive/200...xplorer-8-and-
acid2-a-milestone.aspx

When posting a URL, wrap it in: <URL: to help agents render them
properly, e.g.

<URL: http://blogs.msdn.com/ie/archive/200...milestone.aspx

>

>
Oh my! A somewhat standards compliant Internet Explorer? What about
JavaScript?

What significant bugs does JScript have? OK, there are some well-
known bugs with elisions, toFixed, etc. but there's nothing too major
as far as I know.

[...]

But my question is what about JavaScript? Am I missing a blog or
technote somewhere? It appears that Internet Explorer 8 focuses on
the designer and not the architect... I'm not sure I understand.

For most web application architects, javascript is in the same
category as CSS - it makes life pretty for the user but does not
deliver core functionality. XmlHTTPRequest and similar functionality
has changed that view a bit, but not by much.
--
Rob

[Randy Webb]

RobG said the following on 12/20/2007 2:09 AM:

On Dec 20, 4:55 pm, "-Lost" <[e-mail]:

>http://blogs.msdn.com/ie/archive/200...xplorer-8-and-
acid2-a-milestone.aspx

When posting a URL, wrap it in: <URL: to help agents render them
properly, e.g.

<URL: http://blogs.msdn.com/ie/archive/200...milestone.aspx

>Oh my! A somewhat standards compliant Internet Explorer? What about
JavaScript?

What significant bugs does JScript have? OK, there are some well-
known bugs with elisions, toFixed, etc. but there's nothing too major
as far as I know.

Why can't I appendChild to a script block? <g>

[...]

>But my question is what about JavaScript? Am I missing a blog or
technote somewhere? It appears that Internet Explorer 8 focuses on
the designer and not the architect... I'm not sure I understand.

For most web application architects, javascript is in the same
category as CSS - it makes life pretty for the user but does not
deliver core functionality. XmlHTTPRequest and similar functionality
has changed that view a bit, but not by much.

Depends on who you ask though. I have always said, and believed, that
the trend on the web is towards a JS dependency, not away from it.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[-Lost]

Response to RobG <rg***@iinet.net.au>:

>Oh my! A somewhat standards compliant Internet Explorer? What
about JavaScript?

What significant bugs does JScript have? OK, there are some well-
known bugs with elisions, toFixed, etc. but there's nothing too
major as far as I know.

Not necessarily bugs, but a few inconsistencies in how the DOM is
handled and how CSS is computed and made available to script.

I basically meant, "Is this it?" Pretty much the same as some of the
comments on the page.

[...]

>But my question is what about JavaScript? Am I missing a blog or
technote somewhere? It appears that Internet Explorer 8 focuses
on the designer and not the architect... I'm not sure I
understand.

For most web application architects, javascript is in the same
category as CSS - it makes life pretty for the user but does not
deliver core functionality. XmlHTTPRequest and similar
functionality has changed that view a bit, but not by much.

Hrmm... I don't agree. JavaScript can indeed provide core
functionality in that it can replace standard functionality when
available. Plus I cannot think of a single instance where JavaScript
makes anything look "pretty," unless you mean effects and whatnot.

Granted, most scripters use it to provide little to no benefit to the
end-user, but... *shrugs*

--
-Lost
Remove the extra words to reply by e-mail. Don't e-mail me. I am
kidding. No I am not.

[-Lost]

Response to Randy Webb <Hi************@aol.com>:

>What significant bugs does JScript have? OK, there are some
well- known bugs with elisions, toFixed, etc. but there's nothing
too major as far as I know.

Why can't I appendChild to a script block? <g>

Hence my DOM comment. And of course the quite dead horse of
attachEvent and it's molestation of "this."

Inconsistent pattern with attachEvent as well in that it requires the
user to state an event as if it was declared inline, e.g. the use of
"on."

The necessity to detachEvent's to avoid a leaky Internet Explorer and
the fact there is no cap on the amount of event handlers that can be
registered on a single element/object. And of course then event
capturing as opposed to event bubbling.

</cheatsheet>

>>But my question is what about JavaScript? Am I missing a blog
or technote somewhere? It appears that Internet Explorer 8
focuses on the designer and not the architect... I'm not sure I
understand.

For most web application architects, javascript is in the same
category as CSS - it makes life pretty for the user but does not
deliver core functionality. XmlHTTPRequest and similar
functionality has changed that view a bit, but not by much.

Depends on who you ask though. I have always said, and believed,
that the trend on the web is towards a JS dependency, not away
from it.

I believe the same. Although I cannot vouch for the usability or
effective deployment of most JavaScript content on the Web, but it is
definitely the trend.

A few months back during an introductory Web design course I took one
"expert" user actually argued the point that one should use
JavaScript for whatever because it is more widely supported than CSS.

--
-Lost
Remove the extra words to reply by e-mail. Don't e-mail me. I am
kidding. No I am not.

[Andrew Poulos]

-Lost wrote:

Granted, most scripters use it to provide little to no benefit to the
end-user, but... *shrugs*

If you were to try to build elearning for a SCORM or AICC compliant LMS
then it would be "impossible" to do so without javascript.

Andrew Poulos

[Randy Webb]

-Lost said the following on 12/20/2007 3:20 AM:

Response to RobG <rg***@iinet.net.au>:

>>Oh my! A somewhat standards compliant Internet Explorer? What
about JavaScript?

What significant bugs does JScript have? OK, there are some well-
known bugs with elisions, toFixed, etc. but there's nothing too
major as far as I know.

Not necessarily bugs, but a few inconsistencies in how the DOM is
handled and how CSS is computed and made available to script.

I basically meant, "Is this it?" Pretty much the same as some of the
comments on the page.

Nobody will be able to answer that until a beta release of IE8 is made.
If the picture and article are true, then it is a step forwards. I can't
get FF3 to pass the Acid2 test (even though comments on the blog says it
does).

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[David Mark]

On Dec 20, 3:37 am, "-Lost" <[e-mail]:

Response to Randy Webb <[e-mail]>:

What significant bugs does JScript have? OK, there are some
well- known bugs with elisions, toFixed, etc. but there's nothing
too major as far as I know.

Why can't I appendChild to a script block? <g>

Hence my DOM comment. And of course the quite dead horse of
attachEvent and it's molestation of "this."

And get/setAttribute of course.

Then there are the many missing features, like the previously
mentioned getComputedStyle. Manual conversion of cascaded styles is a
major pain (and sometimes impossible.)

>
Inconsistent pattern with attachEvent as well in that it requires the
user to state an event as if it was declared inline, e.g. the use of
"on."

Yes, that is ugly.

>
The necessity to detachEvent's to avoid a leaky Internet Explorer and

What a mess. I had been using a detachEvent queue for years, but
recently questioned whether it was needed. It isn't as if attachEvent
adds a property to the element object. It seemed reasonable to me
that only DOM0 implementations should have to worry about creating
circular references. The information in the MSDN article on leaks
contradicts this theory. Apparently attachEvent can create a circular
reference behind the scenes. Hopefully, if they do fix the garbage
collection, they will eliminate attachEvent in favor of a standard
addEventListener implementation. Otherwise, scripts will have to
continue to clean up after IE as there is no way to detect if
attachEvent leaks or not.

the fact there is no cap on the amount of event handlers that can be
registered on a single element/object. And of course then event

What cap would you suggest?

capturing as opposed to event bubbling.

That would open up a lot of possibilites, but they should only do it
with an addEventListener implementation. If they added it to
attachListener, there would be no safe way to use it.

>
</cheatsheet>

>But my question is what about JavaScript? Am I missing a blog
or technote somewhere? It appears that Internet Explorer 8
focuses on the designer and not the architect... I'm not sure I
understand.

For most web application architects, javascript is in the same
category as CSS - it makes life pretty for the user but does not
deliver core functionality. XmlHTTPRequest and similar
functionality has changed that view a bit, but not by much.

Depends on who you ask though. I have always said, and believed,
that the trend on the web is towards a JS dependency, not away
from it.

I believe the same. Although I cannot vouch for the usability or
effective deployment of most JavaScript content on the Web, but it is
definitely the trend.

A few months back during an introductory Web design course I took one
"expert" user actually argued the point that one should use
JavaScript for whatever because it is more widely supported than CSS.

I don't know what to make of that.

[-Lost]

Response to David Mark <dm***********@gmail.com>:

>the fact there is no cap on the amount of event handlers that can be
registered on a single element/object. And of course then event

What cap would you suggest?

Oops, I meant to say "no cap on the amount of DUPLICATE event
handlers..."

Sorry about that.

--
-Lost
Remove the extra words to reply by e-mail. Don't e-mail me. I am
kidding. No I am not.

[-Lost]

Response to Andrew Poulos <ap*****@hotmail.com>:

>Granted, most scripters use it to provide little to no benefit to
the end-user, but... *shrugs*

If you were to try to build elearning for a SCORM or AICC
compliant LMS then it would be "impossible" to do so without
javascript.

Good point. Another example of JavaScript providing true core
functionality in my opinion.

--
-Lost
Remove the extra words to reply by e-mail. Don't e-mail me. I am
kidding. No I am not.