Attributes VS Properties

[David Mark]

And I should have added, that when we do this in JS we can gain
flexibility with an options object:


var o = _createElement("foo");
var o = _createElement("foo", {attributes: {bar: "baz"});
var o = _createElement("foo", {attributes: {bar: "baz"}, docNode:
node, appendTo: parent});

Yes, I don't have any problem with that, but I don't find it any more
memorable. Fouls up things like Intellisense as well, but that may not
be a concern.

 

[Thomas 'PointedEars' Lahn]

It is because d (document) is an option used only with frames (another
layer of support that will be filtered by the builder shortly). JFTR,
the above functions are from the PE collection (though my
createElementWithAttributes has arguments in similar order).

AISB, it is only example code.

Because the optional one is best last.

You do see the inconcistency here, don't you?

You almost never use the optional one and the optional one is always
last.

He was rightfully talking about the order of arguments as to their meaning,
not their requirement.

It is optional and as such, it does not necessarily have to be carried
through (unless it is passed to the higher level function).

That "unless" is the point of the argument. *You* need to carry it
through.

There's nothing like that going on with these simple wrappers.

Yes, it is. Too bad that you cannot see it right now.

What suggestion?

That suggestion of mine to keep argument lists short by having one tool for
one purpose, and not one tool implicitly using another one.

I explained that he could do what he wanted to do with
my API, which is not very much unlike his.

Yes, it is.

There's nothing intellectual about these simple wrappers.

Yes, you have to consider limitations in human's short-term memory
(usability studies show this to be a maximum of 7 +/- 2 elements
accessible at once.)

var el = API.createElement('div');

var el = API.createElementWithAtttributes('div', { ... });

You don't find identifiers that long hard to remember? Lucky one.
However, it is not you who is supposed to be the main user of this
library, right? Else you would not publish it, would you?

But wait, you want to use frames? How could that work?

I am afraid you are missing the point.

Not in the above example. There's nothing to remember.

Surely you can see that the more is to remember the more complex it becomes
what the method is doing. However, a good interface should be kept as
simple as possible and reasonably regardless what the implementation is
doing.

So create a macro. Or do this (you should anyway):-

You are missing the point. A good library makes it easy for users to use
it by itself. It does not require the creation of macros to do that.
After all, regardless the misguided realization with the one-function-
method, that is why jQuery has gotten so popular; the *interface* is
concise and consistent. ISTM you are going to the other extreme now, and I
think that is an equally bad idea. I am afraid My Library is going to be
DOA if you don't start considering the larger picture, and that would
really be a shame.

Yes, but how does that apply to the wrappers at hand? Could they
possibly be made simpler?

Yes, definitely. If you allowed the user to pass the result of one wrapper
to the next instead of having one wrapper implicitly use another, the API
would not only become more flexible, but also had less for the user to keep
in mind when using it. Surely you can see that would be an important
advantage, both for you as the library author and for the library user, of
course.

Yes, I agree that needless stacking is bad. I just don't think it's
been shown that the three methods in question are needlessly stacked.
Each layer serves a specific purpose. There are problems with creation
and problems with appending. Each layer deals with its own problems.

No, evidently it does not. The implementation of layer n+1 depends on the
implementation of layer n, needlessly. Such interdependence is best
avoided in an API.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Yes, I don't have any problem with that, but I don't find it any more
memorable.

Order (numbers) has (have) mostly been replaced with names. One less thing
to remember, or if you want, something replaced with something else easier
to remember.

Fouls up things like Intellisense as well, but that may not be a concern.

Whatever "Intellisense" is, a good code completion feature should be able
to handle that as well.


PointedEars

 

[Scott Sauyet]

Yes, I don't have any problem with that, but I don't find it any more
memorable.  Fouls up things like Intellisense as well, but that may not
be a concern.

I do find it more memorable. If I need to do a lot of plain calls
like this:

var o = _createElement("foo")

but also often have to do some like this:

var o = _createElement("foo", {attributes: {bar: "baz"});

it's usually not a leap for me to add

var o = _createElement("foo", {attributes: {bar: "baz"}, appendTo:
parent);

Yes, I still need to know the "appendTo" name, but for me that is much
easier to remember than that it is supposed to be the third parameter
to a function named "createAndAppendElementWithAttributes". In fact,
I confused myself earlier by offering a competing long name for that
function, and I'll be damned if I'm going to look back to check if I
used your original name or my alternative; I *think* that's right.
This is part of the point, though. I'm very likely to remember the
name "createElement".

I don't really know Intellisense. As much as my day job will allow
me, I still work in a programmer's text editor. I hear and understand
all the benefits of powerful IDEs, but I never really feel that they
help me more than they get in my way. Can Intellisense not be
configured to understand named parameters as well as positional ones?

-- Scott

 

[Matt Kruse]

    var o = _createElement("foo", {attributes: {bar: "baz"});
it's usually not a leap for me to add
    var o = _createElement("foo", {attributes: {bar: "baz"}, appendTo:
parent);

And if you keep going with this, you end up with method chaining,
which is even easier to read, IMO:

var o = _createElement("foo", {attributes:{bar:"baz"}).appendTo
(parent);

Matt Kruse

 

[Thomas 'PointedEars' Lahn]

And if you keep going with this, you end up with method chaining,
which is even easier to read, IMO:

var o = _createElement("foo", {attributes:{bar:"baz"}).appendTo
(parent);

But it is error-prone, unless you want to go down the jQuery road and create
a wrapper object that you return a reference to, which in turn is less
efficient instead. All in all, not a good idea.


PointedEars

 

[Matt Kruse]

But it is error-prone, unless you want to go down the jQuery road and create
a wrapper object that you return a reference to, which in turn is less
efficient instead.  All in all, not a good idea.

It's a sliding scale.

At one end, you have minimal wrappers around core functionality that
are less prone to problems, but your API is clunky and verbose, and
developers are not abstracted from the pains of repetitive tasks,
checking for defined objects, etc.

At the other end, you have a fancy API that is concise and full of
sugar and reads more like pseudo-code, but you sacrifice efficiency,
have the potential for more bugs, and your code risks becoming a mess
internally because of your attempt to handle every case.

David's library (which desperately needs to be renamed) is closer to
the first approach, while something like jQuery is closer to the
second approach.

David's library will appeal to experienced js developers who opt for
robust cross-browser coding and efficiency over a sweet and convenient
API, while jQuery will appeal to average or beginner developers who
opt for layers of abstraction and convenience over efficiency and wide
browser support.

There is a need for both, IMO, because the two extremes cannot both be
satisfied in a single library. The reason David's library avoids some
of the problems that jQuery has is because he says, "Abstracting
functionality X into a general method is not possible without
sacrificing browser support or accuracy in some cases, therefore I
choose not to do it." Instead, he provides the core tools for the user
to implement it himself, with code specific to the context.

There are a number of developers who lack the skill required to take
those core tools and implement the functionality correctly, and will
gladly sacrifice browser support and accuracy in some cases and use an
abstraction that works well enough for their situation. This group is
the vast majority, IMO. Hence the popularity of jQuery.

I think that a tool like David's library will only become popular and
widely used if he can A) Educate developers about why they should seek
a better solution than something like jQuery (and do so with grace,
which he lacks) and B) provide a migration path for users to move
towards his library (or something like it).

If his goal is to fill the niche of a toolkit for experienced
developers and not to appeal to the masses, then that's fine too, but
it seems to me that he seeks the latter. Otherwise his target would
surely not be the major libraries like jQuery.

Matt Kruse

 

[Thomas 'PointedEars' Lahn]

But it is error-prone, unless you want to go down the jQuery road and
create a wrapper object that you return a reference to, which in turn is
less efficient instead. All in all, not a good idea.

It's a sliding scale.

At one end, you have minimal wrappers around core functionality that
are less prone to problems, but your API is clunky and verbose, and
developers are not abstracted from the pains of repetitive tasks,
checking for defined objects, etc.

At the other end, you have a fancy API that is concise and full of
sugar and reads more like pseudo-code, but you sacrifice efficiency,
have the potential for more bugs, and your code risks becoming a mess
internally because of your attempt to handle every case. [...]

Let us be clear about this: by "not a good idea" I was referring to *your*
idea of "method chaining". Regardless, I think there is a third dimension
that you are missing here.


PointedEars

 

[Scott Sauyet]

Regardless, I think there is a third dimension
that you are missing here.

That's a pretty vague point. Care to elaborate?

-- Scott

 

[Thomas 'PointedEars' Lahn]

That's a pretty vague point. Care to elaborate?

Sure, if you had cared quoting something for me to refer to.

Your signature is borken, too.


PointedEars

 

[Garrett Smith]

David Mark wrote:

If you build a new library, it will now "work" for all but IE8
standards mode. But I don't want it to work like that, so soon it
will fail for all. Always set the type attribute/property _first_ (or
use a wrapper that does that for you).
And that wrapper is API.createElementWithAttributes:-
You can't be serious. What's wrong with `API.createElement', the
`API' aside (see below)?

[...]
There is a similar issue with the name attribute/property in that it
must be set after appending the element if it is to show up in the
appropriate DOM collection (e.g. document.forms, document.images,
window.frames). That is an issue best handled with a wrapper that
creates _and_ appends an element. Call it
createAndAppendElementWithAttributes perhaps?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No, thanks.

Generalized element builders.

There are too many edge cases support.

That's meaningless.

There are problems with nodes
that can't accept other nodes, special handling for certain attributes
(cellPadding, name).

There are no issues if you have competently written wrappers. Of
course, that lets out... virtually everyone. As for problems of nodes
not accepting other nodes, that's inherent to the underlying DOM
interface, so is irrelevant for a wrapper (unless it claims to support
non-standard behavior).

What about appending to a SELECT? How about creating a named anchor, an
element, anything with `class` or `for` attribute, or any attribute that
IE sees as a property, or needs special case handling, such as cellPadding.

Do you really want to write a wrapper to address that? I'll pass on that.

What calendar widget? And why does that method create HTML? Also,
aren't all methods on demand?

The widget in particular is beside the point: Creating HTML for a
specific case can be simple, unlike trying to fulfill all cases. But
since you asked, here is the calendar:
http://github.com/GarrettS/ape-javascript-library/blob/master/src/widget/calendar/Calendar.js

The method creates the HTML so that the user will have something to
interact with. The HTML could be in the page. That would be a little bit
harder to use the API. The way it is now, the HTML is pretty simple:

| <div class="ape-calendar-container" id="start-container">
| <label for="start" id='sf'>Start (YYYY-MM-DD)</label>
|
| <input id="start" name="start" type="date"
| class="ape-calendar-input">
| </div>


Are all methods on demand?

Not all methods do something on-demand. The method
`createCalendarOnDemand` creates the calendar HTML if it doesn't exist.

| if(d.getElementById(calendar.calendarId) !== null) return;

The HTML for the calendar is called only after the user has started
interacting with the INPUT.

Even though it's beside the point, I'd like to get any feedback on that.

Yes, context specific solutions always trump GP. But we are talking
about (though not necessarily advocating) a GP library.

Reusable wrappers are great for avoiding rewriting things. Ideally.
Sometimes what seems like a simple wrapper -- and this is especially
true for dom stuff -- is that it has to address too much complexity with
divergent browser object models.

 

[David Mark]

Thomas 'PointedEars' Lahn wrote:
David Mark wrote:

If you build a new library, it will now "work" for all but IE8
standards mode. But I don't want it to work like that, so soon it
will fail for all. Always set the type attribute/property _first_
(or
use a wrapper that does that for you).
And that wrapper is API.createElementWithAttributes:-
You can't be serious. What's wrong with `API.createElement', the
`API' aside (see below)?

[...]
There is a similar issue with the name attribute/property in that it
must be set after appending the element if it is to show up in the
appropriate DOM collection (e.g. document.forms, document.images,
window.frames). That is an issue best handled with a wrapper that
creates _and_ appends an element. Call it
createAndAppendElementWithAttributes perhaps?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No, thanks.

Generalized element builders.

There are too many edge cases support.

That's meaningless.

There are problems with nodes
that can't accept other nodes, special handling for certain attributes
(cellPadding, name).

There are no issues if you have competently written wrappers. Of
course, that lets out... virtually everyone. As for problems of nodes
not accepting other nodes, that's inherent to the underlying DOM
interface, so is irrelevant for a wrapper (unless it claims to support
non-standard behavior).

What about appending to a SELECT?

What about it?!

How about creating a named anchor, an

What are you having problems with?

element, anything with `class` or `for` attribute, or any attribute that
IE sees as a property, or needs special case handling, such as cellPadding.

I take it you have been paying only cursory attention.

http://www.cinsoft.net/attributes.html

This stuff is not new.

Do you really want to write a wrapper to address that? I'll pass on that.

Are you paying _any_ attention at all? I wrote the wrapper years ago.
You need something like that for certain types of projects (e.g.
anything with a CSS selector query interface, editors, etc.) It's not a
philosophical question.

The widget in particular is beside the point: Creating HTML for a
specific case can be simple, unlike trying to fulfill all cases. But
since you asked, here is the calendar:
http://github.com/GarrettS/ape-javascript-library/blob/master/src/widget/calendar/Calendar.js

But why HTML? I thought we were talking about creating/mutating DOM
nodes. Is that what you mean? Regardless, I know you don't need such a
wrapper for such a widget. It doesn't really fall into the categories
that have been listed (endlessly it seems).

The method creates the HTML so that the user will have something to
interact with.

The DOM structure? HTML to me means you are creating a string of markup.

The HTML could be in the page. That would be a little bit
harder to use the API. The way it is now, the HTML is pretty simple:

| <div class="ape-calendar-container" id="start-container">
| <label for="start" id='sf'>Start (YYYY-MM-DD)</label>
|
| <input id="start" name="start" type="date"
| class="ape-calendar-input">
| </div>

That markup doesn't make sense to me. I'm picturing it without
scripting. Or is this what the widget creates?

Are all methods on demand?

The quoting is screwed up here.

Not all methods do something on-demand. The method
`createCalendarOnDemand` creates the calendar HTML if it doesn't exist.

Whatever. I don't think it creates HTML at all. And how does "on
demand" simplify things? I'd through that thing out as soon as I read
the name of that method. I don't want to have to remember what you
consider "on demand" to mean.

| if(d.getElementById(calendar.calendarId) !== null) return;

Yes, so? You return early if the element is not in the document. I
hate it (for so many reasons).

The HTML for the calendar is called only after the user has started
interacting with the INPUT.

That sounds more like "on demand" to me. Still, if you can't explain it
without inducing confusing...

Even though it's beside the point, I'd like to get any feedback on that.

I absolutely can't stand the idea of a function that does something,
except when it doesn't. Break that up into two (one that checks if the
element is there and one that appends it). Creating it "on demand"
(according to the last bit of the explanation) can be useful though.
You might want to make it an option. And realize that the user's
interaction has nothing to do with whether the element is in the
document. You've got some wires crossed there.

Reusable wrappers are great for avoiding rewriting things. Ideally.
Sometimes what seems like a simple wrapper -- and this is especially
true for dom stuff -- is that it has to address too much complexity with
divergent browser object models.

Except that isn't the case at all for attributes. There's exactly two
models and one of those is never going to change again.

 

[Scott Sauyet]

Sure, if you had cared quoting something for me to refer to.

Really, you need more context? I'm referring to message

<[email protected]>

which can also be found online at

http://groups.google.com/group/comp.lang.javascript/msg/c9e63eddc8bfecef

and which you posted approximately seven minutes before I responded,
and about fourteen minutes before the message in which seem to have
forgotten the context.


But just for your edification, Matt Kruse had quoted you as saying

||| But it is error-prone, unless you want to go down the jQuery road
and
||| create a wrapper object that you return a reference to, which in
turn is
||| less efficient instead. All in all, not a good idea.


and then responded with:

|| It's a sliding scale.
||
|| At one end, you have minimal wrappers around core functionality
that
|| are less prone to problems, but your API is clunky and verbose, and
|| developers are not abstracted from the pains of repetitive tasks,
|| checking for defined objects, etc.
||
|| At the other end, you have a fancy API that is concise and full of
|| sugar and reads more like pseudo-code, but you sacrifice
efficiency,
|| have the potential for more bugs, and your code risks becoming a
mess
|| internally because of your attempt to handle every case. [...]

To which you said

| Let us be clear about this: by "not a good idea" I was referring to
*your*
| idea of "method chaining". Regardless, I think there is a third
dimension
| that you are missing here.


Is that exchange familiar? Did you really need me to quote it here to
give context?

Now, back to the original question. What third dimension are you
suggesting need to be considered on top of Matt's (one-dimensional!)
scale of API efficiency versus API power?

Your signature is borken, too.

PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <[email protected]>

I have no .sig file, believing that my FROM address header should be
all the contact information necessary and that posting five or six
lines of quotation is simply a waste of other user's bandwidth.
Instead, I manually type what is sometimes called a signature line, as
in this quote from (en) Wikipedia:

| A shortened form of a signature block (sometimes called a
"signature
| line"), only including one's name, often with some distinguishing
| prefix, can be used to simply indicate the end of a post or
| response. -- http://en.wikipedia.org/wiki/Signature_block

Mine is usually two spaces followed by two hyphens (the ususal ASCII
representation of a dash), a space, and my first name. It is set off
from the preceding text by a blank line, for a total of around a dozen
characters including new lines. In contrast, the signature you used
was six lines long, and nearly 300 characters. It consists of your
_nom de guerre_, a signature cut line, and a quotation (one of several
in rotation or randomly chosen, I've noticed) which might be vaguely
amusing the first time read but just becomes tiresome when seen
repeatedly. Your signature, is of course below the McQuarry limit --
I would expect no less -- but it is still a waste of bandwidth, IMHO.

What do you find wrong with my signature, then?

-- Scott

 

[Matt Kruse]

What do you find wrong with my signature, then?

It is unwise to take on Sir Pointy Ears in a contest of pettiness and
triviality - even in jest - for you shall always lose to his
overwhelming talent.

- --- xoxo Matt Kruse (c) (tm)

 

[David Mark]

It's a sliding scale.
Okay.


At one end, you have minimal wrappers around core functionality that
are less prone to problems, but your API is clunky and verbose, and
developers are not abstracted from the pains of repetitive tasks,
checking for defined objects, etc.

I sense an oversimplification here.

At the other end, you have a fancy API that is concise and full of
sugar and reads more like pseudo-code, but you sacrifice efficiency,
have the potential for more bugs, and your code risks becoming a mess
internally because of your attempt to handle every case.

And then there's the possibility that the core beneath the sugar is
rotten (seemingly always).

David's library (which desperately needs to be renamed)

Yeah, I can buy that. I guess my thinking is that it shouldn't
matter. I'm not selling sizzle (no pun intended). I've got the whole
steak wrapped up and ready for your grill. And I support the thing,
so it's really a no-brainer.

is closer to
the first approach, while something like jQuery is closer to the
second approach.

Sort of. It is an API, but certainly it simplifies checking for
"defined objects". The whole point is that feature detection/testing
is not for beginners, so why not provide an interface that shields
them from that entirely. And, of course, without the innovation of
the dynamic API, there'd be no shot of doing "progressive enhancement"
at all. Zero. Did that practice just fall by the wayside with the
arrival of cheap scripts like Prototype and jQuery? Doesn't make a
lot of sense as all they talk about is progressive enhancement (and
the real world, of course).

And then there is the fact that there is an _optional_ OO interface.
It's always been there, supports "chaining" and queries and all of the
rest of what people seem to like about jQuery. And it's _very_ easy
to read that code (DOM | Query | Wrapper Objects). Anyone could put
their own "face" on the underlying API.

David's library will appeal to experienced js developers who opt for
robust cross-browser coding and efficiency over a sweet and convenient
API, while jQuery will appeal to average or beginner developers who
opt for layers of abstraction and convenience over efficiency and wide
browser support.

No, I've got both the apples and the oranges and I support both. Game
over. Nobody should want or need jQuery's shriveled up oranges at
this point.

There is a need for both, IMO, because the two extremes cannot both be
satisfied in a single library.

Oh but they _can_.

The reason David's library avoids some
of the problems that jQuery has is because he says, "Abstracting
functionality X into a general method is not possible without
sacrificing browser support or accuracy in some cases, therefore I
choose not to do it."

I don't remember saying that at all? What is it you find lacking in
the feature set?

Instead, he provides the core tools for the user
to implement it himself, with code specific to the context.

Yes. And the higher-level stuff is there to pile on if you need it.
It's the best of both worlds (and perfectly suited for the "real
world" as imagined by jQuery advocates).

There are a number of developers who lack the skill required to take
those core tools and implement the functionality correctly, and will
gladly sacrifice browser support and accuracy in some cases and use an
abstraction that works well enough for their situation.

But, but, but... See above.

This group is
the vast majority, IMO. Hence the popularity of jQuery.

But none of this adds up and you are just looking at the sordid past
anyway. Things changed dramatically with the arrival of IE8 (who
could have predicted that).

I think that a tool like David's library will only become popular and
widely used if he can A) Educate developers about why they should seek
a better solution than something like jQuery (and do so with grace,
which he lacks)

It's not my job to educate developers. I do have openings for
"evangelists" though...

and B) provide a migration path for users to move
towards his library (or something like it).

I don't follow. If you can do $('#test'), you can do E('#test'). Or
you can skip both of those as they are unnecessary abstractions on top
of gEBI wrappers (e.g. API.getEBI('test'))

If his goal is to fill the niche of a toolkit for experienced
developers and not to appeal to the masses, then that's fine too, but
it seems to me that he seeks the latter.

I seek nothing. I am found. All I had to do was say a few choice
words a month ago to get the ball rolling. It will flatten jQuery
eventually.

Otherwise his target would
surely not be the major libraries like jQuery.

Target? The "major" libraries are so named because they came out (and
were heavily marketed) years ago. That's all. Since then, jQuery has
started to look more and more like My Library. If it weren't for
copied innovations, they'd have nothing but endless rewrites to "keep
up" with the latest set of major browsers. Oh, and "Live". That's a
complete and utter failure for a cross-browser script. Write once, do
nothing, run anywhere, forever. Does jQuery sound anything like that?

 

[Scott Sauyet]

It is unwise to take on Sir Pointy Ears in a contest of pettiness and
triviality - even in jest - for you shall always lose to his
overwhelming talent.

It is perhaps unmanly to joust with the court jester, but sometimes
it's just so much fun!

-- Scott

 

[Garrett Smith]

Garrett Smith wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:

If you build a new library, it will now "work" for all but IE8
standards mode. But I don't want it to work like that, so soon it
will fail for all. Always set the type attribute/property _first_
(or
use a wrapper that does that for you).
And that wrapper is API.createElementWithAttributes:-
You can't be serious. What's wrong with `API.createElement', the
`API' aside (see below)?

[...]
There is a similar issue with the name attribute/property in that it
must be set after appending the element if it is to show up in the
appropriate DOM collection (e.g. document.forms, document.images,
window.frames). That is an issue best handled with a wrapper that
creates _and_ appends an element. Call it
createAndAppendElementWithAttributes perhaps?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No, thanks.

Generalized element builders.

There are too many edge cases support.
That's meaningless.

There are problems with nodes
that can't accept other nodes, special handling for certain attributes
(cellPadding, name).
There are no issues if you have competently written wrappers. Of
course, that lets out... virtually everyone. As for problems of nodes
not accepting other nodes, that's inherent to the underlying DOM
interface, so is irrelevant for a wrapper (unless it claims to support
non-standard behavior).

What about appending to a SELECT?

What about it?!

It is obviously inconsistent. The appended option's `selected` may be
null, string, or boolean (true OR false).

A wrapper that allows appending a SELECT to an OPTION should probably
address the differences. That would best be done in a separate function.

Adding an option to a SELECT is a lot simpler than adding anything to
anything with any attributes.

What are you having problems with?

Links to the anchor don't work:

<a href="#myNewAnchor">

Plenty more examples related to NAME on MSDN.

http://msdn.microsoft.com/en-us/library/ms536389(VS.85).aspx

I take it you have been paying only cursory attention.

http://www.cinsoft.net/attributes.html

This stuff is not new.

You didn't like the feedback I gave you last time?

Are you paying _any_ attention at all? I wrote the wrapper years ago.
So?

You need something like that for certain types of projects (e.g.
anything with a CSS selector query interface, editors, etc.) It's not a
philosophical question.

I don't need a CSS Selector Query interface.

I can see the use of an attributes wrapper for an Editor. For that, it
might make sense to limit the attribute reading to be used for the editor.

But why HTML? I thought we were talking about creating/mutating DOM
nodes. Is that what you mean?

The reason that that is mentioned

Regardless, I know you don't need such a

wrapper for such a widget. It doesn't really fall into the categories
that have been listed (endlessly it seems).

You listed two:-
1) CSS Query Selector
2) Editor

The most complex, feature rich applications will not need a CSS Selector
Query interface.

I can see the use for an Editor. For that, it might make sense to limit
the parsing of editor's html to a narrower scope.

The DOM structure? HTML to me means you are creating a string of markup.


That markup doesn't make sense to me. I'm picturing it without
scripting. Or is this what the widget creates?

When script is disabled, the user sees an input and a label:

"Start (YYYY-MM-DD)" [ ]

The quoting is screwed up here.

You're still using googlegroups.com, so that could be related to the
problem. You might want to consider getting a newsserver.

Whatever. I don't think it creates HTML at all. And how does "on
demand" simplify things?

The calendar widget is not created unless it is needed. Less html =
lighter page.

The benefit of creating the widget on-demand (lazily, when user
interacts), is efficiency.

Consider the alternative. The normal way, building that HTML in an init
method, called onload would have two effects:

1) slow down page load with creating extra HTML
2) adds extra HTML to the DOM, even if it is not needed.

