Over a million developers have joined DZone.

Platform-Specific CSS / Dodging Strategies

· Web Dev Zone

Start coding today to experience the powerful engine that drives data application’s development, brought to you in partnership with Qlik.

The range of css is rapidly branching. Where css used to be a simple language handling basic styling and positioning, it evolved into a mature and rich set of options ready to provide a wealthy user-experience. New modules and functionality are added on a monthly (maybe even weekly?) basis, but not all of these new properties are actually sound and solid. Lately a somewhat alarming trend is emerging and I believe it deserves some extra attention.

CSS and Standards

To be clear, this is not some kind of idealist discussion on the separation of content, styling and functionality. I'm not going to ponder the difference between several different css3 animation use cases (again). I think those who take their job serious already know when they are appropriate and when they need to switch to javascript. This new problem runs a little deeper than mere ideologies.

For years css has been plagued by browser inconsistencies (and if we're honest, they are still there even though their impact lies mostly with effect rendering rather than positioning and layout). Back in the day IE even had its own layout(/box) model which went right against the standards of the w3c. It took a long time to fix all that and to get all the browsers at least somewhat aligned. A process I'm sure nobody with a history in web design is willing to repeat.

With browser inconsistencies close to becoming a problem of the past, a new hurdle has popped up: OSes. With the introduction of mobile the influence of an OS on browser rendering became more and more apparent. We faced differences in font rendering (fonts look fatter on Mac) and form inputs before, but suddenly a whole new slew of changes introduced itself. Somewhat sneakily new css properties are finding their way into the css language (not the spec mind - they are still prefixed) in order to fix these specific platform or device quirks.

Case 1: Overflow on Mobile

A couple of weeks ago I finished my first big responsive project (tip: never trust browsers from the same families to act alike on mobile vs desktop). The site heavily depends on scrollable areas, but apparently scrollbars were not appearing on mobile. You could still scroll the areas, but there was simply no indication that the area was scrollable and no indication of how far you were into the content. Quick research online learned us that this is a common problem with a very convenient fix:

 {-webkit-overflow-scrolling: touch;} 

A true godsend because this immediately fixed all our worries on webkit-based mobile browsers (which is a clear majority on mobile). A feeling of sudden euphoria probably masks the doubts we should be having about using a property like this though. The bigger question here is why this basic (standard browser) behavior isn't working on mobile OSes. Apparently Apple had some good reasons to change the native behavior of scrollable areas (and thus the way the browser operates), but what if other OSes hadn't followed Apple's approach? Browsers now need to decide which css properties to pick based on what OS and device they are running on. This is clearly not a good move.

Case 2: Font-Smoothing on OSX

By accident I ran into a thread on font smoothing on the w3 mailing list. Apparently the font-rendering in OSX triggers a couple of issues in relation to css3 animation. What I got from the thread is that during the animation the font-rendering of the animated element is changed to another rendering mechanism, causing small but intrusive visuals jumps at the start and end of the animation.

No doubt this looks ugly, but is this really something that should be fixed with css? What if a third OS surfaces that comes with a new font rendering mechanism (and its own set of bugs)? Do we really need to write specific css rules to fix rendering issues on certain OSes? I do kinda sympathize with the fact that people are finding quick ways to solve these issues, but I pray properties like these (-webkit-font-smoothing) never make it into the final spec.


For now these properties are proprietary, meaning they can still be considered tryouts of quick-fixes until a better solution comes along. They do open a path to a future where people don't think twice about adding a css property in order to fix a platform-specific bug though, a future I rather not think about.

While I won't advise people to not use these properties (they are incredibly useful, even essential in some cases), I would hope that people involved with writing the css spec think twice before allowing such properties into the spec. I'm pretty sure the slippery slope principle applies to this situation and I for one am not looking forward to adding a bunch of css hacks in each and every css file in order to fix platform-specific rendering issues.




Create data driven applications in Qlik’s free and easy to use coding environment, brought to you in partnership with Qlik.


Published at DZone with permission of Niels Matthijs, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}