Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Compatibility tables in the interim

8 views
Skip to first unread message

Eric Shepherd

unread,
May 27, 2015, 2:08:50 PM5/27/15
to dev-mdc [Docs]
So... we're in a weird spot. Our new compatibility database project,
with its sweet automatically generated compatibility tables is coming
sometime later this year.

But, in the interim, there's at least one major new browser (Microsoft
Edge) and several mobile browsers that may warrant coverage (Firefox on
iOS, for instance). Should we add these as new columns? Or should Edge
be treated just as if it were IE12 or so? Should we replace the existing
"Safari" column with a "Safari/Chrome/Firefox iOS" column? What should
we do?

I'd love to hear opinions on how we should handle this. I have my own
ideas, but I'd like others to input before I share, because I don't want
to bias things.

--

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy

Jean-Yves Perrier

unread,
May 27, 2015, 3:57:51 PM5/27/15
to dev...@lists.mozilla.org
Hi!

On 27/05/2015 19:08, Eric Shepherd wrote:
> But, in the interim, there's at least one major new browser (Microsoft
> Edge) and several mobile browsers that may warrant coverage (Firefox
> on iOS, for instance). Should we add these as new
Edge is not IE12. It has a different engine and both IE11 and Edge will
coexist on the same machine. Hopefully IE will go away, but we don't
know when.
Some features are available on IE11 and not in Edge. More important, for
some times, Web devs will likely test in both browsers. At some point we
will remove the IE column like we removed Netscape column, or the NES
information about JS. (With a DB, it will stay in it, but no more being
displayed in the pages)

So I'm strongly for a new column and handling Edge as a new browser,
like we did for Android Browser and Chrome for Android.

It will be easier to scrap too, btw.

> Should we replace the existing "Safari" column with a
> "Safari/Chrome/Firefox iOS" column? What should we do?
I think you mean on the mobile side here. Because on desktop the
question is void: Safari and Chrome, and of course Firefox, are
completely different beasts. Even Chrome and Opera are treated
differently (mostly for historical reasons).

On Android, between Chrome and Firefox for Android, no problem either.

The question is on iOS: Safari, Chrome for iOS, Firefox for iOS. One or
several? As I said in our last meeting earlier today, the key point here
is: are there browser features that could not be used in all three apps?
E.g. Is it possible to have Websocket enabled on Safari for iOS, but
disabled in Chrome for iOS and Firefox for iOS, or similar combinations?

If so, we need different columns; if not so, we can group the three in
one column, as filling one will fill all of them (doing it or not in
then a mere UX decision). Sheppy, you took the action item to get this
information so that we can decide.



--
Jean-Yves Perrier
Senior Technical Writer / Mozilla Developer Network


Eric Shepherd

unread,
May 27, 2015, 4:35:24 PM5/27/15
to Jean-Yves Perrier, dev...@lists.mozilla.org
Jean-Yves Perrier wrote:
> Edge is not IE12. It has a different engine and both IE11 and Edge will
> coexist on the same machine. Hopefully IE will go away, but we don't
> know when. [...]
>
> So I'm strongly for a new column and handling Edge as a new browser,
> like we did for Android Browser and Chrome for Android.
I personally agree with this, but I've had discussions with some people
who think that we should ignore that fact in order to simplify the
tables. Even so, I think we have to include both IE and Edge, at least
for a while.
>> > Should we replace the existing "Safari" column with a
>> > "Safari/Chrome/Firefox iOS" column? What should we do?
> I think you mean on the mobile side here.
Yes, of course; sorry for not being more clear.
> The question is on iOS: Safari, Chrome for iOS, Firefox for iOS. One or
> several? As I said in our last meeting earlier today, the key point here
> is: are there browser features that could not be used in all three apps?
> E.g. Is it possible to have Websocket enabled on Safari for iOS, but
> disabled in Chrome for iOS and Firefox for iOS, or similar combinations?
Apple can impose some restrictions on non-Safari browsers on iOS, even
though they're still using the same WebKit. In the past, they restricted
non-Safari browsers to running an older, slower JavaScript runtime. This
is no longer the case; in my tests here, Firefox iOS is running actually
slightly faster than Safari on the same iPhone 6.
> If so, we need different columns; if not so, we can group the three in
> one column, as filling one will fill all of them (doing it or not in
> then a mere UX decision). Sheppy, you took the action item to get this
> information so that we can decide.
I feel that the differences are minor enough that we can footnote a
single column. Browsers would have to actually intentionally cripple
themselves to have variation in Web tech functionality. The only thing
they can do is try to accelerate the operations external to the Web
rendering engine and JavaScript core.

