async clipboard read and race conditions
Checking to see if Anupam can join to discuss...
whsieh: the behavior is basically checking (in Windows) the sequence number
… apple has a similar principle. If the data contents changed between binding the requested content and the read, we will throw.
johanneswilm: is this going to result in unexpected errors?
whsieh: there are lots of cases where errors can be thrown (in general).
… So, I'm not sure this is a problem.
… E.g., if the user decides to cancel out of a paste operation, that is also an error.
… so perhaps this can be one of them?
should reading the clipboard throw DataError or empty clipboard items?
(reads the issue)
whsieh_: this is the situation where there IS data on the clipboard, but none of it can be consumed by the webpage...?
… seems weird to throw a DataError in the case where there is nothing in the clipboard/pasteboard...
… in that case, returning an empty list.
travis: I like just returning an empty list too--easy for web authors to handle with erroring out...
whsieh_: In the specific example that snianu (Anupam) gave, I'm not sure if the error is OK.
… probably can't resolve on this at this time without further discussion with snianu.
johanneswilm: can the JS Editors differentiate between the different error conditions?
… could the user re-request? E.g., if the user didn't grant permission?
whsieh_: recap; there are cases where a website might want to know whether they can try again, or whether they shouldn't try again.
… empty list vs throw error could be a way to differentiate.
johanneswilm: there are two other cases...
… one where the user didn't give access, and one where the clipboard is changed after access is granted.
whsieh_: in the first case, Safari throws "NotAllowed" (from the user denying paste).
… in the case where it changed, we also throw an error; but the type of error may not make sense...
… could look at changing it?
(no resolution yet)
johanneswilm: We've invited folks who are working on this to come and present to us in a month!
… if folks would like to follow along, please checkout the links in the issue.
johanneswilm: we talked about this last time.
… I think Microsoft wanted to get more info before continuing...
… alex; is there anything you found?
Anupam: Hi folks, just joined.
… looks like we still need to discuss with Office. We will have to follow up before next meeting.
declarative mechanism to enable overlay content?
snianu: mutliple issues here
… overlayContent was set on VK (in JS) via the navigator object...
… from TAG review, they requested an env variable for inset (for geometrychanged event), then these CSS variables can be used to understand occluded content.
… there was some addition concern--if we have CSS env variables, then why set overlayscontent in JS?
… perhaps there should just be some HTML declarative thing?
… (that's the recap)
… was a suggestion to never resize the visual viewport (on overlays content set)
… (today on Windows we change both layout & visual viewport)
… then the overlays content would only control the layout viewport
… (looking up some examples to share to help explain the details)
snianu: I think we can discuss this async...
johanneswilm: Are you seeking input on seeing if making the suggested (or some other proposal)?
… or are you asking for agreement on the suggested syntax?
… not sure if Safari is planning to implemented overlayscontent, and if so, what the behavior should be?
… should it adjust layout + visual viewport.
… currently only chromium supports.
travis: whenson, do you have any feedback on the declarative mechanism?
whsieh_: The behavior would apply to any element that is a focusable target for the keyboard to appear?
… should the behavior "descend" into other elements? e.g., with iframe?
snianu: currently we're excluding iframes.
whsieh_: My intuition (for like messanger) might be useful in the main chat box... but in search field is may not be as appropriate (or in some other view).
snianu: ex: on dual-screen examples, you can split screen into two. On one screen you have a search element. Current behavior: keyboard covers both screens.
… with overlayscontent flag it doesn't affect the layout of the whole page, just the element in question.
… that was the original scenario that inspired the flag.
… ex: in messager, w/ VK, you might want to adjust just the textbox and not the entire layout.
whsieh_: for a meta tag, does the web engine need to respect dynamic changes?
… for declarative mechanism they may need an attribute on an element.
… whsieh_ the flag on the navigator... object already offers this flexibility.
… stepping back, I'm curious what the declarative mechanism (on the meta tag) would offer?
… if we did add a declarative, I would be more in support of an attribute (i.e., like inputmode or similar)
Travis: I don't like meta tag for cases where the state will dynanically change (meta is usually for set-and-forget states), which this doesn't seem like it's really static...?
johanneswilm: there's a gathering of editor folks.
… would love to get participation and have discussion/feedback from folks on this call
… looking at Megan, Wenson, Travis?
… and sorry, my email didn't have an subject line... (check your spam box)
Megan: at CSS meeting yesterday, Highlight API L2 was brought up.
… Highlight API is a way to specify certain limited styles.
… L2 is about interacting with these (e.g., would fire events for clicks on these) how to handle two highlights.
… CSS trying to figure out where this should live?
… they wondered if maybe they could bring it up for Editing WG to take on for incubation?
Travis: is L2 considered an incubation?
johanneswilm: In the beginning, Highlight API started here, then went to CSS later...
… would love to have someone come back to this group in the fall (after folks back from holidays), and present to the group; discuss whether this WG is a good fit to continue some of the more interactive parts.
Megan: full disclosure: I'm one of the editors on the spec.
johanneswilm: Super! Then you would be able to present.
Travis: that sounds good.