[Edbrowse-dev] setAttribute

[Edbrowse-dev] setAttribute

[Karl Dahlke]

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

Re: [Edbrowse-dev] setAttribute

[Kevin Carhart]

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

[Edbrowse-dev] setAttribute

[Karl Dahlke]

> It seems like people are saying that dot notation is
> actually preferred and is a superset of setAttribute.

Yes so it seems, so I have to query variables as needed anyways,
so no need for setAttribute to do anything more than

function setAttribute(s,t) { this[s] = t; }

I may implement it this way and get rid of the corresponding
20 line native code.

As mentioned last time, I check for form.action before submit,
but I don't check to see if js changed the href=
attribute out from under you before you click on hyperlink.
There's probably quite a few of these "actions" that I don't check for
and should.

Karl Dahlke

Re: [Edbrowse-dev] setAttribute

[Chris Brannon]

Karl Dahlke <eklhad@comcast.net> writes:

> Yes so it seems, so I have to query variables as needed anyways,
> so no need for setAttribute to do anything more than
>
> function setAttribute(s,t) { this[s] = t; }

I'm just going to quote a whole big wall of text from JavaScript, the
Definitive Guide.  Hopefully it's more helpful than not.

<quote>
Getting and Setting Non-HTML Attributes

As described above, HTMLElement and its subtypes define properties that
correspond to the standard attributes of HTML elements. The Element type
also defines get Attribute() and setAttribute() methods that you can use
to query and set nonstandard HTML attributes and to query and set
attributes on the elements of an XML document:

var image = document.images[0];
var width = parseInt(image.getAttribute("WIDTH"));
image.setAttribute("class", "thumbnail");

The code above highlights two important differences between these methods
and the property-based API described above. First, attribute values are
all treated as strings. getAttribute() never returns a number, boolean, or
object. Second, these methods use standard attribute names, even when
those names are reserved words in JavaScript. For HTML elements, the
attribute names are case insensitive.

Element also defines two related methods, hasAttribute() and
removeAttribute(), which check for the presence of a named attribute and
remove an attribute entirely. These methods are particularly useful with
boolean attributes: these are attributes (such as the disabled attribute
of HTML form elements) whose presence or absence from an element matters
but whose value is not relevant.

If you are working with XML documents that include attributes from other
namespaces, you can use the namespaced variants of these four methods:
getAttributeNS(), setAttributeNS(), hasAttributeNS(), and
removeAttributeNS(). Instead of taking a single attribute name string,
these methods take two. The first is the URI that identifies the
namespace. The second is usually the unqualified local name of the
attribute within the namespace. For setAttributeNS() only, however, the
second argument is the qualified name of the attribute and includes the
namespace prefix. You can read more about these namespace-aware attribute
methods in Part IV.

Dataset Attributes

It is sometimes useful to attach additional information to HTML elements,
typically when JavaScript code will be selecting those elements and
manipulating them in some way. Sometimes this can be done by adding
special identifiers to the class attribute. Other times, for more complex
data, client-side programmers resort to the use of nonstandard attributes.
As noted above, you can use the getAttribute() and set Attribute() methods
to read and write the values of nonstandard attributes. The price you pay,
however, is that your document will not be valid HTML.

HTML5 provides a solution. In an HTML5 document, any attribute whose name
is lowercase and begins with the prefix "data-" is considered valid. These
"dataset attributes" will not affect the presentation of the elements on
which they appear and they define a standard way to attach additional data
without compromising document validity.

HTML5 also defines a dataset property on Element objects. This property
refers to an object, which has properties that correspond to the data-
attributes with their prefix removed. Thus dataset.x would hold the value
of the data-x attribute. Hyphenated attributes map to camel-case property
names: the attribute data-jquery-test becomes the property
dataset.jqueryTest.
</quote>

-- Chris