search

mdn / browser-compat-data

This repository contains compatibility data for Web technologies as displayed on MDN
https://developer.mozilla.org
Creative Commons Zero v1.0 Universal
4.98k stars 2.01k forks source link

Discussion: How to resolve Chromium true and null values #3561

Closed jpmedley closed 2 years ago

jpmedley commented 5 years ago

Pursuant to #3555.

At this point, I can write a nearly complete set of rules for version matching and I know exactly where the holes are.

Here's the holes:

This is going to make some people unhappy, but one solution to the webview problem is to stop trying to capture pre-Chromium webview and add '37' to any Chromium features that landed in Chrome Android before 37. In other words, restrict webview_android to refer only to Chromium-based webviews.

a2sheppy commented 5 years ago

This is going to make some people unhappy, but one solution to the webview problem is to stop trying to capture pre-Chromium webview and add '37' to any Chromium features that landed in Chrome Android before 37. In other words, restrict webview_android to refer only to Chromium-based webviews.

While I understand the rationale, it sure would be nice to find a better way. That's a lot of data we lose if we go that route. I won't fight tooth and nail on this one, but as most of us know, I'm big on having all the data available, and never getting rid of information.

If the BCD community and @Elchi3 are okay with it and Google is okay with it, then I suppose that's fine. But it would be excellent to come up with a better answer.

jpmedley commented 5 years ago

Google is ok with it. That's not the bigger issue. The bigger issue is that we have no way of verifying existing data or filling in the gaps and we're not going to spend money to do that for products that are no longer supported or soon will be.

a2sheppy commented 5 years ago

Google is ok with it. That's not the bigger issue. The bigger issue is that we have no way of verifying existing data or filling in the gaps and we're not going to spend money to do that for products that are no longer supported or soon will be.

Sure, I get that. That leaves us with two approaches:

  1. We decide we can't just ignore those versions. In this case, we need to determine what placeholder if any to specify in the meantime until such time as a contributor figures out the correct information and adds it, then make sure the presentation is useful in terms of explaining the versioning and why things are how they are (technology change, obsolete versions, etc).
  2. We decide to do what jpmedley suggests and limit webview_android to covering the Chromium-based versions. We decide on exactly how to present this (essentially as he describes above, probably) and move on.
  3. We decide to establish a "these versions may or may not exist but we do not cover them" data representation and/or presentation method.

While I prefer option 1 by a significant margin, it's not strongly enough to make a fuss over. Deciding between option 2 and option 3 is harder for me. I personally kind of feel that it would be more honest to devise a way to say "some versions in this range do exist, but no specific data is available."

queengooborg commented 5 years ago

Since this also applies to Opera, and soon Microsoft Edge, I think that something we should consider while coming to a conclusion regarding this is who uses the data, and for what purposes. Are we tailoring it to developers to provide better consumer experience on their websites? Or do the users of this data want the most robust data they can get? If it's the first, then most likely consumers won't be using pre-Chromium versions of Opera or Webview (and if they are, they must have heavily outdated hardware), and limiting the data to Chromium-based versions may be the way to go.

Personally, I'm leaning towards option 2 for the simple reason that pre-Chromium Webview is considered obsolete, and obtaining new data for its features does not sound like an option based upon @jpmedley's statement, though I'm skeptical about the removal of data for any reason. I don't feel strong enough about my choice to say that we have to do it that way, though -- whatever outcome is decided, I'll support. 🙂

Edit: looks like we've chosen option 1 with the inclusion of ranged values, which now that I look back at it, makes sense!

a2sheppy commented 5 years ago

Everyone that knows me at all knows I’m a big believer in having the most thorough data set possible. The notion of including the pre-Chromium Opera makes me all cringey. I can live with it for pre-Chromium WebView, since Google particularly doesn’t want that data out there, but I admit I personally wish it were otherwise. :)

On March 20, 2019 at 3:57:33 PM, Vinyl Darkscratch (notifications@github.com) wrote:

