221–230 of 271 posts
Earlier quoted context omitted.
So that's why that happens. Why on earth would you break one of the most foundational aspects of HTML that way?
Yes what will they break next? Scrolling?! It's almost as though web devs enjoy reimplementing the browser in javascript...
Earlier quoted context omitted.
Not the file input button, unless things have changed in the last year since I had to build one. Other buttons, sure, but not on file inputs.
You realize you don't need input field for file input in any of the modern browsers. Just capture the click event and create input field temporarily. let i = document.createElement('input'); i.type = 'file'; // other attributes if you like i.onselect = ev => { // ev.files contains selected files }; i.click(); i.remove(); No stupid styling hacks needed. At most you may need tabIndex on the or that represents the butto…
You’ve just replaced them with stupid DOM hacks.
Earlier quoted context omitted.
Not necessarily: I do not want to click back 30 times to get out of your slideshow and back to my Google results. Thank you.
Your example is exactly why we have both History.pushState and History.replaceState [0]. The core question there is whether a new slide represents a new page or not. And in this case, I agree that it doesn't: it's the same page, just in a different state . EDIT: If you mean one of those 20-image slideshows intentionally made to create fake click statistics, I agree that that's absolutely infuriating. But in that case…
Broad support for history management is well-established at this point: https://caniuse.com/#feat=history
Earlier quoted context omitted.
It's such an extremely simple litmus test: if it breaks the back button of the browser, it's the wrong design. The closest thing to an exception being cases where one needs to be logged in to see a page, or when links are consciously invalidated for some other reason. And even then the website/webapp should still just signal this to the user without a bazillion redirects.
> It's such an extremely simple litmus test: if it breaks the back button of the browser, it's the wrong design. What if state should be destroyed when you press the back button? What if I open an image in a photo app, click a button to delete it, and go to a 'deletion successful' page. Should clicking the back button return me to a page containing the image? A page containing 'this image has been deleted'? The websi…
The web was not designed for such use, yet we continue to stretch and abuse whats there and wonder why most sites suck and get it wrong.
Earlier quoted context omitted.
I agree for cases where the text is supposed to behave like a hyperlink - it should be one. But in cases where its behaviour is that of a button (even a button which has the appearance of blue text - think iOS) then onclick is a good choice. Especially for contexts where “open in new tab” makes no sense. I can’t see any valid reason for using a void link - worst of both worlds?
Maybe a link styled to look like a button? I’d rather style the thing to look the way it should rather than apply unusual functionality to something.
Posted on Medium with a massive pointless image at the top and page loaded asynchronously using JS.
Ironically, a great illustration of why pictures are trash for explaining concepts outside of specific scenarios. What exactly is the picture trying to convey? How much time and how many bits did the picture take compared to the text? Thankfully, my eyesight works. But I’m sick and tired of designers pretending I’m illiterate and replacing text labels with inscruitable icons and graphics. Hey, remember when you could…
Earlier quoted context omitted.
> It's such an extremely simple litmus test: if it breaks the back button of the browser, it's the wrong design. What if state should be destroyed when you press the back button? What if I open an image in a photo app, click a button to delete it, and go to a 'deletion successful' page. Should clicking the back button return me to a page containing the image? A page containing 'this image has been deleted'? The websi…
which really cuts to the core of it: shoehorning something that should be its own app into a website -- all your above problems solved. The web was not designed for such use, yet we continue to stretch and abuse whats there and wonder why most sites suck and get it wrong.
Should I download a Wells Fargo app to my desktop, so that I can do banking with them? And a Google Docs app? And a Seattle City Lights app? Maybe a Progressive app, so I can manage my insurance policy? And one for the Washington DMV?
How many problems is running random binaries from random developers at those organizations going to give me? How much more expensive is it to develop apps, over websites? How will you make these apps run on Android, IOS, Linux, MacOS, and Windows? [1]
All of these websites have rich app-like functionality. The web was designed as a document store, yes. This is 2018, though - its not used as a document store. It's the place where I do my banking, my shopping, keep my spreadsheets, and make image macros. Turning all of that into non-web apps will just make development more expensive, degrade my user experience, and negatively impact my PC's security.
But hey, the upshot is that the sanctity of the back button will be protected!
[1] Maybe we could sandbox them... And have a cross-platform 'operating system'[2] where they can run. Maybe even have several such 'operating systems', with similar functionality, but built by different vendors. Vendors like Microsoft, Apple, Mozilla, and Google, maybe?
[2] We can even make this 'operating system' support opening static .HTML pages, so that we can 'browse' through them.
Earlier quoted context omitted.
Most operating systems have accessibility options to help with that. Consider helping your mother to use those, they exist for a reason. Punishing everyone just because a few folks need help is not the answer.
It's not punishing. It's inconveniencing at best. But flip the logic. Your inaccessible site, due to tiny unreadable fonts, is punishing everyone whose eyes aren't as good as yours, which is a lot of people.
Your mother is inconvenienced, we are punished. She only has to adjust one setting, where as I get no option.
And nobody is talking about tiny unreadable fonts, we're talking normal verses gigantic. If she can't read the normal OS font size, shes the problem and not the rest of us.
Earlier quoted context omitted.
Not the file input button, unless things have changed in the last year since I had to build one. Other buttons, sure, but not on file inputs.
You realize you don't need input field for file input in any of the modern browsers. Just capture the click event and create input field temporarily. let i = document.createElement('input'); i.type = 'file'; // other attributes if you like i.onselect = ev => { // ev.files contains selected files }; i.click(); i.remove(); No stupid styling hacks needed. At most you may need tabIndex on the or that represents the butto…