A page that tries to create many widgets during an/or after load slows
down more noticeably. The value in saving those precious milliseconds on
load is even more noticeable when many widgets are used.

I'd through that thing out as soon as I read

the name of that method. I don't want to have to remember what you
consider "on demand" to mean.

Interesting. How were you planning on calling that method?

Yes, so? You return early if the element is not in the document. I
hate it (for so many reasons).

You're completely wrong here. It is only one line of code. A code
comment seemed like extraneous noise, but if that line is confusing,
then does this seem any clearer:

| // If the element is not null, exit.
| if(d.getElementById(calendar.calendarId) !== null) return;

?

That sounds more like "on demand" to me. Still, if you can't explain it
without inducing confusing...

I didn't explain it. You sort of did, but got it wrong.

I absolutely can't stand the idea of a function that does something,
except when it doesn't. Break that up into two (one that checks if the
element is there and one that appends it).

I don't find the null check to be confusing at all.

Creating it "on demand"

(according to the last bit of the explanation) can be useful though.
You might want to make it an option.

An option? No, absolutely not. That is something that client of the API
has no knowledge of. The client of the API calls:-

Calendar.getById("birthday");

And realize that the user's

interaction has nothing to do with whether the element is in the
document. You've got some wires crossed there.

The user's interation has nothing to do with whether the element is in
the document? Where are you getting this?