Personally, I'm leaning towards option 2 for the simple reason that pre-Chromium Webview is considered obsolete, and obtaining new data for its features does not sound like an option based upon @jpmedley's statement https://github.com/mdn/browser-compat-data/issues/3561#issuecomment-470572508, though I'm skeptical about the removal of data for any reason. I don't feel strong enough about my choice to say that we have to do it that way, though -- whatever outcome is decided, I'll support. 🙂

Eric Shepherd Senior Technical Writer MDN Web Docs https://developer.mozilla.org/ Blog: https://www.bitstampede.com/

jpmedley commented 5 years ago

If we remove the data, it won't be gone. If compat data were still wiki text, it would be. Anyone who wanted to resurrect old data from this repo would be able to check out a particular commit hash (git checkoutcommit-hash). We could add a git tag to make it easy to find the point to check out.

Regarding Microsoft, I had some discussions with someone from MS in January about what they're actually going to do. (I believe Chris was in the room.) It sounds as though they may need to treat their Chromium-based browser as a separate piece of software, at least for a while. I strongly suspect this has to do with enterprise contracts that specify Edge. At the very least this is something to check in to. If Chromium and non-Chromium edge exist side-by-side for any length of time, that makes following WebView plan difficult if not impossible.

a2sheppy commented 5 years ago

On March 20, 2019 at 4:14:18 PM, Joe Medley (notifications@github.com) wrote:

If we remove the data, it won't be gone. If compat data were still wiki text, it would be. Anyone who wanted to resurrect old data from this repo would be able to check out a particular commit hash (git checkout commit-hash). We could add a git tag to make it easy to find the point to check out.

That’s a fair point, although the data would not be easily accessible in a simple tool that uses a single source of truth. But that’s neither here nor there. This particular aspect of the discussion is pretty much over, so what we need to figure out is how to best flesh out the remaining data we’re missing.

Regarding Microsoft, I had some discussions with someone from MS in January about what they're actually going to do. (I believe Chris was in the room.) It sounds as though they may need to treat their Chromium-based browser as a separate piece of software, at least for a while. I strongly suspect this has to do with enterprise contracts that specify Edge. At the very least this is something to check in to. If Chromium and non-Chromium edge exist side-by-side for any length of time, that makes following WebView plan difficult if not impossible.

That sounds plausible. It’s how I’d do it in their shoes.

Eric Shepherd Senior Technical Writer MDN Web Docs https://developer.mozilla.org/ Blog: https://www.bitstampede.com/

Pankajkumarpathak25 commented 5 years ago

pankaj@pankaj:~/chrome/src$ autoninja -C out/Default chrome ninja: Entering directory `out/Default' [1/447] SOLINK ./libblink_platform.so FAILED: libblink_platform.so libblink_platform.so.TOC python "../../build/toolchain/gcc_solink_wrapper.py" --readelf="readelf" --nm="nm" --sofile="./libblink_platform.so" --tocfile="./libblink_platform.so.TOC" --output="./libblink_platform.so" -- ../../third_party/llvm-build/Release+Asserts/bin/clang++ -shared -Wl,-soname="libblink_platform.so" -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,defs -Wl,--as-needed -fuse-ld=lld -Wl,--color-diagnostics -m64 -Werror -rdynamic -nostdlib++ --sysroot=../../build/linux/debian_sid_amd64-sysroot -L../../build/linux/debian_sid_amd64-sysroot/usr/local/lib/x86_64-linux-gnu -L../../build/linux/debian_sid_amd64-sysroot/lib/x86_64-linux-gnu -L../../build/linux/debian_sid_amd64-sysroot/usr/lib/x86_64-linux-gnu -Wl,-rpath=\$ORIGIN -Wl,--gdb-index -o "./libblink_platform.so" @"./libblink_platform.so.rsp" ld.lld: error: undefined symbol: blink::FindColor(char const*, unsigned int)

referenced by color.cc:139 (../../third_party/blink/renderer/platform/graphics/color.cc:139) obj/third_party/blink/renderer/platform/platform/color.o:(blink::(anonymous namespace)::FindNamedColor(WTF::String const&)) clang: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed.

queengooborg commented 2 years ago

Since we've taken care of almost all true/null values for Chromium, and we have a mirroring script that takes these guidelines into account, I think it's safe to close this issue now!