Richard Cornford wrote:
pcx99 wrote:
>HTMLKit is quite happy to insert all of this nice stuff for me
the moment I start typing <script.
No greater condemnation of HTMLKit or its authors could be presented.
Oh I use PSPad and a few other editors as well, but like I say HTML kit
is a bit of a personality test good for endless laughs when its code is
posted on certain discussion boards :)
>Since it costs nothing* to provide a
little ancient/exotic browser insurance,
What "ancient/exotic browser insurance"? The HTML style comments in
script elements was a workaround for browsers pre-dating Netscape 2 and
IE 3. We are currently at a point where a very good general case can be
made for totally disregarding 4th generation browses. There is also the
question of the possible future use of XHTML, where the contents of
script elements are PCDAT and <!-- .. --style comments may be removed
by XML parsers, removing the script content in the process.
Aye. But because of the fact that web pages tend to hang around
forever, these tags you are so obsessive about will never truly go away.
They're not going to be revoked like the analog spectrum to be
re-assigned to something greater and grander. Because it costs nothing
to allow them to remain in the browser's parsers or at least ignored by
the parser, they will remain. They will never be used for something
else, forever a tiny comment in the <scripttag.
>I indulge it, especially since
it evokes such amusing hostility in some people.
Why do you see it as hostility to suggest not using attributes that are
depressed themselves and redundant alongside required attributes is
pointless? Or that actions taken to mitigate the behaviour of browsers
so old that nobody is still using them is better left out?
Because it's anal retentive and the argument is as pointless as the tags
themselves. It costs nothing to leave them in, people can use them
without any ill effects. It won't break the page, it won't break future
pages, it won't break old browsers it won't break new browsers.
Every time the debate is brought up it SCREAMS pompous arrogance because
it is a tangent that has NOTHING at all to do with the original problem
and it doesn't even hinder getting a working answer to the problem save
for the pointless time and effort spent debating the tangent when effort
could be expended solving the original problem.
>I have a REALLY good laugh whenever the topic is brought
up because not even the w3 validators will complain about
a language definition in the script tag
It will complain if you attempt to validate against a strict version of
the DTDs.
>or comment "insulators",
An HTML validator will never complain about the contents of CDATA, and
an XHTML validator is very unlikely to complain about the contents of a
comment.
Aye, but apparently people do ;) Strict mode catches language=?
That's a new one, but I shouldn't be surprised. I validate loose. It's
harder to code for, more frustrating to write, but in the end a little
more powerful in getting your objectives met with a spot of professional
polish. Yes I know the professional web page has a higher chance of
breaking in the next browser version but professional also means the
resources to fix it when that happens or having the site totally
revamped anyway because there is a re-design schedule.
>and lord knows they complain
about everything else.
No they don't, they complain about formally invalid documents, as they
are designed to do.
Funny how accurate the <script language=""personality test is ;)
BTW, you, randy, and the other shaman might as well set up a macro for
your rants because even when I'm using pspad I'm likely as not to drop
in Language <!-- --just for chuckles. Hmmm I better set up a response
macro while I'm here...
<begin macro:P <end macro>
there, that will do it :)
>* Since we're playing lawyercode -- nothing=cost so trivial
in terms of performance/bandwidth as to not being worth notice.
It is still a strange attitude that has the editor making code-authoring
decisions.
No. The editor makes code making suggestions. It's up to me to decide
if I want to be lazy and leave it in, or hit the backspace a few times,
or failing that, go in and customize the package so it doesn't include
comments or language when generating a script block. So far the scales
are deeply tipped toward "status quo" and no amount of rants on CLJ is
going to change that.
>In the upper block you scold me for using 'deprecated
language' and in the second block you scold me for not
pandering to 'deprecated surfing' :P
What makes taking advantage of the configuration options available on
the very newest browsers "deprecated surfing"? Isn't this really a VKish
'I cannot cope so I will deny the need to cope by deprecating the issue'
attitude?
No this is a 'cost benefit analysis' The original problem sought out a
generalized estimate of JS/non-JS surfers. The shaman swooped in and
decided it needed to be a formal scientific survey despite the fact that
there will never be 100% valid results unless each visitor to the web
page is required to set up an account and log in before visiting the
test page, and further that each person that logs in be matched to a
real world identity and that they log in under carefully monitored
network conditions between the client and server.
Since that level of accuracy will not be met we are discussing a
generalized, glorified, hit counter regardless of what you and randy
would like to otherwise believe. And since you're so fond of quoting
history, perhaps you would like to quote the grand and glorious history
images have had in hit counting. I think you'll find that, failing the
resources to do scientific studies of page hits, it's a time honored and
accepted practice of counting pages.
>That said, I understand accessibility and some wireless access
devices would have javascript but for whatever reasons (small
screen, user blind, etc) surf without images.
If this is a major concern simply having the javascript
redirect the page if only to itself with a
?JS=hasJavascript addendum will throw a unique entry into
the log file.
Doesn't that mean that the javascript enabled visitors will only ever
get a chance to bookmark the page with the value on the query string,
and so whenever they re-visit the site they will re-enforce the numbers
for javascript enabled visitors, independently of whether thy have
javascript enabled at the time (and never re-issuing the first request)?
If the starting position already demonstrates a propensity for users to
have javascript enabled then you may end up with a self-biasing system,
that swings rapidly to the extreme position.
Surely, in order to press an attack, you're not blindly overlooking the
fact that referer urls (or lack thereof), history manipulation for the
current url, framesets, and other log analysis can't be used to offset
bookmarks. Or did you truly not consider these tools? Either way, it
doesn't look that great for you over there.
>thing is certain, using weblogs to track this information is
a great deal simpler than using mysql/php/html for the simple
fact that web logs record the user agent and there are enough
weblog analyzers out that will let you look at your data in
countless different ways.
Web logs on a server are only capable of reporting HTTP requests that
get to the server, while it is a necessity of HTTP that servers never be
required to serve all requests directed in their direction. Several
years ago it was already being assented that without the proportion of
HTTP requests that were then being served from HTTP caches on the
network the load would have far exceeded the capacity of the network.
There you go trying to make this into a scientific survey where that was
never a part of the original problem. The fellow wasn't looking for a
dissertation, just a generalized hit counter that separated JS from non JS.
>The fact that it requires less coding effort and has much
richer reporting options still makes analyzing the log file
one of the simplest and easiest ways to approach this problem.
Or one of the simplest ways of deluding yourself into believing whatever
you wanted to believe before looking.
Drumroll please! And the answer is...
Please, do fill in the blank.
--
http://www.hunlock.com -- Musings in Javascript, CSS.
$FA