Except that isn't the case at all for attributes. There's exactly two
models and one of those is never going to change again.

There is IE with attribute-as-properties and then there is the DOM
attributes.

A DOM wrapper for attributes or properties in the general sense seems
like a good exercise for learning about browser quirks.

The nodes for a widget can be build where needed for that widget. The
solution for that might use Array methods, set innerHTML, or assign
property values.

The code you wrote might come in handy for an editor.

 

[David Mark]

David Mark wrote:
Garrett Smith wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:

If you build a new library, it will now "work" for all but IE8
standards mode. But I don't want it to work like that, so soon it
will fail for all. Always set the type attribute/property _first_
(or
use a wrapper that does that for you).
And that wrapper is API.createElementWithAttributes:-
You can't be serious. What's wrong with `API.createElement', the
`API' aside (see below)?

[...]
There is a similar issue with the name attribute/property in that it
must be set after appending the element if it is to show up in the
appropriate DOM collection (e.g. document.forms, document.images,
window.frames). That is an issue best handled with a wrapper that
creates _and_ appends an element. Call it
createAndAppendElementWithAttributes perhaps?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No, thanks.

Generalized element builders.

There are too many edge cases support.
That's meaningless.

There are problems with nodes
that can't accept other nodes, special handling for certain attributes
(cellPadding, name).
There are no issues if you have competently written wrappers. Of
course, that lets out... virtually everyone. As for problems of nodes
not accepting other nodes, that's inherent to the underlying DOM
interface, so is irrelevant for a wrapper (unless it claims to support
non-standard behavior).

