Spent a bunch of hours putting env.js back together with the java pulled out. Added a bunch of core window attributes and their respective functions/attributes.
I checked against the current tests that John had running with make, I should have checked before, now I can't remember how many passed failed etc, but currently 531 pass and 117 fail.
The build process is still rough, concat with ant and run jsl by hand. I commited the distributables so folks can try without having to build for now. You'll want to download dist/env.rhino.js.
The major weakness, imho, currently is the dom stuff which really needs to be seperated out into the dom and html parts respectively. I'm going to look back through the mailings because I know someone started that and it would be great to make a coordinated effort to just get it done.
It's starting to look much more like the skeleton of a full browser environment.
This is great news, Chris - I'll check into the details of your implementation as soon as I can. Definitely try to see what the difference in pass/fail is from the normal one - 117 sounds a little high.
<thatcher.christop...@gmail.com> wrote: > Spent a bunch of hours putting env.js back together with the java pulled > out. Added a bunch of core window attributes and their respective > functions/attributes.
> I checked against the current tests that John had running with make, I > should have checked before, now I can't remember how many passed failed etc, > but currently 531 pass and 117 fail.
> The build process is still rough, concat with ant and run jsl by hand. I > commited the distributables so folks can try without having to build for > now. You'll want to download dist/env.rhino.js.
> The major weakness, imho, currently is the dom stuff which really needs to > be seperated out into the dom and html parts respectively. I'm going to > look back through the mailings because I know someone started that and it > would be great to make a coordinated effort to just get it done.
> It's starting to look much more like the skeleton of a full browser > environment.
pretty sure its related to some stuff I missed with NodeList. I'm breaking the dom stuff out now and implementing the rest of them. I'm also going to stub out the html stuff and if I can pull it out of my butt will have it done by morning. The project will look bloated becuase I'm starting with a js file per interface, but we can move stuff around later.
I am interested in having folks with knowledge of other js engines look at how the env platform specific stuff was broken out, I'm expecting those requirements to change the implementation details, but again, it's just a step in the right direction.
I'm relying heavily on David Flanagan's 'JavaScript - The Definitive Guide' to understand everything that's meant to be exposed for browser client javascript. If there is a better resource let me know.
On Tue, Nov 11, 2008 at 5:53 PM, John Resig <jere...@gmail.com> wrote:
> This is great news, Chris - I'll check into the details of your > implementation as soon as I can. Definitely try to see what the > difference in pass/fail is from the normal one - 117 sounds a little > high.
> --John
> On Tue, Nov 11, 2008 at 3:09 PM, chris thatcher > <thatcher.christop...@gmail.com> wrote: > > Spent a bunch of hours putting env.js back together with the java pulled > > out. Added a bunch of core window attributes and their respective > > functions/attributes.
> > I checked against the current tests that John had running with make, I > > should have checked before, now I can't remember how many passed failed > etc, > > but currently 531 pass and 117 fail.
> > The build process is still rough, concat with ant and run jsl by hand. I > > commited the distributables so folks can try without having to build for > > now. You'll want to download dist/env.rhino.js.
> > The major weakness, imho, currently is the dom stuff which really needs > to > > be seperated out into the dom and html parts respectively. I'm going to > > look back through the mailings because I know someone started that and it > > would be great to make a coordinated effort to just get it done.
> > It's starting to look much more like the skeleton of a full browser > > environment.
Hey Chris,
That would be me that you are talking about. I got distracted (I am
sorry to admit I have been playing Fallout 3).
I am going on a month long holiday in December (around the 7th), but I
going to try and pull myself away from Fallout long enough to get some
more done. I have been relying on the DOM level 2 standard [1]
(straight from the horses mouth), but I have been creating my own
tests (using a framework I help develop for work) to run against this.
IMHO, I would be wary of testing against jQuery. I think the standard
should be the HTML DOM standard. If we work towards providing support
to test jQuery, we might fool ourselves and we may not cover some
cases that jQuery (probably rightly) does not support. For example,
did you know that <br> and script tags can have a class? Things like
this are not supported by jQuery, but I think we should.
I had setup my own repository [2], and you can have a look at it.
Someone had fixed up my code, but I cannot remember who it was. They
put a reference on the mailing list. This code is out of date, and I
need to work out how to upload the new stuff. In the new stuff, I have
better support for HTMLDocument support and HTMLImageElement support
(surprisingly tricky)
Some of the issues I still have to cover off:
* How do we handle DOMElements vs HTMLElement
* Right now, I have hacked the code to have XMLHttpRequest instantiate
a HTMLDocument in all circumstances. This is wrong, so we may need to
remove the use of XMLHttpRequest to initialise the document.
* Right now, I have the following code repeated for most elements that
inherit HTMLElement:
this._dom = node; if (node === undefined) return;
// Load CSS info
var styles = (this.getAttribute("style") || "").split(/\s*;\s*/);
for ( var i = 0; i < styles.length; i++ ) {
var style = styles[i].split(/\s*:\s*/);
if ( style.length == 2 )
this.style[ style[0] ] = style[1];
}
// This isn't accurate, but it will do as most elements support style.
// TODO: Provide more rigid style support.
this.style = {
get opacity(){ return this._opacity; },
set opacity(val){ this._opacity = val + ""; }
}
This is nasty, and it will only get worse. Any suggestions appreciated.
* Also, as I say in the comment above, our support for the style
element is pretty lousy. We need to fix it up.
<thatcher.christop...@gmail.com> wrote:
> pretty sure its related to some stuff I missed with NodeList. I'm breaking
> the dom stuff out now and implementing the rest of them. I'm also going to
> stub out the html stuff and if I can pull it out of my butt will have it
> done by morning. The project will look bloated becuase I'm starting with a
> js file per interface, but we can move stuff around later.
> I am interested in having folks with knowledge of other js engines look at
> how the env platform specific stuff was broken out, I'm expecting those
> requirements to change the implementation details, but again, it's just a
> step in the right direction.
> I'm relying heavily on David Flanagan's 'JavaScript - The Definitive Guide'
> to understand everything that's meant to be exposed for browser client
> javascript. If there is a better resource let me know.
> On Tue, Nov 11, 2008 at 5:53 PM, John Resig <jere...@gmail.com> wrote:
>> This is great news, Chris - I'll check into the details of your
>> implementation as soon as I can. Definitely try to see what the
>> difference in pass/fail is from the normal one - 117 sounds a little
>> high.
>> --John
>> On Tue, Nov 11, 2008 at 3:09 PM, chris thatcher
>> <thatcher.christop...@gmail.com> wrote:
>> > Spent a bunch of hours putting env.js back together with the java pulled
>> > out. Added a bunch of core window attributes and their respective
>> > functions/attributes.
>> > I checked against the current tests that John had running with make, I
>> > should have checked before, now I can't remember how many passed failed
>> > etc,
>> > but currently 531 pass and 117 fail.
>> > The build process is still rough, concat with ant and run jsl by hand.
>> > I
>> > commited the distributables so folks can try without having to build for
>> > now. You'll want to download dist/env.rhino.js.
>> > The major weakness, imho, currently is the dom stuff which really needs
>> > to
>> > be seperated out into the dom and html parts respectively. I'm going to
>> > look back through the mailings because I know someone started that and
>> > it
>> > would be great to make a coordinated effort to just get it done.
>> > It's starting to look much more like the skeleton of a full browser
>> > environment.
Actually, scratch what I said about finishing off the image tag. The
image tag still needs work. I didn't do the height and width
attributes :( They aren't going to be simple to implement. I will have
to think about that.
On Thu, Nov 13, 2008 at 8:03 PM, Kamal Bhatt <kamal.bh...@gmail.com> wrote:
> Hey Chris,
> That would be me that you are talking about. I got distracted (I am
> sorry to admit I have been playing Fallout 3).
> I am going on a month long holiday in December (around the 7th), but I
> going to try and pull myself away from Fallout long enough to get some
> more done. I have been relying on the DOM level 2 standard [1]
> (straight from the horses mouth), but I have been creating my own
> tests (using a framework I help develop for work) to run against this.
> IMHO, I would be wary of testing against jQuery. I think the standard
> should be the HTML DOM standard. If we work towards providing support
> to test jQuery, we might fool ourselves and we may not cover some
> cases that jQuery (probably rightly) does not support. For example,
> did you know that <br> and script tags can have a class? Things like
> this are not supported by jQuery, but I think we should.
> I had setup my own repository [2], and you can have a look at it.
> Someone had fixed up my code, but I cannot remember who it was. They
> put a reference on the mailing list. This code is out of date, and I
> need to work out how to upload the new stuff. In the new stuff, I have
> better support for HTMLDocument support and HTMLImageElement support
> (surprisingly tricky)
> Some of the issues I still have to cover off:
> * How do we handle DOMElements vs HTMLElement
> * Right now, I have hacked the code to have XMLHttpRequest instantiate
> a HTMLDocument in all circumstances. This is wrong, so we may need to
> remove the use of XMLHttpRequest to initialise the document.
> * Right now, I have the following code repeated for most elements that
> inherit HTMLElement:
> this._dom = node;
> if (node === undefined) return;
> // Load CSS info
> var styles = (this.getAttribute("style") || "").split(/\s*;\s*/);
> for ( var i = 0; i < styles.length; i++ ) {
> var style = styles[i].split(/\s*:\s*/);
> if ( style.length == 2 )
> this.style[ style[0] ] = style[1];
> }
> // This isn't accurate, but it will do as most elements support style.
> // TODO: Provide more rigid style support.
> this.style = {
> get opacity(){ return this._opacity; },
> set opacity(val){ this._opacity = val + ""; }
> }
> This is nasty, and it will only get worse. Any suggestions appreciated.
> * Also, as I say in the comment above, our support for the style
> element is pretty lousy. We need to fix it up.
> On Wed, Nov 12, 2008 at 12:53 PM, chris thatcher
> <thatcher.christop...@gmail.com> wrote:
>> pretty sure its related to some stuff I missed with NodeList. I'm breaking
>> the dom stuff out now and implementing the rest of them. I'm also going to
>> stub out the html stuff and if I can pull it out of my butt will have it
>> done by morning. The project will look bloated becuase I'm starting with a
>> js file per interface, but we can move stuff around later.
>> I am interested in having folks with knowledge of other js engines look at
>> how the env platform specific stuff was broken out, I'm expecting those
>> requirements to change the implementation details, but again, it's just a
>> step in the right direction.
>> I'm relying heavily on David Flanagan's 'JavaScript - The Definitive Guide'
>> to understand everything that's meant to be exposed for browser client
>> javascript. If there is a better resource let me know.
>> On Tue, Nov 11, 2008 at 5:53 PM, John Resig <jere...@gmail.com> wrote:
>>> This is great news, Chris - I'll check into the details of your
>>> implementation as soon as I can. Definitely try to see what the
>>> difference in pass/fail is from the normal one - 117 sounds a little
>>> high.
>>> --John
>>> On Tue, Nov 11, 2008 at 3:09 PM, chris thatcher
>>> <thatcher.christop...@gmail.com> wrote:
>>> > Spent a bunch of hours putting env.js back together with the java pulled
>>> > out. Added a bunch of core window attributes and their respective
>>> > functions/attributes.
>>> > I checked against the current tests that John had running with make, I
>>> > should have checked before, now I can't remember how many passed failed
>>> > etc,
>>> > but currently 531 pass and 117 fail.
>>> > The build process is still rough, concat with ant and run jsl by hand.
>>> > I
>>> > commited the distributables so folks can try without having to build for
>>> > now. You'll want to download dist/env.rhino.js.
>>> > The major weakness, imho, currently is the dom stuff which really needs
>>> > to
>>> > be seperated out into the dom and html parts respectively. I'm going to
>>> > look back through the mailings because I know someone started that and
>>> > it
>>> > would be great to make a coordinated effort to just get it done.
>>> > It's starting to look much more like the skeleton of a full browser
>>> > environment.
Hey Kamal, that's great to hear. It is a daunting amount of code to write.
Regarding the css styles I'm finishing up three interfaces CSS2Properties,
CSSRule, and CSSStyleSheet that will allow us to them internally.
Externally the interfaces are defined on the window object but don't allow
construction (this is the way it work in the browser).
I'm adding John's sizzle as the rules engine.
One thing we'll need to think about is allowing css loading to be optional
because some folks won't want to have the overhead.
Still a lot of details to work out but we're getting closer. I'm going to
poke around your repo and see what your doing and maybe we can plan on
integrating our work more next week.
On Thu, Nov 13, 2008 at 4:03 AM, Kamal Bhatt <kamal.bh...@gmail.com> wrote:
> Hey Chris,
> That would be me that you are talking about. I got distracted (I am
> sorry to admit I have been playing Fallout 3).
> I am going on a month long holiday in December (around the 7th), but I
> going to try and pull myself away from Fallout long enough to get some
> more done. I have been relying on the DOM level 2 standard [1]
> (straight from the horses mouth), but I have been creating my own
> tests (using a framework I help develop for work) to run against this.
> IMHO, I would be wary of testing against jQuery. I think the standard
> should be the HTML DOM standard. If we work towards providing support
> to test jQuery, we might fool ourselves and we may not cover some
> cases that jQuery (probably rightly) does not support. For example,
> did you know that <br> and script tags can have a class? Things like
> this are not supported by jQuery, but I think we should.
> I had setup my own repository [2], and you can have a look at it.
> Someone had fixed up my code, but I cannot remember who it was. They
> put a reference on the mailing list. This code is out of date, and I
> need to work out how to upload the new stuff. In the new stuff, I have
> better support for HTMLDocument support and HTMLImageElement support
> (surprisingly tricky)
> Some of the issues I still have to cover off:
> * How do we handle DOMElements vs HTMLElement
> * Right now, I have hacked the code to have XMLHttpRequest instantiate
> a HTMLDocument in all circumstances. This is wrong, so we may need to
> remove the use of XMLHttpRequest to initialise the document.
> * Right now, I have the following code repeated for most elements that
> inherit HTMLElement:
> this._dom = node;
> if (node === undefined) return;
> // Load CSS info
> var styles = (this.getAttribute("style") ||
> "").split(/\s*;\s*/);
> for ( var i = 0; i < styles.length; i++ ) {
> var style = styles[i].split(/\s*:\s*/);
> if ( style.length == 2 )
> this.style[ style[0] ] = style[1];
> }
> // This isn't accurate, but it will do as most elements
> support style.
> // TODO: Provide more rigid style support.
> this.style = {
> get opacity(){ return this._opacity; },
> set opacity(val){ this._opacity = val + ""; }
> }
> This is nasty, and it will only get worse. Any suggestions appreciated.
> * Also, as I say in the comment above, our support for the style
> element is pretty lousy. We need to fix it up.
> On Wed, Nov 12, 2008 at 12:53 PM, chris thatcher
> <thatcher.christop...@gmail.com> wrote:
> > pretty sure its related to some stuff I missed with NodeList. I'm
> breaking
> > the dom stuff out now and implementing the rest of them. I'm also going
> to
> > stub out the html stuff and if I can pull it out of my butt will have it
> > done by morning. The project will look bloated becuase I'm starting with
> a
> > js file per interface, but we can move stuff around later.
> > I am interested in having folks with knowledge of other js engines look
> at
> > how the env platform specific stuff was broken out, I'm expecting those
> > requirements to change the implementation details, but again, it's just a
> > step in the right direction.
> > I'm relying heavily on David Flanagan's 'JavaScript - The Definitive
> Guide'
> > to understand everything that's meant to be exposed for browser client
> > javascript. If there is a better resource let me know.
> > On Tue, Nov 11, 2008 at 5:53 PM, John Resig <jere...@gmail.com> wrote:
> >> This is great news, Chris - I'll check into the details of your
> >> implementation as soon as I can. Definitely try to see what the
> >> difference in pass/fail is from the normal one - 117 sounds a little
> >> high.
> >> --John
> >> On Tue, Nov 11, 2008 at 3:09 PM, chris thatcher
> >> <thatcher.christop...@gmail.com> wrote:
> >> > Spent a bunch of hours putting env.js back together with the java
> pulled
> >> > out. Added a bunch of core window attributes and their respective
> >> > functions/attributes.
> >> > I checked against the current tests that John had running with make, I
> >> > should have checked before, now I can't remember how many passed
> failed
> >> > etc,
> >> > but currently 531 pass and 117 fail.
> >> > The build process is still rough, concat with ant and run jsl by hand.
> >> > I
> >> > commited the distributables so folks can try without having to build
> for
> >> > now. You'll want to download dist/env.rhino.js.
> >> > The major weakness, imho, currently is the dom stuff which really
> needs
> >> > to
> >> > be seperated out into the dom and html parts respectively. I'm going
> to
> >> > look back through the mailings because I know someone started that and
> >> > it
> >> > would be great to make a coordinated effort to just get it done.
> >> > It's starting to look much more like the skeleton of a full browser
> >> > environment.
I think we need to think about how we are going to access resources in
general and what we are going to do with them. For example, you can
get the height and width of an image. From what I understand, if no
height and width is specified then you get the height and width of the
image. This is potentially difficult and resource hungry.
<thatcher.christop...@gmail.com> wrote:
> Hey Kamal, that's great to hear. It is a daunting amount of code to write.
> Regarding the css styles I'm finishing up three interfaces CSS2Properties,
> CSSRule, and CSSStyleSheet that will allow us to them internally.
> Externally the interfaces are defined on the window object but don't allow
> construction (this is the way it work in the browser).
> I'm adding John's sizzle as the rules engine.
> One thing we'll need to think about is allowing css loading to be optional
> because some folks won't want to have the overhead.
> Still a lot of details to work out but we're getting closer. I'm going to
> poke around your repo and see what your doing and maybe we can plan on
> integrating our work more next week.
> Thatcher
> On Thu, Nov 13, 2008 at 4:03 AM, Kamal Bhatt <kamal.bh...@gmail.com> wrote:
>> Hey Chris,
>> That would be me that you are talking about. I got distracted (I am
>> sorry to admit I have been playing Fallout 3).
>> I am going on a month long holiday in December (around the 7th), but I
>> going to try and pull myself away from Fallout long enough to get some
>> more done. I have been relying on the DOM level 2 standard [1]
>> (straight from the horses mouth), but I have been creating my own
>> tests (using a framework I help develop for work) to run against this.
>> IMHO, I would be wary of testing against jQuery. I think the standard
>> should be the HTML DOM standard. If we work towards providing support
>> to test jQuery, we might fool ourselves and we may not cover some
>> cases that jQuery (probably rightly) does not support. For example,
>> did you know that <br> and script tags can have a class? Things like
>> this are not supported by jQuery, but I think we should.
>> I had setup my own repository [2], and you can have a look at it.
>> Someone had fixed up my code, but I cannot remember who it was. They
>> put a reference on the mailing list. This code is out of date, and I
>> need to work out how to upload the new stuff. In the new stuff, I have
>> better support for HTMLDocument support and HTMLImageElement support
>> (surprisingly tricky)
>> Some of the issues I still have to cover off:
>> * How do we handle DOMElements vs HTMLElement
>> * Right now, I have hacked the code to have XMLHttpRequest instantiate
>> a HTMLDocument in all circumstances. This is wrong, so we may need to
>> remove the use of XMLHttpRequest to initialise the document.
>> * Right now, I have the following code repeated for most elements that
>> inherit HTMLElement:
>> this._dom = node;
>> if (node === undefined) return;
>> // Load CSS info
>> var styles = (this.getAttribute("style") ||
>> "").split(/\s*;\s*/);
>> for ( var i = 0; i < styles.length; i++ ) {
>> var style = styles[i].split(/\s*:\s*/);
>> if ( style.length == 2 )
>> this.style[ style[0] ] = style[1];
>> }
>> // This isn't accurate, but it will do as most elements
>> support style.
>> // TODO: Provide more rigid style support.
>> this.style = {
>> get opacity(){ return this._opacity; },
>> set opacity(val){ this._opacity = val + ""; }
>> }
>> This is nasty, and it will only get worse. Any suggestions appreciated.
>> * Also, as I say in the comment above, our support for the style
>> element is pretty lousy. We need to fix it up.
>> On Wed, Nov 12, 2008 at 12:53 PM, chris thatcher
>> <thatcher.christop...@gmail.com> wrote:
>> > pretty sure its related to some stuff I missed with NodeList. I'm
>> > breaking
>> > the dom stuff out now and implementing the rest of them. I'm also going
>> > to
>> > stub out the html stuff and if I can pull it out of my butt will have it
>> > done by morning. The project will look bloated becuase I'm starting
>> > with a
>> > js file per interface, but we can move stuff around later.
>> > I am interested in having folks with knowledge of other js engines look
>> > at
>> > how the env platform specific stuff was broken out, I'm expecting those
>> > requirements to change the implementation details, but again, it's just
>> > a
>> > step in the right direction.
>> > I'm relying heavily on David Flanagan's 'JavaScript - The Definitive
>> > Guide'
>> > to understand everything that's meant to be exposed for browser client
>> > javascript. If there is a better resource let me know.
>> > On Tue, Nov 11, 2008 at 5:53 PM, John Resig <jere...@gmail.com> wrote:
>> >> This is great news, Chris - I'll check into the details of your
>> >> implementation as soon as I can. Definitely try to see what the
>> >> difference in pass/fail is from the normal one - 117 sounds a little
>> >> high.
>> >> --John
>> >> On Tue, Nov 11, 2008 at 3:09 PM, chris thatcher
>> >> <thatcher.christop...@gmail.com> wrote:
>> >> > Spent a bunch of hours putting env.js back together with the java
>> >> > pulled
>> >> > out. Added a bunch of core window attributes and their respective
>> >> > functions/attributes.
>> >> > I checked against the current tests that John had running with make,
>> >> > I
>> >> > should have checked before, now I can't remember how many passed
>> >> > failed
>> >> > etc,
>> >> > but currently 531 pass and 117 fail.
>> >> > The build process is still rough, concat with ant and run jsl by
>> >> > hand.
>> >> > I
>> >> > commited the distributables so folks can try without having to build
>> >> > for
>> >> > now. You'll want to download dist/env.rhino.js.
>> >> > The major weakness, imho, currently is the dom stuff which really
>> >> > needs
>> >> > to
>> >> > be seperated out into the dom and html parts respectively. I'm going
>> >> > to
>> >> > look back through the mailings because I know someone started that
>> >> > and
>> >> > it
>> >> > would be great to make a coordinated effort to just get it done.
>> >> > It's starting to look much more like the skeleton of a full browser
>> >> > environment.