Stephanie Hobson

unread,
May 27, 2015, 5:10:35 PM5/27/15
to Eric Shepherd, dev-mdc [Docs]
On Wed, May 27, 2015 at 11:08 AM, Eric Shepherd <eshe...@mozilla.com>
wrote:


> should Edge be treated just as if it were IE12 or so?


For display purposes in the compat tables, I think so. Devs are going to
think of it as the next logical extension. Caniuse is already treating it
this way. I suspect browser support contracts are going to treat it this
way. And I really don't want Microsoft to get twice as many columns in the
support table as any other vendor for the next 3 years :P

>From the API perspective, it should be a separate browser. (And that might
mean listing it separately temporarily so it can be scraped separately).


> Should we replace the existing "Safari [iOS]" column with a
> "Safari/Chrome/Firefox iOS" column? What should we do?
>

I like sheppy's idea of treating these 3 as the same browser in the API and
identifying differences in footnotes. We've moved away from naming things
after their engines though so I'm not sure what to call it.

S.

Chris Mills

unread,
May 28, 2015, 2:08:17 AM5/28/15
to Stephanie Hobson, dev-mdc [Docs], Eric Shepherd

> On 27 May 2015, at 22:10, Stephanie Hobson <sho...@mozilla.com> wrote:
>
> On Wed, May 27, 2015 at 11:08 AM, Eric Shepherd <eshe...@mozilla.com>
> wrote:
>
>
>> should Edge be treated just as if it were IE12 or so?
>
>
> For display purposes in the compat tables, I think so. Devs are going to
> think of it as the next logical extension. Caniuse is already treating it
> this way. I suspect browser support contracts are going to treat it this
> way. And I really don't want Microsoft to get twice as many columns in the
> support table as any other vendor for the next 3 years :P
>
> From the API perspective, it should be a separate browser. (And that might
> mean listing it separately temporarily so it can be scraped separately).

I am unsure about this. caniuse actually list it as "IE Edge”, which is just, um, wrong.

If we did list it as two separate columns, it would make more logical sense to me, although I am also cuting down on column numbers.

Is there an option for some kind of split column, which makes it clear they are separate browsers but still conserves space. The header could be something like “MS IE/Edge” (identify by vendor name, not just IE), and then we can list compat info as appropriate:

IE10, Edge
IE11, Edge
Edge only

Something like this would sit better for me.

>
>
>> Should we replace the existing "Safari [iOS]" column with a
>> "Safari/Chrome/Firefox iOS" column? What should we do?
>>
>
> I like sheppy's idea of treating these 3 as the same browser in the API and
> identifying differences in footnotes. We've moved away from naming things
> after their engines though so I'm not sure what to call it.

just iOS sounds ok to me - we should follow the existing convention of “Chrome for Android”, so “Safari/Chrome/Firefox for iOS”.

BTW, we probably ought to rename “Firefox Mobile” in our tables to “Firefox for Android” to avoid confusion and respect the convention, if we are not planning to do so already.

To help further avoid confusion, perhaps we could include a page somewhere on MDN that explains in detail the naming of the columns, for people to refer to if they are not sure.

Jeremie Patonnier

unread,
May 28, 2015, 8:47:29 AM5/28/15
to Chris Mills, Stephanie Hobson, dev-mdc [Docs], Eric Shepherd
Hi!

Regarding the IE vs Edge point: In a strictly data sens those are two
different browsers and should be stored in the database as two different
browsers. However, in a display point of view, I agree with Chris'
suggestion to merge their information to cut off the number of column.

For Safari on iOS, we could do something like "Safari & iOS Webview". As
such I think the "Android browser" should be rename as "Android Webview",
which is very different than Chrome for Android. However, as the Android
market is Highly fragmented, we should also be prepared to handle special
Android build as foot notes.

Best,
Jeremie
> _______________________________________________
> dev-mdc mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdc
> MDN contributor guide: http://bit.ly/ContributorGuide
> Doc project Trello board: https://trello.com/b/HAhl54zz/status
>



--
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>

Jean-Yves Perrier

unread,
May 28, 2015, 10:33:16 AM5/28/15
to dev-mdc
So we have consensus for Edge.

1. New column for the moment. Makes the scrapping easier, easier to put
info without losing info.
2. Storage as 2 browsers in the DB (only sane of doing it).
3. New widget: 1 column for the moment, we will see how it evolves
(there will likely be 2 rapid releases of Edge before we launch it, so
we will be able to revisit this if things change before we release the
widget second half of Q3 at the earliest).

For iOS, I like Jeremie ideas.

Cool
0 new messages