PHP Meeting Recap – May 28th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • We started with discussing Trac ticket #43986 – Disable “Install Plugin” button for PHP required version mismatch and the currently posted patches. An immediate goal was to distill the different approaches we’ve been exploring so that the #design team can give specific feedback on these approaches, instead of only asking for general and vague “feedback”.
  • Questions we’ve distilled for that ticket:
    • Where does compatibility breakdown go: 1. under install button, 2. in bottom panel, 3. hidden away under “More Details” modal
    • Whether to show compatible/not-compatible state, or only show non-compatible state and stay quiet for compatible state
    • Whether to use (colorized) icons or not
    • Whether to show current/required version numbers or not
    • If both PHP and WordPress version are insufficient: 1. show both, 2. show only WordPress (easier to fix), 3. show only PHP (more problematic)
  • Both @afragen & @SergeyBiryukov had provided similar patches, which differed in their general approach of how to integrate into existing Core behavior: while @afragen added actions to make the new blocking functionality extensible, @SergeyBiryukov opted to hardcode the integration into the existing Core flow instead.
    After some deliberation, we decided to go with the hardcoded approach, to avoid introducing new actions (that are not needed for now) that would entail additional documentation, maintenance and backward compatibility effort.
  • @SergeyBiryukov stated that we could target 4.9.7 for this if we manage to get it ready soon.

Post-Meeting Updates

  • We agreed that, although we could filter out incompatible plugins, we prefer to show them with a disabled “Install” button, as this provides the incentive we need to encourage people to upgrade.
  • The #design team discussed the #43986 Trac ticket and provided some feedback. Mainly, the bottom area should be cleared and used completely for providing meaningful feedback if an “Install” action is being blocked.
  • @MelChoyce collaborated with @afragen directly to produce a new version of the patch that matches this #design feedback. This seems to be the screenshot that reflects the current state of the patch best:Plugin search result: "Incompatible plugin" error

Next week’s meeting

  • Next meeting will take place on Monday, June 4th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue work on the “Disable Install button” patch.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy, #summary

PHP Meeting Recap – May 7th, 2018

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

At this meeting there was some continued conversation around plugins & theme php version requirements (see parent ticket here)

  • @sergey has made some progress on technical restrictions
  • #design feedback will be needed as a part of implementing how restrictions are communicated to the user.
  • Initial goal for this is block installation of plugins in environments that don’t match php requirements for the plugin.
  • @flixos90 is going to get in touch with the design team regarding feedback on the mockups.

Also on the agenda was continued conversation around design/layout work for the PHP upgrade page. We took a look at this mockup that was done by @jaymanpandya, however for the most part we felt that in order to progress on this, the feedback needs to come from the #design team itself and those involved in the design of the overall site. To that end, @flixos90 has created a ticket in meta for tracking this and this is a callout to anyone involved in #design (and particularly with regards to the overall design of and how this would fit in with that) to review the current mockup and add comments.

Next Meeting

Next meeting will take place on Monday May 14, 15:00 UTC in #core-php


  • Followup on php requirement restrictions for plugins/themes (hopefully with some design feedback).
  • Followup on PHP upgrade page design feedback (if there is any).

PHP Meeting Recap – April 30th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • We first discussed whether we could have the current widget implementation backported to the upcoming minor release 4.9.6. @desrosj was positive about doing this, but left it open for a final review and someone with the willingness to actually commit it. One benefit would be to include this with the privacy policy changes, which has translators already be aware that a portion of new text strings need to be translated. Also, getting it in as soon as possible will finally allow us to get real feedback on its reception and effectiveness.
  • The “Upgrade PHP” information page needs a visual overhaul. It currently is a pure wall of text, and any change in that regard will be an improvement at this point. @schlessera will work on changing the page for a few quick wins to make it more digestible, and the discussion with the #design team needs to be relaunched.
  • As the first two components of the “Servehappy” initiative are now in a usable state, it is time to focus on the third component: enforcing the “Requires PHP” plugin header information.
  • There are several different mechanisms that need to be changed for enforcing the PHP version requirement, and we agreed to split the main ticket up into smaller subtasks so that blocking issues in one will not block progress in others.
    Here are tickets for the current subtasks:
    1. Disable “Install” (plugin) buttons – #43986
    2. Block updates to new plugin releases – #43987
    3. Allow filtering plugin searches by required PHP version – #43989
  • @afragen has already built a proof of concept that shows a basic implementation for blocking updates. This immediately points out a problem with the current API, which can only serve the plugin information for the latest release of a plugin. If we need to cycle to prior versions to do something like “find the latest version that still runs on PHP 5.2”, we’ll have to work on infrastructure changes as well.
  • Blocking updates does have security implications. We want to block updates to new versions that would bump the required PHP version past a version the server provides, but at the same time, we still want to provide the possibility for plugin authors to push security updates.

