edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Kevin Carhart <kevin@carhart.net>
To: Karl Dahlke <eklhad@comcast.net>
Cc: Edbrowse-dev@lists.the-brannons.com
Subject: Re: [Edbrowse-dev] setAttribute
Date: Tue, 6 Oct 2015 16:51:01 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LRH.2.03.1510061641040.12804@carhart.net> (raw)
In-Reply-To: <20150906134334.eklhad@comcast.net>



Hmmmm.

I was wondering "what is the difference between
the two techniques anyhow?"
When I go and check around for an answer to the question
"what is the difference between the two techniques anyhow?"
It seems like people are saying that dot notation is
actually preferred and is a superset of
setAttribute.  So what if
our setAttribute implementation just did blah.prop = value
under the hood?  Would that also obviate the side
effects question because now it would get back to
edbrowse just like any assignment would?



On Tue, 6 Oct 2015, Karl Dahlke wrote:

> Question - does the setAttribute() method need to have any side effects?
> If not, then it need not be native.
>
> Here's how I see it.
> If all js all the time uses setAttribute to change js dom variables
> that edbrowse would need to know about,
> then yes it has to have a side effect, to pass the variable assignment
> back to edbrowse.
> But if ever js ever sets foo=bar directly,
> and still this is something edbrowse needs to know about,
> then edbrowse just has to check at run time,
> and it's always checking, and since it is checking there is no need for
> a setAttribute side effect.
>
> Perhaps an example would clear up this mess.
> When you submit a form you jump to the action attribute in the form tag.
> 	<form action=this.that.com>
> All good but if js changes the action to somewhere else
> 	form.action="peanutbutter.com";
> then that is where submit is suppose to go.
> This must have happened somewhere, some time, because I programmed for this.
> At time of submit, if js is active
> I retrieve the action variable from js and go there,
> if js is not active then I use the url in the html tag.
> It's even exercised in jsrt.
> I'm not relying on setAttribute to tell me that action has changed,
> I check for it at time of submit.
> I think in this case, or in some cases,
> I just have to check the js variables at run time.
>
> As I mentioned above, if I have to check variables at run time
> then I'm going to check them,
> and there's no real advantage of getting a heads up from setAttribute.
>
> Well these are just the thoughts running around my head today.
>
> 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

  reply	other threads:[~2015-10-06 23:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-06 17:43 Karl Dahlke
2015-10-06 23:51 ` Kevin Carhart [this message]
2015-10-07  0:10   ` Karl Dahlke
2015-10-07  2:26     ` Chris Brannon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LRH.2.03.1510061641040.12804@carhart.net \
    --to=kevin@carhart.net \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    --cc=eklhad@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).