Do you really want the server to have to recalculate every time I change browser window size?
I don't know about you, but I don't resize that often. Do you have a rubber tablet on a bumpy road or something? Minor cost compared to net benefits.
If you need a static document, that's what PDF is for.
Not sure what you mean by static. PDF is still paper-centric and not designed for user interaction. Dynamic extensions are proprietary, I believe. But I'm open to the idea of expanding on the concept and/or making an OSS version.
Users actually like PDF's because they can create them via WYSIWYG editors and don't have to learn web design and "semantic encoding" to make a fricken page that renders as intended. Why should content writers all have to learn web design? Wasteful, dumb, illogical unless you are a web designer who wants job security for greed purposes.
Also, when I display something on my monitor, it isn't yours
Sorry, I'm not following what this is intended to communicate.
If you can't deal with this, get out of web design.
Per above, many want to, but our standards currently suck eggs, turning what should be simple content authoring into rocket science so greedy CSS/JS neckbeards have a job.
but they will be far more functional that you insisting the button must go right here on 1920x1080 and thus off the screen at 1024x760
You mean like a programming error? A programming error in the application or the server-side rendering library?
The first case (app error) would typically only happen if one chooses to use absolute coordinates and calculates them wrong in the app. One can also choose to use (mostly) absolute coordinates in a current browser and make the same error, I would note, and thus client-side rendering is not immune to the same issue.
You seem to assume one has to choose to program directly in absolute coordinates under my suggestion, which is NOT the case. The absolute coordinate thing is about what the server sends to the client for final rendering. The app dev doesn't have to do this themselves.
The second case (render library error) could also happen in a browser and/or client-side JS layout library. It's not immune either. If a client-side rendering engine can handle ALL dimensions than so can a server side one, if it knows the client screen size vertically and horizontally.
(Note I think it should have a fall-back/default mode, such as scrolling, if the client only wants to send the horizontal dimension of the screen.)
The difference between the two is that using server-side layouts/rendering engine, you are dealing ONE engine. With client side, you are dealing with hundreds layout/rendering engines. Most act mostly the same, but it's a big "mostly". You'd have to test on all hundreds, and that's before even considering multiple sizes.
[design for 3 sizes] And this hack is the problem.
It's only one option to consider. It's also an option with the current way of doing things.
[User-adjustable client-side MDI windows or slide panels could also be an option for more complex applications.] Not when you have an 800x600 screen and your window requires 1000 pixels at a minimum.
How is this diff from the fat-client way? Again, one doesn't have to program in absolute coordinates with server-side rendering. I see a lot alleged "responsive" pages that go kaflooey when re-sized certain ways. If you respond "the UI programmer is simply dumb and marked it up wrong", then the same applies to server-side UI codding. GIGO in both cases. The advantage of the server-centric way is that one only has to test one rendering engine to find such glitches, not hundreds.
As far as your "1000 minimum" scenario (assuming app dev choose to use absolute coordinates or the render engine has a bug), a good default overflow handling would be to have the client add scrollbars. It may not be optimal design, but at least use-able in most cases. I don't know how current browsers handle that, I haven't tested them all, but I believe most add scrollbars when out-of-range stuff is established. Same diff.
The fact that you only think this is only a vertical issue is kind of an indication that you haven't thought this through.
I'm just floating suggestions (no pun intended), I didn't say it was a vertical-only issue.
It seems like we'd have to consider specific design decisions (one model at a time) and discuss various specific scenarios with these to communicate our concerns (or lack of) more clearly. I invite you to think more about server-centric rendering and see if the hangups you have about it are INHERENT, or simply based on your current assumptions about how it would or can work. If you can prove they are inherent limits, drop me a line.
It's not really much different than what current browsers do, except we are shifting much more of the rendering processing load/burden to the server so that we can control the rendering more rather than rely on gajillion client variations that reinvent the wheel in hundreds of mutated ways. I'm tired of mutants.
Does the quota exception apply only to legitimate handles, or any handles? If the first, what if you start with legitimate handles and a user name expires? Does a message that fit before now not fit?
If the second case, @then @just @by @handlizing @all @words @you @indeed @could @send @yuuuuge @messages.
Because they're just getting raw graduates, absolutely everything is taught, such as how to dress, what language to use in front of customers, and a mini-MBA school.
It would be interesting to find leaked video of the courses. The snow-job lessons could be quite entertaining; a kind of Dilbert-based Cult.
The recording industry "studies" keep making this same "lost sale" fallacy over and over. People will often find alternatives or have no music track if you start charging such that you cannot convert usage to lost revenue 1-for-1.
There's plenty of free or at least royalty-free stuff. I post my own music for free even. (I don't claim it to be good, only to be free).
The fact they keep making this same fallacy despite pundits pointing out the error means they are either incompetent or bribed. I suspect the latter.
Our nation started out with very few Federal regulations on food, safety, and medicine. It was either assumed to be a state-level issue, or lawsuits were assumed to be the proper way to settle disputes between consumers and suppliers.
As mass manufacturing and cross-state commerce picked up, this gradually changed, often based on cases of nefarious practices. For example, law-makers realized it's not practical for the average consumer to test all their purchased food for pesticide residue.
What's that have to do with job merit? Sure, English language proficiency matters in the office and I don't dispute that, but you seem to be talking about OTHER things beyond language.
I haven't seen anything refuting my original point. I categorize English skills as a direct merit for the job. Music, food, history, sports, etc. should be moot to hiring decisions, but in practice it's not. Human habit is to hire people more like ones self.
Tape worms? Below is an article. Some researchers say the claims are dubious and that ads or labels mentioning tape-worms don't necessarily mean the pills actually contained tape-worm eggs. It could be a lie. But the fact some co's openly advertised it itself suggests lax regulation.
Commercial iPhones optionally take multiple exposures for a single "snap" so that one can skip blinking subjects, for example. Just do similar for exposure time.
And I realize suddenly replacing all that equipment would be quite expensive, but at least make the next batch of cameras better than the last batch so the ratio of good cameras in production gradually goes up over time.
the best person for the job regardless of race or gender is how it should be, nothing else.
I've been in the workforce long enough, including in interview panels, to know that raw merit is only half the game. Hiring and promotion decisions are largely social, especially when multiple candidates have similar merit credentials. Humans are social animals, and thus naturally biased.
and atheist (right and wrong aren't enforced socially in the same manner as Western countries)
Hogwash! For one, China is largely Buddhist (or variations of), not atheist.
Second, the USA started off industrialization in a similar poorly-regulated dog-eat-dog kind of way. Europe used to rib us about it. Poor people take more risks because they have less to lose. Read about "Muck Rakers". Tape-worm eggs were sold as diet medicine, for example, and nobody did anything about it.
How is that combo different for client-side-auto-adjust testing? Testing one rendering engine for many sizes is STILL going to be easier than testing many sizes for say 200 rendering engines (browser brands x browser versions x OS settings, etc.)
Roughly 1/200th the work.
Also note one doesn't necessarily have to have infinite combinations: they could design for 3 sizes: small, media, and large; showing the closest fit. Sometimes you want to control what's shown anyhow for diff devices. For example, you may want to show fewer graphics or thumbnails for smaller devices to save room (phones & watches) than for tablets and screens.
User-adjustable client-side MDI windows or slide panels could also be an option for more complex applications. The MDI windows themselves could optionally be managed client-side. Treat each sub-window/panel as a mini application, in terms of how the rendering happens. (It does complicate the client a little bit.)
And one could also let scroll-bars automatically appear on the client for the vertical issue, somewhat like typical PDF displayers. PDF layouts are typically coordinate-based, but a vertical scroll-bar appears if the window doesn't have enough room to the show the entire thing.
Models are used to harsh lights. They learn not to squint. It's part of their job.
The problem isn't tweaking the images, it's that there isn't enough information in the images.themselves.
If so, they need better cameras, such as cameras that take photos under multiple different exposures and/or has a high brightness sensitivity range. Software and/or remote human experts can then select the best exposure and/or tune levels. In the end you probably still need a human to adjust them; AI is still sketchy.
You didn't read the entire thing. The server CAN adjust the layout to fit different resolutions. The calculations are just done on the server, NOT the client (because clients do it wrong/inconsistent).
So many controls that get lopped off the screen or massive empty space because I dared to use the "wrong" resolution.
You didn't read the entire thing. The server CAN adjust the layout to fit different resolutions. The calculations are just done on the server, NOT the client (because clients do it wrong/inconsistent).
One thing that layout and UI designers miss about Flash is WYSIWYG. Web (non) standards display differently under different browser and OS brands, versions such that you either have to test under a gijjillion client variations, or live with rendering mistakes. I HATE THAT and it makes me scream bloody murder. I want WYSIWYG dammit! Even slashdot often gets it wrong, as menus overlap when they shouldn't, etc.
And WYSIWYG doesn't mean that you have to settle on one screen size, it just means that if you test under size X it renders the same way under a client set for size X. Essentially the server does any resizing so that one doesn't have to rely on an inconsistent client. The client just sends it's preferred screen size and the server renders it and sends "dumb" coordinate-based vectors back: no client-side auto flow or "float" shit. Floats can float up my ass; floaters are what you find in the john.
It's probably the dumbest invention I've seen in my many decades of IT. Great job security perhaps, but sucky productivity as we fight with the plague of fat-client versionitus. Makes DLL-Hell look good in comparison. Now we got Client-Hell.
Damned humans! Its like a mom or wife that randomly rearranges your room while at work or in the basement. Whoever invented auto-flow deserves to have wake up one day to find that one of their girlfriend's tits are on her crotch and another on her back, but her snatch is now where her nose used to be. Hell, the client-floaters probably WANT it that way, sicko Picasso pervs!
I hope something like Flash with WYSIWYG comes back, as an open standard. The schizophrenic client problem is the main reason PDF's still live. Managers, customers, and/or designers decide where the put stuff and it STAYS there; imagine that. It stays where they actually want it and you satisfy their request as they sketched it. No drifting, screwy overlaps, or surprises when browser version N + 1 comes out. It's like magic! Imagine a Beowulf cluster of shit that stays where you actually PUT it. Imagine all the people living in WYSIWYG harmony, like God, I mean the Matrix admin, wanted it. Shifty shifters go to the basement to be Picasso BBQ.
I'm still not following. Do you mean "racist software" in the literal AI sense that the software is thinking like a racist human being?
i mean that you need to have lights specifically for lighting their face.
You mean like a spot-light to the face? Then you get squinty photos. And awkward. One probably has to manually adjust the gamma levels instead, otherwise the background or clothing has too much effect on auto-adjustment. Either train the staff or have the photos sent to an adjustment lab to be tuned by experts (assuming it was taken with a camera good enough to capture sufficient details to be later extracted via gamma et al adjustments.)
Boss: Did it fry yet? Tester: No. Boss: Did it fry yet? Tester: No! Boss: Did it fry yet? Tester: No!! Boss: Did it... ~*KABOOM!*~ Tester: Can I have a vacation now?
Slashdot Mirror
I don't know about you, but I don't resize that often. Do you have a rubber tablet on a bumpy road or something? Minor cost compared to net benefits.
Not sure what you mean by static. PDF is still paper-centric and not designed for user interaction. Dynamic extensions are proprietary, I believe. But I'm open to the idea of expanding on the concept and/or making an OSS version.
Users actually like PDF's because they can create them via WYSIWYG editors and don't have to learn web design and "semantic encoding" to make a fricken page that renders as intended. Why should content writers all have to learn web design? Wasteful, dumb, illogical unless you are a web designer who wants job security for greed purposes.
Sorry, I'm not following what this is intended to communicate.
Per above, many want to, but our standards currently suck eggs, turning what should be simple content authoring into rocket science so greedy CSS/JS neckbeards have a job.
You mean like a programming error? A programming error in the application or the server-side rendering library?
The first case (app error) would typically only happen if one chooses to use absolute coordinates and calculates them wrong in the app. One can also choose to use (mostly) absolute coordinates in a current browser and make the same error, I would note, and thus client-side rendering is not immune to the same issue.
You seem to assume one has to choose to program directly in absolute coordinates under my suggestion, which is NOT the case. The absolute coordinate thing is about what the server sends to the client for final rendering. The app dev doesn't have to do this themselves.
The second case (render library error) could also happen in a browser and/or client-side JS layout library. It's not immune either. If a client-side rendering engine can handle ALL dimensions than so can a server side one, if it knows the client screen size vertically and horizontally.
(Note I think it should have a fall-back/default mode, such as scrolling, if the client only wants to send the horizontal dimension of the screen.)
The difference between the two is that using server-side layouts/rendering engine, you are dealing ONE engine. With client side, you are dealing with hundreds layout/rendering engines. Most act mostly the same, but it's a big "mostly". You'd have to test on all hundreds, and that's before even considering multiple sizes.
It's only one option to consider. It's also an option with the current way of doing things.
How is this diff from the fat-client way? Again, one doesn't have to program in absolute coordinates with server-side rendering. I see a lot alleged "responsive" pages that go kaflooey when re-sized certain ways. If you respond "the UI programmer is simply dumb and marked it up wrong", then the same applies to server-side UI codding. GIGO in both cases. The advantage of the server-centric way is that one only has to test one rendering engine to find such glitches, not hundreds.
As far as your "1000 minimum" scenario (assuming app dev choose to use absolute coordinates or the render engine has a bug), a good default overflow handling would be to have the client add scrollbars. It may not be optimal design, but at least use-able in most cases. I don't know how current browsers handle that, I haven't tested them all, but I believe most add scrollbars when out-of-range stuff is established. Same diff.
I'm just floating suggestions (no pun intended), I didn't say it was a vertical-only issue.
It seems like we'd have to consider specific design decisions (one model at a time) and discuss various specific scenarios with these to communicate our concerns (or lack of) more clearly. I invite you to think more about server-centric rendering and see if the hangups you have about it are INHERENT, or simply based on your current assumptions about how it would or can work. If you can prove they are inherent limits, drop me a line.
It's not really much different than what current browsers do, except we are shifting much more of the rendering processing load/burden to the server so that we can control the rendering more rather than rely on gajillion client variations that reinvent the wheel in hundreds of mutated ways. I'm tired of mutants.
Ultimately the browser guts translate ma
Does the quota exception apply only to legitimate handles, or any handles? If the first, what if you start with legitimate handles and a user name expires? Does a message that fit before now not fit?
If the second case, @then @just @by @handlizing @all @words @you @indeed @could @send @yuuuuge @messages.
The merge will be detected by LIGO.
It would be interesting to find leaked video of the courses. The snow-job lessons could be quite entertaining; a kind of Dilbert-based Cult.
The recording industry "studies" keep making this same "lost sale" fallacy over and over. People will often find alternatives or have no music track if you start charging such that you cannot convert usage to lost revenue 1-for-1.
There's plenty of free or at least royalty-free stuff. I post my own music for free even. (I don't claim it to be good, only to be free).
The fact they keep making this same fallacy despite pundits pointing out the error means they are either incompetent or bribed. I suspect the latter.
"I smell a troll" will be literal now.
AFTER the damage is done.
Our nation started out with very few Federal regulations on food, safety, and medicine. It was either assumed to be a state-level issue, or lawsuits were assumed to be the proper way to settle disputes between consumers and suppliers.
As mass manufacturing and cross-state commerce picked up, this gradually changed, often based on cases of nefarious practices. For example, law-makers realized it's not practical for the average consumer to test all their purchased food for pesticide residue.
What's that have to do with job merit? Sure, English language proficiency matters in the office and I don't dispute that, but you seem to be talking about OTHER things beyond language.
I haven't seen anything refuting my original point. I categorize English skills as a direct merit for the job. Music, food, history, sports, etc. should be moot to hiring decisions, but in practice it's not. Human habit is to hire people more like ones self.
What exactly is "refuse to assimilate"? Not eating the same foods? Not having the same religion? Not listening to the same music?
Tape worms? Below is an article. Some researchers say the claims are dubious and that ads or labels mentioning tape-worms don't necessarily mean the pills actually contained tape-worm eggs. It could be a lie. But the fact some co's openly advertised it itself suggests lax regulation.
http://www.philly.com/philly/b...
If you think goatse was nasty before...
Commercial iPhones optionally take multiple exposures for a single "snap" so that one can skip blinking subjects, for example. Just do similar for exposure time.
And I realize suddenly replacing all that equipment would be quite expensive, but at least make the next batch of cameras better than the last batch so the ratio of good cameras in production gradually goes up over time.
"1984"
I've been in the workforce long enough, including in interview panels, to know that raw merit is only half the game. Hiring and promotion decisions are largely social, especially when multiple candidates have similar merit credentials. Humans are social animals, and thus naturally biased.
Hogwash! For one, China is largely Buddhist (or variations of), not atheist.
Second, the USA started off industrialization in a similar poorly-regulated dog-eat-dog kind of way. Europe used to rib us about it. Poor people take more risks because they have less to lose. Read about "Muck Rakers". Tape-worm eggs were sold as diet medicine, for example, and nobody did anything about it.
How is that combo different for client-side-auto-adjust testing? Testing one rendering engine for many sizes is STILL going to be easier than testing many sizes for say 200 rendering engines (browser brands x browser versions x OS settings, etc.)
Roughly 1/200th the work.
Also note one doesn't necessarily have to have infinite combinations: they could design for 3 sizes: small, media, and large; showing the closest fit. Sometimes you want to control what's shown anyhow for diff devices. For example, you may want to show fewer graphics or thumbnails for smaller devices to save room (phones & watches) than for tablets and screens.
User-adjustable client-side MDI windows or slide panels could also be an option for more complex applications. The MDI windows themselves could optionally be managed client-side. Treat each sub-window/panel as a mini application, in terms of how the rendering happens. (It does complicate the client a little bit.)
And one could also let scroll-bars automatically appear on the client for the vertical issue, somewhat like typical PDF displayers. PDF layouts are typically coordinate-based, but a vertical scroll-bar appears if the window doesn't have enough room to the show the entire thing.
Just have "reverse mode" where the blocks fall up. "Sirtet"?
Models are used to harsh lights. They learn not to squint. It's part of their job.
If so, they need better cameras, such as cameras that take photos under multiple different exposures and/or has a high brightness sensitivity range. Software and/or remote human experts can then select the best exposure and/or tune levels. In the end you probably still need a human to adjust them; AI is still sketchy.
You didn't read the entire thing. The server CAN adjust the layout to fit different resolutions. The calculations are just done on the server, NOT the client (because clients do it wrong/inconsistent).
You didn't read the entire thing. The server CAN adjust the layout to fit different resolutions. The calculations are just done on the server, NOT the client (because clients do it wrong/inconsistent).
One thing that layout and UI designers miss about Flash is WYSIWYG. Web (non) standards display differently under different browser and OS brands, versions such that you either have to test under a gijjillion client variations, or live with rendering mistakes. I HATE THAT and it makes me scream bloody murder. I want WYSIWYG dammit! Even slashdot often gets it wrong, as menus overlap when they shouldn't, etc.
And WYSIWYG doesn't mean that you have to settle on one screen size, it just means that if you test under size X it renders the same way under a client set for size X. Essentially the server does any resizing so that one doesn't have to rely on an inconsistent client. The client just sends it's preferred screen size and the server renders it and sends "dumb" coordinate-based vectors back: no client-side auto flow or "float" shit. Floats can float up my ass; floaters are what you find in the john.
It's probably the dumbest invention I've seen in my many decades of IT. Great job security perhaps, but sucky productivity as we fight with the plague of fat-client versionitus. Makes DLL-Hell look good in comparison. Now we got Client-Hell.
Damned humans! Its like a mom or wife that randomly rearranges your room while at work or in the basement. Whoever invented auto-flow deserves to have wake up one day to find that one of their girlfriend's tits are on her crotch and another on her back, but her snatch is now where her nose used to be. Hell, the client-floaters probably WANT it that way, sicko Picasso pervs!
I hope something like Flash with WYSIWYG comes back, as an open standard. The schizophrenic client problem is the main reason PDF's still live. Managers, customers, and/or designers decide where the put stuff and it STAYS there; imagine that. It stays where they actually want it and you satisfy their request as they sketched it. No drifting, screwy overlaps, or surprises when browser version N + 1 comes out. It's like magic! Imagine a Beowulf cluster of shit that stays where you actually PUT it. Imagine all the people living in WYSIWYG harmony, like God, I mean the Matrix admin, wanted it. Shifty shifters go to the basement to be Picasso BBQ.
I'm still not following. Do you mean "racist software" in the literal AI sense that the software is thinking like a racist human being?
You mean like a spot-light to the face? Then you get squinty photos. And awkward. One probably has to manually adjust the gamma levels instead, otherwise the background or clothing has too much effect on auto-adjustment. Either train the staff or have the photos sent to an adjustment lab to be tuned by experts (assuming it was taken with a camera good enough to capture sufficient details to be later extracted via gamma et al adjustments.)
Boss: Did it fry yet? ... ~ *KABOOM!* ~
Tester: No.
Boss: Did it fry yet?
Tester: No!
Boss: Did it fry yet?
Tester: No!!
Boss: Did it
Tester: Can I have a vacation now?