Well I suppose I used the term “mobile” loosely. As a birthday present, recently, I got an Android tablet. It’s nothing top end, an Archos Arnova 10g2, but it has Android 2.31. For ---- and giggles I decided to check how some of the sites I have worked on looked on this thing and I was dismayed to see that “black lines” ( sometimes vertical sometimes horizontal ) were appearing in many pages ( not all)
sample link : I see a horizontal line through the text near the bottom (Bg image) another vertical lineadded to the right of the sample side of the sample pic (content IMG).
My observations indicate that these lines appear inconsistently ( some have it some dont) in at the right or bottom of images ( whether they are content or BG)… GIF/ JPG/ or PNG types.
My sites work perfectly on iPhones, iPad and my HTC HERO/ Android 2.1’s default browser. On the tablet, Opera Mini doesn’t exhibit this behaviour. Only the default “internet” browser and DolphinHD/Mini do this.
Is there some known issue I am missing? encoding type? Something?
A LOT of complex image structures built with techniques like sliding doors fall apart miserably on the auto-resizing in both webkit and opera. it’s why I usually strip out those types of images on my narrow screen overrides – but on the whole with such devices I gave up worrying about broken decorations as it’s an effort in futility given what total **** the browsers on such devices are.
*** please don’t take offense to the following, but…
The page you linked to? Embedding the CSS 1997 style for netscape 4 with an incomplete media set, split into multiple files just to make page loads take longer, the BS made up Adobe golive tag nonsense, ID’s on elements that should NEVER need ID’s (body and H1), 1990’s style onmouseover based menus, completely broken and nonsensical heading orders, clearing DIV, spans for nothing, and overall code bloat – along with the bloated redundant CSS that wastes time compressing everything into single lines without even attempting to use condensed properties…
I’d say a minor rendering issue in an obscure mobile browser are the least of the problems – I’m a bit shocked it doesn’t have bigger cross-browser issues. With the fixed width, fixed fonts, lack of mobile targeting, and on the whole decade out of date code it’s surprising that the other devices you listed are not having issues with it… though in the xCode iPhone emulator I’m running hackInBox (OSX under VirtualBox) it is in fact all screwy.
Much less the jpeg artifacts on those images (header/menu/sidebar) are disastrously bad.
No offense taken. The link given was my SECOND EVER CSS attempt. Yeah my code then was pretty bad.
I was just concerned because what I am seeing doesn’t ALWAYS seem to be related to sliding doors. For example , the sample item is merely an <IMG> yet it develops a vertical black line on the right. The issue happens in the simplest of code structures. That’s just 3 div’s containing 3 IMGS, for example… cant get more bare than that.
Another issue I discovered ( and improved coding practices ) happens here… where the textshadow is rendered as TEXT ( no blur) and offset… incredibly lower ( like if it were a headline for another section). But geez it’s only text-shadow.
I have noticed that turbo/light versions of any browser over compress images, it seems to me so Artifacts ahoy, but at least I know what happening there so it doesn’t irk me as much. I suppose what bothers me about this issue is that they work fine in android 2.1’s browser … why would they break on the NEWER 2.3? I guess after almost 3 years of trying to be a purist, I’d loathe to have to use js to detect mobile.
The page of just images is doing the same thing here in the xCode iPhone emulator… and goes away if I change the width on those images (in the file) to 368 px (the closest multiple of 8) – so I think the issue is their image resizer… the image renderer on these mobile devices SUCKS at resizing images, and usually you have to play with your widths to get those types of problems to go away…
Which generally goes back to making sure your images are an even multiple of 4 or 8 just like the old days when IE 5 under winCE had the exact same problem.
The iphone has similar problems with scaling background images and repeated background images and the fix is to add background-size which irons out the gaps. Maybe you could see if the same is works for your tablet but you’d have to use background images.
The state of mobile browsers is a bit of a mess at the best of times and I am reluctant to dip my toe in too deeply (especially as I don’t even own a mobile phone).
I am beginning to side with you on this , Paul. I just founded odd because I got a smart phone for myself year ago and never saw this problem in any of my work. I received the tablet as a surprise birthday gift, under the context that it would be easy to show off work on it ( literally their only consideration when choosing this device was screen size).
Still I was just surprised that the bugginess came not in the layout rendering but in the displaying of images.
DS60… genius as usual, I would have never thought of multiples of 8. That’s the oddest limitation I have even encountered, but at least now I know…
Wow I barely REMEMBER IE5… thanks for making my day
I am beginning to side with you on this , Paul. I just founded odd because I got a smart phone for myself year ago and never saw this problem in any of my work. I received the tablet as a surprise birthday gift, under the context that it would be easy to show off work on it ( literally their only consideration when choosing this device was screen size).
Still I was just surprised that the bugginess came not in the layout rendering but in the displaying of images.
DS60… genius as usual, I would have never thought of multiples of 8. That’s the oddest limitation I have even encountered, but at least now I know…
whoa! it double posted rather than edited my previous post. hmmm.
I ran a couple of extra tests and thought I would share my findings for anyone else who may find this thread useful.
Apparently the default rendering engine on Android 2.3.1 ( Opera Mobile seems unaffected by this bug to begin with) does not like when you optimize your images in Photoshop, which is sad because it makes for marginally smaller file sizes. I re-saved some of my test images , still using save for web but with “optimized” off and that did the trick on the JPGs even if their sizes weren’t “multiples of 8”.
Oh man, you slay me… Optimized… images… Photoshop… Bwahaha… RIGHT. Even odds that almost totally makes the biggest little files?
Side note – you might want to try loading it into PHP using GD and saving it out again… the GD module in PHP appears to make much smaller files than anything else with much less loss and/or artifacting – particularly if you’re talking jpeg.
Which surprised me it being better than PSP’s save-time optimizer, though I’ve noted a few times Gd’s optimizations can cause problems in IE 5.x and FF 3.5/earlier… like we give a flying fig about pixel perfect on those
Optimized… images… Photoshop… Bwahaha… RIGHT. Even odds that almost totally makes the biggest little files?
Hmmm w/o Save for web makes for the smaller files, in PS ( as opposed to just SAVE AS> file type: JPG) The optization option seems to shave 10-15% on most files, but of course that is comparing PS to itself. Really I haven’t found a better image editor; though it has let me down TWICE now. This and the way it handles PNG-24.
Side note – you might want to try loading it into PHP using GD and saving it out again…
I will try that… Thanks for the tip, DS
This is probably totally irrelevant, but I’ll throw it in anyway.
I was having problems with the W3C mobile validator, which was throwing a wobbly over some of my jpeg files. It was showing a “critical failure” of “The image does not match its supposed format.” As they were all jpegs and all taken on the same camera, I was flummoxed. However, I had used two different programmes to edit them, and one saved them as JFIF standard while the other saved as EXIF standard. The JFIF images passed the validation while the others did not.
Whether that was just a foible of the validator, or whether it is in fact relevant, I don’t know. If anybody else does, I’d be most interested.
I’d suspect either it is the type of JPG image as not all phones support the full features of that image format or the server wasn’t set to the serve the correct MIME type HTTP header so the Mobile OK Validator hit a snag. Else the image editor wasn’t saving the newer Exif correctly since its not an actual standard and a lot of propriety workarounds occur in many cameras apparently regarding Exif.
) happens 