What about appending to a SELECT?

What about it?!

It is obviously inconsistent. The appended option's `selected` may be
null, string, or boolean (true OR false).

Oh, forget that bullshit. That property doesn't matter until you append
the thing to a document. Host objects 101. Don't try to do stupid things.

A wrapper that allows appending a SELECT to an OPTION should probably
address the differences. That would best be done in a separate function.

I don't follow that, even if you mean adding an option to a select. The
way to address the "issue" is in a function that finds the selected option.

Adding an option to a SELECT is a lot simpler than adding anything to
anything with any attributes.

Yes, that's true.

Links to the anchor don't work:

<a href="#myNewAnchor">

So? You don't know how to fix that? See the wrapper posted in this
thread.

Plenty more examples related to NAME on MSDN.

http://msdn.microsoft.com/en-us/library/ms536389(VS.85).aspx

Examples of what? That anchors don't show up in the anchors or links
collections if you name them prematurely? Same for forms, iframes, etc.
It's an old issue and easily dealt with in a wrapper.

You didn't like the feedback I gave you last time?

About what? The unit tests (and don't start with semantics again?) No,
not really as it was sort of missing the point.

So?

So nothing. It's there. This stuff should not be an issue in 2010 for
a browser that came out in 1999. The whole idea is beyond belief.

I don't need a CSS Selector Query interface.

Few do, but everybody seems to want one anyway.

I can see the use of an attributes wrapper for an Editor. For that, it
might make sense to limit the attribute reading to be used for the editor.


The reason that that is mentioned

Looks like your reply ran aground here. (?)

Regardless, I know you don't need such a
You listed two:-
1) CSS Query Selector
2) Editor

