|
down with slavery posted:http://caniuse.com/usage_table.php I really wish someone would make a site with aggregated stats on a per industry basis. For example, a site I maintain aimed mainly at scientists looks like this: code:code:code:These are all in more or less the same geographic area (which is usually the most granular information I've been able to find), but their stats are completely different. It's handy to have information like this, but in my experience it's hard to get ahold of unless you have analytics on an existing site in the same industry/region.
|
#
?
Oct 27, 2014 18:55
|
|
|
|
| # ? May 9, 2024 21:33 |
|
|
Yeah, there's really no such thing as "browser use statistics". There's only "browser use statistics of a particular industry". With that said, I oversee a website for a company that provides exam services for candidates in a wide variety of fields, so I feel the stats for this site represent a pretty well-balanced sampling of browser use. And right now the stats look like this: code:code:
|
|
#
?
Oct 27, 2014 19:05
|
|
|
caiman posted:Yeah, there's really no such thing as "browser use statistics". There's only "browser use statistics of a particular industry". Please don't get me started on poo poo like resolution ≠ viewport 
|
|
#
?
Oct 27, 2014 20:16
|
|
|
Speaking generally, if I'm starting a fresh project (and don't have to worry about meshing with existing style), and I have jQuert alongside a bunch of buttons and inputs, is it better to give each of those buttons an ID and then in my JS document ready function do $("#thing").on('click', myClickHandler), or is it better to do onclick="myClickHandler('foo')" in the HTML? EDIT: Thank you much. Duly noted. Jo fucked around with this message at 20:55 on Oct 27, 2014 |
|
#
?
Oct 27, 2014 20:50
|
|
|
Jo posted:Speaking generally, if I'm starting a fresh project (and don't have to worry about meshing with existing style), and I have jQuert alongside a bunch of buttons and inputs, is it better to give each of those buttons an ID and then in my JS document ready function do $("#thing").on('click', myClickHandler), or is it better to do onclick="myClickHandler('foo')" in the HTML? Very generally speaking, it's best to avoid inline JavaScript (your "onclick=" example) so that your content and functionality remain separate.
|
|
#
?
Oct 27, 2014 20:53
|
|
|
Munkeymon posted:Every time I think it's safe to stop caring about IE < 10 I get an email about a client using 8 or 9 and 
|
|
#
?
Oct 27, 2014 21:24
|
|
|
I didn't see a 'dumb css questions' megathread, so I'm hoping this is an OK place to post this. I've got a page that's basically this (simplified): code:On desktop browsers everything displays as expected ('word' is highlighted and the same font-size as the parent) but on mobile browsers (both Chrome and Safari) 'word' is a smaller font size than it's parent, but proportionally so, so the p mark is still smaller than the h1 mark. I've tried a million variations and keep getting the same result. Any thoughts? e; Same issue if I switch out mark for span or if I completely omit the mark font-size. blunt fucked around with this message at 00:57 on Oct 28, 2014 |
|
#
?
Oct 28, 2014 00:41
|
|
Try adding the following to your html's head element: code:
|
|
|
#
?
Oct 28, 2014 00:56
|
|
|
down with slavery posted:Try adding the following to your html's head element: Thanks, that worked! Weird, I never realised (lack of) viewports would effect css in that way...
|
|
#
?
Oct 28, 2014 01:00
|
|
|
I would like to "stream" a song in iOS Safari, while using as little memory as possible. My web page uses a great deal of memory already, and the client wishes a fairly long song to play in the background. (This is a promotional entertainment page, sort of like a video game.) If the song MP3 file is seven megs, I do not wish seven megs of memory to be used. Because iOS 7 Safari will crash at a fairly low memory limit, I would love to be able to 'stream' the song, as opposed to 'progressive download'. That is to say, I wish the buffer to only hold a small portion of the song at a time. (Whichever part is playing). So far I have found something called 'Byte Serving' for use with HTML5 ausio, and I it looks like HLS MP3 is even possible. Is there a good solution to my problem?
|
|
#
?
Oct 28, 2014 04:41
|
|
|
down with slavery posted:Try adding the following to your html's head element: You should not restrict users from zooming in and out on your website, drop the "maximum-scale=1.0, user-scalable=no" part.
|
|
#
?
Oct 28, 2014 08:29
|
|
|
Skiant posted:You should not restrict users from zooming in and out on your website, drop the "maximum-scale=1.0, user-scalable=no" part. What if it's a web app that you want to feel like a native app?
|
|
#
?
Oct 28, 2014 14:17
|
|
|
Captain Pike posted:I would like to "stream" a song in iOS Safari, while using as little memory as possible. https://developer.apple.com/library...eStreaming.html may or may not help you avoid hitting the memory limit. It's really up to the browser either way since it doesn't technically have to keep much of an MP3 in memory to play it back. You could also try messing with the https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement interface which might even be supported on iOS.
|
|
#
?
Oct 28, 2014 14:59
|
|
|
So I finally found a workaround for my css menu woes in iOS. Basically: $('.primaryMenu li a').on('click touchend', function() { window.location = $(this).attr('href'); }); Works perfectly with the exception that performing a drag over the menu causes an unintended navigation change. Seems to be a ton of articles out there explaining this iOS double-tap issue and various fixes, this is the only one that I've gotten to work. Strangely, most CSS hover menus work out of the box on iOS. I haven't been able to figure out what's unique to my menu that causes this bug, it's a pretty basic CSS menu. It's definitely caused by the '#menu ul { display none }' rule, as if I remove it I'm able to click the menus no problem, but of course you lose the whole dropdown aspect. I think I'm just going to live with the drag quirk. We don't get a whole lot of mobile users on this app and it's a pretty mild quirk. Still frustrating I can't get it perfect though.
|
|
#
?
Oct 28, 2014 15:33
|
|
|
Would thisCSS code:
|
|
#
?
Oct 28, 2014 16:22
|
|
Skiant posted:You should not restrict users from zooming in and out on your website, drop the "maximum-scale=1.0, user-scalable=no" part. Eh, I disagree. You should use CSS to make the website look appropriate on devices based on viewport width. There's really no reason to allow zooming and in many ways a user needing to zoom is a sign that you've hosed up your mobile site. That being said, there are some edge case accessibility issues where allowing zooming might be ideal. But if you're not using media queries and actively making sure you're dealing with things like text size appropriately then yeah, don't remove the ability for users to scale the site. down with slavery fucked around with this message at 17:18 on Oct 28, 2014 |
|
|
#
?
Oct 28, 2014 17:16
|
|
|
Munkeymon posted:Would this That just makes all the various dropdown menus visible.
|
|
#
?
Oct 28, 2014 17:17
|
|
|
down with slavery posted:Eh, I disagree. You should use CSS to make the website look appropriate on devices based on viewport width. There's really no reason to allow zooming and in many ways a user needing to zoom is a sign that you've hosed up your mobile site. That being said, there are some edge case accessibility issues where allowing zooming might be ideal. I mean, some people have poor eyesight or maybe fat fingers and will need to zoom in to read poo poo/make buttons bigger. What harm do you see in allowing a zoom? Taking away a default and expected feature that has real and, honestly, fairly obvious use-cases seems pretty stupid at face value.
|
|
#
?
Oct 28, 2014 17:33
|
|
|
down with slavery posted:Eh, I disagree. You should use CSS to make the website look appropriate on devices based on viewport width. There's really no reason to allow zooming and in many ways a user needing to zoom is a sign that you've hosed up your mobile site. Why would you restrict users from adapting the content to their own needs? It's the same idea as people realizing their superb pixel-perfect design looks botched as gently caress when people zoom in with their desktop browsers and throw a tantrum about how "users are stupid". Well, some people have bad eyes and want to read better. Some have 10/10 eyes and want to see as much content in a single page as possible. Throwing the "no zoom" meta is basically saying gently caress you to anyone who wish to read your content on their own terms.
|
|
#
?
Oct 28, 2014 17:35
|
|
The March Hare posted:I mean, some people have poor eyesight or maybe fat fingers and will need to zoom in to read poo poo/make buttons bigger. What harm do you see in allowing a zoom? Taking away a default and expected feature that has real and, honestly, fairly obvious use-cases seems pretty stupid at face value. Yeah, there are accessibility features in browsers that will allow users that have poor eyesight to change the behavior of their browser. It might be an expected feature, but the only reason (imo) that feature exists is because mobile sites are a relatively new thing and for many desktop sites it's simply necessary to use on a phone. If a user is pinching to zoom on your mobile site, chances are you've hosed something up w/r/t proper responsive design principals. Also, a big benefit you get is that you can now use the pinch to zoom feature to actually do more interesting things on your site with that gesture on mobile sites (for example on a recent site I did they had a huge explorable image where they wanted to use a google maps like interface to explore the image while retaining the scale of the rest of the site) Skiant posted:Throwing the "no zoom" meta is basically saying gently caress you to anyone who wish to read your content on their own terms. It's not though because browser settings overwrite your websites style. Beyond that, you should build your website around these use-cases. Like I said, the reason pinch to zoom exists is so that websites which aren't built for mobile can be used. That's why you don't see pinch to zoom as a feature in native apps. If you're developing a website for mobile devices from the ground up there's no good reason to allow that feature. down with slavery fucked around with this message at 17:41 on Oct 28, 2014 |
|
|
#
?
Oct 28, 2014 17:38
|
|
|
revmoo posted:That just makes all the various dropdown menus visible. Derp. OK, I'll just paste in from my CSS because the SASS plugin is better at translating than I am: CSS code:Mine has sub-menus, so there'll be some cruft to work around that left over, but basically I'm setting max sizes and disabling overflow instead of doing a display: none because I want to animate the expand/collapse which isn't possible with the display property. I also didn't have the same problem you had or if I did, I had it quite early on and forgot about it.
|
|
#
?
Oct 28, 2014 17:45
|
|
|
down with slavery posted:It's not though because browser settings overwrite your websites style. Beyond that, you should build your website around these use-cases. Like I said, the reason pinch to zoom exists is so that websites which aren't built for mobile can be used. That's why you don't see pinch to zoom as a feature in native apps. If you're developing a website for mobile devices from the ground up there's no good reason to allow that feature. Allow? Pinch to zoom is core browser functionality. You have to explicitly tell the browser to disable it. You have it exactly backwards: Instead of disabling zoom and "building around the use cases," you should leave it alone and think about why you would want to stop people from zooming.
|
|
#
?
Oct 28, 2014 18:15
|
|
|
Kobayashi posted:Allow? Pinch to zoom is core browser functionality. You have to explicitly tell the browser to disable it. You have it exactly backwards: Instead of disabling zoom and "building around the use cases," you should leave it alone and think about why you would want to stop people from zooming. Because it's almost always more annoying than a well-made responsive layout?
|
|
#
?
Oct 28, 2014 18:35
|
|
Kobayashi posted:Allow? Pinch to zoom is core browser functionality. You have to explicitly tell the browser to disable it. You have it exactly backwards: Instead of disabling zoom and "building around the use cases," you should leave it alone and think about why you would want to stop people from zooming. Because accidental pinches to zoom when you're using the pinch for other features are disruptive to the browsing experience. I'm aware it's "core browser functionality" but like I said previously, I also understand why said feature exists and can tell you that it's only a core feature because some websites require it (because mobile browsers came out before responsive design was really a thing in earnest). Like I said previously, if your users are pinching to zoom it's usually sign you've hosed up along the road of making your website (assuming you want to have a first class mobile experience, if not you shouldn't be messing with the viewport head tag) You also can still do things like pick up pinches on images to display the image in a larger fashion, there are ways to support scaling of the site that don't involve just letting the mobile browser do whatever the gently caress it wants with the display elements. See also: x-overflow: hidden on your body/html, no reason to let your users move left to right in a browser window on mobile either. Edit. also, regarding viewport tag: https://www.youtube.com/watch?v=DujfpXOKUp8&t=1435s you get a pretty heavy performance bump from removing that user-scalable as well down with slavery fucked around with this message at 18:46 on Oct 28, 2014 |
|
|
#
?
Oct 28, 2014 18:37
|
|
|
Munkeymon posted:Because it's almost always more annoying than a well-made responsive layout? If your "well-made responsive layout" is indeed made well, nobody's zooming it. There's no need to disable zooming. down with slavery posted:Because accidental pinches to zoom when you're using the pinch for other features are disruptive to the browsing experience. I'm aware it's "core browser functionality" but like I said previously, I also understand why said feature exists and can tell you that it's only a core feature because some websites require it (because mobile browsers came out before responsive design was really a thing in earnest). Maybe your layout has text so small that when I long-press a word to select it, I can only select the entire paragraph, and I'd like to zoom in so I can select more specifically. Maybe you won't be there to add yet another breakpoint when some goofy screen size comes out and now your responsive design doesn't look so great for me. Maybe you should reconsider overloading a fundamental gesture on everyone's phone. quote:Like I said previously, if your users are pinching to zoom it's usually sign you've hosed up along the road of making your website (assuming you want to have a first class mobile experience, if not you shouldn't be messing with the viewport head tag) I've had my fill of what a lot of people consider "a first class mobile experience". The least you can do is not seal my escape hatch. quote:You also can still do things like pick up pinches on images to display the image in a larger fashion, there are ways to support scaling of the site that don't involve just letting the mobile browser do whatever the gently caress it wants with the display elements. Unless you forgot about something like word-wrap or word-break and now content breaks out of its container except I can't possibly read it because I can't zoom and I can't scroll. Nailed it. quote:Edit. also, regarding viewport tag: https://www.youtube.com/watch?v=DujfpXOKUp8&t=1435s you get a pretty heavy performance bump from removing that user-scalable as well If you've profiled your site and figured out this is causing a big problem, then sure, maybe this is a worthwhile tradeoff. The problem is, the Gmail team figures this out by actually putting in the work and shares their findings, and now everyone does it because it's "faster" when their real problem is somewhere else. Your "first class mobile experience" is still slow, but on top of that now I can't zoom. Thanks?
|
|
#
?
Oct 28, 2014 19:01
|
|
|
Munkeymon posted:Because it's almost always more annoying than a well-made responsive layout? If you think responsive design somehow means you should disable zoom, you're doing it wrong. down with slavery posted:Because accidental pinches to zoom when you're using the pinch for other features are disruptive to the browsing experience. I'm aware it's "core browser functionality" but like I said previously, I also understand why said feature exists and can tell you that it's only a core feature because some websites require it (because mobile browsers came out before responsive design was really a thing in earnest). Phrases like "letting the mobile browser do whatever the gently caress it wants with display elements" read like a print designer spurned. The web is a fluid, dynamic medium. Give up your contrived notions of control, and the idea that you can predict every possible use case and context of use. By all means, use your analytics data to classify your device support priorities and define your breakpoints. Sweat the details of font choice, size and color, vertical rhythm, gutters and padding, line length, and so on, but at the end of the day, recognize that ultimate control rests with the user and their browser. Zooming and rotation and reader view and user agent stylesheets aren't vestigial annoyances to be worked around, they're an explicit acknowledgement that the user has the final say over how content should be presented.
|
|
#
?
Oct 28, 2014 19:02
|
|
Kobayashi posted:recognize that ultimate control rests with the user and their browser. Done that multiple times quote:Zooming and rotation and reader view and user agent stylesheets aren't vestigial annoyances to be worked around, they're an explicit acknowledgement that the user has the final say over how content should be presented. Nothing I've said will prevent you from using user agent stylesheets (which is what I would recommend for someone with accessibility issues, not living by the pinch). Zooming, rotation, reader view... not sure what you're talking about. It's about producing a user experience that is consistent throughout devices and browsers. pokeyman posted:If you've profiled your site and figured out this is causing a big problem, then sure, maybe this is a worthwhile tradeoff. The problem is, the Gmail team figures this out by actually putting in the work and shares their findings, and now everyone does it because it's "faster" when their real problem is somewhere else. Your "first class mobile experience" is still slow, but on top of that now I can't zoom. Thanks? It's a big problem for any site. A 300ms delay on any click is very noticeable on any site. The real problem isn't anywhere else, it's faster and provides a better experience on the web for your users. Yes, google did the research for us, now it's time to apply their findings to our websites. Kobayashi posted:If you think responsive design somehow means you should disable zoom, you're doing it wrong. 
|
|
|
#
?
Oct 28, 2014 19:07
|
|
|
down with slavery posted:Nothing I've said will prevent you from using user agent stylesheets (which is what I would recommend for someone with accessibility issues, not living by the pinch). Zooming, rotation, reader view... not sure what you're talking about. It's about producing a user experience that is consistent throughout devices and browsers. Sorry, where's the user agent stylesheet setting on my iPhone? I'm having trouble locating it. quote:It's a big problem for any site. A 300ms delay on any click is very noticeable on any site. The real problem isn't anywhere else, it's faster and provides a better experience on the web for your users. Yes, google did the research for us, now it's time to apply their findings to our websites. Why is that 300ms delay present in the first place? Why does it disappear when you disable zooming?
|
|
#
?
Oct 28, 2014 19:09
|
|
pokeyman posted:Sorry, where's the user agent stylesheet setting on my iPhone? I'm having trouble locating it. Don't have an iPhone, can't help you there. I'm guessing Apple has accessibility settings hidden in the OS somewhere that apply to Safari as well. Chrome's should be easy enough to find. quote:Why is that 300ms delay present in the first place? Why does it disappear when you disable zooming? Because of a double click to zoom feature built in to most browsers. Chrome will ignore that feature if you set user-scalable to no which means it won't wait 300ms to see if it's a double tap. The youtube video I posted goes into more detail.
|
|
|
#
?
Oct 28, 2014 19:11
|
|
|
down with slavery posted:Nothing I've said will prevent you from using user agent stylesheets (which is what I would recommend for someone with accessibility issues, not living by the pinch). Zooming, rotation, reader view... not sure what you're talking about. It's about producing a user experience that is consistent throughout devices and browsers. Zooming is pinch-to-zoom, i.e. what we've been talking about. Rotation is physically turning the phone, which also affects the viewport. I've seen sites try to hack around this behavior by insisting on one orientation or another. Reader view is an iOS feature that strips out site formatting and applies sane typography, good for listicle sites and sites that use bad typography. I include it as another example of a feature browser vendors have built to give the user more control. It's important to keep that in mind. People don't want "experiences" (visiting your site is not "an experience") that are "consistent throughout devices and browsers." That's the print mentality I mentioned earlier. People want content that is optimized for their particular device, be it an Android phone, an iPad, or a Windows computer.
|
|
#
?
Oct 28, 2014 19:17
|
|
|
pokeyman posted:If your "well-made responsive layout" is indeed made well, nobody's zooming it. There's no need to disable zooming. Kobayashi posted:If you think responsive design somehow means you should disable zoom, you're doing it wrong. We've all found a site that looks pretty responsive but if you accidentally scroll just a little too diagonally you find that some random thing has overflowed the intended page width and now you can 'zoom in/out' a whopping 2% or hide a column of text accidentally, which is just annoying and could have been elided if the dev had used that header instead of hoping his layout was universally correct, which is an insane assumption. I'd rather just slap a header on the page and save myself some frustration, but I also hate fighting CSS quirks. I guess if that's your bag, then cool, but good luck.
|
|
#
?
Oct 28, 2014 19:21
|
|
|
We should all internet petition Google to force native apps to force pinch to zoom because if they don't then they're literally hitler. I'm going to continue disabling zooming and building my apps to work without zoom. I think having a native app feel is more important.
|
|
#
?
Oct 28, 2014 19:23
|
|
Kobayashi posted:Zooming is pinch-to-zoom, i.e. what we've been talking about. Rotation is physically turning the phone, which also affects the viewport. Rotation is fine, your website should look great at 320px and 480px. Nothing we've talked about has touched on rotation and I'm not even sure you can restrict rotation behavior. quote:I've seen sites try to hack around this behavior by insisting on one orientation or another. Reader view is an iOS feature that strips out site formatting and applies sane typography, good for listicle sites and sites that use bad typography. I include it as another example of a feature browser vendors have built to give the user more control. It's important to keep that in mind. People don't want "experiences" (visiting your site is not "an experience") that are "consistent throughout devices and browsers." That's the print mentality I mentioned earlier. Yes, it is, if you're building anything other than a basic landing page. I'm sorry you don't like the language but your website is an experience for the viewer. And ensuring that experience is uniform not only is best practices, but is requested of pretty much every client I've worked with. quote:People want content that is optimized for their particular device, be it an Android phone, an iPad, or a Windows computer. Yes, this is exactly why I advise removing the built in browser features and DOING THIS YOURSELF as you will get a superior finished project.
|
|
|
#
?
Oct 28, 2014 19:24
|
|
|
I mean, how do you guys feel about things like http://necolas.github.io/normalize.css/ which explicitly overwrite browser defaults in order to provide a more uniform experience. edit. And yes, I know http://dowebsitesneedtolookexactlythesameineverybrowser.com/ is a valid position but it makes testing incredibly difficult down with slavery fucked around with this message at 19:28 on Oct 28, 2014 |
|
|
#
?
Oct 28, 2014 19:26
|
|
|
down with slavery posted:I mean, how do you guys feel about things like http://necolas.github.io/normalize.css/ which explicitly overwrite browser defaults in order to provide a more uniform experience. Design != functionality.
|
|
#
?
Oct 28, 2014 19:30
|
|
kedo posted:Design != functionality. Yeah, it's an absurd example, but it is a sacrifice in functionality (letting the user's browser determine how to display the content versus defining your own display) that we all agreed was in our best interest however many years ago. I imagine we'll look at browser functions like pinch to zoom (which I still believe only exists because of the need to display websites not optimized for mobile... soon to be archaic) in the same way in the future. Ultimately, it is just a CSS property (you don't need to use the meta tag... eventually) https://developer.mozilla.org/en-US/docs/Web/CSS/@viewport down with slavery fucked around with this message at 19:36 on Oct 28, 2014 |
|
|
#
?
Oct 28, 2014 19:33
|
|
|
Munkeymon posted:We've all found a site that looks pretty responsive but if you accidentally scroll just a little too diagonally you find that some random thing has overflowed the intended page width and now you can 'zoom in/out' a whopping 2% or hide a column of text accidentally, which is just annoying and could have been elided if the dev had used that header instead of hoping his layout was universally correct, which is an insane assumption. I'd rather just slap a header on the page and save myself some frustration, but I also hate fighting CSS quirks. I guess if that's your bag, then cool, but good luck. So someone else fucks up their implementation and you conclude that you should cripple your implementation by disabling zoom? I don't understand that mentality at all. down with slavery posted:Rotation is fine, your website should look great at 320px and 480px. Nothing we've talked about has touched on rotation and I'm not even sure you can restrict rotation behavior. It's the same kind of thing, disabling a native behavior for no good reason. Here's an example from WTF Mobile Web, which is a good Tumblr to follow if you want more examples of well-intentioned implementations that produce  results.
|
|
#
?
Oct 28, 2014 19:38
|
|
Kobayashi posted:It's the same kind of thing, disabling a native behavior for no good reason. Like I said, there are major performance boosts AND you can still use the pinch to zoom gesture for things like zooming on individual elements or increasing text size (based on where you pinch). I only advocate you remove user-scaling if you are going to take the time to ensure a first-class mobile experience, which is a bit involved these days (but imo should be done by anyone making a website thats going to be viewed on multiple devices) Regardless of whether "make the experience consistent" is a "print-media" era mindset, it's largely what you're going to here from your clients/users.
|
|
|
#
?
Oct 28, 2014 19:40
|
|
|
Brb y'all letting my grandmother know that she can't zoom on a website because disabling core features of her phone provides a more native experience and that all she has to do is override some settings in her user-agent stylesheet.
|
|
#
?
Oct 28, 2014 19:42
|
|
|
|
| # ? May 9, 2024 21:33 |
|
The March Hare posted:Brb y'all letting my grandmother know that she can't zoom on a website because disabling core features of her phone provides a more native experience and that all she has to do is override some settings in her user-agent stylesheet. If your grandmother can't read 16pt text, chances are she's using her phone's accessibility features, which propagate to the browser.
|
|
|
#
?
Oct 28, 2014 19:43
|
|