Though I agree in principle, the various SMB ports are near useless on so-called "high-speed" connections. There is just way too much broadcasting and redundant back-and-forth traffic that it's too slow to actually use.
It's also an inherently insecure protocol. I suppse one could port-forward via SSH (I have no idea, just musing out loud). Authentication will often fall-back to cleartext if the weak challenge-and-response fails.
I actually prefer that my provider block such ports on the wire. They did this mostly because new customers would fire up their boxes and immediately be able to browse (or be browsed) on the "Network Neighbourhood". The whole world is your "WORKGROUP"!
I have the feeling most people didn't know or care that they have such a thing available to them. At work, they may use "the network" but apparently they need no such thing at home and certainly don't want to know how to set one up (with any amount of security, anyway).
My guess is that only a few of us run an internal network that routes to a shared connection.
The problem, of course, is that blocking ports can be seen as the "thin edge of the wedge" in terms of providers slowly removing connectivity until we are all paying for a single port-80 connection to their proxy (complete with Carnivore) and maybe POP or IMAP. If you are lucky, and really ask nice.
"The Twirlip of the Mists doth protest too much, methinks."
Look, all you have to do is state your case. You don't have to get your knickers all in a twist. I, in fact, have never really given this all that much thought and don't really give a shit. You'll notice I haven't, in fact, been "protesting" about this at all. I posted exactly one reply to a single thread. Perhaps you have me confused with someone else.
And how have I been a smart-ass? Show me anywhere in my single reply where I was difficult or name calling or otherwise disrespectful? Now check your post. I'd be tempted to say that someone around here is acting the ass, and it sure isn't me.
Since you didn't state your sources, we only have your word to go on about the Intel issue. Assuming you are correct, you have made a compelling case (however, I'm not convinced that "Mac OS" itself could not have been enough of a trademark without having to rebrand). However, It's pretty clear that regardless of what Apple intended, there is enough semantic confusion to warrant criticism. Which was, in fact, the crux of my posting.
If you can't stand someone having an opinion about something, however misinformed that opinion may be, you are in the wrong place. If the slightest disagreement sends you off into vitriol and name-calling, perhaps you should reconsider how you spend your time here.
Install a sense of humour, willya. You are taking all this much too seriously.
Well, according to Apple, the name of the OS is "Mac OS Ten". As in one more than OS 9. I think a lot of people feel the "ten" part is redundant. That is, saying "Mac OS Ten ten-dot-two-two" is kind of lame.
Most folks I know either say "Mac OS ex ten-dot-two-two" or "Mac OS ten-dot-two-two".
The first is, according to Apple, incorrect. The latter is more natural. The recommendation by Apple is the last choice anyone wants to make. I don't think people care that much about it, but it is unnecessarily obtuse. It might have been more clever to brand the release "Mac OS X R2.2", or something.
Brands and labels are important. If people don't find the official way to refer to something easy, they will create their own, possibly varied, names.
As pointed out in this thread, there is no way anyone is going to say "Mac OS Ten Eleven Twelve" or "Mac OS Ten Eleven One Two" for OS X 11.1.2. Not without deep irony, anyway.
Then again, Apple may just be carrying on the tradition of naming UNIX releases with an unwieldy string of digits that get ignore;)
Oh, I dunno. In the "smaller is better" game men like to play with their electronic gadgets, the iBook is pretty apropos. Apparently (the inverse) size does matter for notebooks, cell phones &etc. The marketing folks know we like these gadgets small.
The 12in. iBook is small and light, and fits nicely in a shoulder bag (sorry: a man purse).
With apologies to "Friends", or at least the only episode I watched all the way through.
My local "alter-native" video store puts a little red dot on the anime that may not be for everyone. A red dot means "warning! tentacles and demon-sperm rape scenes!"
This is handy for people who may not be in the mood (now, or ever) for such fare, but also helps against simple mistakes.
"Honey, this cover looks cool, let's get this"
"Ok"
Note to self: "Urotsukidoji: Legend of the Overfiend" is not a first date movie.
Not sure what you mean, but I publish my iCal calendars to my WebDAV server all the time. This is actually unrelated to the iDisk-fake stuff in this article.
It's pure WebDAV, with a proper <LIMIT> section for the iCal directory. I can publish, and others can subscribe with iCal.
*shrug* I'm well aware of this. I was too lazy to check the specific net ranges which is why I hand-waved and said "and friends". It isn't important, anyway. I presume anyone who actually sets up a proper internal network will get the details they need.
The point is that you can use a local, non-routable IP address for a fake.Mac server (or any server, for that matter), and you do not have to pay for a publicly routable static IP. This seemed to be a point of confusion for the top post of this thread.
I wasn't indicating anything else in my reply. The exact range you use and how to use it is left as an exercise for the reader.
getting a fixed IP costs way more than a.mac account
You don't need a static IP, or at least you do not need a routable one. Unless, or course, you intend to serve.Mac to a bunch of friends on different networks. The point of the article was to make a local.Mac-like server for iCal, and iDisk access.
Remember, you always have 10.x, 192.x and friends to play with all you want at home. This article interests me because I have a stable of Macs on my internal network. Implementing this means that it is trivial to get folks to do regular backups, publish calendars and such without having to install any new software.
It's all about leveraging existing Apple software with open standards.
I've seen the same thing. The latest "Queens of the Stone Age" locks up the iBook, but my two G4's have no problem with it.
Even a manual eject left the iBook in a state where it couldn't read any CD.
I'd love to apply this firmware update, but I've got a hacked firmware that makes the DVD player region-free. It also looks like nobody is interested in making a new region-free ROM image based on these latest firmware changes.
Ok, you win. I'm am trying to control the user agent. In fact, I'm trying to control all user agents, including the one you are using right now.
Seriously, I'm not missing anything, trust me. I've gone over this one-point-two million times, it feels like (once in the bug posting, once here). I'm not alone here. For every sane and logical argument you have for this decision, there are others with just as many sane and logical arguments counter to yours. You will ust never convince me that an applicaton control should effect the flow of content in this manner. It'll never happen.
I understand why this is happening, I just don't agree with the solution. I, in fact, don't have a solution, but probably would have chosen one of the other poor solutions.
This is one of those things we will have to just agree to disagree on.
There isn't an easy solution. The tweaker in me would want to solve this in a better manner.
*shrug* Meanwhile, I just added a "min-height" property to one of my container CSS classes (to fix a column flow problem if a left-hand column was shorter than the right) which had an unintended side-effect of forcing the scrollbar always on in most user agents.
A hack, to be sure.
I don't know about whether people prefer always-present scrollbars or not. I don't think anyone of us here are in a position to say for sure, as all we have are anecdotal evidence (as far as I know). I do know that one non-designer I helped with a web site noted that her X% wide centred (via generic CSS, not tables) pages would jump around during simple navigation in Mozilla -- activity where she would not expect the content to reflow. She's savvy enough to know that she can't count on a particular sized viewport, nor would she want to; but it is jarring for some users to see things reflow on a gesture they didn't expect. It's pretty common to toggle back and forth between top-level navigation to make sure you got all the text and links to match up.
What could I say? From an end-user perspective, Mozilla could look a bit broken. I'd say a good number of people I know have noticed it, and either hated it or chalked it up as a user agent difference.
As a developer, I spend a good portion of my life saying "that's by design" in response to a bug posting or feature request. Sometimes I have to accept that this may not be good enough for some users.
I personally don't see the problem with always-present scrollbars that are greyed-out if not in active (as per Internet Explorer). It's just an application thing I can live with. This seems to be one of those things that really attracts strong feelings, so I'm not going to suggest it as a solution. It would solve a boat-load of problems and (to my mind) doesn't really introduce any new ones.
Anyway, I'd say I'm really done on this subject. Obviously I have an opinion, but contrary to the volume of this thread, I don't mind all that much. If there was an O'Reilly book called "Mozilla Annoynances", I'd expect this to be in there.
I agree. The cable/satellite companies make it very attractive to overbuy, by making the discrete channels expensive and the packages cheap. They also tend to break the discrete channels into aggragate similar groups that you can't split up.
This means I can't easily assemble, for example, a group with a hockey channel, and not get the Golf Channel. Which means I end up paying for two channels I sometimes watch (NHL Channel) and one I never watch (Golf). The same goes for many other of my choices.
One criticism I have of the 1000 channel universe is that while I agree with splitting up some things into speciality channels, I think it's presumptuous to do so for other subjects. For example, in Canada we have a few digital music stations spun off of MuchMusic segments. I don't agree that one must listen to the same stuff all the time. I have a varied taste in music, and splitting the channels into an age or earning demographic is good enough for me. Instead, I have to decide whether I want MuchLoud, MuchGroove, MuchFoo or MuchBar (or all four).
The same goes for the movie channels. Sometimes I like "lost drive-in classics" and sometimes I like "independents". I either have to choose between them, or pay for both. I'm not saying there are not any general movie or music channels, but that I see a tendency toward more and more specialization until we might be coerced into buying more channels than we really want. I'd like the optin to underbuy and still get a fair amount of value. My back-of-the-envelope calculations show that pick and choosers like me pay almost 50-70% more.
This is all moot, I guess, since I'm leaning toward getting rid of cable altogether. The only reason I have cable now is for high-speed inet. As soon as I arrange a DSL connection, I imagine I'll cancel cable completely.
I've heard this explanation, and I understand that this is not a simple thing I'm asking. Then again, I don't have the solution, I just have a beef with the current behaviour. I guess the Moz team had three choices:
1. Add the scrollbar, having it take up viewport space, triggering a reflow because the width has changed
2. Always have the scrollbar take up the space (whether it is visible or not)
3. Paint the scrollbar over or under the content when necessary
So, they chose (1) as the most correct behaviour, and I can almost see why. I almost want there to be a 4th option:
4. Draw the scrollbar, or lack thereof, on the frame of the application, treating it like a toolbar or button bar.
This is obviously not optimal either, but I just don't like the current behaviour, and mostly because simple, well designed pages will cause things like navbars to move out from underneath the mouse point. I think this bug came down to whether you consider the current behaviour "correct", and whether you found any other solution "elegant". Of course, what one person things is correct or not is a bit of opinion.
I'm pretty sure this horse is dead, so I'll shut up now.
Well, we will just have to agree to disagree. I don't consider a scrollbar part of the content, and don't care if it is there or not. I object to an application control behaving as a CSS object.
I build pages that flow well in any reader, be it Lynx, screen readers or a graphical browser. I leave the flow up to the user agent.
It may be "logical" to you, but when I build applications, I tend to not have my application controls be part of the user's data.
I'm pretty sure this horse is well and dead by now.
I don't know how you are getting that from me. I'm the last to say I want an absolute width, and have made that clear several times. I am using percentiles to describe CSS objects which are floated left. This is pretty generic. I am not flaunting anything. I have no problem with the width changing if the container the text is in, or near, changes.
I can't put it any plainer: I object to the scrollbar, which is an application widget, counting as any width in the viewable contents of a page. If it was anything else, I'd be agreeing with you, but it is a scrollbar. I do not consider the scrollbar a CSS object around which I must flow my content. If you do, fine. This is what the bug is essentially about. Some agree, some don't.
It's pretty common to build a site with a common navbar across the top. If some of those pages happen to have a maximum height above the viewport, and some that do not, navigating between the pages does two major things:
1. Causes the right margin to jump by however many pixels the scrollbar is set to
2. Causes the hyperlink that the mouse pointer is currently under to move away from the pointer
This last is especially insidious. UIs where gestures cause controls to move away from the the pointer are just bad.
From a usability standpoint, I cannot agree that this is not a problem. Scrollbars are part of the chrome, and not the content. Gestures shouldn't move the UI around in unexpected ways. An interface that encourages this behaviour is flawed.
The first item just makes Moz look unpolished unfinished. It's a graphical browser, for crying out loud! It should look good.
It should be easy for designers to develop simple pages that do not violate good usability. It should be easy for Mozilla to render standards-compliant pages in a friendly manner.
Mozilla is the only browser that does this, AFAIK. This is not a user agent issue. It is an application issue squarely in the domain of the Mozilla presentation code. Just because we can access the application chrome with a URL doesn't mean we should, in this case.
Just to make it clear, I am not trying to establish an abolute size. I am not trying to enforce a particular width. I am objecting to 60% + 20% in a simple CSS property that is changing because of an application control, and not content. I have no problem with reflows being forced due to content changes. Scrollbars are not content. If you must disagree with me on this, so be it. Please do not conflate my issues with usability with any type of fixed or absolute positioning.
there's a bunch of utilities [at] [wormintheapple.gr]
I can confirm that the firmware hack mentioned here works for me. Watched the Region 2 version of "Spirited Away" on an iBook. Even have the RGB to SVideo adapter so I can watch it on the big Sony. No 5.1 though:(
If you absolutely, unavoidably need two elements to have exactly the same visual width, you need to be specifying widths in pixels. If you rely on relative widths, you subject yourself to this sort of problem and shouldn't complain about it.
I've made my position clear in other posts in this thread, so suffice it to say that I will cheerfully agree to disagree. I reserve the right to complain about anything I like. This is the point of having an opinion.
I rely on relative widths because that is good practice. I simply disagree with having an application widget effect the flow of content. Having application controls affect page content is just bad design.
Minor perhaps, but bad nontheless. I don't see how anyone can consider that "expected behaviour".
There is nothing in the various specs about this because this is not a rendering or reflow issue, per se. It is about how an application decides the widgets and controls affects data. Would anyone expect the addition of a ruler or toolbar (without changing the size of the viewport) cause a reflow of a document in a work processor, or cause the margins to change size?
Yes, it would be nice to count on a relative width not changing if _only_ the height of the viewport changes. Really, I just feel it makes the browser look stupid.
...think about whether or not there's really any need to use frames to begin with. There almost always is not
Whoops. I think there may be a misunderstanding here. When I say "viewframe" I mean "the part of the page that you can see in the browser, bounded by what may or may not have scrollbar controls". I don't mean Netscape framesets, and I don't think anyone else in the Moz bug meant that.
Note that I only mentioned pixels in in my previous reply because there was a thread in the bug posting talking about how to paint the scrollbar on (or under) the content, and what width it would be (since it is absolute, and not affected by "normal" page mark-up). I certianly do not measure my pages to the pixel, and do not use pixels in my CSS. I use only percentiles and ems. No tables (for layout) and framesets.
I've pretty much made my case as best I can in other threads, so I won't go any further into this for now. Suffice it to say that I subscribe deeply to letting the page flow as it may. I also know that scrollbars will either be there, or not, and that we cannot count on it.
Actually, this is my main reason for disagreeing with the decision to WONTFIX for this bug. Having an application control affect content offends my sensibilities. I suppose having a hack like reserving the (again, I'm using absolute dimensions because it was mentioned in the bug) 10 pixels for the missing scrollbar, or having a greyed-out scrollbar, or painting the scrollbar over/under the content offends others' sensibilties.
I don't know what the solution is, but I do know that the current behaviour seems wrong. Minor, perhaps, but wrong.
While helping a non-designer friend make some personal pages she remarked, "why do the pages jump around so much", when going back and forth between some top-level centred pages (the problem is most obvious when you have a navbar at the top that is X% wide, and the width changes only when you navigate between long and short pages).
"That's a long story", I answered. And is certainly is.
I'm reasonably sure this is what has been said, over and over again. To be sure, the bug as posted was a misnomer. The original poster just knew something was wrong.
My point in posting was simple: in some very generalized cases, decisions about browsing behaviour have been arbitrarily made.
Perhaps it was a case of too many bugs in an inbox, or unclear explanation of the problem. There are example test cases listed that were submitted consisting of standards-compliant HTML that do the unexpected, with calm descriptions of the problem.
These voices of reason ended up being drowned out by the clamor on both sides of the "IEs permanent scrollbars suck!" argument.
Hello? HTML 101. The page width, and any other physical attributes of the output device, are unknown and unknowable. That's the entire point to the abstraction involved in HTML, as opposed to.pdf or something.
You don't have to shout, I can hear you just fine.
Seriously, you are making my exact point. This is why designers will use relative widths to ensure their content can be rendered nicely in a variety of interfaces.
My assertion is simple: the existence or non-existence of a height scrollbar should not change the relative width of the viewframe. The scrollbars belong to the application, and not the content. I don't know any designer or user who expects a scrollbar to cause a reflow of the contents, shortening or lengthening all responsibly stated relative widths by X pixels.
You are right: designers should expect the width and height to change. This why we have used percentiles to describe relative widths to make sure things flow nicely, regardless of the interface. Having a situation where the width changes on arbitrary changes to height is, IMHO, plain stupid.
Anyway, if the history of that bug, and the conversation threads here say anything, it's that this is not one of those cases where anyone is concretely "right" or "wrong". This is a usability issue, and I would challenge the Moz team (or anyone else) to submit this behaviour to a battery of real usability tests. If it was determined that the majority of users and designers don't mind how a good number of existing pages render, then I'd reconsider.
Lots of pages look better without the vertical scrollbar space.
...just as most pages render better without the viewframe width changing as content length changes.
Having the wdith stay the same as height changes so that CSS percentiles work as expected is not the same as always having a scrollbar. In fact, I'd say the majority of HTML will expect the right margin to stay put, regardless of the length of the page, given that most designers (rightly) let the height be "auto", but strictly control width. People hate scrolling sideways. They don't mind scrolling down. This is just good design.
So why not make the browser-specific property be the inverse? Why don't we assume that the scrollbar could potentially take up the 10 pixels (or whatever) on the right (or left!), and have a property to invert this for the pages that absolutely need those 10 pixels? Why can't those pixels be render transparently when the scrollbar is not there? I assert that this is the minority, and the norm is to expect to scroll through the height.
Plainly put, I argue that the scrollbar is not part of the contents, but part of the application, and as such, should keep it's bloody paws off my content.
Slashdot Mirror
<HOMER>Look at me! I'm surfing the net! And getting PAID. Woo-hoo!</HOMER>
If I do just a little more "research" for only one more hour, I can go for lunch!
Man, this is the truth. We need to start using crypto for everyday things, as well as the "important" stuff. It needs to be ubiquitous.
Though I agree in principle, the various SMB ports are near useless on so-called "high-speed" connections. There is just way too much broadcasting and redundant back-and-forth traffic that it's too slow to actually use.
It's also an inherently insecure protocol. I suppse one could port-forward via SSH (I have no idea, just musing out loud). Authentication will often fall-back to cleartext if the weak challenge-and-response fails.
I actually prefer that my provider block such ports on the wire. They did this mostly because new customers would fire up their boxes and immediately be able to browse (or be browsed) on the "Network Neighbourhood". The whole world is your "WORKGROUP"!
I have the feeling most people didn't know or care that they have such a thing available to them. At work, they may use "the network" but apparently they need no such thing at home and certainly don't want to know how to set one up (with any amount of security, anyway).
My guess is that only a few of us run an internal network that routes to a shared connection.
The problem, of course, is that blocking ports can be seen as the "thin edge of the wedge" in terms of providers slowly removing connectivity until we are all paying for a single port-80 connection to their proxy (complete with Carnivore) and maybe POP or IMAP. If you are lucky, and really ask nice.
"The Twirlip of the Mists doth protest too much, methinks."
Look, all you have to do is state your case. You don't have to get your knickers all in a twist. I, in fact, have never really given this all that much thought and don't really give a shit. You'll notice I haven't, in fact, been "protesting" about this at all. I posted exactly one reply to a single thread. Perhaps you have me confused with someone else.
And how have I been a smart-ass? Show me anywhere in my single reply where I was difficult or name calling or otherwise disrespectful? Now check your post. I'd be tempted to say that someone around here is acting the ass, and it sure isn't me.
Since you didn't state your sources, we only have your word to go on about the Intel issue. Assuming you are correct, you have made a compelling case (however, I'm not convinced that "Mac OS" itself could not have been enough of a trademark without having to rebrand). However, It's pretty clear that regardless of what Apple intended, there is enough semantic confusion to warrant criticism. Which was, in fact, the crux of my posting.
If you can't stand someone having an opinion about something, however misinformed that opinion may be, you are in the wrong place. If the slightest disagreement sends you off into vitriol and name-calling, perhaps you should reconsider how you spend your time here.
Install a sense of humour, willya. You are taking all this much too seriously.
Well, according to Apple, the name of the OS is "Mac OS Ten". As in one more than OS 9. I think a lot of people feel the "ten" part is redundant. That is, saying "Mac OS Ten ten-dot-two-two" is kind of lame.
Most folks I know either say "Mac OS ex ten-dot-two-two" or "Mac OS ten-dot-two-two".
The first is, according to Apple, incorrect. The latter is more natural. The recommendation by Apple is the last choice anyone wants to make. I don't think people care that much about it, but it is unnecessarily obtuse. It might have been more clever to brand the release "Mac OS X R2.2", or something.
Brands and labels are important. If people don't find the official way to refer to something easy, they will create their own, possibly varied, names.
As pointed out in this thread, there is no way anyone is going to say "Mac OS Ten Eleven Twelve" or "Mac OS Ten Eleven One Two" for OS X 11.1.2. Not without deep irony, anyway.
Then again, Apple may just be carrying on the tradition of naming UNIX releases with an unwieldy string of digits that get ignore ;)
[Mimes placing laptop computer over his head] You just lift the TiBook by the handle up over your head. Keeps you nice and dry!
Oh, I dunno. In the "smaller is better" game men like to play with their electronic gadgets, the iBook is pretty apropos. Apparently (the inverse) size does matter for notebooks, cell phones &etc. The marketing folks know we like these gadgets small.
The 12in. iBook is small and light, and fits nicely in a shoulder bag (sorry: a man purse).
With apologies to "Friends", or at least the only episode I watched all the way through.
This is handy for people who may not be in the mood (now, or ever) for such fare, but also helps against simple mistakes.
Note to self: "Urotsukidoji: Legend of the Overfiend" is not a first date movie.
Not sure what you mean, but I publish my iCal calendars to my WebDAV server all the time. This is actually unrelated to the iDisk-fake stuff in this article.
It's pure WebDAV, with a proper <LIMIT> section for the iCal directory. I can publish, and others can subscribe with iCal.
All done on an OpenBSD server.
The point is that you can use a local, non-routable IP address for a fake .Mac server (or any server, for that matter), and you do not have to pay for a publicly routable static IP. This seemed to be a point of confusion for the top post of this thread.
I wasn't indicating anything else in my reply. The exact range you use and how to use it is left as an exercise for the reader.
You don't need a static IP, or at least you do not need a routable one. Unless, or course, you intend to serve .Mac to a bunch of friends on different networks. The point of the article was to make a local .Mac-like server for iCal, and iDisk access.
Remember, you always have 10.x, 192.x and friends to play with all you want at home. This article interests me because I have a stable of Macs on my internal network. Implementing this means that it is trivial to get folks to do regular backups, publish calendars and such without having to install any new software.
It's all about leveraging existing Apple software with open standards.
I've seen the same thing. The latest "Queens of the Stone Age" locks up the iBook, but my two G4's have no problem with it.
Even a manual eject left the iBook in a state where it couldn't read any CD.
I'd love to apply this firmware update, but I've got a hacked firmware that makes the DVD player region-free. It also looks like nobody is interested in making a new region-free ROM image based on these latest firmware changes.
Ok, I'll let you get the last word in.
Err. Maybe not.
Ok, you win. I'm am trying to control the user agent. In fact, I'm trying to control all user agents, including the one you are using right now.
Seriously, I'm not missing anything, trust me. I've gone over this one-point-two million times, it feels like (once in the bug posting, once here). I'm not alone here. For every sane and logical argument you have for this decision, there are others with just as many sane and logical arguments counter to yours. You will ust never convince me that an applicaton control should effect the flow of content in this manner. It'll never happen.
I understand why this is happening, I just don't agree with the solution. I, in fact, don't have a solution, but probably would have chosen one of the other poor solutions.
This is one of those things we will have to just agree to disagree on.
Jim, the horse is dead.
How about fgrep, then? Far simpler syntax.
Sorry, couldn't resist.
*shrug* Meanwhile, I just added a "min-height" property to one of my container CSS classes (to fix a column flow problem if a left-hand column was shorter than the right) which had an unintended side-effect of forcing the scrollbar always on in most user agents.
A hack, to be sure.
I don't know about whether people prefer always-present scrollbars or not. I don't think anyone of us here are in a position to say for sure, as all we have are anecdotal evidence (as far as I know). I do know that one non-designer I helped with a web site noted that her X% wide centred (via generic CSS, not tables) pages would jump around during simple navigation in Mozilla -- activity where she would not expect the content to reflow. She's savvy enough to know that she can't count on a particular sized viewport, nor would she want to; but it is jarring for some users to see things reflow on a gesture they didn't expect. It's pretty common to toggle back and forth between top-level navigation to make sure you got all the text and links to match up.
What could I say? From an end-user perspective, Mozilla could look a bit broken. I'd say a good number of people I know have noticed it, and either hated it or chalked it up as a user agent difference.
As a developer, I spend a good portion of my life saying "that's by design" in response to a bug posting or feature request. Sometimes I have to accept that this may not be good enough for some users.
I personally don't see the problem with always-present scrollbars that are greyed-out if not in active (as per Internet Explorer). It's just an application thing I can live with. This seems to be one of those things that really attracts strong feelings, so I'm not going to suggest it as a solution. It would solve a boat-load of problems and (to my mind) doesn't really introduce any new ones.
Anyway, I'd say I'm really done on this subject. Obviously I have an opinion, but contrary to the volume of this thread, I don't mind all that much. If there was an O'Reilly book called "Mozilla Annoynances", I'd expect this to be in there.
I agree. The cable/satellite companies make it very attractive to overbuy, by making the discrete channels expensive and the packages cheap. They also tend to break the discrete channels into aggragate similar groups that you can't split up.
This means I can't easily assemble, for example, a group with a hockey channel, and not get the Golf Channel. Which means I end up paying for two channels I sometimes watch (NHL Channel) and one I never watch (Golf). The same goes for many other of my choices.
One criticism I have of the 1000 channel universe is that while I agree with splitting up some things into speciality channels, I think it's presumptuous to do so for other subjects. For example, in Canada we have a few digital music stations spun off of MuchMusic segments. I don't agree that one must listen to the same stuff all the time. I have a varied taste in music, and splitting the channels into an age or earning demographic is good enough for me. Instead, I have to decide whether I want MuchLoud, MuchGroove, MuchFoo or MuchBar (or all four).
The same goes for the movie channels. Sometimes I like "lost drive-in classics" and sometimes I like "independents". I either have to choose between them, or pay for both. I'm not saying there are not any general movie or music channels, but that I see a tendency toward more and more specialization until we might be coerced into buying more channels than we really want. I'd like the optin to underbuy and still get a fair amount of value. My back-of-the-envelope calculations show that pick and choosers like me pay almost 50-70% more.
This is all moot, I guess, since I'm leaning toward getting rid of cable altogether. The only reason I have cable now is for high-speed inet. As soon as I arrange a DSL connection, I imagine I'll cancel cable completely.
I've heard this explanation, and I understand that this is not a simple thing I'm asking. Then again, I don't have the solution, I just have a beef with the current behaviour. I guess the Moz team had three choices:
1. Add the scrollbar, having it take up viewport space, triggering a reflow because the width has changed
2. Always have the scrollbar take up the space (whether it is visible or not)
3. Paint the scrollbar over or under the content when necessary
So, they chose (1) as the most correct behaviour, and I can almost see why. I almost want there to be a 4th option:
4. Draw the scrollbar, or lack thereof, on the frame of the application, treating it like a toolbar or button bar.
This is obviously not optimal either, but I just don't like the current behaviour, and mostly because simple, well designed pages will cause things like navbars to move out from underneath the mouse point. I think this bug came down to whether you consider the current behaviour "correct", and whether you found any other solution "elegant". Of course, what one person things is correct or not is a bit of opinion.
I'm pretty sure this horse is dead, so I'll shut up now.
Well, we will just have to agree to disagree. I don't consider a scrollbar part of the content, and don't care if it is there or not. I object to an application control behaving as a CSS object.
I build pages that flow well in any reader, be it Lynx, screen readers or a graphical browser. I leave the flow up to the user agent.
It may be "logical" to you, but when I build applications, I tend to not have my application controls be part of the user's data.
I'm pretty sure this horse is well and dead by now.
I don't know how you are getting that from me. I'm the last to say I want an absolute width, and have made that clear several times. I am using percentiles to describe CSS objects which are floated left. This is pretty generic. I am not flaunting anything. I have no problem with the width changing if the container the text is in, or near, changes.
I can't put it any plainer: I object to the scrollbar, which is an application widget, counting as any width in the viewable contents of a page. If it was anything else, I'd be agreeing with you, but it is a scrollbar. I do not consider the scrollbar a CSS object around which I must flow my content. If you do, fine. This is what the bug is essentially about. Some agree, some don't.
It's pretty common to build a site with a common navbar across the top. If some of those pages happen to have a maximum height above the viewport, and some that do not, navigating between the pages does two major things:
1. Causes the right margin to jump by however many pixels the scrollbar is set to
2. Causes the hyperlink that the mouse pointer is currently under to move away from the pointer
This last is especially insidious. UIs where gestures cause controls to move away from the the pointer are just bad.
From a usability standpoint, I cannot agree that this is not a problem. Scrollbars are part of the chrome, and not the content. Gestures shouldn't move the UI around in unexpected ways. An interface that encourages this behaviour is flawed.
The first item just makes Moz look unpolished unfinished. It's a graphical browser, for crying out loud! It should look good.
It should be easy for designers to develop simple pages that do not violate good usability. It should be easy for Mozilla to render standards-compliant pages in a friendly manner.
Mozilla is the only browser that does this, AFAIK. This is not a user agent issue. It is an application issue squarely in the domain of the Mozilla presentation code. Just because we can access the application chrome with a URL doesn't mean we should, in this case.
Just to make it clear, I am not trying to establish an abolute size. I am not trying to enforce a particular width. I am objecting to 60% + 20% in a simple CSS property that is changing because of an application control, and not content. I have no problem with reflows being forced due to content changes. Scrollbars are not content. If you must disagree with me on this, so be it. Please do not conflate my issues with usability with any type of fixed or absolute positioning.
I can confirm that the firmware hack mentioned here works for me. Watched the Region 2 version of "Spirited Away" on an iBook. Even have the RGB to SVideo adapter so I can watch it on the big Sony. No 5.1 though :(
I've made my position clear in other posts in this thread, so suffice it to say that I will cheerfully agree to disagree. I reserve the right to complain about anything I like. This is the point of having an opinion.
I rely on relative widths because that is good practice. I simply disagree with having an application widget effect the flow of content. Having application controls affect page content is just bad design.
Minor perhaps, but bad nontheless. I don't see how anyone can consider that "expected behaviour".
There is nothing in the various specs about this because this is not a rendering or reflow issue, per se. It is about how an application decides the widgets and controls affects data. Would anyone expect the addition of a ruler or toolbar (without changing the size of the viewport) cause a reflow of a document in a work processor, or cause the margins to change size?
Yes, it would be nice to count on a relative width not changing if _only_ the height of the viewport changes. Really, I just feel it makes the browser look stupid.
Whoops. I think there may be a misunderstanding here. When I say "viewframe" I mean "the part of the page that you can see in the browser, bounded by what may or may not have scrollbar controls". I don't mean Netscape framesets, and I don't think anyone else in the Moz bug meant that.
Note that I only mentioned pixels in in my previous reply because there was a thread in the bug posting talking about how to paint the scrollbar on (or under) the content, and what width it would be (since it is absolute, and not affected by "normal" page mark-up). I certianly do not measure my pages to the pixel, and do not use pixels in my CSS. I use only percentiles and ems. No tables (for layout) and framesets.
I've pretty much made my case as best I can in other threads, so I won't go any further into this for now. Suffice it to say that I subscribe deeply to letting the page flow as it may. I also know that scrollbars will either be there, or not, and that we cannot count on it.
Actually, this is my main reason for disagreeing with the decision to WONTFIX for this bug. Having an application control affect content offends my sensibilities. I suppose having a hack like reserving the (again, I'm using absolute dimensions because it was mentioned in the bug) 10 pixels for the missing scrollbar, or having a greyed-out scrollbar, or painting the scrollbar over/under the content offends others' sensibilties.
I don't know what the solution is, but I do know that the current behaviour seems wrong. Minor, perhaps, but wrong.
While helping a non-designer friend make some personal pages she remarked, "why do the pages jump around so much", when going back and forth between some top-level centred pages (the problem is most obvious when you have a navbar at the top that is X% wide, and the width changes only when you navigate between long and short pages).
"That's a long story", I answered. And is certainly is.
I'm reasonably sure this is what has been said, over and over again. To be sure, the bug as posted was a misnomer. The original poster just knew something was wrong.
My point in posting was simple: in some very generalized cases, decisions about browsing behaviour have been arbitrarily made.
Perhaps it was a case of too many bugs in an inbox, or unclear explanation of the problem. There are example test cases listed that were submitted consisting of standards-compliant HTML that do the unexpected, with calm descriptions of the problem.
These voices of reason ended up being drowned out by the clamor on both sides of the "IEs permanent scrollbars suck!" argument.
You don't have to shout, I can hear you just fine.
Seriously, you are making my exact point. This is why designers will use relative widths to ensure their content can be rendered nicely in a variety of interfaces.
My assertion is simple: the existence or non-existence of a height scrollbar should not change the relative width of the viewframe. The scrollbars belong to the application, and not the content. I don't know any designer or user who expects a scrollbar to cause a reflow of the contents, shortening or lengthening all responsibly stated relative widths by X pixels.
You are right: designers should expect the width and height to change. This why we have used percentiles to describe relative widths to make sure things flow nicely, regardless of the interface. Having a situation where the width changes on arbitrary changes to height is, IMHO, plain stupid.
Anyway, if the history of that bug, and the conversation threads here say anything, it's that this is not one of those cases where anyone is concretely "right" or "wrong". This is a usability issue, and I would challenge the Moz team (or anyone else) to submit this behaviour to a battery of real usability tests. If it was determined that the majority of users and designers don't mind how a good number of existing pages render, then I'd reconsider.
Until then, I'm not convinced.
...just as most pages render better without the viewframe width changing as content length changes.
Having the wdith stay the same as height changes so that CSS percentiles work as expected is not the same as always having a scrollbar. In fact, I'd say the majority of HTML will expect the right margin to stay put, regardless of the length of the page, given that most designers (rightly) let the height be "auto", but strictly control width. People hate scrolling sideways. They don't mind scrolling down. This is just good design.
So why not make the browser-specific property be the inverse? Why don't we assume that the scrollbar could potentially take up the 10 pixels (or whatever) on the right (or left!), and have a property to invert this for the pages that absolutely need those 10 pixels? Why can't those pixels be render transparently when the scrollbar is not there? I assert that this is the minority, and the norm is to expect to scroll through the height.
Plainly put, I argue that the scrollbar is not part of the contents, but part of the application, and as such, should keep it's bloody paws off my content.