Just an FYI for everyone:  mobile browers really haven't been addressed at
all by me yet, short of the viewport improvement in 1.02.  The fact that
they work at all is simply up to whether the mobile browser translates
desktop-y things into mobile equivalents on a reliable basis.  So, it's
going to be bumpy deploying on mobile browsers until I actually start
testing EWB with them on a on-going basis and make the necessary adjustments
to the framework.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:
> Just an FYI for everyone:  mobile browers really haven't been addressed
> at all by me yet, short of the viewport improvement in 1.02.  The fact
> that they work at all is simply up to whether the mobile browser
> translates desktop-y things into mobile equivalents on a reliable basis.
> So, it's going to be bumpy deploying on mobile browsers until I actually
> start testing EWB with them on a on-going basis and make the necessary
> adjustments to the framework.

I hear you, but it is working pretty well so far. The only issue I've had
is an iOS 5 one, that is fixed in iOS6, and is generally an unfixable one
in plain javascript, so I'm not addressing it. If there was one thing you
could do, it would be to have an "arbitrary header" item for the html
output. Use at our own risk, but it would be nice to have. It could be
replaced later with a more polished tag/item/value thing, but a simple
string insertion would be a good step.

(Can you tell my main target is mobile? I've been testing on about 8
devices in the last few days, and bought a Nexus 7 just for this testing.)
--
Matthew Jones

>>I hear you, but it is working pretty well so far. The only issue I've had
>>is an iOS 5 one, that is fixed in iOS6, and is generally an unfixable one
>>in plain javascript, so I'm not addressing it. If there was one thing you
>>could do, it would be to have an "arbitrary header" item for the html
>>output. Use at our own risk, but it would be nice to have. It could be
>>replaced later with a more polished tag/item/value thing, but a simple
>>string insertion would be a good step.

Certain I agree that IOS support is pretty good (native controls aside). I also very much second the requirement to inject some additional header HTML info.

Matthew,

<< I hear you, but it is working pretty well so far. >>

Yes, absolutely.  I was speaking more to the iOS Safari mouse events issue
that showed up with 1.02.  It's caused by the way that Safari on iOS treats
elements that are clickable, and is completely non-standard.  It would have
been caught had I been testing on mobile browsers, but I'm not yet, so......

<< (Can you tell my main target is mobile? I've been testing on about 8
devices in the last few days, and bought a Nexus 7 just for this testing.)
>>

Good.  I'm building up a nice list of items to address for mobile
deployment, and that should allow me to bring the mobile platforms to full
functionality.

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<< Good.  I'm building up a nice list of items to address for mobile deployment, and that should allow me to bring the mobile platforms to full functionality. >>

Stop teasing me.