Or parser or anything that needs to canonicalize the document. Use your
imagination.

The most complex, feature rich applications will not need a CSS Selector
Query interface.

Almost nobody does, but...

I can see the use for an Editor. For that, it might make sense to limit
the parsing of editor's html to a narrower scope.

Which is something you can build on top of the low-level functions. And
not just for an editor either. Are you familiar with things like the
Dijit (ecch) parser? See what I'm getting at? All of these things out
there, ostensibly produced by huge concerns (e.g. IBM, Apple) are
slipping around on shitty foundations and apologizing profusely for it,
year after year (at least they are polite about it). It is time
somebody cried foul. It's not the browsers causing the mess. It's
_them_. Hell, the browsers have been great for years. All you have to
do is run my test page back through time and the drop-offs become apparent.

The DOM structure? HTML to me means you are creating a string of markup.


That markup doesn't make sense to me. I'm picturing it without
scripting. Or is this what the widget creates?

When script is disabled, the user sees an input and a label:

"Start (YYYY-MM-DD)" [ ]

That's what I would have expected. Somehow I didn't see that earlier
(just the DIV with the funny class).

You're still using googlegroups.com, so that could be related to the
problem. You might want to consider getting a newsserver.

No, I am not still using anything specifically. I use whatever is
handy. And yes, I "got" a news server (I'm using it now).

The calendar widget is not created unless it is needed. Less html =
lighter page.

Yes, I am all for lighter pages.

The benefit of creating the widget on-demand (lazily, when user
interacts), is efficiency.

Sometimes sacrificing responsiveness. It's a trade-off that depends on
context, which is why I suggested a configuration flag for that.

Consider the alternative. The normal way, building that HTML in an init
method, called onload would have two effects:

I don't see that as the "normal" way (just another way).

1) slow down page load with creating extra HTML

