GreyWyvern <spam DeleteThis @greywyvern.com> wrote:
>And lo, hug didst speak in alt.www.webmaster:
>
>> Toby Inkster <usenet200611 DeleteThis @tobyinkster.co.uk> wrote:
>>
>>> However, say a future version of HTML assigned a special meaning to
>>> '&id'.
>>> For example, it could represent the mathematical symbol for "identical
>>> to"
>>> (Unicode U+02261, which looks like an equals sign with three bars
>>> instead of two), then your link becomes:
>>>
>>> http://www.ren-prod-inc.com/maint/test_site/store.php (wrap...)
>>> ?action=122?=1BMJEP0AM,1BMJFAL4N
>>>
>>> So your PHP script gets:
>>>
>>> <?php
>>> echo $_GET['action'];
>>> // prints "122?=1BMJEP0AM,1BMJFAL4N"
>>> ?>
>>>
>>> Would your script be able to cope with that?
>>
>> In 5 minutes it could be using "&parms=" or anything else instead of
>> "&id=".
>
>I think the point is, why write code so the possibility exists you will
>have to spend "5 minutes" on it *multiple* times in the future, when you
>can spend five minutes on it *once* to ensure you never need to do so
>again?
>
>Really, the only difference between changing the parameter name and
>changing the & to & seems to be an aversion to submit to perceived W3C
>overlords.
>
>They want to help you do less work to make the same pages, hug; honestly.
>A little more work in the present, perhaps, but a lot less work down the
>road, for certain. The above is just one small example.
>
>Grey
Nah, it's not so much an aversion to standards, Grey. And it's not a
big deal to fix. Every anchor in every document is already parsed and
twiddled, changing to & is trivial. Whether that would change
operation on parsing or not is another question, should be no biggie
though -- I've already tested it, just not rigorously.
My real concern? I don't want to break rendering on any legacy
browsers that are already supported. As soon as I get 'round to it,
I'll dig out how long this "standard" has been "real" and make some
kind of decision. I'm not the type to avoid something that will save
me grief in the long run, in fact just the opposite. But there are
many kinds of grief, and I try to minimize the total. <g>
The whole validation issue... it has many aspects. I've been working
up a validation utility so I can give the validator access to the
version of pages that I'm working on rather than the live version,
it's all dynamic stuff without a single static html document in the
lot. If I can get the html I'm generating to validate clean without
breaking any legacy rendering, great; if not, validation takes a
definite backseat to correct rendering and functionality. Currently,
as far as I know (though my tester has been unavailable lately to
really beat things up) things work on enough browsers, current and
legacy, that I'm satisfied for now.
Too much stuff going on, several new major functional additions and a
complete rewrite for CGI in the works, for me this whole "correct
html" issue is nearly trivial in comparison to the other stuff. If I
was building static html pages that would be a different story, but as
mentioned everything is dynamic; table-based layout is a pita to
maintain manually but when all you have to do is tweak one subroutine
or a template, it's not so bad.
Everybody has his own approach, his own set of priorities. Everybody
is really doing something a little different. I'm vastly more
concerned about the proper functioning of the server code, and
rendering on all-current-browsers, than I am about conforming to html
standards. I know that for lots of people conformance is a big deal
because of possible future problems, in my situation html is no more
than an output format and by no means an end in itself. Probably
makes no sense to anybody else, so it goes. <g>
--
Legacy browsers never heard of emerging standards.
(contact via
http://www.ren-prod-inc.com/hug_soft)
FAQ
Profile
Private Messages
Log in
