Full url in Opera 17. Any chances?
-
Deleted User last edited by
Originally posted by scratchspace:
But notwithstanding your wording "urls I visit", you have clearly been discussing this matter not as one of personal preferences but rather as a matter of proper browser design. If you would now would like to say that your point concerning the showing or not showing of the full URL is merely a matter of your personal preference, fine, but that's not what you've been saying.
If it were a matter of my own personal preference, I would not even have spoken. The thing is that url is a basic web standard, an essential element to it. You said it's not. Or, the way you put it, "not as essential as page numbers in a book". Sorry, but urls really are more essential than page numbers in a book. Below I'll show how.
Originally posted by scratchspace:
Originally posted by ersi:
As Frenzie showed, urls have the same function as page numbers. Imagine your bookmarks and history with "focused" imprecise urls, recoverable only when you copy and paste them to Notepad. How do you edit your bookmarks?
You edit them in the "Edit bookmark" dialogue. I don't understand why you're asking this—have you actually installed and used Opera 17?
You missed a little important detail: I said "imagine". You are here defending the mangling of urls in the address field. Imagine, how you would defend if urls were mangled in bookmark items. Ask yourself: With an imprecise url, is it really still a bookmark?
Originally posted by scratchspace:
Whoaaaa . . . Nobody said anything about "tak(ing) the URL away". The issue that you raised was that of "half-hidden" link URLs, that is, truncated link URLs, as a parallel to the truncation of address bar URLs.
It just occurred to me that there is one legitimate case for truncating urls - namely, when there's not enough space on the screen. But the current case is far from it. What is going on right now is embellished with arguments like "hide irrelevant information" or "protect you", i.e. somebody else is doing the thinking for you, in this case deciding for you what you should see or not. It's called censorship. Read the article I linked above close tot he beginning of the thread. My arguments are against that.
Apart from it being censorship, it's actually the case on the web that urls are essential and web browsing means visiting web addresses. Now I'll show how.
Originally posted by scratchspace:
Originally posted by ersi:
Originally posted by scratchspace:
A browser, on the other hand, unquestionably performs its defining, essential function regardless of whether it "show(s) the full address".
What on earth is a browser's essential function? To me it's visiting web addresses, a.k.a. urls. To you?
It's visiting webpages. As for your assertion that the essential function is "visiting web addresses, a.k.a. urls", I can't believe that you're saying this.
This is a subtle but crucial difference now. Yes, the web consists of pages, but the pages are identified by urls. To bring up the book analogy again, are the book's author and title irrelevant when you are looking for a book to read?
Url is to webpages what ISBN is to books. Without url you won't even get to your first webpage, so, even though for you it may seem that the browser's essential function is to visit webpages, visiting webpages cannot even begin without a url. Therefore I named the browser's essential function more precisely.
Moreover, there are other files on the web, files to download, file lists on servers to browse, dead links, etc. By url I can often tell what kind of operation to expect from the browser when I click or enter it.
Originally posted by scratchspace:
Originally posted by ersi:
By the way, urls are, by definition, either correct and precise or not. "Fullness" is actually changing the topic.
No, actually it's not; it's only a question of what is displayed in the address bar. The page itself—do I actually have to say this?—is not affected.
Let's repeat it so it will be very clear: You won't see any page at all in the browser if the url is incorrect. Or you may be looking at the wrong page, if the browser is hiding the url from you. The page may be there, but you can't access it without knowing the url and entering it precisely to the point. This is rather essential and elementary feedback from the browser, has been there all along. Muddling this functionality is certainly non-standard, if not outright criminal.
Originally posted by scratchspace:
This is all from me, guys!
See you tomorrow.
Originally posted by rafaelluik:
Originally posted by ersi:
Urls must be correct and I have to be able to verify the correctness before I click or press enter.
That's what the status bar is for.
Indeed, status bar is for that. Now, would you be able to articulate a defence for mangling the url on the status bar as eloquently as you have in case of address field?
Originally posted by rafaelluik:
As for pressing Enter in that case you obviously already know whether the URL is right or not because you followed it from your bookmarks or pasted the URL yourself and the address field will retain the focus and the text in regular font you can read.
There's more to it. I often enough extract urls from links, for example when noticing that the url is evidently malformed and needs editing to take me to the right place, or when I need to go to a slightly different destination than the url. For this task, the status bar is not enough. The most obvious place for this task is the address field. This is why I care a lot what is going on there.
I need precise feedback of the address where I stand. Something less than full exact url on the address field makes the software in question something less than a browser. There is more stuff on the web than just webpages and it's often important to know it before clicking or pressing enter.
-
missingno last edited by
So,
wellknownhoster.com/goodsite/
and
wellknownhoster.com/badsite/
are basically the same to any user? I mean, obviously there is no reason to know on which side I am as they both share the same domain. -
Deleted User last edited by
Originally posted by scratchspace:
What, are we getting metaphysical here? Or are you simply not understanding that the browser knows and stores the full URL, regardless of whether it's displayed in the most obvious location?
If it knows and stores it but doesn't display it, what's the use? Remember that you are defending the mangling of urls, saying that it's somehow practical. This is a rather metaphysical point to defend. I do not envy your position at all.
-
frenzie last edited by
Originally posted by ersi:
Let's repeat it so it will be very clear: You won't see any page at all in the browser if the url is incorrect. Or you may be looking at the wrong page, if the browser is hiding the url from you. The page may be there, but you can't access it without knowing the url and entering it precisely to the point. This is rather essential and elementary feedback from the browser, has been there all along. Muddling this functionality is certainly non-standard, if not outright criminal.
That actually reminds me of something. Rafael asked why I am "obsessed" with the query string and hash, and I think I sufficiently expressed my astonishment at the very question. Well, I don't know if this bug still exists, but for a while the MyOpera forum would occasionally try to send me to a link like http://my.opera.com/community/forums/findpost.pl?idx=14888352.* Hiding the query string would've made it impossible for me to see at a glance what the problem was and fix it. I would've been unfamiliar with the regular format, and I may never have noticed the problem at all, even with my current knowledge, had it required focusing the addressbar.
You might counter that most users wouldn't be able to do this kind of simple problem solving regardless. Perhaps you'd be right; I haven't the slightest idea. But I can tell you one thing: if you hide the query string by default, far fewer people will develop similar capabilities autonomously.
* Something along those lines; I don't recall the details but the point is the argument not "id" like it's supposed to, or perhaps there was something in front of the numbers that wasn't supposed to be there.
-
serious last edited by
Aaanyhow, without reading the flamefest (though it looks very funny): I prefer to see the whole address, including protocol and query string, at all times. It's not like it distracts you any more from the page than a shortened URL and in case you need to know eg. a query string param you don't have to do bullshit like focusing the address bar first.
I think Opera12 had the implementation right, option for showing the full address or shortened version and if you click into the address field when having the shortened version it also shows you the _full_ address with protocol and everything.
-
Deleted User last edited by
Originally posted by Frenzie:
That actually reminds me of something. Rafael asked why I am "obsessed" with the query string and hash, and I think I sufficiently expressed my astonishment at the very question. Well, I don't know if this bug still exists, but for a while the MyOpera forum would occasionally try to send me to a link like http://my.opera.com/community/forums/findpost.pl?idx=14888352.* Hiding the query string would've made it impossible for me to see at a glance what the problem was and fix it.
That question of Rafael was silly.
Another use case when a full url is very useful/handy is when you want to access some data which sometimes you can't directly from the page you are on. By modifying the string you can access data which you otherwise would have to search for at first and wasting time.
Worked for me more often, except I got an access denied
-
frenzie last edited by
Originally posted by serious:
I think Opera12 had the implementation right, option for showing the full address or shortened version and if you click into the address field when having the shortened version it also shows you the _full_ address with protocol and everything.
The lowlighted text has been hard-coded gray since it first showed up in Opera 11. The implementation was better, but definitely not right. By making it only work with a particular color scheme, it's most assuredly broken. It'd actually be less broken if they hard-coded all three colors, but that'd obviously be the worst "solution" to this fairly severe GUI bug.
The simplest fix would be a switch to disable all meddling with the addressbar.
A proper fix which maintains the undesired behavior of lowlighting might check if there's sufficient contrast between the background color and the lowlighted text color. It could perhaps even calculate a lowlighting color on the fly, based on background and text color. A simplified version of this fix would turn off lowlighting when contrast is too low, but that'd just make everyone with a more or less standard color scheme jealous.
Another possible proper fix would implement actual highlighting. As long as it doesn't work with hard-coded text colors, just about anything should be better than the current disaster.
The best solution would be extensive configuration options or an extensive API so one can achieve results similar to Locationbar². Here's all the styling handles it offers:
.textbox-presentation-box .textbox-presentation .textbox-presentation-prePath .textbox-presentation-protocol .textbox-presentation-subdomain .textbox-presentation-domain .textbox-presentation-port .textbox-presentation-path .textbox-presentation-segment-label .textbox-presentation-slash .textbox-presentation-pathFile .textbox-presentation-file .textbox-presentation-query .textbox-presentation-fragment .textbox-overflow-ellipsisThe best solution would of course only be the best when implemented in addition to the simplest fix, or on top of one other other possible fixes. By itself it would be a rather marginal improvement too complicated for most.
-
serious last edited by
Originally posted by Frenzie:
making it only work with a particular color scheme
ok, I dont have such issues as I use the default skin
Originally posted by Frenzie:
The best solution would be extensive configuration options or an extensive API so one can achieve results similar to Locationbar².
+1, best would be for skins or the user directly to be able to style the different url-parts
EDIT: Ps: does Locationbar² allow for eg :focus selector with these attributes?
-
frenzie last edited by
Originally posted by serious:
ok, I dont have such issues as I use the default skin
I like the rest of Opera so much that I went for a lighter shade of gray than I used before the Opera 11 addressbar disaster, and on another installation I went with X11 with custom colors instead of desktop integration. But I've been using Opera for many years and have extensively customized my installation; if I were just trying Opera and saw it utterly failing on my custom color scheme—well, let's just say I would not be impressed. Opera 15+ lacks Opera's other redeeming qualities.
By the way, I'm not talking about skins. I'm talking about my operating system or window manager.
Originally posted by serious:
EDIT: Ps: does Locationbar² allow for eg :focus selector with these attributes?
I couldn't say, good question. I'm of course talking about the principle, not the specifics.
-
frenzie last edited by
Originally posted by Krake:
Another use case when a full url is very useful/handy is when you want to access some data which sometimes you can't directly from the page you are on. By modifying the string you can access data which you otherwise would have to search for at first and wasting time.
I just realized I've been using this example since they made the forums worse: http://my.opera.com/community/forums/tgr.dml
-
A Former User last edited by
Originally posted by Krake:
Originally posted by Frenzie:
That actually reminds me of something. Rafael asked why I am "obsessed" with the query string and hash, and I think I sufficiently expressed my astonishment at the very question. Well, I don't know if this bug still exists, but for a while the MyOpera forum would occasionally try to send me to a link like http://my.opera.com/community/forums/findpost.pl?idx=14888352.* Hiding the query string would've made it impossible for me to see at a glance what the problem was and fix it.
That question of Rafael was silly.
Another use case when a full url is very useful/handy is when you want to access some data which sometimes you can't directly from the page you are on. By modifying the string you can access data which you otherwise would have to search for at first and wasting time.
Worked for me more often, except I got an access deniedMy question was not silly. You can check and edit the URL string easily with F8.
-
A Former User last edited by
Originally posted by ersi:
Originally posted by rafaelluik:
Originally posted by ersi:
Urls must be correct and I have to be able to verify the correctness before I click or press enter.
That's what the status bar is for.
Indeed, status bar is for that. Now, would you be able to articulate a defence for mangling the url on the status bar as eloquently as you have in case of address field?
Honestly I haven't even noticed the http:// part is trimmed from the floating status bar, when a link leads to a different protocol like a https:// or ftp:// URL it's shown though so there's your way to verify it. The rest of the URL is there...
Originally posted by ersi:
Originally posted by rafaelluik:
As for pressing Enter in that case you obviously already know whether the URL is right or not because you followed it from your bookmarks or pasted the URL yourself and the address field will retain the focus and the text in regular font you can read.
There's more to it. I often enough extract urls from links, for example when noticing that the url is evidently malformed and needs editing to take me to the right place, or when I need to go to a slightly different destination than the url. For this task, the status bar is not enough. The most obvious place for this task is the address field. This is why I care a lot what is going on there.
"I often enough extract urls from links" - if you mean via the "copy link address" command then you pasted it and it'll be displayed fully.
"when I need to go to a slightly different destination than the url" - then I assume the protocol is not important, or are you really in need of pursuing the protocol to go to a sightly different page? -
Deleted User last edited by
Originally posted by rafaelluik:
Originally posted by ersi:
Now, would you be able to articulate a defence for mangling the url on the status bar as eloquently as you have in case of address field?
Honestly I haven't even noticed the http:// part is trimmed from the floating status bar, when a link leads to a different protocol like a https:// or ftp:// URL it's shown though so there's your way to verify it. The rest of the URL is there...
My question was if you are able to defend any mangling of the url on the status bar, as you are trying to defend the mangling of the address field. Since you offered no defence, I take it that your answer is no. Which is good.
Originally posted by rafaelluik:
"I often enough extract urls from links" - if you mean via the "copy link address" command then you pasted it and it'll be displayed fully.
Hence it's good when the program doesn't mangle it. Which has been my point all along.
Originally posted by rafaelluik:
"when I need to go to a slightly different destination than the url" - then I assume the protocol is not important, or are you really in need of pursuing the protocol to go to a sightly different page?
A case in point:
http://ftp.opera.com/pub/opera/
ftp://ftp.opera.com/pub/opera/Is the protocol not important there? Absolutely everything is important. Above you said "I haven't even noticed the http:// part is trimmed from the floating status bar, when a link leads to a different protocol like a https:// or ftp:// URL it's shown though". Thus the protocol evidently *is* important. If https, ftp, gopher, etc. must be shown, then there's no justification to remove http either, right?
If you still think that mangling of the urls is justified, then you need to also think exactly how far it is justified, because obviously there's a limit. At least you would notice for example when the address field and status bar were entirely removed, right? So, if a little mangling is okay, think further, how far would you allow it. As for me, I allow no mangling at all. The program must display everything faithfully. There's no reason for it not to.
-
serious last edited by
Originally posted by rafaelluik:
You can check and edit the URL string easily with F8
and previously I could check it easily without doing anything if I wished so.
Originally posted by rafaelluik:
the protocol is not important
It is for me at work. Long story short, we have same addresses running on http or https (eg. depending on host entry to skip the ssl-offloading load balancer) so going to a url without a protocol will (in my chrome experience) in 90% of the time give you exactly the wrong one from the history. Seeing the full url is way easier for debugging and selecting the right one from the address bar autocomplete dropdown.
-
A Former User last edited by
Originally posted by ersi:
My question was if you are able to defend any mangling of the url on the status bar
There's no mangling, as I said http:// is hidden but all the others are kept so there's your differentiation. The rest of the URL string is intact in the status bar.
Originally posted by ersi:
If you still think that mangling of the urls is justified, then you need to also think exactly how far it is justified, because obviously there's a limit. At least you would notice for example when the address field and status bar were entirely removed, right? So, if a little mangling is okay, think further, how far would you allow it. As for me, I allow no mangling at all.
The problem with the address field being ENTIRELY removed is that there would be no way to go to any URL and the security information would have to lie elsewhere. But look, this hypothesis you're talking about has nothing to do with the discussion here: URL string trimming.
Originally posted by ersi:
The program must display everything faithfully. There's no reason for it not to.
It does, in the status bar no protocol = http, https:// = https://, and so on. In the address field you've got security information and the full URL with F8.
The reason is readability of the main domain...Originally posted by ersi:
A case in point:
http://ftp.opera.com/pub/opera/
ftp://ftp.opera.com/pub/opera/Originally posted by serious:
It is for me at work. Long story short, we have same addresses running on http or https (eg. depending on host entry to skip the ssl-offloading load balancer) so going to a url without a protocol will (in my chrome experience) in 90% of the time give you exactly the wrong one from the history.
Well guys you aways come up with the most obscure examples that regular users will never come to experience or that doesn't make any difference (like the Opera FTP or HTTP pages)... "The company I work on have broken their own intranet/website." kind of examples...
-
serious last edited by
Originally posted by rafaelluik:
regular users
well, that's a thing of definition ... considering opera is a classic power-user app so go figure
Originally posted by rafaelluik:
that doesn't make any difference (like the Opera FTP or HTTP pages)
only in that case, if you access a server that does not only serve static content but runs scripts the difference is quite huge (accessing the file vs executing it)
Originally posted by rafaelluik:
"The company I work on have broken their own intranet/website."
its not broken, but I am working as a tester and need to poke around in the guts of it all here and there.
Edit: anyhow, all we are asking for is to provide the same option that Op12 had: a checkbox that lets you toggle to show the abbreviated or full url by default (or to make it fully styleable by the skin which would be even more awesome)
-
Deleted User last edited by
Originally posted by rafaelluik:
...this hypothesis you're talking about has nothing to do with the discussion here: URL string trimming.
Let's call it trimming then. The change of name doesn't change anything in my arguments against it. What you call trimming is a fact, not a hypothesis. Surely *you* are not talking hypothetically...
Originally posted by rafaelluik:
Originally posted by ersi:
The program must display everything faithfully...
It does, in the status bar no protocol = http, https:// = https://, and so on. In the address field you've got security information and the full URL with F8.
The reason is readability of the main domain...The reason is not only flimsy, but also wrong. If the protocol name takes away readability from the domain name, is it just http that does so? Not at all. So, all protocols are equal here.
Originally posted by rafaelluik:
Well guys you aways come up with the most obscure examples that regular users will never come to experience or that doesn't make any difference (like the Opera FTP or HTTP pages)... "The company I work on have broken their own intranet/website." kind of examples...
Looks like you have no concept of internet as a tool - a major part of it being intranet when in work environment. In both nets, a browser is a tool that must work or another tool will be chosen, plain and simple. It would also do good to you to have a concept of web-developing or office work done for a living. These are serious concepts for you to get a grasp of. When you look around even in these forums, you'll see there's nothing obscure about these things.
-
frenzie last edited by
Originally posted by rafaelluik:
My question was not silly. You can check and edit the URL string easily with F8.
Indeed, it was more than silly. Silly would be to suggest one write an extension to display a full addressbar underneath the addressbar. Suggesting one press F8 constantly is beyond silly. It fits a pattern, of course.
Originally posted by rafaelluik:
or are you really in need of pursuing the protocol to go to a sightly different page?
It's not like this came up recently or anything.
http://my.opera.com/desktopteam/blog/show.dml/109458842?startidx=200#comment112867522
http://my.opera.com/desktopteam/blog/show.dml/109458842?startidx=200#comment112870972
http://my.opera.com/desktopteam/blog/show.dml/109458842?startidx=200#comment112875252
http://my.opera.com/desktopteam/blog/show.dml/109458842?startidx=200#comment112884802
http://my.opera.com/desktopteam/blog/show.dml/109458842?startidx=250#comment112899952I've already typed a different address from the addressbar while I was on one of the opera:// pages, only to end up on opera://whatever.com doesn't exist. Hiding the protocol is broken. Hard-coded text colors are broken. Hiding the query string and hash makes the browser appear broken in many circumstances because it's not clear that a different page is actually being loaded, nor that jumping will occur due to the presence of a hash. And in any case, having to press keys constantly on a device meant for automation of meaningless tasks is broken.
Originally posted by rafaelluik:
The problem with the address field being ENTIRELY removed is that there would be no way to go to any URL and the security information would have to lie elsewhere. But look, this hypothesis you're talking about has nothing to do with the discussion here: URL string trimming.
Sure there is. Just press F2, or change how F8 works. The Ctrl+F dialog might serve as an example.
Originally posted by rafaelluik:
Well guys you aways come up with the most obscure examples that regular users will never come to experience or that doesn't make any difference (like the Opera FTP or HTTP pages)... "The company I work on have broken their own intranet/website." kind of examples...
It's not broken. But even if it were, you keep claiming Blink is so much better than Presto in the website compatibility department. Why would you want to take away part of that alleged advantage?
Originally posted by serious:
Edit: anyhow, all we are asking for is to provide the same option that Op12 had: a checkbox that lets you toggle to show the abbreviated or full url by default (or to make it fully styleable by the skin which would be even more awesome)
Not me, I want more.
Like I keep saying, the hard-coded text color is a broken disaster, and a shining example of the very worst kind of UX: that which doesn't take the user into account, but only some designer's personal preferences. -
serious last edited by
Originally posted by Frenzie:
Not me, I want more.
as I said ...
Originally posted by serious:
(or to make it fully styleable by the skin which would be even more awesome)
-
frenzie last edited by
Originally posted by serious:
as I said ...
Originally posted by serious:
(or to make it fully styleable by the skin which would be even more awesome)
Sure, but I'd already be satisfied with just the appropriate text color taken from the OS, just so it wouldn't be broken. Most important, a non-broken implementation shouldn't require any action on my end at all. I'm incredibly patient with Opera, but some random Firefox user checking it out will not be. They'll just see it doesn't even integrate with their dark color scheme and Opera will be gone as quickly as it came.
