> Given that more people use IE than read W3C, IE has more "general
> consent". In this situation, since Mozilla and Opera also support the
> same functionality, it's nearly universal consent. You can't get much
> more standard than ubiquity.
Unfortunately, the entire reason spaces are automagically
grandfathered in by Opera, Mozilla, and other browsers is _because_ IE
ignored that standard, and decided to use spaces as _both_ a field separator
_and_ a syntactic character in their file manager "Internet Explorer" back
in the Windows 95 days.
Load up Windows, launch IE and put in "C:\Program Files\Internet
Explorer" in the URL bar. Does it encode the spaces? Nope. Now do the same
thing in Mozilla. Hey, look.. a %20! Also notice that the same icon that
launches the browser "transparently" becomes a file manager when you use a
local URI. Launch IE by clicking on the little 'e' icon, then do ^N to
launch a new copy of IE. Seems to work. Now, close those, and launch IE
again, and put in "C:\Program Files" and do ^N. Hrm, magically, it doesn't
work. I stand by my longtime conclusion that IE is a file manager that
(poorly) renders HTML.
Again, this is moot. Spaces are invalid, and should be encoded,
regardless of how a desktop browser chooses to handle them, IE, Mozilla, or
othewise. Current versions of all of these encode the space to the proper
'%20' character anyway. The same goes for the backslashes in relative links
found on the previous site I mentioned in an earlier list post.
> Intentionally locking out interesting content that every major browser
> supports out of dedication to a standard that is poorly reflected in the
> online world is the issue.
I wonder why you keep bringing this up. Nobody has yet suggested
"locking out" interesting content in Plucker or otherwise. We've already
cleared up the fact that it's easy to implement in Plucker, using whatever
tools the parser authors are using. A quick google shows that we want to use
urllib, as follows in the Python distiller:
urllib.quote("http://www.foo.com/some url/with spaces.html")
Or perhaps:
urllib.urlencode(whatever)
Someone needs to figure out where in Url.py this goes, i.e. not me.
> When I got involved with some of the coding last autumn, it was to make
> Plucker work to my satisfaction, not to make it more finicky.
Again, I'm not sure where this assertion comes from. Nobody said
Plucker was going to make existing sites break in future versions. Quite the
opposite in fact. The point is that solving the "problem" in Plucker does
not solve the problem overall, and in fact, lets it continue to propagate.
Do you just tell everyone who gets a flat tire from hitting that
huge pothole in the road to just keep replacing tires? Or do you fix
the pothole?
> You stated several times that the issue is what to do about the problem of
> defective webpages. Maybe I'm just getting old, but I'm way past trying
> to convince web site authors that their pages need rewriting even though
> they work fine with every browser they can find.
And.. if they just used the published, established, industry-agreed
upon standards from the start, they wouldn't _have_ to worry about whether
or not it works in browsers that do or don't conform to those standards. See
how easy that is? Code that works with the standards will work well with
browsers that support the standards.
> I agree that spaces in URLs are "bad", and that they don't meet the W3C
> standard, but I don't agree that the W3C standard holds more water with
> corporations, web authors, and users than what their browsers do.
They're not "bad", they're wrong, flat out. There is a difference.
Read the link below for more detail:
http://www.blooberry.com/indexdot/html/topics/urlencoding.htm
> That doesn't mean I don't support standards, but it does mean I'm not
> religous about them. That's an important distinction.
As is the distinction between "supporting" standards, and "adhering"
to them. You and I differ in this regard.
I like spending less time re-engineering code every time a new
browser or patch comes out. Since my code is matched lockstep with the
documented standards, I can be sure that if it looks good in a browser that
is standards-compliant (i.e. Mozilla, et al) today, and a patch is releasd
to Mozilla or IE or JoeBrowser2003, and it looks horrible.. my code isn't at
fault. Again, this is why IE will never be fixed to work with the standards.
It has too much of an install-base of users who have spent more time making
it work "good" in IE, than making it work "right" using the standards which
IE is purported to be following.
> Just as with projects in my commercial environment, where I may WANT to do
> something the architecturally-elegant and extensible way, but the project
> scope, requirements, and budget point to doing it more pragmatically,
> bordering on a kludge but a reliable one within the defined parameters.
Again, a possible difference between you and I. I don't implement
kludges in my code.
> Leveraging standards is valuable, Idolizing standards is destructive.
> This group more than any other I consort with often slips into zealotry
> about such things.
Do you know why? Because we get more bugs reported for things that
are completely unrelated to Plucker, but which "affect" Plucker to the user.
I take ownership of probably being the most zealoutous of the rest
of anyone here (apologies to all), but that's because I spend my entire day,
every day, supporting hundreds of users who have issues with these and
similar tools, only to discard 95% of their "bugs" as external, precipitated
by something outside the relevant code the bug is reported against. Check
the bugtracker sometime, and see what kinds of things we get reported.. it
gets tiring (and repetitive) after awhile.
> "Go away"? No, but they will, as they already have, follow rather than
> lead. They will continue to adopt what the marketplace has already
> enacted. And I'm not saying that's a good thing, only that it's reality.
Since when has the cart been before the horse here, with regard to
standards? Without standards, people would make up anything they felt was
"cool" or "hip", and implement that.. (Oh wait, Microsoft already does that,
never mind). </sarcasm>
Seriously though, standards are here to stay, and exist for a
reason, as a baseline for developing products and technologies against. I'm
actually glad that the number of people conforming to the W3C standards is
actually _increasing_ in number, not decreasing. I see it on irc and in
email all the time, where people will come into an HTML channel asking how
to do this-or-that in frames or popups, and when they are educated as to why
those methods are bad, they begin to learn how to do the same thing using
CSS and validated HTML. They listen, they learn, and that says a lot.
"One spoonful at a time, and eventually you can move the mountain."
> My point is that, given that it IS common and supported invisibly by all
> major browsers, resisting supporting those same evils with a collection
> tool sacrifices usability to no good end. It may FEEL "right", but it
> doesn't accomplish "right". Even though what it's doing is refusing to
> work with what's "wrong".
So, as I've said, and I think everyone has agreed with me from the
start, there's nothing wrong with supporting this in Plucker, and it will
get implemented by someone, when the itch is big enough to scratch.
I've already fixed it in my code with one line, and I've provided
some direction to those contributors who wish to fix it in the Python
distiller as well (google://urllib). I don't think anyone has ever said we
"should not" support spaces in URLs in Plucker, just that the problem is
not a Plucker issue or inadequacy, but yes, it can be fixed in Plucker, so
it doesn't affect the end user (and hence, increase the number of non-bug
bug reports we have to deal with).
Let's move on.. we both agree that it needs to be fixed at some
point in Plucker, and that the real issue is mostly out of our control,
upstream due to people not reading the standards. I've offered some methods
to fix this in Plucker in at least two languages, so we'll let the others
who know those better implement them when they can.
d.
_______________________________________________
plucker-list mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-list
