David said:
Garrett said:
David said:
Garrett Smith wrote:
David Mark wrote:
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.
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.
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.
Adding an option to a SELECT is a lot simpler than adding anything to
anything with any attributes.
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.
How about creating a named anchor, an
What are you having problems with?
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.
The solution I am familiar with is using MS createElement nonstandard
extension.
That's the stupid solution. Did you read this thread?
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.
Which sucks.
No, that too, though. I commented on the long section of statements you
refer to as a "unit test" in your viewport function.
There you go again with semantics. I _hate_ that fucking shit. Yes, I
know I pointed out my "assertions" in that page as examples of simple
tests and you've been harping on the "those are not unit tests" bullshit
for weeks since. No wonder nothing ever gets settled in here. Where
are we on the new Viewport FAQ entry?
I do not keep tabs on when you write things.
You could hardly miss most of it (and haven't IIRC).
Creating nodes can work for specific tasks such as above, but for
general purpose, it is unneeded.
What the hell does that mean?
Keep your general purpose wrapper. Do whatever you like with it, but it
is a foolish endeavor.
No, not whatever: Speculative generality is a pointless waste of time.
SOrt of like trying to explain things to you.
This isn't working (in any sense of the word).
Well, parsers, editors, queries, etc. have been around forever. It's
not some new need I have identified.
You've not identified anything!
Your attr function does not serve any practical purpose.
It's an old need that was never
filled because nobody bothered to figure it out. It's beyond belief,
but there it is.
You are rambling.
you can say that I am rambling, but does that say something about what I
wrote, or does it say something about your communication skills (reading
and asking questions).
No, not whatever. The point is that the General purpose wrapper is never
going to be the ideal solution. It will be mired in complexity and will
never be as efficient as something that is designed for the task.
Never mind. Look at it if you want to. It parses fucking documents.
Get the picture? Same as queries query documents. It's all based on
getting an accurate view of the document (something that all of these
stupid projects neglected).
Nothing that you have posted has parsed documents; not that I've seen.
[...]
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.
?
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?
I wasn't.
Why would you have to remember the name of that method?
I don't follow and don't really care at this point.
What a cop out. You cannot remember the reason for your comment
"through that out". So either the comment was made thoughtlessly, or it
wasn't.
I have maintained this whole time that you do not understand the code.
Indeed you got that one line wrong, insisted that you were right, even
after it was pointed out to you again that you were wrong. Insisting
that I was barking.
Why are you are wasting my time with this?
Calling the function wer are talking about with whatever the hell would
make it exit early (returning undefined apparently). What were we
talking about?
And that's _stupid_. Doesn't the caller know if it has called it yet or
not? It certainly should.
No, there is no state of "function has been called before". The state is
maintained in the HTML. If the element doesn't exist, it gets created.
I have no clue what you are talking about at this point.
You got confused about one line of code. You made a blatantly false
statement about the code:-
| Yes, so? You return early if the element is not in the document. I
| hate it (for so many reasons).
And this was regarding the line of code:-
| if(d.getElementById(calendar.calendarId) !== null) return;
You continued to argue that that was correct and true, and that I was
wrong about the understanding of that line of my code.
Heh, apparently not.
You're still not reading the one line of code. You've gotten the code
wrong and got the comment misinterpreted, too.
All a bunch of nothingness. There's just no meaning there at all.
No, that is a false statement.
The meaning was not understood by you. That is a fact.
The reason for that fact probably comes down to your irrationality.
I did not misinterpret anything. What sort of idiot would think that an
early return statement could be misinterpreted? Or perhaps this is just
more baiting?
I can explain it to you, but I cannot understand it for you.
For the fourth time: "If the element is not null, exit."
Not a chance. It seems more likely that you don't understand the
subtleties I am describing and that's not a new experience.
No, not "not a chance." Most likely.
You failed to correctly read one line of code.
You made a statement providing what you believed to be a reason for
"through it away" but forgot what it was.
You made some other statements but did not explain what they meant.
Given that I know the code pretty well, don't you think that it might be
the case that when I say you read the code wrongly, that I am correct
and that you have made a mistake?
Do you see the futility in furthering this discussion?
Sorry, I don't take orders.
It is irrational to continue on the way you are. You are incorrect in
your assessment of one line of code. You are being stubborn in not
admitting that you are wrong. I would stop doing that if I were you.
It's mutual at this point. The thread is another lost cause.
This thread is as useful as your attr function.
Neither are wrappers for accurately reading and mutating documents. And
how did this become calendar vs. attributes? I truly hate these detours.
calendar vs. attributes is your imagination.
The point is -- and I've been saying this all along -- generalized dom
accessor (attribute property) functions have too much complexity to bear
to be useful.
Although a generalized function for creating nodes with attributes may
be too complicated, a specialized function for creating a widget can be
useful.
If the problem is to "createAndAppendElementWithAttributes", then for a
widget that has to perform such tasks, innerHTML might work better.
Creating elements. Create an element and set innerHTML ,then append that
element somewhere in the document.
