profile
viewpoint
Dan Clark dandclark Microsoft Seattle, WA

WICG/open-ui 790

Maintain an open standard for UI and promote its adherence and adoption.

tc39/proposal-import-assertions 161

Proposal for syntax to import ES modules with assertions

dandclark/BigInt 6

C library for operations with integers of arbitrary size

dandclark/perspective-remover 2

Alter image of a flat surface to remove perspective

dandclark/MSEdgeExplainers 1

Home for explainer documents originated by the Microsoft Edge team

dandclark/built-specs 0

Built web standards specs for PR review

dandclark/chromium-color-control 0

A repository for convenient development of the color picker for <input type="color" /> in Chromium

dandclark/ecma262 0

Status, process, and documents for ECMA262

dandclark/ecosystem 0

Simulator for an ecosystem with predators, prey etc.

issue closedMicrosoftEdge/MSEdgeExplainers

<select> anatomy seems Windows-centric

The proposed anatomy for a <select> includes a part named listbox. <select> elements in macOS Safari (and in the closest matching native macOS controls) don't have a listbox, except in the <select multiple> state; they have a menu. On iPadOS, there's a popover instead. On iOS, it's a list wheel. On iOS and iPadOS, this is true even for the <select multiple> state; they use a checkable list wheel and a checkable popover respectively. I am not sure if the anatomy is meant to encompass the <select multiple> case.

Can we name this part of the anatomy something that is suitable for all the different ways this control is presented on different platforms?

closed time in a few seconds

othermaciej

issue commentMicrosoftEdge/MSEdgeExplainers

<select> anatomy seems Windows-centric

Closing here, let's keep discussing at WICG/open-ui#142 and WICG/open-ui#143.

othermaciej

comment created time in a few seconds

issue closedMicrosoftEdge/MSEdgeExplainers

Opt-in for `<select>` customizability

It's necessary that control customizability be opt-in rather than on by default in order to not break compatibility with older sites and to avoid issues where capabilities of the customizable controls be limited, e.g. the customizable <select> must not escape the bounds of windows due to security concerns.

Opt-in for custom control behavior for <input> type like <input type="range"> will be done by introducing new elements, e.g. <range>, for the customizable version, while <input> will remain the same.

For <select>, since unlike <input> the parser does not prevent it from being parsed with child DOM nodes, we've proposed that it's not necessary to create a new element for it and we could instead do opt-in through an attribute like <select custom="">.

There are downsides to relying on an attribute though:

  • @mfreed7 pointed out that we'd need to deal with the fact that the custom attribute could be added/removed dynamically, which adds complexity. Parsing is particularly concerning here, since the attribute would change the parsing rules for the subtree of the <select>. Is there any scenario where a <select> could have script change it to custom when we're in the middle of parsing its subtree?
    • @travisleithead raised this specific concern about the dynamic case: consider a dynamically-created <select> (via document.createElement()), when the custom attribute must be set using setAttribute(). When should the transition to the custom behavior be applied? Applying it at the point of setAttribute() would be inconsistent with how other elements like <input type="range"> work when created dynamically; typically the transformation would occur when the element was appended to the DOM. But, this means that for a dynamically created <select>, the developer would have to wait until the <select> is appended to the DOM before calling attachShadow(), since attachShadow() throws for a non-custom <select>.
  • If we're minting new elements for all the customizable <input> types then it seems odd to do something different just for <select>.

On the other hand there are downsides to adding a new element for <select>:

  • What would we name it? @mfreed7 suggested <selectmenu>, I don't have any other ideas at the moment.
  • @gregwhitworth pointed out that some might be opposed to a new element that is almost 1:1 with the current one but had more capabilities.

Overall, introducing a new element and thereby sidestepping the problems of dynamic opt-in seems better to me.

closed time in 2 minutes

dandclark

issue commentnodejs/modules

import assertions RFC

[1] Are unknown assertions ignored? I assume they must be because of future compat.

This is also left up to hosts. The current status of the HTML integration is to fail on unrecognized assertions.

This seems important from a security perspective. If I'm asserting some security-related restriction on the thing I'm importing, if the implementation can't guarantee that the assertion is true because the assertion is not yet implemented, then I'd rather it cause a failure than just be ignored.

bmeck

comment created time in 3 hours

issue commentnodejs/modules

import assertions RFC

Regarding the other discussion in this thread:

I’m pretty sure the current proposed spec merely allows creating a new module record for a new specifier/assertions combination, and never requires it.

