You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[GitHub Pages Improvement] Update links to be relative (#1236)
Updating various links throughout the repo to use relative links instead of absolute. This allows the generated html version to point to other generated html versions, instead of forcing it back to the original markdown.
Small fix for the recent rename from Form Control Range to Opaque Range.
Correcting the link for ResourceTimingContentEncoding to use the correct file name.
Small adjustment to the `PerformanceNavigationTiming for User Agent Launch' explainer link to not pre-escape the path.
This document provides an overview of the proposed changes in Chromium to support native caret browsing. For a high-level description of native caret browsing and the motivation for introducing the feature, see the associated [explainer doc](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/CaretBrowsing/explainer.md).
9
+
This document provides an overview of the proposed changes in Chromium to support native caret browsing. For a high-level description of native caret browsing and the motivation for introducing the feature, see the associated [explainer doc](explainer.md).
@@ -35,7 +35,7 @@ With UIA, ATs can enhance web browsing for their users in Chromium-based browser
35
35
* Spend less time writing to different accessibility APIs, and more time on core capabilities.
36
36
* Take advantage of a continually-evolving platform, and the performance gains and extended capabilities that come along with it.
37
37
38
-
For extended background on motivations, please refer to the [explainer](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/UIA/explainer.md).
38
+
For extended background on motivations, please refer to the [explainer](explainer.md).
Copy file name to clipboardExpand all lines: AtRuleFeatureDetection/explainer.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -49,7 +49,7 @@ There have been many scenarios described that call for feature detection of at-r
49
49
- In the [Blink intent-to-ship thread for `@property`](https://groups.google.com/a/chromium.org/g/blink-dev/c/3ygpsew53a0/m/Ar_OPlthAwAJ), it was pointed out that authors need a mechanism to detect support so that they can fall back to `CSS.registerProperty()` if needed.
50
50
- A [StackOverflow question](https://stackoverflow.com/questions/44244221/is-it-possible-to-do-a-css-supports-check-on-a-media-rule) asks whether it is possible to detect support for `@media` features, for example to detect if the user agent can return a yes/no answer for `@media (pointer)`.
51
51
- A [Mastodon post](https://mastodon.social/@xro/113106213499516093) asks whether it is possible to test for style query support.
52
-
- At time of writing, several in-development CSS features propose to implement new at-rules. These include [`@sheet`](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/AtSheet/explainer.md) as well as [CSS Functions and Mixins](https://css.oddbird.net/sasslike/mixins-functions/).
52
+
- At time of writing, several in-development CSS features propose to implement new at-rules. These include [`@sheet`](../AtSheet/explainer.md) as well as [CSS Functions and Mixins](https://css.oddbird.net/sasslike/mixins-functions/).
Copy file name to clipboardExpand all lines: AtSheet/explainer.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,7 +31,7 @@ Additionally, bundling of stylesheets is difficult for developers who are distri
31
31
32
32
We propose an enhancement to allow the declaration of new stylesheets via an `@sheet` CSS block and using existing mechanisims such as `@import`, `<link>`, and CSS module script `import` to apply those shared styles to DSDs without the use of JavaScript.
33
33
34
-
We're currently investigating this and [Declarative CSS modules](/ShadowDOM/explainer.md) in parallel.
34
+
We're currently investigating this and [Declarative CSS modules](../ShadowDOM/explainer.md) in parallel.
35
35
36
36
## Goals
37
37
* Allow the reuse of styles in markup-based shadow DOM without requiring JavaScript.
@@ -86,7 +86,7 @@ This will also import only the rules for "foo" - in this case, the `div { color:
86
86
87
87
Shadow DOM isolates styles, but fragment identifiers from the light DOM are global and referenceable from shadow DOM (but not vice versa).
88
88
89
-
Combined with [Local References In <link> Tags](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/LocalReferenceLinkRel/explainer.md), developers may define a set of styles for their components upfront,
89
+
Combined with [Local References In <link> Tags](../LocalReferenceLinkRel/explainer.md), developers may define a set of styles for their components upfront,
90
90
and then reference these styles declaratively from their component. By using inline styles instead of an external .css file, a Flash of Unstyled Content (FOUC) can be avoided in many cases.
91
91
92
92
This example demonstates importing `@sheet` references from the light DOM into a Declarative Shadow DOM:
@@ -119,7 +119,7 @@ or imported from JavaScript:
119
119
120
120
This proposal augments the HTML `<link>` tag by introducing the `sheet` attribute, which scopes the specified style reference to rules within an `@sheet` identifier.
121
121
122
-
A separate proposal to support fragment identifiers to same-document `<style>` in the `href` attribute for `<link>` tags is described in [Local References In <link> Tags](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/LocalReferenceLinkRel/explainer.md).
122
+
A separate proposal to support fragment identifiers to same-document `<style>` in the `href` attribute for `<link>` tags is described in [Local References In <link> Tags](../LocalReferenceLinkRel/explainer.md).
123
123
124
124
This proposal augments the CSS `@import` syntax by adding the `from` keyword, with comma-separated list of `@sheet` identifiers ( `@import foo, bar from "sheet.css";`).
125
125
@@ -229,8 +229,8 @@ interface SheetNameList {
229
229
230
230
## Considered alternatives
231
231
232
-
1.[Declarative CSS Modules](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ShadowDOM/explainer.md) are another mechanism for sharing styles between Declarative Shadow DOM and light DOM without the use of JavaScript.
233
-
2. Some additional alternatives to parts of the problems discussed here are discussed in the [Alternate proposals](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ShadowDOM/explainer.md#alternate-proposals) section of that explainer.
232
+
1.[Declarative CSS Modules](../ShadowDOM/explainer.md) are another mechanism for sharing styles between Declarative Shadow DOM and light DOM without the use of JavaScript.
233
+
2. Some additional alternatives to parts of the problems discussed here are discussed in the [Alternate proposals](../ShadowDOM/explainer.md#alternate-proposals) section of that explainer.
Copy file name to clipboardExpand all lines: CSSAnchoredPositioning/explainer.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,7 @@ This document is a starting point for engaging the community and standards bodie
20
20
21
21
## Introduction
22
22
23
-
When building interactive components or applications, authors frequently want to leverage UI elements that can render in a "top-layer". Examples of such UI elements include content pickers, teaching UI, tooltips, and menus. ["Enabling Popups"](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Popup/explainer.md) introduced a new `popup` element to make many of these top-layer elements easier to author.
23
+
When building interactive components or applications, authors frequently want to leverage UI elements that can render in a "top-layer". Examples of such UI elements include content pickers, teaching UI, tooltips, and menus. ["Enabling Popups"](../Popup/explainer.md) introduced a new `popup` element to make many of these top-layer elements easier to author.
24
24
25
25
Authors frequently wish to "pin" or "anchor" such top-layer UI to a point on another element, referred to here as an "anchor element". How the top-layer UI is positioned with respect to its anchor element is further influenced or constrained by the edges of the layout viewport.
26
26
@@ -57,7 +57,7 @@ Example use cases include:
57
57
58
58
### Declaring an anchor element
59
59
60
-
First, the author must provide an anchor element, using the `anchor` HTML attribute proposed in ["Enabling Popups"](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Popup/explainer.md):
60
+
First, the author must provide an anchor element, using the `anchor` HTML attribute proposed in ["Enabling Popups"](../Popup/explainer.md):
@@ -602,7 +602,7 @@ A previous (internal) version of this CSS anchored positioning scheme used the `
602
602
603
603
One of the goals for this proposal states: "Maintain a logical content order that matches the visual order, if the visual order has been impacted by anchored positioning."
604
604
605
-
Most likely, the `anchor` attribute should be the hook that hoists an anchored element somewhere else in the logical order. There are some interesting [interactions with the `popup` attribute](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Popup/explainer.md#open-questions) to consider, as well as where exactly the anchored element gets hoisted to. Open questions under this umbrella:
605
+
Most likely, the `anchor` attribute should be the hook that hoists an anchored element somewhere else in the logical order. There are some interesting [interactions with the `popup` attribute](../Popup/explainer.md#open-questions) to consider, as well as where exactly the anchored element gets hoisted to. Open questions under this umbrella:
606
606
607
607
* Should the anchored element be treated as a sibling of the anchor element, immediately succeeding it in tab cycles / accessibility tree structures?
608
608
* What happens if the context to which the anchored element is hoisted has a restrictive content model where said anchored element is not valid?
Copy file name to clipboardExpand all lines: CSSModules/v1Explainer.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -60,7 +60,7 @@ One of the main differences between options 2 and 3 is that 3 implies that if a
60
60
61
61
However, as @tabatkins discussed [here](https://github.com/w3c/webcomponents/issues/759#issuecomment-490685490), option 3 is a significant departure from the current `@import` behavior in a way that can't be reproduced dynamically: the CSS object model can't be used to make multiple sheets depend on a single child stylesheet. The `.parentStyleSheet` and `.ownerRule` references also pose a problem here as these currently reference only a single sheet and become ambiguous if a sheet were to have multiple importers.
62
62
63
-
The discussion following [this comment](https://github.com/w3c/webcomponents/issues/759#issuecomment-490256626) contains more extensive discussion of this issue. Given the lack of consensus on far, we're moving forward with a V1 that sidesteps the question by going with option 1. This is forward-compatible given that any use of `@import` in a CSS module will prevent the module from loading. Making progress on this now rather than waiting for a final option 2 vs 3 decision is advantageous given that we can get earlier developer feedback on the feature and a better perspective of how it is used in practice, both of which may help us in making these design decisions. Additionally, completing a V1 of CSS modules unblocks progress on [HTML modules](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/HTMLModules/designDoc.md).
63
+
The discussion following [this comment](https://github.com/w3c/webcomponents/issues/759#issuecomment-490256626) contains more extensive discussion of this issue. Given the lack of consensus on far, we're moving forward with a V1 that sidesteps the question by going with option 1. This is forward-compatible given that any use of `@import` in a CSS module will prevent the module from loading. Making progress on this now rather than waiting for a final option 2 vs 3 decision is advantageous given that we can get earlier developer feedback on the feature and a better perspective of how it is used in practice, both of which may help us in making these design decisions. Additionally, completing a V1 of CSS modules unblocks progress on [HTML modules](../HTMLModules/designDoc.md).
64
64
65
65
## Example: Custom Element Definition using CSS Modules
0 commit comments