Browser support

[Sander D]

Is there a list of Web browser versions that Closure Library intends
to support? I couldn't find such a list on code.google.com, but it
would be useful in order to decide whether it's fit for my project.
Thanks!

[Erik Arvidsson]

We do not have an official list. In spirit we follow Yahoos Graded
browser support

http://developer.yahoo.com/yui/articles/gbs/

On the top of my head:

Chrome 3
Safari 4
Firefox 3 and 3.5
IE 6, 7 and 8
Opera 10

Closure library also works in Firefox 2 and latest Safari 3.x but
these are non goals.

--
erik

[Dennis]

Does Closure Library support [the main] mobile browsers?

When I searched this google group and doing a general google search, it does not come up with much about this topic, so I assumed that there is no support.

Then, I tried 

https://google.github.io/closure-library/source/closure/goog/demos/editor/editor.html

on my phone.

The operations seem to work, but the UI is difficult because selecting text on my phone creates a copy/paste popup that blocks the toolbar.

Also, the size pull-down menu only works when the screen is zoomed out.

It might be possible to configure the editor so there is less interference with the mobile UI.

But before going down that path, I wanted to ask if there was any official stance on the topic -- it's a big question that is left unanswered on the web...

If the answer is "no official support"  or  "not recommended", then is there any roadmap for mobile browser support that can be shared with the world?

Or recommendations for editing for mobile browsers from the Closure Library group?

Thanks,

Dennis

[Nick Santos]

First, "Mobile Browser support in Closure Library minus goog.editor"
and "Mobile browser support in goog.editor" are two radically
different topics. It is likely that they will have completely
different mobile support guarantees.

It seems like you're mainly asking about goog.editor, so I'll answer
that question.

I do not speak for the Closure Library team, but I would personally
not recommend using goog.editor (or any ContentEditable-based rich
text editor) on a mobile browser. Historically, browser makers have
done a poor job figuring how how to make the contentEditable
input/selection APIs work well on mobile. For example, there was a
legit and serious argument that mobile keyboard events should never
have keycodes, because it plays badly with how virtual keyboards do
autocompletion, and that we should totally throw out current web
keyboard APIs in favor of something that was more well-suited to
autocompletion. As you can imagine, goog.editor is heavily reliant on
current keyboard APIs.

Instead, I've found it's usually better to fallback to plaintext
inputs and textareas on mobile. YMMV, I haven't looked into this for a
while, so my impressions might be out of date.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Closure Library Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to closure-library-d...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.