Target browser (browserslist)

[jer3m01]

css-prefix uses browser specific prefixes, unfortunately rome doesn't have an actual target browser implementation yet.

So;

• This implementation would be compatible with browserslist like strings.
• Would have a match (or similar) function to check if a browser matches the target.

How should we format a browser?
In a similar way to browserslist in a string "firefox 84" or an object with a browser and version property {browser: "firefox", version: 84}.

We probably should support browser list from both package.json and rome's config.

Internally it should be an array of whatever kind of format we chose. This would be cached someway so that repeated calls with the same target don't affect performance.

browserslist("last 2 versions")

[
    "firefox 84",
    "firefox 83",
    "chrome 87",
    "chrome 86",
    ...
]

[
    {browser: "firefox", version: 84},
    {browser: "firefox", version: 82},
    {browser: "chrome", version: 87},
    {browser: "chrome", version: 86},
    ...
]

Personally I prefer the object format.

As for the match function we could either check if an array contains another array of browsers or have a more complex design that also accepts an operator (before, after).

I think comparing two arrays would be simpler.

function match(target: BrowserListThing, query: BrowserListThing) {}

match(browserslist("last 5 versions"), browserslist("firefox < 82"));
match(browserslist("last 5 versions"), [{browser: "opera", version: 72}]);

We shouldn't support IE as it's pretty much deprecated.

The easiest way to store all existing browser version would probably just be an array of possible versions per browser. Although it would require us to update it on each browser release.

Any feedback is welcomed!

[ematipico]

So, here's what I have in mind about it:

• we should have a codec-browsers package, where we will create a small parser for the internal "syntax" to define the browser versions. (the possible custom strings that we decide to have, e.g. "last 2 versions");
• having a parser would allow us extend and make also our own syntax, generating diagnostics. provide possible fixes and warnings;
• we should support browserlist syntax because it would make it easier to use rome inside an existing projects;
• we should have a small "database" of all the browsers we support; in this database we should have all the features that a browser do/doesn't support. For example: transition might be unsupported in version X of a browser - so we have to prefix it - but when version Y comes along, transition is supported and we won't need to prefix it anymore

That being said:

• internal/codec-browsers
• internal/browsers-db
• internal/browser-features

internal/codec-browsers

The parser that understands the syntax a la "last 2 versions", "not dead", etc.

internal/browsers-db

We will store all the features that are supported/unsupported. For now let's just focus on the CSS part. One day we could add also web API (location, camera, notifications, etc.)

internal/browser-features

We could have an abstract class Browser and we will create new classes with all the information we need for specific browser

import { db } from "internal/browsers-db"

class Browser {
  constructor({ prefix }) {
    this.prefix = prefix;
  }
 

  get getPrefix() { return this.prefix; }
}

class Chrome extends Browser {
  constructor() {
    super({ prefix: "-webkit-" });
    this.cssFeatures = db.getCssFeatures("Chrome")

  }

  supportsFeature(featureName) {
     return this.cssFeatures.supports(featureName);
  }

 match(configMatch) {
   // check db and return value
}

}

This is something reaaaaally rough and raw. I just wrote down my thoughts

[jer3m01]

• we should have a small "database" of all the browsers we support; in this database we should have all the features that a browser do/doesn't support. For example: transition might be unsupported in version X of a browser - so we have to prefix it - but when version Y comes along, transition is supported and we won't need to prefix it anymore

We would need to find how to structure that data.
The easiest would be to copy it from https://github.com/mdn/browser-compat-data and have browser-features convert it a Browser instance.

That being said:

* `internal/codec-browsers`

* `internal/browsers-db`

* `internal/browser-features`

Nice to have some structure.

  get getPrefix() { return this.prefix; }

Some browsers have multiple prefixes. Opera used -o- in the early versions and switched to -webkit- later on. We could just not support the old one, would be simpler.

About that, (not 100% on topic) what's rome philosophy about feature support? Is rome aiming to be "modern" and only support current features or try to support every (including deprecated) features?

This is something reaaaaally rough and raw. I just wrote down my thoughts

This is a great start!

[ematipico]

Some browsers have multiple prefixes. Opera used -o- in the early versions and switched to -webkit- later on. We could just not support the old one, would be simpler.

The prefix could come from the database, so it will change based on the version of the browser.

[jer3m01]

Did some more research and browserslist uses caniuse-lite which itself is a stripped version of caniuse-db.

We should go the same route and generate our own data from caniuse-db using a script.

[jer3m01]

To do so we would have a dev dependency of caniuse-db inside the package.json of internal/browsers-db.

A generated-files script that would check the latest caniuse-db version and update the package.json. If there was a new version, generate updated data from fulldata-json/data-2.0.json.

Think we should have:

• browsers (except ie and edge pre chromium)
  • abbreviation
  • version
  • prefix
  • type
  • remove usage_global (each version also have the usages and are duplicates)
  • version_list
    • version
    • remove era (not sure what it does)
    • global_usage
    • release_date
    • if the prefix is an empty string remove the key
  • current_version
• data
  • only keep css features for the moment (categories: ["CSS"])
  • strip notes (not useful)
• region usage (from region-usage-json/<ISO>.json)

A few notes:

• supported features are marked as y, unsupported with n
• partially supported features are marked as a
• features requiring a prefix have x (usually y x)

[ematipico]

No dependencies, that's our mission. Instead, we could have a command that downloads that JSON file and creates a smaller version locally (inside the project). In this way, users can upload their DB without having to update Rome version (in case there are new features or new browser versions).

[jer3m01]

Of course, but what other way can we download that json except trough an npm download? Should we use raw.githubusercontent?

[ematipico]

Yes, why not? I don't see any problem doing so :)

EDIT: of course, as long as that is allowed by the license

[jer3m01]

EDIT: of course, as long as that is allowed by the license

Yep, it's under CC BY 4.0

[jer3m01]

Locking this as there doesn't seem to be a close feature for discussions and codec-browsers has been implemented.