Will you stop fucking calling it HTML. There's enough confusion in this
group as there is. You aren't creating HTML any more than Resig is
detecting "object literals". You are creating a DOM structure.

2) adds extra HTML to the DOM, even if it is not needed.



A page that tries to create many widgets during an/or after load slows
down more noticeably. The value in saving those precious milliseconds on
load is even more noticeable when many widgets are used.

As mentioned, it all comes down to context (e.g. how many widgets, how
long do they take to create, etc.)

I'd through that thing out as soon as I read

Dammit. Your quoting is fucking up here again. No way this is my
fault. I used GG for years and never hard this problem.

Interesting. How were you planning on calling that method?

I wasn't.

You're completely wrong here.

No I am not. You are barking up the wrong tree.

It is only one line of code.

That tree.

A code
comment seemed like extraneous noise, but if that line is confusing,
then does this seem any clearer:

Of course not. It has to do with code design, not clarity. Returning
early like that is bullshit. Restructure the design so that the caller
doesn't call in the first place in that circumstance. If you are
worried about public API calls, you don't want those to fail silently
either.

| // If the element is not null, exit.
| if(d.getElementById(calendar.calendarId) !== null) return;

?


I didn't explain it. You sort of did, but got it wrong.

Bullshit and no time for semantic arguments. Thanks anyway.

