[Edbrowse-dev] defaultView and getComputedStyle patch

[Edbrowse-dev] defaultView and getComputedStyle patch

[Kevin Carhart]

>From 55a287314b389387e9a21da90282981d6c05959b Mon Sep 17 00:00:00 2001
From: Kevin Carhart <kevin@carhart.net>
Date: Sun, 13 Aug 2017 21:36:32 -0700
Subject: [PATCH] cleaning up defaultView and computedStyle, which is sitting
 in startwindow and is wrong.  Referred to some MDN documents about what it is
 supposed to do.  We are trying to pass the acidtests test #0

---
 src/jsrt           | 23 +++++++++++++++++++++++
 src/startwindow.js | 22 ++++++++++------------
 2 files changed, 33 insertions(+), 12 deletions(-)

diff --git a/src/jsrt b/src/jsrt
index 0fad97f..000d0c4 100644
--- a/src/jsrt
+++ b/src/jsrt
@@ -838,6 +838,29 @@ if(document.metas[1].content != "Snoopy")
 fail(163);
 // add tests for getAttribute etc, once Meta is actually a class in startwindow.js.
 
+test_computedstyle();
+function test_computedstyle()
+{
+var el = document.createElement("p");
+el.style = {"bgcolor":"white","color":"red"};
+var lbg = document.defaultView.getComputedStyle(el,'').bgcolor
+if (lbg == "white")
+{
+// pass
+} else {
+fail(164);
+}
+}
+
+
+
+
+
+
+
+
+
+
 </script>
 
 </body>
diff --git a/src/startwindow.js b/src/startwindow.js
index f7d3e02..18e7da6 100644
--- a/src/startwindow.js
+++ b/src/startwindow.js
@@ -752,24 +752,22 @@ getPropertyValue: function (n)         {
                 } else {
                         return this.style[n];
                 }
-        }
+        },
+
 }
 
