Will you implement feature X?


“I want Warhol to do X, when will you add support for that?”

Automated tests / CI #

  • Intent to implement: yes
  • Current priority: high
  • Current state: working prototype

Automated tests are definitely the next big feature we want to focus on after Warhol's initial release. Warhol's architecture has always been planned for automatic browsers that check hundreds of pages at dozens of screen sizes and we have a working prototype that can do just that. Getting this feature ready for public use will still require a lot of work, but this is work that we are absolutely committed to.

Support for more browsers #

  • Intent to implement: yes
  • Current priority: medium
  • Current state: it depends

We are well aware that Chrome is not the only browser and we definitely want to support and test more than just one platform! Warhol's core libraries (the code that analyzes pattern libraries and performs tests) are known to work on other browsers and hacks around browser-specific quirks that do not relate to Chrome are abundant in every one of Warhol's modules.

Supporting automated tests in more browsers than just Chrome should be relatively straightforward, but before this happens, we will have to launch automated tests in the first place. Supporting the browser extension in other browsers (primarily Firefox) should also be possible, but will require major effort.

Statistics and charts #

  • Intent to implement: yes
  • Current priority: high
  • Current state: concept phase

The results of automated tests will not just point developers to bugs they have to fix, but are also a rich source of insights into a project's state and progress. Turning this data into something digestible is a challenge, but it is a challenge that we are willing to face once automated tests are launched and have stabilized.

Interactivity (:hover and component states) #

  • Intent to implement: yes
  • Current priority: medium
  • Current state: implemented in bits and pieces

We want Warhol to analyze the entirety of your web page in one pass and this plan does include interactivity. Warhol must be able to predict that the styles in an element's :hover state are wrong without you (or the automated browser) having to actually trigger :hover state. This turns out to be possible, but has immense ramifications on everything. While states like :hover can be discovered from analyzing CSS, we will need to add configuration options to let you configure your own interactive states for components. Visualizing errors that are predicted to happen next to errors that already are visible is a major challenge, as is test performance and data storage for the vastly extended snapshots and test results. As a consequence we want to take it slow and roll out this feature in bits and pieces over time. Some parts have already been shipped - just not in a user-visible way, yet.

API access #

  • Intent to implement: yes
  • Current priority: mixed
  • Current state: concept phase

Everything in Warhol's architecture already revolves around a REST API, so making at least parts of this API accessible for users seems like a logical step. We feel that it is imperative that any user-facing API is rock-solid, well-documented and perfectly stable, which is why opening up the API will be a very deliberate and not particularly fast process. You can expect certain features, like a way to trigger automated tests, to appear sooner than later, but you should not hold your breath for full API access.

Is your feature missing? Le us know! #

We want your feature requests! Write an email to hello@warhol.io or tweet us at @wearewarhol.

See also #

Join our Slack Community

Any question not answered yet? You want to get the latest information on Warhol and discuss new features? Join our Slack Community.