That is correct. The proposal leaves it to hosts to decide whether assertions are part of the module cache key (see https://tc39.es/proposal-import-assertions/#sec-hostresolveimportedmodule), although it recommends that assertions are not part of the key. An earlier version required that they were not part of the cache key, but this restriction was loosened based on feedback from proposal's integration with HTML. HTML is going to consider assertions part of the module cache key.

However, it is still a requirement that assertions do not affect the interpretation of the module (other than potentially causing it to fail to load). So, things like changing the HTTP headers depending on the assertions would not be permitted.

Thus, given these two statements it is up to the host whether or not these result in two module instances (assuming neither set of assertions results in failure to load):

import thing from "./url" assert {foo: "bar"};
import thing2 from "./url" assert {foo2: "bar2"};

However, if the host chooses to treat these as two module instances, then the instances must be interpreted exactly the same. They must have the same HTTP request headers, they must be parsed and executed the same, etc.

bmeck

comment created time in 4 hours

issue commentnodejs/modules

import assertions RFC

I agree with @bmeck's comment regarding noexecute. @rniwa also pointed out here that:

Execution vs. no execution is an important distinction but changing the parser mode based on MIME type isn't great either. We've definitely had security attacks which used an existing content by reinterpreting it in a different text encoding & MIME type.

bmeck

comment created time in 5 hours

push eventtc39/proposal-import-assertions

Daniel Clark

commit sha 2ea51b677065d1143b968669861240fea6df9a07

Relax constraint requiring hosts not to use [[Assertions]] in cache key

view details

Daniel Clark

commit sha 943ceb4a6ef352911a46d334d15f91ec8b58c8f8

consider --> use

view details

Dan Clark

commit sha fa83e728d50030110135d0bc01618372636e229a

Merge pull request #89 from tc39/dandclark/relax-assertions-caching-condition Relax restriction forbidding hosts from using import assertions in cache key

view details

push time in 5 hours

delete branch tc39/proposal-import-assertions

delete branch : dandclark/relax-assertions-caching-condition

delete time in 5 hours

PR merged tc39/proposal-import-assertions

Reviewers
Relax restriction forbidding hosts from using import assertions in cache key

As agreed on at the July TC39 meeting, relax the constraint that had banned hosts from using ModuleRequest.[[Assertions]] as part of the cache key. Still recommend, however, that they do not do so, though we know that the HTML integration will go against this recommendation in https://github.com/whatwg/html/pull/5658. Continue requiring that [[Assertions]] do not affect the interpretation of the module.

+8 -3

1 comment

1 changed file

dandclark

pr closed time in 5 hours

pull request commenttc39/proposal-import-assertions

Relax restriction forbidding hosts from using import assertions in cache key

I'm going to go ahead and merge this, happy to address any feedback in a follow-up change.

dandclark

comment created time in 5 hours

issue commentMicrosoftEdge/MSEdgeExplainers

ControlUICustomization - Common HTML structure for views

I'm inclined to agree with this. I think we'll need to do some experimenting to see how robust the user-slotted parts are to changes in the control HTML structure. If we don't come up with a way to minimize interop issues, we might have to go further than OpenUI is currently going in restricting allowable differences in the default control HTML structure across browsers.

Given how much we're specifying in OpenUI, including the structure of the control anatomy (the parts, and their parent/child/sibling relationships) and the location of <slot>s, it might not actually be a huge leap from there to specifying the exact HTML. This too would require experimentation to ensure that we could arrive on a common HTML structure with enough flexibility that different UA stylesheets could morph it into what each browser wants their default to look like.

jcgregorio

comment created time in 6 days

issue commentMicrosoftEdge/MSEdgeExplainers

Opt-in for `<select>` customizability

From the beginning I've been in favor of having new elements for the new controls as it also allows us to keep some native ones and specific needs for certain capabilities (window escape, etc).

This would still be possible if we used an attribute. <select custom=""> would get all the new stuff, but <select> would work the same as it does now and would not have limitations on window escape etc. That said, at this point I'm also in favor of using new elements instead of an attribute.

I think this is a good discussion for WHATWG as I want to raise the open state discussion as well and that should only hang off the element that is decided here? Is there a reason this discussion should remain here @dandclark ?

I'm fine with moving this discussion to WHATWG.

dandclark

comment created time in 6 days

issue commentMicrosoftEdge/MSEdgeExplainers

ControlUICustomization - OS-native UIs

Yeah, I think the best outcome here is that the customizable controls never use OS-native UIs, while the old, non-customizable versions of the controls could continue to use them as they do now. I wrote some thoughts on this over at https://github.com/WICG/open-ui/issues/143#issuecomment-664690025.

@hwikyounglee were you able to get in touch with the Android Chrome team to learn their thoughts on not using OS-native UIs for customizable controls? cc @gregwhitworth who had asked about this. As I commented at https://github.com/WICG/open-ui/issues/143#issuecomment-664690025, I suspect that developers who need control customizability would already not be getting OS-native controls, because they'll be rolling their own control implementations e.g. with custom elements.

jcgregorio

comment created time in 7 days

issue commentMicrosoftEdge/MSEdgeExplainers

ControlUICustomization - CSS Styling of Parts

I don't think there would be any limits. @melanierichards can you think of any reason we'd need to limit styles that could be applied to a control part? It seems to me like anything should be allowed, including animations, just like styling a part of a developer-defined custom element.

If we did have any limitations then they should be clearly standardized, not left up to browser vendors.

jcgregorio

comment created time in 7 days

issue commentMicrosoftEdge/MSEdgeExplainers

ControlUICustomization - User supplied ARIA attributes on slotted parts.

Yes, this would work similarly to how the implicit ARIA semantics defined in the HTML-AAM can be overridden by ARIA attributes for normal HTML elements.

E.g. I can do stuff like this (link to jsfiddle):

<input type="range" value="10" role="button" aria-pressed="true"/>
<button role="slider" aria-valuenow="42" aria-label="pretending to be a slider">Test</button>

Which produces the Windows Narrator output:

  1. "Button, 10, on"
  2. "Pretending to be a slider, slider at 42"

Similarly, something like this could be written:

<select custom="">
    <div slot="button" part="button" role="slider" aria-valuenow="10">
    <option>A</option>
    <option>B</option>
</select>

And the role="slider" would override the implicit aria-role of "button" that would have been applied due to part="button". But, this is probably bad practice, in the same way as my first example mis-applying ARIA roles doesn't make sense. If a developer finds themselves overriding the default roles applied from the part attribute, then there's a good chance that they are applying part to the wrong element, or using the wrong control for the job.

jcgregorio

comment created time in 7 days

issue commentMicrosoftEdge/MSEdgeExplainers

ControlUICustomization - Feature detection in Javascript

I expect that a browser's implementation of the new parts and states for a given control would roll out the same time as the overall customization capability for that control. That is, if the feature check for <select> in feature-detection passes (select.attachShadow() doesn't throw), then the developer should be able to expect that all the parts, states, and "controller" code work as specified for <select>. If they wanted to use custom <input type="range">, though, they'd need to do a separate feature check for that.

If a browser were to release customization for a given control type in a piecemeal fashion then these feature checks would not be reliable, but this sort of problem would exist any time a browser were to release a feature that's only half-implemented. I believe that browser vendors would want to avoid doing so for this reason.

jcgregorio

comment created time in 7 days

issue openedMicrosoftEdge/MSEdgeExplainers

Opt-in for `<select>`

It's necessary that control customizability be opt-in rather than on by default in order to not break compatibility with older sites and to avoid issues where capabilities of the customizable controls be limited, e.g. the customizable <select> must not escape the bounds of windows due to security concerns.

Opt-in for custom control behavior for <input> type like <input type="range"> will be done by introducing new elements, e.g. <range>, for the customizable version, while <input> will remain the same.

For <select>, since unlike <input> the parser does not prevent it from being parsed with child DOM nodes, we've proposed that it's not necessary to create a new element for it and we could instead do opt-in through an attribute like <select custom="">.

There are downsides to relying on an attribute though:

  • @mfreed7 pointed out that we'd need to deal with the fact that the custom attribute could be added/removed dynamically, which adds complexity. Parsing is particularly concerning here, since the attribute would change the parsing rules for the subtree of the <select>. Is there any scenario where a <select> could have script change it to custom when we're in the middle of parsing its subtree?
    • @travisleithead raised this specific concern about the dynamic case: consider a dynamically-created <select> (via document.createElement()), when the custom attribute must be set using setAttribute(). When should the transition to the custom behavior be applied? Applying it at the point of setAttribute() would be inconsistent with how other elements like <input type="range"> work when created dynamically; typically the transformation would occur when the element was appended to the DOM. But, this means that for a dynamically created <select>, the developer would have to wait until the <select> is appended to the DOM before calling attachShadow(), since attachShadow() throws for a non-custom <select>.
  • If we're minting new elements for all the customizable <input> types then it seems odd to do something different just for <select>.

On the other hand there are downsides to adding a new element for <select>:

  • What would we name it? @mfreed7 suggested <selectmenu>, I don't have any other ideas at the moment.
  • @gregwhitworth pointed out that some might be opposed to a new element that is almost 1:1 with the current one but had more capabilities.

Overall, introducing a new element and thereby sidestepping the problems of dynamic opt-in seems better to me.

created time in 8 days

issue commentWICG/open-ui

Should <select> anatomy include type-to-search?

I'll create a PR (though I may not get to it before this week's sync) proposing an addition to the anatomy. I agree that some parts of it will probably need to be UA defined, e.g. the specific timeout value before the character buffer resets. But we can outline at least the general behavior.

To me this version of typeahead is fully distinct from the mode of operation where there is a visible text input and the options are filtered. If we want to include the text-input-plus-filtering dropdown scenario (like with <datalist>) in the <select> anatomy it seems like it should be a separate mode, sort of like <select multiple>. The type-ahead in that mode would be different in these ways:

  • The typed text is visible to the user (because the button has been replaced by a text input)
  • Typing doesn't change the selected option, instead it filters the options list
  • There is no timeout where the "buffer" is cleared and the typed characters reset