Post-meeting update

  • The Servehappy nag widget was not included in the beta of release 4.9.6. We should work on getting it backported early in the 4.9.7 release cycle.

Next week’s meeting

  • Next meeting will take place on Monday, April 7th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss how best to relaunch the #design process and go over the individual tickets for enforcing the “Requires PHP” header.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #summaries

PHP Meeting Recap – March 19th & 26th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

Chat log from March 19th
Chat log from March 26th

Chat Summary

Dashboard widget (#41191)

  • The voice of the widget text has been adapted to better match the overall WordPress feel.
  • The accessibility concerns that were raised have been addressed.
  • The widget currently looks like this:
  • The Trac ticket was flagged for ui-feedback and we are now waiting for the #design team to be able to go over the ticket. Once all of their feedback has been processed and incorporated, the version in trunk will be ready to discuss backporting it to the next minor release (4.9.6).

PHP version requirements for plugins & themes (#40934)

Next week’s meeting

  • Next meeting will take place on Monday, April 2, 2018 at 15:00 UTC in #core-php.
  • Agenda: [Go over #design feedback and] discuss how to proceed with plugin requirements.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #servehappy, #summaries

PHP Meeting Recap – November 6th

This recap is a summary of this week’s PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

The meeting’s chat log.

Attendees: @bpayton @flixos90 @jdgrimes @mte90 @nerrad @overclokk @psykro @schlessera @vizkr

Chat Summary

The agenda for this week was to review the suggestions @flixos90 has worked on for the “Before Upgrading PHP” section that is available in the Google document, taking the past weeks’ discussions into account.

As other important topics had come up after the agenda had been laid out though, the discussion ended up revolving around different topics, only taking a short peak at the document towards the end of the meeting. Here is the discussion summary:

  • @flixos90 shared some great news about the tool that the XWP team has been working on, which had been mentioned a few times before in other meetings: The tool automatically scans all plugins in the plugin repository for their usage of the WordPress coding standards and, more important for the PHP team, their compatibility with different PHP versions from 5.2 to 7.x. The project is going to be an official part of the repository, and all of this will be handled through an external API. The results of the scans will be displayed on the respective plugin page, and the PHP compatibility checker could leverage that data as well. The API will even be able to scan plugins and themes which are not part of the repository, by temporarily uploading them. This will allow to test even paid or custom developed plugins and themes. That part will not be exposed through any UI in the initial release, but it will be possible through the API.
  • @nerrad commented that this will likely require some changes on the Servehappy page copy that exists so far. These changes will likely be minor though and most importantly take away some points of uncertainty that with that tool at hand won’t matter anymore.
  • It would make sense for the PHP Compatibility Checker to leverage that API, so it needs to be discussed with the responsible people at WP Engine what steps should be taken here. The new API could either be used in addition for more accurate results, but it may possibly even be better to replace the current mechanism with it entirely, as it would improve speed significantly because it could in many cases use data that has already been gathered before rather than running the expensive checks on the server.
  • The above two topics should be discussed in detail once the API has been officially released to the public.
  • @psykro asked whether it would be possible to change the meeting time or host a second meeting. Everyone who responded was open to a change, however it should preferably remain close to when it’s currently scheduled (every Monday at 19:00 UTC). If you are interested, please leave your vote(s) on this Slack post.
  • @mte90 asked about the new plugin headers for a minimum required PHP version and specifically about when the integration with core for it should be developed. While core should not include any PHP-related notices or warnings until the Servehappy page is published, it makes sense to start work on it before. This will not be a major topic for the PHP meetings for now, but should mainly happen in its Trac ticket #40934, unless a rather complex topic comes up which would benefit from a discussion in a meeting. @psykro, @schlessera and @mte90 expressed their interest in working on this. Mockups for the visual side of things should be created early, and the #design team should be asked for help with this. Since the project will likely involve quite a bit of code and it’s not optimal managing this solely through Trac, it was suggested to go either with a plugin-first approach or use a GitHub fork of the WordPress development repository.
  • After that, attendees started reviewing the sections in the Google document and added some comments and suggestions. @nerrad highlighted that the last section about contacting a developer should only be targeted at those site owners that already have an ongoing relationship with one, or at least already know one. People who have never hired a developer are unlikely to do so for a “random” PHP upgrade. More in-depth review and discussion on the Google document was postponed to next week’s meeting.

Next week’s meeting

The next meeting will take place on November 13th, 2017, 19:00 UTC as always in #core-php, and its agenda will be to actually review the initial suggested copy for the “Before Upgrading PHP” section so that it can be passed on to the marketing team afterwards. If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account. See you next week!

#core-php, #php, #summary

Customize Meeting Summary: September 25th

This post summarizes the Customize meeting from September 25th in the #core-customize Slack channel (Slack archive).

Participants: @westonruter, @melchoyce, @obenland, @sirjonathan, @joemcgill, @sayedwp, @jbpaul17. Misbehaving: @tracbot.

Discussion highlights

Drafting and Scheduling

Gallery widget

Customizer UX for themes

Bug scrub

  • Trac listing of the enhancements and feature requests milestoned for 4.9 for the team
  • #39930: docs changes, so changing this from enhancement task ticket
  • #28721: related to and will be resolved when #39896 is merged
  • #34843: will be resolved by #37661
  • #35827: no one working on this, so punting to Future Release
  • #40527: punting
  • #40922: punting
  • #37964: will be picked up by @sayedwp when #39896 is done
  • #38707: CSS highlight part is implemented, but “revisions, selection, per-page, pop-out” is not
    • “per-page” aspect has been yanked from consideration in the near future
    • will work on revisions, selection, and pop-out in a feature plugin outside of core
  • #39275: likely to be resolved in #39896
  • #40104: @bpayton hopes to have a patch up by Friday
  • Topic for future devchat: What is the difference between a feature request and a feature project. It’s not really formalized. Are we deeming “feature request” to be the same as “feature project”?

Next week’s meeting

The next meeting will take place on Monday, October 2, 17:00 UTC in the #core-customize Slack channel. Please feel free to drop in with any updates, questions, or tickets you’d like to discuss. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-customize, #summary

Editor Experience Survey

As you’re well aware, a project is underway with the focus on redesigning the editing experience in the wp-admin. As the project moves forward, a better understanding of how WordPress users actually feel about the editing experience is needed. Please take a few minutes to fill out this survey and help influence the future of your favorite CMS, WordPress.

Survey Link:


#core-editor, #design, #survey

Dev Chat Summary: September 28 (4.7 week 6)

This post summarizes the dev chat meeting from September 21st (agenda, Slack archive).


  • Schedule: We are 3 weeks from the final chance to merge in major features. This includes Twenty Seventeen.
  • Tickets: There are currently 196 tickets in the 4.7 milestone. This is 14 more than last week. In just 6 short weeks, this needs to be zero. For any tickets you’ve moved into the milestone, please make sure these are active tickets, with some kind of activity in the last 10 days.
  • Bug Scrubs: We’re looking for people to help run a bug scrub, please reach out to @jorbin if you have interest (details here). Bug scrubs this week plus one on Monday and one on Wednesday next week at yet to be scheduled times.

Components & Features

  • Twenty Seventeen (@davidakennedy, @melchoyce)
    • Latest update
    • Add multi-panel feature to pages through add_theme_support (#37974) & Enable Video Headers in Custom Headers (#38172) need eyes and help the most
    • Additional i18n eyes on Better support for non-latin font fallbacks especially designers who use non-latin alphabets natively to hear suggestions for non-latin font stacks that would look good in the theme
    • Next meeting Friday at 18:00UTC (theme-focused), Tuesday (feature-focused)
  • Media (@mikeschroder, @joemcgill)
    • Latest update
    • Unexpected change to media title behavior in WP 4.6.1 (#37989) – Looks like @sergey added a patch that fixes the remaining issues with some UTF-8 characters. Should be committed soon.
    • Media search doesn’t include file name (#22744) – The current implementation is trampling any preexisting JOINs. Should have a patch a new patch ready to test soon.
    • Also looking at pursuing additional media organization improvements through a feature plugin, details still need discussion, @karmatosed on board to help with design
    • Next meeting Friday at 17:00 UTC
  • Customize (@westonruter, @celloexpressions)
    • Latest update
    • Primary commit for Harden panel/section UI code by removing contents from being logically nested (read: goodbye margin-top hacks) (#34391) is in, and a dev note is scheduled to be published after today’s dev chat
      • Some major changes here, so we need plugin and theme authors to test
    • Received design feedback on A New Experience for Discovering, Installing, and Previewing Themes in the Customizer (#37661) and working on making those revisions by the end of this week and planning to publish a feature proposal on Friday
      • Need to discuss themes again during tomorrow’s #design meeting for final approval before the changes are made
    • Need attention on Provide a better gateway for code-based theme customizations with the Customizer (#35395)
      • Discussion of whether this direction is appropriate lead to tentative consensus that this is likely appropriate for core
      • Next steps will be to loop @folletto in to improve the design and polish up the patch
      • Big other block discussed: sanitizing and validating the CSS & most appropriate corresponding capability
        • Currently rudimentary validation in the patch for balanced braces and comments. Need improvement if relying on it heavily, but it provides instant user feedback
        • Capability solution needs to work for multisite if at all possible, since that’s a primary use case
        • Discussion to continue on the Trac ticket and/or #core-customize
  • i18n (@swissspidy)
    • Feedback/help on Introduce a locale-switching function (#26511) would be appreciated
      • The problem is that labels of custom post types and taxonomies are only evaluated once, so switching locales wouldn’t properly translate those.
      • There’s a proposed fix for built-in types and taxonomies, but we prefer a better solution that works for all of these.
  • Editor (@azaozz, @iseulde)
    • Would like to help with a survey (scratchpad/draft). Need to start gathering user usage stats, should be opt-in, start with a plugin first, and release the aggregated data
    • Weekly data tracking (back-end) meeting Wednesday at 1900 UTC
  • HTTPS (@johnbillion)
  • REST API (@krogsgard, @kadamwhite )
    • Latest update
    • Whether the API should follow core behavior and save a revision every time a post is updated
      • Right now every update to a post creates a revision and can be a bit painful for some clients, so: 1) should that always happen? 2) should we have the ability to turn it off?
      • Decided on: 1) Yes.  2) The ability to use auto-drafts like in core makes sense, but doesn’t need to block merge.
    • How to handle image permissions, specifically for the case where an image is attached (uploaded) to a private post and then featured in a public post
      • Specifically, if I upload an attachment to a private post, its visibility is governed by that post, so it too is private but, in wp-admin I can add it as featured media to another public post. When that public post is queried: what happens!?
      • @joemcgill summary: I happen to think it’s an oversight in WordPress that we allow an image attached to a private post to be set as the featured image of another post (and by an author without permission to view the private parent post). We should probably either close this loophole or detach the attachment from the private post whenever it’s set as a featured image on another post.
      • @kadamwhite to document decision, @rmccue @joemcgill @helen et al will identify core tickets that should be opened.
    • Whether (and how) to expose edit locks through the API
      • Main thing here is whether this is a blocker? Decision: edit locks are great, but doesn’t need to block merge.
    • Next bug scrub is Thursday 1400 UTC; next team meeting is 1400 UTC on Monday, October 3rd

#4-7, #core, #core-editor, #core-http, #core-i18n, #core-media, #core-restapi, #dev-chat, #summary, #twenty-seventeen

Dev Chat Summary: September 21 (4.7 week 5)

This post summarizes the dev chat meeting from September 21st (agenda, Slack archive).


  • Schedule: As of this meeting, we are 4 weeks from the final chance to merge in major features. This includes Twenty Seventeen.

Bug Scrubs

Components & Features

  • Twenty Seventeen (@davidakennedy, @melchoyce)
  • REST API (@krogsgard, @kadamwhite )
    • Latest update
    • API discussion is at 7 am Pacific on Mondays
    • Settings endpoints and meta support both have first-passes on them, which need internal review and some more testing before we ship
    • We have a path forward for passworded posts (password in the query string, eww, but only viable option), there really isn’t a way we can see to avoid sending them as a query param
    • Meeting tomorrow in #core-restapi at 21:00 UTC to go through open issues around non-trivial, conceptual issues in WordPress. REST API team will prepare summary of issues for component maintainers and/or lead devs to review, question, and help guide discussion towards consensus.
  • Media (@mikeschroder, @joemcgill)
    • Latest update
    • Moving our weekly meetings up to Fridays at 17:00 UTC starting this week
    • Unexpected change to media title behavior in WP 4.6.1 (#37989) – The main issue here was resolved, but there seems to still be some odd behavior affecting words being chopped off filenames with international characters. Could use extra eyes from anyone (along with @sergey) more versed in i18n. Regression on the attachment titles that we generate on upload all became URL encoded instead of reading like a normal title.
    • Media search doesn’t include file name (#22744) – Committed earlier this week. Please report any issues that come as a result.
    • Next step in improving the organization of the media library is to assess both the infrastructure and UI improvements that need to be made here. Prefer to include #design early in this process, rather than asking for UI feedback on development driven decisions, hope to be part of the #design chat agenda tomorrow
  • Customize (@westonruter, @celloexpressions)
    • Latest update
    • In this week’s meeting we developed a schedule for publishing make/core feature proposals/dev notes for the remaining primary 4.7 customize projects, working backward from anticipated time to commit after the proposal and current readiness:
      • Week of 9/19: Improving sliding panels UI (34391, @delawski)
      • Week of 9/26: A new experience for themes in the customizer (37661, @celloexpressions). Please review soon for any requested changes in direction or design.
        • Summary: The existing themes section in the customizer is replaced with a full-screen theme browser and installer… The UI is nearly identical to wp-admin/theme-install.php… The .org-based theme-install previewer is not accessible here because it is likely to cause confusion with its customizer-like interface and the resulting need to switch contexts back and forth… An overarching goal is to avoid switching in and out of the admin/frontend/customize contexts during theme installation and previewing, instead staying in the hybrid customizer context that provides a combination of frontend plus controls… On the technical side, this heavily leverages JS-templated customizer controls and scales nicely to hundreds of themes.
        • Visual:
        • Please comment on the ticket with your feedback as soon as possible, preferably with specific concerns/ideas and reasons.
        • @celloexpressions to check in with @karmatosed on user testing ahead of posting final feature proposal
      • Week of 9/26: Customize transactions (30937, @westonruter evaluating this week and might punt again)
      • Week of 10/3: Code-editing gateways, via CSS (35395, @johnregan3/@celloexpressions). Awaiting approval/feedback on the acceptability/ability to bundle the two proposed libraries in core, with feedback particularly needed from committers and anyone familiar with the Jetpack fork of CSSTidy.
      • Week of 10/10: Customizer browser history (28536, @westonruter)
  • I18n (@swissspidy)
    • User Admin Language (#29783) – almost ready, another review this week and will commit if no blocker pops up
    • Introduce a locale-switching function (#26511) – @ocean90 to do some benchmarking
    • Introduce some JavaScript i18n functions (#20491) – GlotPress side has a solid plugin for exporting translations as JSON files (assistance on testing would be helpful). Still tinkering with the WordPress side and would love to get some additional feedback there.
  • Editor (@azaozz, @iseulde)
    • No updates, but would love to figure out a way to get more user feedback that helps us set direction for the editor. Will look to add some Core questions to annual survey on Otherwise will start with something in the beta tester plugin, biased audience but it’s one that exists, is more likely to opt-in, and will be more flexible.
  • HTTPS (@johnbillion)

Open Floor

  • @pbearne on Add filters to wp_new_user_notification and wp_password_change_notification (#38068) – added a set of filters to allow us to override email messages send by the wp_new_user_notification and wp_password_change_notification functions. @johnbillion to review as it relates to work on notifications.
  • @danieliser checking for interest for core in a set of reusable templates, models & functionality for forms, tabs & modals
  • @ericlewis on Bulk actions: Reactivate bulk actions hook + add hander hook for all admin screens (#16031) – could use a review of the latest patch, looking to commit sometime in the next week
  • @dshanske still working through the Pings and Trackbacks component

#4-7, #core, #dev-chat, #summary

Native Fonts in 4.6

When WordPress switched to Open Sans in version 3.8 at the end of 2013, the state of typography on the web was just beginning to evolve. Before, our choices for typefaces were limited to a small subset of fonts reliably installed on most major operating systems. And, in some cases, those fonts were optimized for print, not the web. Open Sans is optimized for the screen, has generous character support, and, best of all, is open source. For these reasons, it was a better option for a modern web app than the system fonts of that time.

Today, the landscape has changed. The majority of our users are now on devices that use great system fonts for their user interface. System fonts load more quickly, have better language support, and make web apps look more like native apps. By using the same font that the user’s device does, WordPress looks more familiar as a result. This change prioritizes consistency from the user’s perspective over consistency in branding. And while typography does play a role in the WordPress brand, the use of color, iconography, and information architecture still feels very much like WordPress.

To this end, Font Natively (#36753) replaces Open Sans with a set of system fonts that covers major operating systems, including Android, iOS, Windows, macOS, and Linux.

The Font Stack

Safari, Chrome, and Firefox on iOS and macOS have new CSS values that return the current system UI font, but on other platforms, the font has to be declared by name. As such, the font stack includes the following:

  • -apple-system for Safari (iOS & macOS) and Firefox macOS
  • BlinkMacSystemFont for Chrome macOS
  • Segoe UI for Windows
  • Roboto for Android and Chrome OS
  • Oxygen-Sans for KDE
  • Ubuntu for Ubuntu
  • Cantarell for GNOME
  • Helvetica Neue for versions of macOS prior to 10.11
  • sans-serif, the standard fallback

The complete CSS declaration: font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;


The operating system’s UI font is used for any text that’s part of the WordPress user interface. In other contexts, like the Editor, we continue to use a serif system typeface, Georgia. This creates a clear typographic distinction between text that is part of the interface, and text that is part of the user’s content.

Not all system fonts provide the same range of weights that Open Sans did. We recommend using only the 400 and 600 weights, which will display most consistently across all platforms. I’ve created a test page that shows the difference between Open Sans and your current device’s system font at every available weight. (A collection of screenshots of that test page is also available).

The order in which they’re called is important, because we want the user’s system font to be the first available font in the stack. For example: if Roboto were listed ahead of Segoe UI, Windows developers who have installed the Roboto font for Android development would see it instead of their native system font. There may be edge cases if users have manually installed these fonts on their machines, but this order should work best for the majority of users.

When using this font stack, it must be called using the font-family property, and not the font shorthand. This works around an issue in Microsoft Edge.


All screenshots were taken on a retina (2dppx) device. If you’re reviewing screenshots on a non-retina display, check out this Cloudup gallery of 1x screenshots.

#4-6, #design, #dev-notes, #fonts