-getComputedStyle = function(n) {
+getComputedStyle = function(e,pe) {
+	// disregarding pseudoelements for now
         obj = new CSSStyleDeclaration;
-        obj.element = this;
-        obj.style = new Array;
-        obj.style.push({n:obj.style[n]});
-        return obj;
+        obj.element = e;
+        obj.style = e.style;
+        return obj.style;
 }
 
-document.defaultView = function() { return this.style; }
+document.defaultView = function() { return window; }
 
-document.defaultView.getComputedStyle = function() {
-        obj = new CSSStyleDeclaration;
-        obj.element = document;
-        obj.style = document.style;
-        return obj;
+document.defaultView.getComputedStyle = function(e,pe) {
+	return window.getComputedStyle(e,pe);
 }
 
 // @author Originally implemented by Yehuda Katz
-- 
1.8.3.2

[Edbrowse-dev] defaultView and getComputedStyle patch

[Karl Dahlke]

I went ahead and pushed this patch because it does no harm and moves you forward, but it still confuses me.
Your getComputedStyle function at line 759 is equivalent to

function getComputedStyle(e, p) { return e.style; }

The obj variable is local and goes away when the function returns.
So why not write it my way it's a whole lot easier to understand. Unless I'm missing something.

Karl Dahlke

Re: [Edbrowse-dev] defaultView and getComputedStyle patch

[Kevin Carhart]

I think I've read mixed messages on what needs to be there, and that's why 
I ended up with something redundant.  It's confusing at the source. I 
think last year I had the getComputedStyle returning a 
CSSStyleDeclaration object, not just one of its properties.  I changed it 
yesterday because this usage:

document.defaultView.getComputedStyle(penultimate, '').whiteSpace

Suggests to me that the return value from getComputedStyle needs to be 
solely the CSSStyleDeclaration.style.  I was getting an error from the 
test #0 code yesterday when I returned the object, because I am off by 
one hop.  .whiteSpace exists, but it is located at 
CSSStyleDeclaration.style.whiteSpace.  I ended up with a muddle because I 
don't know which to do.  The documentation for window.getComputedStyle 
says "The returned style is a live CSSStyleDeclaration object, which 
updates itself automatically when the element's style is changed." 
Automatic updating is what the test is about I think.  But do we have to 
code something extra to make it work that way?

So here is a way of turning this into a specific question.  Is there a 
common thing in OOP where, if you just address the object on its own, it 
is the same as calling a particular method that has been designated as the 
default?  I don't remember the name for this but I feel like it exists. 
And the thing that would resolve what to do would be if this expression:

.getComputedStyle(penultimate, '').whiteSpace

Would actually reroute you under the hood to:

.getComputedStyle(penultimate, '').getPropertyValue(whiteSpace)

That's what I want to do - designate getPropertyValue to be the method 
that runs if nothing has been specified.  Is this a getter?  Is this a 
familiar idiom to anyone?

thanks
Kevin





  On Mon, 14 Aug 2017, Karl Dahlke wrote:

> I went ahead and pushed this patch because it does no harm and moves you forward, but it still confuses me.
> Your getComputedStyle function at line 759 is equivalent to
>
> function getComputedStyle(e, p) { return e.style; }
>
> The obj variable is local and goes away when the function returns.
> So why not write it my way it's a whole lot easier to understand. Unless I'm missing something.
>
> Karl Dahlke
> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

[Edbrowse-dev] defaultView and getComputedStyle patch

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

So CSSStyleDeclaration is a class that spins off objects.
Is it possible that every one of our style objects, that we create under nodes, should be an instance of CSSStyleDeclaration, rather than Object?
So under an anchor tag, or I should say the anchor object, we create style as an instance of CSSStyleDeclaration,
then link element back to the anchor object so we know where it came from.
anchorObj.style.element = anchorObj;
And I don't know about style, maybe that links to itself.
style.style = style;
Then your getComputedStyle(e) can indeed return e.style and everything works.
I don't know if this is how it's suppose to work, but I bet it would pass all the tests.

Karl Dahlke

Re: [Edbrowse-dev] defaultView and getComputedStyle patch

[Kevin Carhart]

If I understand correctly, I think you can't have too much dynamism or 
dynamicness.  Does CSSStyleDeclaration get you something that style does 
not?  Maybe so, if we write it that way.  Does CSSStyleDeclaration hinder 
you from something that style gives you?  I don't think so.  Are there any 
drawbacks?


  On Mon, 14 Aug 2017, Karl Dahlke wrote:

> So CSSStyleDeclaration is a class that spins off objects.
> Is it possible that every one of our style objects, that we create under nodes, should be an instance of CSSStyleDeclaration, rather than Object?
> So under an anchor tag, or I should say the anchor object, we create style as an instance of CSSStyleDeclaration,
> then link element back to the anchor object so we know where it came from.
> anchorObj.style.element = anchorObj;
> And I don't know about style, maybe that links to itself.
> style.style = style;
> Then your getComputedStyle(e) can indeed return e.style and everything works.
> I don't know if this is how it's suppose to work, but I bet it would pass all the tests.
>
> Karl Dahlke
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

Re: [Edbrowse-dev] defaultView and getComputedStyle patch

[Kevin Carhart]

I agree!   Sorry, I was being sort of rhetorical!  I should have said, 
it's a good idea because blah blah, CSSStyleDeclaration is a superset of 
style so it's good on all cylinders.

Where does it live, and how should we do it?  Is it JS, or is it back in 
decorate?

If you have time and stamina, I would like to keep going from this, to 
what is actually going wrong when it goes through the motions in test 
zero.  It can't be that difficult.  It is just some DOM maneuvers, but I 
think I have noticed something wrong with which scripts are found in head, 
or body.  It's great that we're banging this out.  Could you run those 
first three or four lines in case something will leap out at you that 
doesn't leap out at me?






On Tue, 15 Aug 2017, Karl Dahlke wrote:

>> Does CSSStyleDeclaration get you something that style does not?
>
> Sure. All the methods of CSSStyleDeclaration.
> Like if js ever calls
> some_element.style.getPropertyValue("foo");
> Etc.
>
> Karl Dahlke
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

[Edbrowse-dev] defaultView and getComputedStyle patch

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

> Where does it live, and how should we do it?

Both C and JS. I pushed the change, most of it but not all, look and see if it is reasonable.
If this is the right path then I still have to change the actual html tag <style> to be of this type, and a new tag action TAGACT_STYLE etc, so I'll try to do that in the next 24.

Karl Dahlke

Re: [Edbrowse-dev] defaultView and getComputedStyle patch

[Kevin Carhart]

It looks great to me!
I think my existing jsrt test still does the trick, right, even though the 
......

jesus, I left the semicolon off at 842 of jsrt.  Shouldn't this make it 
fail?



On Tue, 15 Aug 2017, Karl Dahlke wrote:

>> Where does it live, and how should we do it?
>
> Both C and JS. I pushed the change, most of it but not all, look and see if it is reasonable.
> If this is the right path then I still have to change the actual html tag <style> to be of this type, and a new tag action TAGACT_STYLE etc, so I'll try to do that in the next 24.
>
> Karl Dahlke
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

Re: [Edbrowse-dev] defaultView and getComputedStyle patch

[Kevin Carhart]

Sorry, that was kind of a distraction.  :)  Apparently I need to go read 
more articles like "Semicolons in Javascript are optional" by Mislav 
Marohnic.


On Tue, 15 Aug 2017, Kevin Carhart wrote:

>
> It looks great to me!
> I think my existing jsrt test still does the trick, right, even though the 
> ......
>
> jesus, I left the semicolon off at 842 of jsrt.  Shouldn't this make it fail?
>
>
>
> On Tue, 15 Aug 2017, Karl Dahlke wrote:
>
>>> Where does it live, and how should we do it?
>> 
>> Both C and JS. I pushed the change, most of it but not all, look and see if 
>> it is reasonable.
>> If this is the right path then I still have to change the actual html tag 
>> <style> to be of this type, and a new tag action TAGACT_STYLE etc, so I'll 
>> try to do that in the next 24.
>> 
>> Karl Dahlke
>> 
>
> --------
> Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

[Edbrowse-dev] defaultView and getComputedStyle patch

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

> Semicolons in Javascript are optional

Yes, if there is a newline that can syntactically stand in for semicolon, or a closing brace etc.
Some people think this is cool, I think it's kinda ridiculous / sloppy.
I can tell you it plays hell with the lexical scanner, I don't think you can use traditional tools like lex, and even if this weren't there, the bare regular expressions   /jkl'"qrs/  also derail any traditional scanner.
Yuck! Well that's duktape's problem.

Karl Dahlke