I don't find the null check to be confusing at all.

Confusion is not the issue either.

Creating it "on demand"

Again, the quoting is off. The problem is in your set.

An option? No, absolutely not. That is something that client of the API
has no knowledge of. The client of the API calls:-

And why not? They don't have to have knowledge of it. It could be
optional with the default the same as it is now. Context is everything
with this stuff. You can't decide what is best for all apps.

Calendar.getById("birthday");

And realize that the user's

The user's interation has nothing to do with whether the element is in
the document? Where are you getting this?

You aren't thinking. What you repeated is correct, but there seems to
be some design concepts that aren't registering with you. Asking where
I am "getting this" isn't likely to bear fruit.

There is IE with attribute-as-properties and then there is the DOM
attributes.

A DOM wrapper for attributes or properties in the general sense seems
like a good exercise for learning about browser quirks.

So is writing a calendar widget, yet they both have practical
applications as well.

The nodes for a widget can be build where needed for that widget. The
solution for that might use Array methods, set innerHTML, or assign
property values.

The code you wrote might come in handy for an editor.

Or anything else that creates elements. It depends on the author(s),
context, scope of the project, etc. Certainly an editor (which seems to
be the centerpiece of every widget library) is the quintessential example.

 

[Garrett Smith]

David Mark wrote:
[...]
There is a similar issue with the name attribute/property in that it
must be set after appending the element if it is to show up in the
appropriate DOM collection (e.g. document.forms, document.images,
window.frames). That is an issue best handled with a wrapper that
creates _and_ appends an element. Call it
createAndAppendElementWithAttributes perhaps?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No, thanks.

Generalized element builders.

There are too many edge cases support. There are problems with nodes
that can't accept other nodes, special handling for certain attributes
(cellPadding, name).

If the problem is narrower there aren't as many edge cases. For example,
a hidden method `createCalendarOnDemand` creates HTML for the calendar
widget. It has no options to determine the HTML structure, and so there
is not testing multiple contexts and configurations. I like that.

You have failed to post a coherent follow-up.

I missed a comma right after "narrower".

In the third sentence, could have used "That method" instead of "It", as
in:-

"That method has no options to..."

 

[Garrett Smith]

Garrett Smith wrote:
David Mark wrote:
Garrett Smith wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:

If you build a new library, it will now "work" for all but IE8
standards mode. But I don't want it to work like that, so soon it
will fail for all. Always set the type attribute/property _first_
(or
use a wrapper that does that for you).
And that wrapper is API.createElementWithAttributes:-
You can't be serious. What's wrong with `API.createElement', the
`API' aside (see below)?

[...]
There is a similar issue with the name attribute/property in that it
must be set after appending the element if it is to show up in the
appropriate DOM collection (e.g. document.forms, document.images,
window.frames). That is an issue best handled with a wrapper that
creates _and_ appends an element. Call it
createAndAppendElementWithAttributes perhaps?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No, thanks.

Generalized element builders.

There are too many edge cases support.
That's meaningless.

There are problems with nodes
that can't accept other nodes, special handling for certain attributes
(cellPadding, name).
There are no issues if you have competently written wrappers. Of
course, that lets out... virtually everyone. As for problems of nodes
not accepting other nodes, that's inherent to the underlying DOM
interface, so is irrelevant for a wrapper (unless it claims to support
non-standard behavior).

