|
|
Posted by Onideus Mad Hatter on 07/22/05 17:15
On Fri, 22 Jul 2005 12:29:05 GMT, Michael Winter
<m.winter@blueyonder.co.uk> wrote:
>On 22/07/2005 11:00, ^reaper^ wrote:
>
>[snip]
>
>> To enter into business contracts without explicitly identifying and
>> agreeing to meeting specific requirements is a good way to run a company
>> into teh ground. Sound business practices *always* involve requirements.
>> And in teh case of web products, these requirements include, but are not
>> limited to, identifying supportable browsers, protocols, layout and
>> behavior, security, etc. While teh product may very well support more than
>> teh agreed upon browsers, what you are doing is identifying and agreeing
>> upon what is minimally required for delivery of teh product. And this
>> agreement is legally binding.
>
>Certainly, but you seem to under the impression that this is in conflict
>with what I proposed. It is not.
>
>You said yourself that a product may achieve more than what was agreed
>upon. Indeed, agree to 'officially' support whatever subset of known
>browsers you like, but don't write code that falls apart uncontrollably
>in everything else. That's laziness, pure and simple, and hardly
>presents a good image of the client (particularly if 'unofficial'
>browsers are still relatively common). Using feature detection is an
>effective means to that end as it permits code to adapt to its environment.
>
>As for development time, it's much like any other approach: if you're
>unfamiliar then it will take longer, of course.
>
>[snip]
>
>> Btw, it's called method overloading (in teh behavioral sense, and
>> just in case you've never heard of teh term).
>
>Yes, I'm quite familiar with overloading, but you seem to have missed
>the point I was trying to make at this particular juncture: the
>behaviour would change based on number and type, but I wouldn't want it
>to (I'm sure I said that in my previous post). I use the array literal
>for empty arrays (for brevity), and those whose contents can be defined
>at the point of instantiation.
>
>Note that the literal form was introduced after the constructor, which
>is undoubtedly why the latter was overloaded - it was the only option at
>the time. Now an alternative is available with the benefit of uniform
>behaviour, I prefer not to use it.
>
>[snip]
>
>> Excluding teh layout, as I have yet to address that bit, teh dom element
>> data is not updating. So, if for example, I click on teh mask (for teh 340
>> cipher), and excluding teh wonky behavior (e.g., scrunched input fields,
>> buttons moving, monkeys flying, etc), nothing happens.
>
>I'm afraid we seem to be at the point where I say: works for me. No
>moving buttons, no flying monkeys (lol), still the scrunched fields, but
>plenty of red capital letters and cookies with (accurate) values in them.
>
>> Btw, and as an aside, I've uploaded teh changed (zk.js) code that reflects
>> teh changes per out convo. Attributing them to you, of course.
>
>Appreciated, but not necessary. :)
>
>> Hehe. Well, hopefully other readers (who haven't become bored to tears by
>> now) are learning summit from this convo as well. ^_~
>
>Maybe. What do you think the odds are?
Really though, you two haven't covered that much, due primarily to
Richard's posturing, self important attitutde. It's like, you can be
arrogant, but OMG have something REAL to back it up, don't just sit
there and fuckin whine like a little girl.
--
Onideus Mad Hatter
mhm ¹ x ¹
http://www.backwater-productions.net
Navigation:
[Reply to this message]
|