diff --git a/netlify.toml b/netlify.toml new file mode 100644 index 000000000..266f85072 --- /dev/null +++ b/netlify.toml @@ -0,0 +1,14 @@ +# Temporary as I need to override the Netlify build settings for the Gatsby site +[build] + publish = "/dist" + + +[[redirects]] + from = "/contribute" + to = "/get-involved" + status = 301 + +[[redirects]] + from = "/components/popup.research.explainer" + to = "/components/popover.research.explainer" + status = 301 diff --git a/platform/README.md b/platform/README.md deleted file mode 100644 index 9922cb080..000000000 --- a/platform/README.md +++ /dev/null @@ -1,33 +0,0 @@ -# Standardized Form Controls and Components -The goal of this repo is to begin to standardize controls and components that ship natively within UAs. - -# Overview -This will be a central repro that will help track individual specifications that will make their start in WICG and then ultimately land the respective pieces in the necessary WGs. This central repo is being created for a few reasons: - -* Easy tracking of which ones we're actively investigating and their respective locations -* Discuss issues that span all of the controls & components - * Where necessary we will close and direct these issues to the relevant WGs for discussion (eg: CSSWG, Web Components WG, WHATWG, TC39, etc) - -# How it will work -We will take existing legacy controls and based on user feedback and testing we'll derive the top pain points to begin -addressing them with standardized solutions. As the pattern to bringing a new control -to the platform becomes more clear, I'll continue to update these steps. - -# Key pillars for a solid control that web developers will use -In discussions, customer & partner discussions, and surveys there are a few key aspects that we must deliver in order -for the native components and controls that the platform delivers to be heavily utilized. All of these don't have to land at once, but need to be considered so we don't back ourselves into a corner and create yet another control/component that is unusable. - -* They need to be customizable -* Extensibility needs to be possible -* Behavior hook or adjustments needs to be possible -* State management across component, even in a composite component, is possible -* Expectation from developers that it "just works" (<-- we need to bring the magic back, even if built on primitives) -* Accessibility, focus and other foundational items work as expected - -# Controls to standardize (initial thinking) -* `` control, a key consideration is progressive enhancement—that is, ensuring that users with browsers that do not yet support the new ``, the control will strip out all non-text content and still function. - -This was verified by creating a representative case of a ``, which inherently limits its potential for customization with non-text content compared to desktop. -### iOS -![Progressive Enhancement - iOS](images/prog-enhancement-ios.png) - -### Android -![Progressive Enhancement - Android](images/prog-enhancement-android.png) diff --git a/platform/select/investigations/use-cases.md b/platform/select/investigations/use-cases.md deleted file mode 100755 index 809370730..000000000 --- a/platform/select/investigations/use-cases.md +++ /dev/null @@ -1,100 +0,0 @@ -# Understanding Patterns of Custom Select Control Implementations -## Google.com -### Example 1: Search Filter - -This control allows users to filter their results by time period and type of match (all results or just verbatim). At first glance, it appears to be a control that could mostly be implemented and styled as a traditional `` control (without doing something very hacky like dynamically adding `