What about appending to a SELECT?
What about it?!

It is obviously inconsistent. The appended option's `selected` may be
null, string, or boolean (true OR false).

Oh, forget that bullshit. That property doesn't matter until you append
the thing to a document. Host objects 101. Don't try to do stupid things.

DOn't try stupid things? Like what? Append an OPTION to a SELECT and
then append the SELECT to the DOM, but expect something related to the
option being selected? Nope, I have a different approach for SELECTs.

Here's another stupid idea: A wrapper for DOM attributes.

I don't follow that, even if you mean adding an option to a select. The
way to address the "issue" is in a function that finds the selected option.

A function createAndAppendElementWithAttributes would seem to be capable
of creating and appending an element with attributes. It should also be
reasonably expected to be consistent across browsers.

Yes, that's true.

You don't even need to know about the problems with adding an OPTION to
a SELECT to recognize the obviousness of that.

So? You don't know how to fix that? See the wrapper posted in this
thread.

The solution I am familiar with is using MS createElement nonstandard
extension.

That approach is specified to throw errors, and so if it is used, then
it must be feature tested and the feature test would involve try-catch.

Examples of what? That anchors don't show up in the anchors or links
collections if you name them prematurely? Same for forms, iframes, etc.
It's an old issue and easily dealt with in a wrapper.


About what? The unit tests (and don't start with semantics again?) No,
not really as it was sort of missing the point.

No, that too, though. I commented on the long section of statements you
refer to as a "unit test" in your viewport function.

So nothing. It's there. This stuff should not be an issue in 2010 for
a browser that came out in 1999. The whole idea is beyond belief.

I do not keep tabs on when you write things.

Looks like your reply ran aground here. (?)

Creating nodes can work for specific tasks such as above, but for
general purpose, it is unneeded.

Or parser or anything that needs to canonicalize the document. Use your
imagination.

Speculate on a need that does not exist? Never.

Work the other way.

Create abstractions as they're needed. Organize the abstractions to
allow for effective reuse.

Test the abstractions. When something doesn't work, the test can be
added to the suite. When the abstration gets refactored, then the tests
can reflect that.

Adding OPTION to a SELECT is very generic, but probably can work in
almost any normal context.

Creating a specific widget (UserPanel) is going to be more specific. In
a specific case, for a higher level widget, the nodes/html for the
widget can be generated in a self-contained function.

Almost nobody does, but...

Nope.


Which is something you can build on top of the low-level functions. And
not just for an editor either. Are you familiar with things like the
Dijit (ecch) parser?

Feel free to enlighten me.

My experiences with Dojo based applications is that they tend to be slow
to load. Well I've only worked on two applications that used Dojo.

Other applications that use dojo that I interviewed for, they complained
about slow performance.

[...]

Dammit. Your quoting is fucking up here again. No way this is my
fault. I used GG for years and never hard this problem.

?


I wasn't.

Why would you have to remember the name of that method?

No I am not. You are barking up the wrong tree.

YOu wrote "You return early if the element is not in the document." That
is wrong. Please do look at that one line of code.

That tree.

It is not a tree.

Of course not. It has to do with code design, not clarity. Returning
early like that is bullshit.

Oh really? It is "bullshit" to return early? Who taught you that? Or
better yet, why did you believe it?

Restructure the design so that the caller

doesn't call in the first place in that circumstance. If you are
worried about public API calls, you don't want those to fail silently
either.

What caller and what circumstance?

The caller of that method calls it so that the calendar can be created.
If the calendar is already created, then the method exits.

Bullshit and no time for semantic arguments. Thanks anyway.

Apparently the code comment did *not* help. So it is down to an English
problem. What meaning do you get from: "If the element is not null, exit."

Confusion is not the issue either.

Apparently it was.

Again, the quoting is off. The problem is in your set.


And why not? They don't have to have knowledge of it. It could be
optional with the default the same as it is now. Context is everything
with this stuff. You can't decide what is best for all apps.

The job of the API is to define a public interface. More options means
more complexity, more bloat, longer methods, harder to read, more bugs,
more maintenance time.

You aren't thinking.

I asked you to explain yourself.

You misinterpreted that one line of code. It seems likely that you're
misunderstanding other things about that code.

Don't blame me for your misunderstanding. Don't call bullshit and say
that I'm not thinking.

What you repeated is correct, but there seems to

be some design concepts that aren't registering with you. Asking where
I am "getting this" isn't likely to bear fruit.

What I repeated was what you stated, but in question form. I can't make
sense of what you're saying here, or why.

So is writing a calendar widget, yet they both have practical
applications as well.

A Calendar widget is not limited to learning about browser quirks.

Or anything else that creates elements.

Nope. Because sometimes, innerHTML might be a better option. Sometimes
Array.prototype.join or Array.prototype.push would be good options for
that. In some cases, not all cases, the code might have a browser quirk
to deal with. In other cases, another browser quirk might appear.

What sorts of quirks? Creating a table with cellPadding, creating a
named anchor.

It depends on the author(s),

context, scope of the project, etc. Certainly an editor (which seems to
be the centerpiece of every widget library) is the quintessential example.

If the attribute wrapper is needed for an Editor then limit it to that.