We can add this combobox-like mode to the anatomy if that is the consensus, but I think that should be separate from the addition of type-to-select in "normal" <select> mode; the functionality is quite different even if we call both things "typeahead".

dandclark

comment created time in 8 days

issue openedWICG/open-ui

Should <select> anatomy include type-to-search?

I've seen "typeahead' used to mean a few slightly different things, so in this issue I'm specifically talking about this behavior/functionality:

  • The the <select> is focused (either open or closed), if the user types characters, these are collected in a buffer and selection jumps to the next <option> following the currently selected <option> that matches the text in the buffer (there may be some subtleties here that I am eliding for the purposes of this discussion).
  • After some timeout with no more characters (short, maybe 0.5s) the buffer is cleared.
  • The select has a button, not a textfield, so the buffer contents are not visible except as they are reflected in the changing selection.
  • The <option>s are not filtered; typing makes the selection jump around but does not hide non-matching <option>s.

This behavior is present on the default <select> in desktop Chromium, Firefox, and Safari (there are some subtle differences but they are mostly the same). I tried it on a few design systems (Ant Design, Carbon, Atlas) and the only one I saw that had this functionality was Carbon but that's because they build on the native <select>.

We should consider including this behavior in the <select> anatomy. If we don't do so, implementers would probably include it in their controller code for Custom Select anyway, because not to do so would mean that custom selects would less accessible and less generally convenient than native <select>s. This behavior is a big time-saver for typical <select> use cases like choosing one's country or state from a long list of <option>s.

It's more complicated than the other <select> "controller code" we have defined so far, but I think it's worth including. The fact that it's not trivial means that it's less likely that developers rolling their own implementations would include this functionality, and I think that the lack of it in several major component frameworks is proof of this.

created time in 9 days

issue commentWICG/open-ui

<select> anatomy seems Windows-centric

Thinking about this more, one observation is that the goal isn't necessarily to encompass all the ways that a <select> controls are currently presented on different platforms. There will be some OS-native controls that won't fit the anatomy defined in OpenUI, but web developers creating a custom control based on the OpenUI anatomy probably weren't going to be using the native controls anyway. Control usage by developers could be divided into two distinct categories:

A) The developer wants to specify the appearance of their control, e.g. to match the styles on the site or match the guidelines of a particular design system. The developer wants it to look the same across different browsers and OS platforms. Currently a developer in this category would use a component framework, or just roll their own control. They aren't using the native controls because those might have drastically different appearances and structures, e.g. the big differences of <select multiple> on Windows vs iOS. B) The developer doesn't need to specify the appearance of the control. They are fine with it having potentially significant differences in appearance and behavior on different platforms, as long as it still fulfills its basic function. The cross-platform differences could even be considered an advantage for this developer because they know that the control will have an experience tailored for each platform without any work on their part.

Proposals based on OpenUI like Enabling Custom Control UI target only the first category, where the goal is to make life easier for developers who want to specify how their controls look. Developers in the second category will continue using the default non-customizable <select>.

Given that the target audience of Enabling Custom Control UI and, I believe, OpenUI as a whole, is developers who are using controls from component frameworks or are writing their own, rather than developers who are using native controls, it need not be a requirement that the OpenUI anatomy encompass all OS-native control implementations.

That said, the <select> anatomy shouldn't be overly biased towards any particular current <select> implementation; it should instead be a distillation of widely agreed-upon ideas of how a <select> should work. This considers not just OS implementations but browser implementations and those of popular component frameworks like Bootstrap, Ant Design, etc etc. If folks feel that we're steering the anatomy too close to any given implementation at the expense of others then we should be prepared to correct for this.

dandclark

comment created time in 9 days

PR opened tc39/proposal-import-assertions

Reviewers
Relax restriction forbidding hosts from using import assertions in cache key

As agreed on at the July TC39 meeting, relax the constraint that had banned hosts from using ModuleRequest.[[Assertions]] as part of the cache key. Still recommend, however, that they do not do so, though we know that the HTML integration will go against this recommendation in https://github.com/whatwg/html/pull/5658. Continue requiring that [[Assertions]] do not affect the interpretation of the module.

+8 -3

0 comment

1 changed file

pr created time in 9 days

push eventtc39/proposal-import-assertions

Daniel Clark

commit sha 943ceb4a6ef352911a46d334d15f91ec8b58c8f8

consider --> use

view details

push time in 9 days

issue commenttc39/proposal-import-assertions

Consider more name change fallout from 'if' --> 'assert' rename

@xtuc Oh, I didn't notice it was done that way last time. Looks like dbaron beat us to it though: https://github.com/mozilla/standards-positions/commit/da631527be5346a8993496e9d9f1cf36219bde12

dandclark

comment created time in 9 days

push eventdandclark/html

Daniel Clark

commit sha dca376bb5aa947d032424715a61429702232cab8

Update for the latest rename of the proposal from 'Import Conditions' to 'Import Assertions'

view details

Daniel Clark

commit sha e3359b5f4d4d19993552dd577a62a2b5f125f64d

Use module type as part of module map cache key instead of caching response body in the case of a failed type check.

view details

push time in 9 days

push eventMicrosoftEdge/MSEdgeExplainers

Dan Clark

commit sha ea9e7dfa95d2acf50d7c609b9e0b3a04bdc07c11

Add open-ui links to 'Standardized control UI anatomy' section (#363) Add open-ui links to the 'Standardized control UI anatomy, parts, and behavior' section. Open-UI is already referenced in the 'Incremental Approach' section but it seems best to include it in the section about standardized anatomies as well since Open-UI is the venue for driving that process. Context: #361 made me realize that Open UI wasn't really mentioned in the appropriate place.

view details

push time in 13 days

PR merged MicrosoftEdge/MSEdgeExplainers

Add open-ui links to 'Standardized control UI anatomy' section

Add open-ui links to Standardized control UI anatomy, parts, and behavior section. Open-UI is already referenced in Incremental Approach but it seems best to include it in the section about standardized anatomies as well since Open-UI is the venue for driving that process.

Context: #361 made me realize that Open UI wasn't really mentioned in the appropriate place.

+2 -2

0 comment

1 changed file

dandclark

pr closed time in 13 days

push eventdandclark/MSEdgeExplainers

Daniel Clark

commit sha 42aa2471e1ec703d9e0035ba71d1243d03268c15

Add 'the'

view details

push time in 13 days

push eventdandclark/MSEdgeExplainers

Daniel Clark

commit sha 50f325809c0fb6fa46643db8b4e42701dec92336

Address comments from melanierichards review

view details

push time in 13 days

PR opened MicrosoftEdge/MSEdgeExplainers

Reviewers
Add open-ui links to 'Standardized control UI anatomy' section

Add open-ui links to Standardized control UI anatomy, parts, and behavior section. Open-UI is already referenced in Incremental Approach but it seems best to include it in the section about standardized anatomies as well since Open-UI is the venue for driving that process.

Context: #361 made me realize that Open UI wasn't really mentioned in the appropriate place.

+2 -2

0 comment

1 changed file

pr created time in 13 days

create barnchdandclark/MSEdgeExplainers

branch : dandclark/add-openui-link

created branch time in 13 days

push eventdandclark/MSEdgeExplainers

Dan Clark

commit sha 61ad6cfe1a659a5b939d50bfab2a94041d7f8d8b

Introduce Custom Control UI Explainer (#357) Introduce Custom Control UI Explainer

view details

Melanie Sumner

commit sha 7b87f1f692484d480453bebbe030a7126b873d51

Custom Control UI: fix quote syntax on a code sample

view details

Chris Lilley

commit sha 0e1219c60912da00ac797a25a5ed3503e703d404

Update to latest syntax (#358) Colorspace is first, percentages go right next to each color

view details

Dan Clark

commit sha fedc28bddf0059459e64bfab4fa3b01046823266

Add section on feature detection (#362) Add a section on options for feature detection for custom controls. Closes #359.

view details

push time in 13 days

issue commentMicrosoftEdge/MSEdgeExplainers

<select> anatomy seems Windows-centric

Thanks for raising this issue!

The control anatomies that will end up being used are being developed over at WICG/open-ui, so that is the best place to raise specific anatomy issues (<select> is at https://open-ui.org/components/select). I've gone ahead and opened https://github.com/WICG/open-ui/issues/143 to discuss this point over there.

If OpenUI resolves to change the name or other aspects of the anatomy then I'll propagate the update to this explainer to keep it roughly in-sync with https://open-ui.org/components/select.

Meanwhile I'll also add a link to OpenUI in the standardized control UI anatomy and parts section of the explainer to call out that that's where the real anatomy will be developed, and that the sample one I've proposed in the explainer might not match the one arrived at by OpenUI and eventually standardized.

othermaciej

comment created time in 13 days

issue openedWICG/open-ui

<select> 'listbox' part name seems Windows-centric

In MicrosoftEdge/MSEdgeExplainers#361 @othermaciej raised the following issue:

The proposed anatomy for a includes a part named listbox. <select> elements in macOS Safari (and in the closest matching native macOS controls) don't have a listbox, except in the <select multiple> state; they have a menu. On iPadOS, there's a popover instead. On iOS, it's a list wheel. On iOS and iPadOS, this is true even for the <select multiple> state; they use a checkable list wheel and a checkable popover respectively. I am not sure if the anatomy is meant to encompass the <select multiple> case. Can we name this part of the anatomy something that is suitable for all the different ways this control is presented on different platforms?

The open-ui anatomy is intended to encompass the <select multiple> case, but I don't think it's been fully fleshed-out yet; I just opened #142 .

Perhaps we can come up with a term that better encompasses all use cases while still being somewhat descriptive. Something like "popup" could describe a lot of these cases, but doesn't fit with <select multiple> on Windows.

Thoughts?

created time in 13 days

issue openedWICG/open-ui

Modify button part behavior for <select multiple>?

In the <select> anatomy, there are a couple of spots where we don't modify open or aria-expanded if the multiple attribute is set, e.g. see listbox keydown(enter). However for button there's nothing to indicate that it should not toggle these attributes, or that it should not appear at all, if multiple is present. So there's an inconsistency here.

Adding an extra layer of difficulty is the fact that for Safari/Chrome/Edge on iOS there is actually still a visible button for <select multiple> that opens a popover with checkable options. So, the button not affecting the open state of the popup if multiple is set isn't even universally true if we consider iOS.

created time in 13 days

PR opened WICG/open-ui

Reviewers
Add light dismiss to listbox controller

Per the discussion in #137, implementing light dismiss for the <select> listbox is not trivial because relying on focusout causes the listbox to be collapsed when non-focusable content inside a listbox is clicked. However, for our current set of examples this behavior doesn't come up except in for the split-button example, where there is a non-focusable divider. It turns out that this closes the listbox in the real Bootstrap split-button though, so it seems fine to match that behavior.

Aside from that issue, adding light dismiss makes the examples behave a lot more like "real" <select>s.

Note that this doesn't affect the filter example because it implements its own dropdown and prevents event propagation, so it would need to implement its own light dismiss.

+63 -7

0 comment

5 changed files

pr created time in 13 days

push eventdandclark/open-ui

Daniel Clark

commit sha c134a5e75597112c3e09f72d83850969149b24c4

Update 'Gap' for light dismiss

view details

push time in 13 days

create barnchdandclark/open-ui

branch : dandclark/components-select-listbox-blur

created branch time in 13 days

issue closedtc39/proposal-import-assertions

Consider more name change fallout from 'if' --> 'assert' rename

#80 changed the keyword from if to assert. There are two other name changes to consider as follow-ups:

  • Rename the proposal from "Import Conditions" to "Import Assertions"
  • Rename ModuleRecord's [[Conditions]] fields to [[Assertions]]

Thoughts/objections/any other changes we're missing?

closed time in 13 days

dandclark

issue commenttc39/proposal-import-assertions

Consider more name change fallout from 'if' --> 'assert' rename

I landed #88 and posted an update to https://github.com/mozilla/standards-positions/issues/373 (if they want to change it I'll offer to submit a PR; I'm not sure if creating a PR against mozilla/standards-position as a non-Mozilla employee presumes too much 😄). So, closing this.

dandclark

comment created time in 13 days

issue commentmozilla/standards-positions

Import Attributes

This proposal was renamed to "Import Assertions" to reflect the keyword we ended up settling on (assert), and to reflect that the presence of the attributes won't affect the behavior of a module, only block it from loading (as opposed to potential "evaluator attributes").

The old URL in activities.json will redirect to the renamed proposal so it's probably not critical to change anything, but we just wanted to keep everyone updated.

xtuc

comment created time in 13 days

delete branch tc39/proposal-import-assertions

delete branch : dandclark/finish-rename-to-assertions

delete time in 13 days

push eventtc39/proposal-import-assertions

Daniel Clark

commit sha 1fe8707bfd2840b7e7b9faf71b3b75bf20014c42

Update README wording from 'condition' to 'assertion'

view details

Daniel Clark

commit sha d2a0774b34e8256bb18ce57fe1f2ef2e492fd9bf

Update spec wording from 'condition' to 'assertion' and rename ModuleRequest.[[Conditions]] to [[Assertions]]

view details

Daniel Clark

commit sha 4a725b5886fdfd72d26b15c27d498ca00c77e165

Rename 'condition' to 'assertion' in all remaining spec names

view details

Daniel Clark

commit sha 4fec94bbadd7c666656f35a98fcb0a80291a8401

Update all links to point to https://github.com/tc39/proposal-import-assertions

view details

Dan Clark

commit sha dc2f3fbd5433ce28d017230e179fd37a3fc41cb3

Merge pull request #88 from tc39/dandclark/finish-rename-to-assertions Finish the rename to 'import assertions' started in 3d71669 by updating all remaining references from 'condition' to 'assertion' in the README and the spec text.

view details

push time in 13 days

PR merged tc39/proposal-import-assertions

Reviewers
Finish rename to import assertions

Finish the rename to 'import assertions' started in 3d716696f0685ba086beac7da57a62f42f5ede2e by updating all remaining references from 'condition' to 'assertion' in the README and the spec text.

+92 -92

1 comment

2 changed files

dandclark

pr closed time in 13 days

push eventMicrosoftEdge/MSEdgeExplainers

Dan Clark

commit sha fedc28bddf0059459e64bfab4fa3b01046823266

Add section on feature detection (#362) Add a section on options for feature detection for custom controls. Closes #359.

view details

push time in 13 days

PR merged MicrosoftEdge/MSEdgeExplainers

Reviewers
Custom Controls UI: Add section on feature detection

Add a section on options for feature detection for custom controls. Closes #359.

+46 -0

0 comment

1 changed file

dandclark

pr closed time in 13 days

issue closedMicrosoftEdge/MSEdgeExplainers

Feature detection / fallback path?

I was unable to find any information or guidance on what the feature detection/fallback path would look like. Is that TBD or did I just jump the gun too early on this? :)

In any case this looks great and I hope it progresses.

closed time in 13 days

frehner

PR opened MicrosoftEdge/MSEdgeExplainers

Reviewers
Custom Controls UI: Add section on feature detection

Add a section on options for feature detection for custom controls. Closes #359.

+46 -0

0 comment

1 changed file

pr created time in 13 days

issue commenttc39/proposal-import-conditions

Consider more name change fallout from 'if' --> 'assert' rename

Other parts of spec text also reference "conditions" (ConditionEntries, ConditionKey, AssertClauseToConditions...), so I'm renaming those as well in #88.

dandclark

comment created time in 14 days

pull request commenttc39/proposal-import-conditions

Finish rename to import assertions

We'll want to change the actual repository name prior to landing this, or at the same time, or all the links will be broken. Alternatively I can split out the URL changes and land those separately.

dandclark

comment created time in 14 days

PR opened tc39/proposal-import-conditions

Reviewers
Finish rename to import assertions

Finish the rename to 'import assertions' started in 3d716696f0685ba086beac7da57a62f42f5ede2e by updating all remaining references from 'condition' to 'assertion' in the README and the spec text.

+92 -92

0 comment

2 changed files

pr created time in 14 days

issue commentMicrosoftEdge/MSEdgeExplainers

Feature detection / fallback path?

I don't think @supports selector() will work here because this proposal doesn't introduce any new CSS selectors or rules, it just adds another use for ::part. And it turns out that @supports selector(element::part(part-name)) will "evaluate" to true even if part-name doesn't exist for that element: https://jsfiddle.net/dandclark_msft/odprfubk/1/. So there's no way that I know of to check whether e.g. select::part(button) will match anything.

Also @supports selector() isn't implemented in Safari yet :( MDN link.

That said, you could create a rule specifying a control part, and if the part doesn't exist (e.g. because a browser hasn't implemented this proposal yet for the control in question) then the rule would just be ignored:

select::part(button) {
 /*
  * This will apply to the button of a <select> if customizable <select> has
  * been implemented, and will be a no-op on browsers that haven't yet
  * implemented customizable <select> since the selector won't match anything.
  * Other CSS rules in the stylesheet will still apply normally.
 */
}

But, switching to a whole different set of CSS rules if the feature has not been implemented will probably require JS.

frehner

comment created time in 14 days

issue commenttc39/proposal-import-conditions

Decouple JSON module from this proposal

I wonder whether or not it makes sense to also decouple the HTML spec integration PR. If Import Conditions Assertions advances before JSON modules, I think that HTML could still technically go ahead and implement JSON modules without being in violation of the spec. The JSON modules proposal would only restrict what a host can do with assert { type: "json" }, but HTML could run ahead and implement them before that. Where we'd run into trouble is if TC39 makes a different decision about whether to freeze the JSON object, HTML could suddenly find itself in violation.

I propose this course of action: Keep the HTML spec integration combined for now. If Import Assertions and JSON modules end up advancing to Stage 3-4 in lockstep, then we'll land their combined HTML spec integration together. If however Import Assertions pulls ahead of JSON modules in stage advancement, we should revisit splitting the HTML spec PR.

xtuc

comment created time in 15 days

Pull request review commentWICG/open-ui

Create section defining 'light dismiss' behavior of `<select>` listbox part

 and is therefore considered to be invalid. - The currently selected `<option>`, or the first if one isn't selected, should be   visible within the listbox. This may require moving the list to accomodate listbox positioning   and available space.-- The user can dismiss the listbox and remove the state of `open` from the `<select>` in any of the+- The user can dismiss the listbox and remove the state of `open` from the `<select>` in either of the   following manners:-  - The user clicks outside of the listbox-  - Presses the escape key-  - Selects one, or more (if `multiple` is true), by clicking or hitting `enter` or `space` key+  - Triggering any of the listbox's <a href="#light-dismiss">light dismiss</a> behaviors+  - Selecting one, or more (if `multiple` is true), options by clicking or hitting the `enter` or `space` key++### Light dismiss <a class="link" href="#light-dismiss" id="light-dismiss"></a>

(so I removed it).

dandclark

comment created time in 15 days

push eventdandclark/open-ui

Daniel Clark

commit sha ea875c3b630e9c2b3436432af81e9b7a551ce7cb

Remove empty <a>. Anchor navigation still works without it.

view details

Daniel Clark

commit sha 199862905e262e5a054e92ee3078a1fc1a871882

Clarify reference to listbox in light dismiss definition

view details

push time in 15 days

Pull request review commentWICG/open-ui

Create section defining 'light dismiss' behavior of `<select>` listbox part

 and is therefore considered to be invalid. - The currently selected `<option>`, or the first if one isn't selected, should be   visible within the listbox. This may require moving the list to accomodate listbox positioning   and available space.-- The user can dismiss the listbox and remove the state of `open` from the `<select>` in any of the+- The user can dismiss the listbox and remove the state of `open` from the `<select>` in either of the   following manners:-  - The user clicks outside of the listbox-  - Presses the escape key-  - Selects one, or more (if `multiple` is true), by clicking or hitting `enter` or `space` key+  - Triggering any of the listbox's <a href="#light-dismiss">light dismiss</a> behaviors+  - Selecting one, or more (if `multiple` is true), options by clicking or hitting the `enter` or `space` key++### Light dismiss <a class="link" href="#light-dismiss" id="light-dismiss"></a>+The listbox part has "light dismiss", behavior, defined as being dismissed (removing+the `open` state of the `<select>`, in this case) by either of the following things:+- The user presses the escape key.+- Focus moves outside of the subtree of the element with <a href="#light-dismiss">light dismiss</a>

The attempted meaning was that "the element" refers to "the element that has the property of being light-dismiss" aka the listbox, but this just makes things murkier so I'll just say "listbox".

dandclark

comment created time in 15 days

Pull request review commentWICG/open-ui

Create section defining 'light dismiss' behavior of `<select>` listbox part

 and is therefore considered to be invalid. - The currently selected `<option>`, or the first if one isn't selected, should be   visible within the listbox. This may require moving the list to accomodate listbox positioning   and available space.-- The user can dismiss the listbox and remove the state of `open` from the `<select>` in any of the+- The user can dismiss the listbox and remove the state of `open` from the `<select>` in either of the   following manners:-  - The user clicks outside of the listbox-  - Presses the escape key-  - Selects one, or more (if `multiple` is true), by clicking or hitting `enter` or `space` key+  - Triggering any of the listbox's <a href="#light-dismiss">light dismiss</a> behaviors+  - Selecting one, or more (if `multiple` is true), options by clicking or hitting the `enter` or `space` key++### Light dismiss <a class="link" href="#light-dismiss" id="light-dismiss"></a>

That link is actually not visible on the page (since it's empty); it's just there to be a target for # anchor navigation. The The image link to the left of the header text is apparently generated by the build, with aria-label="Anchor" included: image

However it turns out that I don't actually need that empty link at all. The <h3> gets the right ID if I remove it, so anchor navigation to the section still works correctly.

image

dandclark

comment created time in 15 days

issue commentMicrosoftEdge/MSEdgeExplainers

Feature detection / fallback path?

I edited the above comment, should be !window.hasOwnProperty("HTMLRangeElement")

frehner

comment created time in 15 days

issue commentMicrosoftEdge/MSEdgeExplainers

Feature detection / fallback path?

Thanks for raising the issue!

For controls where we end up introducing new HTMLElement types, e.g. <range> for <input type="range">, feature detection could check whether the new element exists:

if (!window.hasOwnProperty("HTMLInputElement")) { /* apply polyfill/fallback */ }

If we choose not to introduce new element types for things like custom <select>, one idea that comes to mind is checking attachShadow, which currently throws for controls like <select> but will not do so with this proposal:

function hasCustomSelectFeature() {
  try {
    document.createElement("select").attachShadow({mode: "open"});
    return true;
  } catch (e) {
    return false;
  }
}
frehner

comment created time in 15 days

pull request commenttc39/proposal-import-conditions

Change `if` keyword to `assert`

Should the proposal be renamed as well, to "import assertions"?

I think so, and @littledan also pointed out that the [[Conditions]] field should probably also be renamed. I filed #87 and I will make these changes if there are no objections.

dandclark

comment created time in 15 days

issue openedtc39/proposal-import-conditions

Consider more name change fallout from 'if' --> 'assert' rename

#80 changed the keyword from if to assert. There are two other name changes to consider as follow-ups:

  • Rename the proposal from "Import Conditions" to "Import Assertions"
  • Rename ModuleRecord's [[Conditions]] fields to [[Assertions]]

Thoughts/objections/any other changes we're missing?

created time in 15 days

issue commentWICG/open-ui

Make <select> change to closed state when focus leaves listbox

That would be roughly the same thing as focusout. The problem is that for both blur and focusout, when something non-focusable is clicked, there's no way to tell what non-focusable element was clicked, because the event.relatedTarget is always null and the document.activeElement always goes to the body. So we can't easily distinguish whether the click was inside or outside of the listbox.

I'm not sure yet what platform primitive I would propose here. Introducing light dismiss into the platform more formally through a <dialog>/<popup> element would perhaps be enough, and that's something that's being worked on.

Other ideas could be to include the target of the click on the Event object, or establish some context where focus doesn't always fall back to the <body> but can fall back to some specified ancestor element if a non-focusable descendant is clicked.

dandclark

comment created time in 15 days

pull request commentWICG/open-ui

Create section defining 'light dismiss' behavior of `<select>` listbox part

cc @melanierichards

dandclark

comment created time in 15 days

PR opened WICG/open-ui

Reviewers
Create section defining 'light dismiss' behavior of `<select>` listbox part

Create a new section to define "light dismiss" behavior for the <select> listbox part, and reference the new section from the Open State Section.

Ideally we would describe this behavior in terms of a blur or focusout event, but it turns out that both of these are not adequate for the task; see #137. To achieve this behavior today would require a combination of multiple JS events to prevent the listbox from collapsing when non-focusable content inside the listbox is clicked. In the future we could consider fleshing out the light dismiss section to clearly specify this combination, or reference a new platform primitive if one is introduced to make this easier.

+12 -4

0 comment

1 changed file

pr created time in 15 days

create barnchdandclark/open-ui

branch : dandclark/select-lightdismiss

created branch time in 15 days

issue commentWICG/open-ui

Make <select> change to closed state when focus leaves listbox

Thanks to both of you, I agree with this approach. I'll create a PR to refactor the "light dismiss" behavior into its own section that we can either iterate on eventually change to reference the popup documentation when it's ready.

dandclark

comment created time in 15 days

issue openedWICG/open-ui

Make <select> change to closed state when focus leaves listbox

Today I set out to make what I thought would be a simple improvement: update the <select> anatomy such that the listbox part has a blur event handler that switches the open state to false. This achieves the classic <select> behavior where clicking outside the listbox (or anything else that causes focus to jump elsewhere on the page) causes it the listbox to be collapsed.

It turns out that blur doesn't quite work; it doesn't bubble, so when focus goes from an option in the listbox to something else, the listbox won't get the event. Note: the listbox itself normally isn't focusable, only its contents.

An better alternative is focusout. This one fires when anything in the subtree of the element loses focus. This is a bit too noisy by default, since it will fire when focus switches from one <option> to another, but we can scope it thusly (relatedTarget for focusout is the element that is receiving focus):

if (!event.relatedTarget || // event.relatedTarget is null if something non-focusable was clicked and focus is going back to the <body>
    !listbox.contains(event.relatedTarget)) { // Close the <select> if the focus target isn't in the listbox's subtree.
// set <select> `open` state to false
}

This mostly works except for the case when something non-focusable is clicked inside the listbox. In the context of focusout this is indistinguishable from when something non-focusable is clicked outside the listbox (relatedTarget == null either way). So, it will cause the <select> to close, which seems wrong. Non-focusable things would include <optgroup> headers and dividers like the one in Bootstrap buttons (the spacer between Option Three and Option 4):

image

For the native <select>, clicking an <optgroup> caption does not cause the <select> to close in at least Chrome/Edge/Firefox. This matches my expectation. With Bootstrap buttons, clicking the divider actually does cause it to collapse, which is not what I would expect and might actually be due to the implementation difficulties that I'm outlining.

So, how to denote this behavior in the <select> anatomy? I was hoping that we could continue to express behavior in terms of JS event handlers, but I'm not sure that is possible here without invoking hacks such as using e.g. mouseover/mouseout or watching click event bubbling in the listbox to alter the behavior of the focusout handler somehow such that it won't trigger a close for clicks inside the popup.

Thoughts? @gregwhitworth @melanierichards Native light-dismiss for the listbox popup should make all this "just work", but there is still the question of how to describe this behavior in the <select> anatomy tables if this is not straightforwardly possible to implement in terms of JS events.

Or maybe it's fine to just collapse the <select> when something non-focusable inside the listbox is clicked. It doesn't seem to be a blocker for Bootstrap.

Or maybe (hopefully) I'm missing a more straightforward way to achieve this behavior. :)

created time in 16 days

push eventdandclark/open-ui

Dan Clark

commit sha 085530f759b6494690a199f7d72db4142cec770c

Fix build break from wrong param passed to <ConceptCoverage> (#88) * Remove openUIName causing build breaks for concept only present in semantic * Add back the openUIName, fix in concepts.js by passing uniqueName instead of openUIName

view details

Nicholas Rice

commit sha 1a1dc08b7cc258eb55d530bb5999171416665aef

Research: adds checkbox draft proposal (#54) * adds bootstrap and material checkbox names * adding checkbox research to atlassian * adding checkbox research to bootstrap * adds initial proposal work * add anatomy * adding propsoal page * add indeterminate state * aligning to template

view details

pompomon

commit sha 34ed4a65f1e30d5ccd9ef7af96e71004cb80b0d6

Add datepicker draft

view details

Greg Whitworth

commit sha 545dab3caec4c65636ac7be03ad4fd8684acb250

Added definitions to contribute (#97) * Made it so that Home shows up at the top of the navigation * Added heading links * Added definitions section * Added anchors and fixed ids * Modified the definition since components have models and states as well, not just controls. * Made slight editorial tweak based on Daniel's feedback

view details

pompomon

commit sha de5e7075fdf05a722f4cee0271a0aace7a3e40c0

Add `firstDayOfWeek` prop

view details

Greg Whitworth

commit sha dc5da9b0fd64e8bd975960bc9bb4d904ec96ba11

Moved the slider to analysis section and removed Editor's Draft from signal

view details

Greg Whitworth

commit sha eee306bd7dc34dd98c2fcbef3a90a38b80b6662f

Make anchors apply to heading levels 1-4 (#101) * Moved the select content into a folder * Made it so that the anchor is applied to h1-h4 headers for ease of linking

view details

Greg Whitworth

commit sha 93633bbb64cce6e4cd4d077aa917f879e5b2eeda

Create 2020-06-04.md

view details

Greg Whitworth

commit sha 33b23df09fcc417b718cbeaaf30ef5b8ede3a37b

Added minutes from the meeting

view details

Emilio Cobos Álvarez

commit sha 06e3bd66206bc9d9fbfc3029d4966f612eeed606

image: Don't use the non-standard zoom property to shrink images. (#108) Not entirely sure why the change is necessary since most if not all aren't providing numerous sources from what I can tell but it has no impact on the end result so I'll merge it.

view details

Greg Whitworth

commit sha 0feb63d9eef0c1f755b228b3ec5cf803b0a9dd74

Initial recommendations for part events (#103) * Moved the select content into a folder * Made it so that the anchor is applied to h1-h4 headers for ease of linking * Added initial event table * Added events for each part on the select * Added pointer and select event for setting the value in the selected-value slot * Fixed formatting issue * Updated the events based on feedback and investigations * Made changes based on Daniel Clark's feedback * Fixed aria-expanded referencing on the select rather than the button part Co-authored-by: Greg Whitworth <gwhit@microsoft.com>

view details

pompomon

commit sha 3b445435a0cdc122ce6184debfb7c5e523544571

PR comments, removing proposal part

view details

Greg Whitworth

commit sha 3e4b40202ba9b24469ce3d23a95f5dc959cd2206

Updated anatomy with named outer slots (#99) * Updated anatomy with named outer slots. Also fixed a few warnings that ESLint was yelling about * Named the value slot * Updated cutton-container anatomy * Removed slots that are expected in elements of optgroup and option Co-authored-by: Greg Whitworth <gwhit@microsoft.com>

view details

Greg Whitworth

commit sha 9536db9665c60df5da05f2b89dabf5c60b72ee81

Create 2020-06-18.md

view details

Greg Whitworth

commit sha e4d9892aea169e8ca9f49e1c121f87b3311c3e7e

Update 2020-06-18.md

view details

Greg Whitworth

commit sha 35c05d137dfa9b6e2ea1f3692a37961da9ced73a

Create 2020-07-02.md

view details

Greg Whitworth

commit sha 2dd25af299df361985f7e0c125be5738be4bbfab

Added in the minutes

view details

Greg Whitworth

commit sha d03c98ffa1e5572d5613cfcfb1162b7dd1749754

Update 2020-07-02.md

view details

Greg Whitworth

commit sha ec0224c52d39eab9f2efe31424111460031ed678

Merge branch 'research/Datepicker' of https://github.com/pompomon/open-ui into pompomon-research/Datepicker

view details

Greg Whitworth

commit sha 884a1dcf7149879b3e68266dd93f86eb91e0a370

Added menu category, removed Editor's draft from name, and removed path to proposal

view details

push time in 16 days

push eventMicrosoftEdge/MSEdgeExplainers

Dan Clark

commit sha 61ad6cfe1a659a5b939d50bfab2a94041d7f8d8b

Introduce Custom Control UI Explainer (#357) Introduce Custom Control UI Explainer

view details

push time in 16 days

pull request commentMicrosoftEdge/MSEdgeExplainers

Introduce Custom Control UI Explainer

Note to reviewers: I'm going to go ahead and complete this. It's the same document you've already reviewed; the only thing new here are the links from the README and the New Issue Template.

Happy to address any feedback in a follow-up change.

dandclark

comment created time in 16 days

push eventdandclark/MSEdgeExplainers

Daniel Clark

commit sha fd2173e6a22972e6dd2c6cf00a84b27daff4ce72

Make new issue_template match New Issue link.

view details

push time in 16 days

issue commenttc39/proposal-import-conditions

Should we allow string literal as key in condition entries?

That would move things further along the object-literal-like spectrum if that's what we want to optimize for.

@littledan You'd stated above that you were not in favor of allowing NumericLiterals, thoughts?

I don't see a really solid reason for/against any of these, but NumericLiteral key names just seem odd to me, especially for 'check' conditions. I'm having trouble thinking of a use case where a host would ever use one as a key name for a check. I guess the argument might be that syntactically it should be allowed for consistency's sake, even if they probably wouldn't be used in practice?

However unlike both StringLiterals and IdentifierNames, NumericLiterals are not currently allowed in any other parts of import statements.

JLHwung

comment created time in 19 days

pull request commenttc39/proposal-import-conditions

Allow condition keys to be StringLiterals in addition to IdentifierNames

Oh, I misunderstood. Let's discuss in #78.

dandclark

comment created time in 19 days

pull request commenttc39/proposal-import-conditions

Allow condition keys to be StringLiterals in addition to IdentifierNames

Just use LiteralPropertyName.

LiteralPropertyName also includes NumericLiteral, and I don't think anyone's been advocating to allow those at this point (looking at #78).

dandclark

comment created time in 19 days

issue commenttc39/proposal-import-conditions

Should we allow string literal as key in condition entries?

I guess someone could be frustrated if they have this:

import("./foo", { if: { "key1": "value1", "key2", "value2", ... } }) // quotes around keys are fine because it actually is an object literal here

And when they copy/paste to a static import, it's a syntax error:

import "./foo" if { "key1": "value1", "key2", "value2", ... }; // error: unexpected token '"', or something

And then they have to strip the quotes around the keys to make it work.

On the other hand it might be preferable to start with the more restrictive version (only allow IdentifierNames) and only open it up to StringLiterals if this becomes a problem in practice. In any case we're not going to reach complete parity with object literals as long as we're still disallowing NumericLiterals, expressions, etc, so allowing StringLiterals just puts us further in this strange middleground.

There are good points on both sides of this issue, I could really go either way on whether we should take #84.

JLHwung

comment created time in 19 days

create barnchdandclark/MSEdgeExplainers

branch : main

created branch time in 19 days

push eventtc39/proposal-import-conditions

Dan Clark

commit sha 36b99eb34171dfa8d3d335814eb732665d2088e5

Make name match for recursive calls to IfClauseToConditions (#83) Fix invocations of `IfClauseToConditions` that were using the wrong name.

view details

Daniel Clark

commit sha 51278ed54333f7f8226ca4f8d903fc3ea97e7137

Switch keyword from `if` to `assert` in README and spec.

view details

Daniel Clark

commit sha d1c5f89b3929a2b9b722755a8fe753bc32862d88

Add 'no LineTerminator here' before AssertClauses

view details

push time in 20 days

push eventtc39/proposal-import-conditions

Dan Clark

commit sha 36b99eb34171dfa8d3d335814eb732665d2088e5

Make name match for recursive calls to IfClauseToConditions (#83) Fix invocations of `IfClauseToConditions` that were using the wrong name.

view details

Daniel Clark

commit sha c38a33558104150634847482c51cdb958b0503ab

Allow condition keys to be StringLiterals as well as IdentifierNames

view details

push time in 20 days

push eventtc39/proposal-import-conditions

Dan Clark

commit sha 36b99eb34171dfa8d3d335814eb732665d2088e5

Make name match for recursive calls to IfClauseToConditions (#83) Fix invocations of `IfClauseToConditions` that were using the wrong name.

view details

push time in 20 days

delete branch tc39/proposal-import-conditions

delete branch : dandclark/fix-IfClauseToConditions-naming

delete time in 20 days

PR merged tc39/proposal-import-conditions

Reviewers
Make name match for recursive calls to IfClauseToConditions

Fix IfClauseToConditions's recursive invocations that used the wrong name.

+4 -4

0 comment

1 changed file

dandclark

pr closed time in 20 days

PR opened tc39/proposal-import-conditions

Reviewers
Allow condition keys to be StringLiterals in addition to IdentifierNames

Condition keys are currently limited to being IdentifierNames. This change additionally allows them to be string literals (' or ") , so that the condition entries list can be written a bit more like an object literal.

Numeric literals are still not permitted.

It's not yet certain that we want to go this route, so this won't be merged until we reach some conclusion regarding the discussion in #78.

Closes #78.

+22 -8

0 comment

1 changed file

pr created time in 20 days

push eventtc39/proposal-import-conditions

Daniel Clark

commit sha e916cf51a52286fe08b7f3c8b4d7fee89637b11b

Fix a couple other instances with the wrong name

view details

push time in 20 days

PR opened tc39/proposal-import-conditions

Reviewers
Make name match for recursive calls to IfClauseToConditions

Fix IfClauseToConditions's recursive invocations that used the wrong name.

+2 -2

0 comment

1 changed file

pr created time in 20 days

issue commenttc39/proposal-import-conditions

Should we allow string literal as key in condition entries?

@littledan I'll prep that PR.

JLHwung

comment created time in 20 days

Pull request review commenttc39/proposal-import-conditions

Change `if` keyword to `assert`

 <h1>Syntax</h1>     ImportDeclaration :       `import` ImportClause FromClause `;`       `import` ModuleSpecifier `;`-      <ins>`import` ImportClause FromClause IfClause `;`</ins>-      <ins>`import` ModuleSpecifier IfClause `;`</ins>-      <ins>`export` ExportFromClause FromClause IfClause `;`</ins>+      <ins>`import` ImportClause FromClause [no LineTerminator here] AssertClause `;`</ins>+      <ins>`import` ModuleSpecifier [no LineTerminator here] AssertClause `;`</ins>+      <ins>`export` ExportFromClause FromClause [no LineTerminator here] AssertClause `;`</ins>

Resolved in #81, and rebased.

dandclark

comment created time in 20 days

push eventtc39/proposal-import-conditions

Daniel Clark

commit sha b087414f14d0fe2c60b981d13f258c6a4c7eaaaf

Move export syntax with IfClause to ExportDeclaration

view details

Daniel Clark

commit sha ee4515ad15e10b3ed0b3f6ca58f244872a40ff66

Add JSON module example to Synopsis, and reorder Proposed Syntax section so that syntax in this proposal comes before syntax of potential future proposals.

view details

Dan Clark

commit sha 12c0d02a0f97d7ce86acbac760db24d1d1994c08

Merge pull request #82 from tc39/dandclark/make-json-module-example-prominent Make JSON module examples more prominent.

view details

Dan Clark

commit sha 728b8fe2c15dd1e278af05f0976a3985d5c5c6e0

Editorial: Move export syntax with IfClause to ExportDeclaration #81 Pull in the ExportDeclaration syntax, and move the new export syntax with added IfClause into it.

view details

Daniel Clark

commit sha 665a945af1cefe0b3b5ea82adf22543da725600d

Switch keyword from `if` to `assert` in README and spec.

view details

Daniel Clark

commit sha cdab9d51155239bb01e0dbb759f73767a0b21eaa

Add 'no LineTerminator here' before AssertClauses

view details

push time in 20 days

delete branch tc39/proposal-import-conditions

delete branch : dandclark/add-ExportDeclaration

delete time in 20 days

push eventtc39/proposal-import-conditions

Daniel Clark

commit sha b087414f14d0fe2c60b981d13f258c6a4c7eaaaf

Move export syntax with IfClause to ExportDeclaration

view details

Dan Clark

commit sha 728b8fe2c15dd1e278af05f0976a3985d5c5c6e0

Editorial: Move export syntax with IfClause to ExportDeclaration #81 Pull in the ExportDeclaration syntax, and move the new export syntax with added IfClause into it.

view details

push time in 20 days

PR merged tc39/proposal-import-conditions

Editorial: Move export syntax with IfClause to ExportDeclaration

Pull in the ExportDeclaration syntax, and move the new export syntax with added IfClause into it.

+9 -0

0 comment

1 changed file

dandclark

pr closed time in 20 days

push eventtc39/proposal-import-conditions

Daniel Clark

commit sha ee4515ad15e10b3ed0b3f6ca58f244872a40ff66

Add JSON module example to Synopsis, and reorder Proposed Syntax section so that syntax in this proposal comes before syntax of potential future proposals.

view details

Dan Clark

commit sha 12c0d02a0f97d7ce86acbac760db24d1d1994c08

Merge pull request #82 from tc39/dandclark/make-json-module-example-prominent Make JSON module examples more prominent.

view details

push time in 20 days

delete branch tc39/proposal-import-conditions

delete branch : dandclark/make-json-module-example-prominent

delete time in 20 days

PR merged tc39/proposal-import-conditions

Reviewers
Make JSON module examples more prominent.

Add JSON module example to Synopsis so someone skimming the proposal will immediately see how it's used. Reorder Proposed Syntax section so that the syntax we're proposing in this document comes before syntax of potential future proposals.

Closes #79 .

+15 -9

0 comment

1 changed file

dandclark

pr closed time in 20 days

more